几乎没有剩余空间了，所以我决定删除2008年的所有数据。执行delete查询（已清理了约一千万行）并清理了事务日志我发现我的操作对数据库大小没有影响。我还有什么需要做的吗？
#1 楼
实际上，由于此处提到的原因，收缩确实很危险。 Jimbo的答案和John的答案之间有一个快乐的中介...您应始终认真考虑是否要缩小数据库。在理想的世界中-您将创建具有足够的可用空间来成长的数据库。我称此为“正确调整大小”您的数据库。您会允许该可用空间存在，而不会努力将其退还，并使总大小保持在您使用的大小上。因为您的数据库最终将再次增长。.然后您将再次收缩..而且，您将陷入这种无用的收缩，然后增长的可怕模式中，并且整个过程（正如一些人指出的那样）增加索引碎片。
我在博客上对此进行了劝告，劝告人们“不要触摸缩小按钮！”但是有时候...有时候你需要。如果您有一个大型数据库，只需释放大量空间并且不希望再回到原来的空间中-那么，只要您可以在以后通过重建来解决索引碎片问题，可以考虑将收缩操作视为一次性操作他们。收缩操作可能很耗时，因此您需要计划一个可以支付收缩运行价格的时间。创建空数据库并将数据复制到其中的方法是可行的-但是对于较大的数据库和大量数据而言，这将变得非常困难。
如果您打算通过常规方式将该空间添加回数据库中未来的使用和增长模式，那么您可能只想留在那里。
也
您说您“清除”了交易日志。我很想知道您是如何做到的，但是当您阅读我分享的帖子以及本系列的其他文章时，您会看到有关事务日志管理的一些技巧。但简而言之-如果您处于“完全恢复”模式，则应该进行定期日志备份，以保持日志自身的重用。否则-在完全模式下没有日志备份-日志文件会不断增长，并且会一直保存您所做的事情，因为您告诉SQL您不只是希望维护该日志以进行崩溃恢复，而且希望保留对其进行手动备份以重播事务/撤消事务以恢复到特定时间点以进行恢复...如果您很简单并且看到日志过度增长，则可能（通常）表明您正在做很多一笔交易中的工作（无论您说的是
BEGIN TRAN ... do work.... COMMIT TRAN还是只发布了一个大的DELETE语句，并在一次隐式交易中删除了整个数据混乱。）我还假设您正在寻找这个文件系统上的可用空间。如果要在SQL和大型文件中寻找它，则可能是在等待操作后立即进行幽灵清理工作。 Paul Randal关于Ghost Cleanup的博客。
#2 楼
删除数据库中的行不会减少实际的数据库文件大小。删除行后需要压缩数据库。
SQL Server 2005 DBCC SHRINKDATABASE（Transact-SQL）
运行此命令后，您将要重建索引。缩小通常会导致索引碎片，这可能会带来巨大的性能成本。
我还建议缩小之后，重新增长文件，以便有一些可用空间。这样，当出现新行时，它们不会触发自动增长。自动增长会降低性能，这是您希望避免的（通过适当的数据库大小调整）。
#3 楼
请勿收缩您的数据库！“为什么会发生？数据文件收缩操作一次只能在一个文件上进行，并使用GAM位图（请参阅内部存储引擎：GAM，SGAM， PFS和其他分配映射）以找到文件中分配的最高页面，然后将其尽可能移到文件的最前面，依此类推，依此类推，在上述情况下，它完全颠倒了顺序索引，从完全碎片整理到完全碎片化。”
http://www.sqlskills.com/BLOGS/PAUL/post/Why-you-should-not-shrink-your -data-files.aspx
”“看一下收缩数据库的讽刺。一个人收缩数据库以获取空间（认为这将有助于性能），这导致碎片增加（降低性能）。为了减少碎片，一个重建索引会导致数据库的大小增加到比原始数据库的大小更大的程度（收缩之前）。 n他通常要找的东西。“
http://blog.sqlauthority.com/2011/01/19/sql-server-shrinking-database-is-bad-increases-fragmentation-reduces -性能/
评论
您应该将数据移动到新文件组，然后删除旧文件组。这样，您就不会产生碎片，并且可以缩小数据库。
–阿里·拉泽吉（Ali Razeghi）
2012年11月8日19:49