Answers:
由于这里提到的原因，收缩确实很危险。Jimbo的答案和John的答案之间有一个快乐的中介...您应该始终认真考虑是否要收缩数据库。
在理想的世界中-您将创建具有足够的可用空间来成长的数据库。我称此为“正确调整大小”您的数据库。您会允许该可用空间存在，而不会努力将其退还，并使总大小保持在您使用的大小上。因为您的数据库最终将再次增长..然后您将再次收缩..而且，您将陷入这种无用的收缩，然后增长的可怕模式中-整个过程，正如一些人指出的那样，增加索引碎片。
我已经在博客上写了一篇文章，劝告人们“ 不要触摸缩小按钮！ ”，但有时……有时您需要这样做。如果您有一个大型数据库，只需释放大量空间并且不希望再回到原来的空间中-那么，只要您可以在以后通过重建来解决索引碎片问题，可以考虑将收缩操作视为一次性操作他们。收缩操作可能很耗时，因此您需要计划一个可以支付收缩运行价格的时间。创建空数据库并将数据复制到其中的方法是可行的-但是对于较大的数据库和大量数据而言，这将变得非常困难。
如果您打算通过将来的正常使用和增长模式将空间添加回数据库，那么您可能只想保留该空间。
也
您说您“清除”了交易日志。我很想知道您是如何做到的，但是当您阅读我分享的帖子以及本系列的其他文章时，您会看到有关事务日志管理的一些技巧。但简而言之-如果您处于“完全恢复”模式，则应该定期备份日志，以保持日志重用。否则-在完全模式下没有日志备份-日志文件会不断增长，并且会一直保存您所做的事情，因为您告诉SQL您不只是要维护该日志以进行崩溃恢复，而是希望保留对其进行手动备份以重播事务/撤消事务以恢复到特定的时间点以进行恢复...如果您很简单并且看到日志增长过多，BEGIN TRAN ... do work.... COMMIT TRAN或者您是否只是发布了一条大DELETE语句并在一次隐式事务中删除了整堆数据。）
我还假设您正在文件系统上寻找此可用空间。如果要在SQL和大型文件中寻找它，则可能是在等待操作后立即进行幽灵清理工作。Paul Randal关于Ghost Cleanup的博客。
删除数据库中的行不会减小实际数据库文件的大小。
行删除后，您需要压缩数据库。
SQL Server 2005 DBCC SHRINKDATABASE（Transact-SQL）
运行此命令后，您将要重建索引。缩小通常会导致索引碎片，这可能会导致巨大的性能成本。
我还建议缩小后，重新增长文件，以便有一些可用空间。这样，当新的行进入时，它们不会触发自动增长。自动增长会降低性能，这是您希望避免的（通过适当的数据库大小调整）。
不要收缩您的数据库！
“为什么会发生这种情况？数据文件收缩操作一次只能处理一个文件，并使用GAM位图（请参阅存储引擎内部：GAM，SGAM，PFS和其他分配图）来查找分配给在上面的例子中，它完全颠倒了聚集索引的顺序，从完全碎片整理到完全碎片化。 ”
http://www.sqlskills.com/BLOGS/PAUL/post/Why-you-should-not-shrink-your-data-files.aspx
“看一下收缩数据库的讽刺意味。一个人收缩数据库以获取空间（认为这将有助于提高性能），这会导致碎片增加（降低性能）。要减少碎片，一个重建索引会导致碎片的大小。数据库的增加幅度要大于原始数据库的大小（收缩之前）。通过收缩，人们通常无法获得所需的东西。”
删除数据时，SQL Server保留其空间供以后用于插入新数据。您需要缩小数据库。您可以在此处找到更多信息。
我发现此问题是因为我的数据库已“最大化”，所以我刚刚删除了一堆备份表。我一直在查看“大小”属性，以为为什么它没有变小？。读完这篇文章后，不，我不想缩小数据库。我想要做的是“回收”刚刚删除的垃圾的空间。我需要看的是“可用空间”。我在想，也许这也是其他人也需要考虑的问题。？*