3

我在 SQL Server 2005 中有一个大表，占用了大约 3.5 GB 的空间（根据 sp_spaceused）。它有 1000 万条记录和多个索引。

我只是从中删除了一堆列，这样记录长度就减少了一半，令我惊讶的是，它花了零时间来做到这一点。显然，sp_spaceused 仍然报告相同的占用空间，SQL 服务器在删除列时并没有真正做任何事情，除了将它们标记为“已删除”。

所以我把这个表中的所有数据移到另一个新表中，截断它，然后把所有数据移回来，这样它就会全部重建。

现在，在那之后，数据占用了 2.8 GB，比以前少了，但我预计会有更大的下降。

该表最初具有这些列的事实是否可能仍然存在？

截断它还不够吗？我应该删除它并使用较小的列集再次创建它吗？

还是数据真的需要 2.8 GB？

谢谢！

4

2 回答 2

4

您将需要重建聚集索引（假设您有一个 - 默认情况下，您的主键是聚集键）。

ALTER INDEX (your clustered index) ON TABLE (your table) REBUILD

数据实际上是聚集索引的叶级——一旦你重建它，它将被“压缩”并且行应该存储在更少的数据页上，也减少了你的数据库大小。

如果这根本没有帮助，您可能还需要在数据库上运行 DBCC SHRINKDATABASE 以真正回收空间。这两个步骤一起应该真正为您提供一些较小的数据库文件！

马克

于 2009-06-05T20:52:29.600 回答
2

你是如何计算“预计会有更大的跌幅”的？请注意，数据以 8K 页的形式出现，这意味着即使单个行较小，也并不总是意味着您需要更少的页来存储它们。例如（一个极端的例子），如果您的行曾经是每行 7.5K，那么每页只能容纳一行。您删除了一些列，您的行是 5K，但仍然是每页一行。

于 2009-06-05T20:08:57.363 回答