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