清除了表中的 100,000 多条记录，但数据库的大小没有减少

Question

我使用的是在 Windows Server 2008 R2 Standard 上运行的 SQL Server 2008 R2 版本。我的数据库大小约为 207MB。由于它在一个表中包含 100 条记录，我决定只保留前 10000 条记录并删除剩余的记录以最小化数据库的大小。

我从数据库中删除了 90000 条记录，并重建了索引：

 DELETE FROM toptrends
 WHERE HandleID NOT IN (SELECT TOP 10000 HandleID
                        FROM toptrends
                        ORDER BY lastmodifieddatetime DESC)
 go

 ALTER INDEX ALL ON TopTrends
 REBUILD WITH (FILLFACTOR = 80, SORT_IN_TEMPDB = ON,
          STATISTICS_NORECOMPUTE = ON);
 GO

并检查了数据库和database_log 文件的大小。该database_log文件的大小尺寸有所增加，但是数据库文件保持不变。我认为它应该减少

• 删除前的文件大小：大约 207892

• 删除后的文件大小：大约 207892（相同）

• database_log 文件的大小 625MB（大约 300MB）

我们不能通过从表中清除不需要的/旧记录并重建索引来减小数据库的大小吗？

ps：database_log清除表后我的文件急剧增加，我不希望它变得太大。

Answer 1

当您面临数据库太大时，无论出于何种原因（增长超出预期、磁盘空间不足、内存中的缓冲池空间不足），您可能想要问几个问题在采取行动之前问问自己：

1. 发生了什么导致数据库过大？
2. 我究竟在哪里看到问题？
3. 我现在可以采取哪些措施来缓解我对空间的紧迫担忧？
4. 我需要采取哪些步骤来防止将来再次发生这种情况？

很多时候，如果人们使用将数据添加到数据库的系统，增长是可以预期的。毕竟，这是数据库的目的。但是，了解根本原因将是长期解决问题的关键，因此提前进行这项工作将节省以后的时间。这可能意味着您需要查看使用 DMV 或其他机制的使用模式。

接下来您要确定的是您在哪里看到了问题。如果您已将数据与日志驱动器分开，您应该能够轻松分辨出您在哪里看到增长。如果它在日志文件中，找出如何更好地解决日志文件增长问题（更频繁的日志文件备份？）。如果是数据库，您的选择会变得更加丰富。如果是临时数据库，请找出导致临时数据库增长的原因。

确定导致数据增长的原因后，您可以采取措施确定如何立即处理问题并长期解决问题。如果您在登录的情况下运行（并且您应该这样做），那么从数据库中删除数据可能是一个非常激烈的步骤。一方面，日志文件会增长，因为它必须在其中保存有关删除的信息，直到您能够备份日志文件。另一方面，正如您所注意到的，当您删除数据时，SQL Server 不会自动调整文件的大小。从长远的角度来看，您可以假设如果数据库在正常使用中最终达到一定大小，它将再次到达那里......因此花时间缩小和增加文件将是浪费。

要立即解决该问题，您可以执行以下操作：

• 如果您绝对确定数据库不会再次增长，则可以缩小数据库。您不会想要这样做，因为数据库可能会再次增长，而且这不是有助于解决实际问题的长期解决方案。
• 如果您没有遇到 CPU 压力，您可以启用页面或行压缩以缩小数据。一般的权衡是，虽然行和页压缩减少了磁盘大小（从而减少了内存使用），但它需要 CPU 周期来压缩。您还需要确保添加到数据库的新对象被压缩。
• 您可以尝试限制输入数据库的数据量。

通过不仅查明原因，而且确定长期行动方案，您将为未来做好更好的准备，甚至可以避免恐慌。