因此，我们正在使用一些数据库，这是一个非常大的问题。出于某种原因，人们的数据库已经发展成一个荒谬的文件大小而没有对表格数据进行任何改变。虽然我不知道是什么原因引起了这种情况，但我现在更关心清理其使用的磁盘空间。我运行sp_spaceused并跟踪主要罪魁祸首到2个表中的一个（取决于数据库）。对于每个数据库，其中一个表将超过半GB分配给保留空间，而数据只有50 MB。它表明index_size位于~113 MB。该表没有聚簇索引，并且有大约15列，所有列都相对较小，除了2列类型为nvarchar且长度为255的列（表中通常为null或空）。
我尝试过运行DBCC shrinkdatabase和truncate table但它没有做任何事情。我对此进行了一些研究，其他一些人遇到了这个问题，但如果shrinkdatabase没有修复它，那么也找不到解决方案。
如果您需要了解有关表格或数据库设置的其他信息，请告诉我。我不知道还有什么可以尝试，这对我们来说是一个重大问题，因为人们的数据库突然占用了之前空间的10倍。
编辑： 尝试运行DBCC DBREINDEX并尝试通过企业管理器更改为聚簇索引后，我收到一条错误消息：
无法为数据库'DB'分配新页面。文件组PRIMARY中没有更多页面可用。可以通过删除对象，添加其他文件或允许文件增长来创建空间。
我也试过从这个表中删除行，它对表的大小没有影响。正如预期的那样，日志文件会增加，但这是对表大小的唯一更改。
答案 0 :(得分：2)
这些是堆（没有聚簇索引）？为什么？
如果用户进行了大量更新或删除，我会尝试重建表格。 Shrinkdatabase不是这样做的方法。它不会修复碎片，删除未恢复的空间或更改列的宽度，也不会浪费作为转发指针的行。我敢打赌，通过重建和/或聚集索引，表格会更好。在SQL Server 2000中，您可以通过以下任一方式执行此操作：
（a）添加聚集索引。 （我无法为您提供添加聚簇索引（或更改现有索引或要聚集的非聚集主键）的确切语法，因为我没有足够的有关您的表的信息。）
（b）DBCC DBREINDEX（'dbo.tablename'）;
这将重建堆上的非聚集索引，但根据浪费空间的发生位置，这可能对您没有好处。我仍然建议你创建一个聚簇索引。如果您可以共享有关表的一些详细信息（例如，存在的索引，通常运行的查询类型，当前如何唯一标识行以及数据更改/添加到此表的性质），我们可能会提供更多详细的建议。