bum*_*una 46 sql-server maintenance shrink disk-space
我知道收缩是魔鬼：它会颠倒页面顺序并导致皮肤癌、数据碎片化和全球变暖。名单还在继续……话虽如此，假设我有一个 100 GB 的数据库，我删除了 50 GB 的数据——不是在一个表上，而是在数据库范围内对旧数据进行一般修剪，覆盖 90% 的数据表——这是否构成缩小数据库的适当用例？
如果没有，从数据库中删除如此高比例的数据后，应采取哪些适当的步骤来清理房屋？我可以想到两个：重建索引和更新统计。还有什么？
Aar*_*and 15
数据库会再次增长吗？如果是这样，那么您将投入到收缩操作中的努力将是一种浪费，因为当您减小文件大小然后添加更多数据时，文件将不得不再次增长，并且交易必须等待这种增长发生。如果您的自动增长设置欠佳和/或驱动缓慢，那么这种增长活动将非常痛苦。
如果您确实缩小了数据库，您打算将释放的磁盘空间用于什么？同样，如果您只是要保持该空间空闲，以防此数据库再次增长，那么您只是在转动轮子。
既然您已经在文件中获得了所有这些可用空间，您可能会考虑做的是重建索引，以便更好地优化它们（并且当您有可用空间时，这样做会减少很多痛苦 -考虑尝试在小壁橱和大卧室中更换毛衣）。
因此，除非这是一次重大的清理操作，并且您真的不会再次提升到相同级别的数据，否则我只会保持原样并专注于其他优化领域。
Dav*_*ett 14
从不真正推荐重组和收缩。
如果您可以使数据库服务的应用程序脱机，您可以通过在收缩之前删除所有索引和主/外键约束来加快进程并减少索引碎片（这意味着需要移动的数据更少，因为只有数据页将被改组而不是现在不存在的索引页，从而加快进程）然后重新创建所有索引和键。
在收缩后重新创建索引意味着它们不应该被严重碎片化，并且在收缩期间让它们消失意味着重建它们不会在文件内的页面分配中留下许多可能会在以后引起碎片的小“漏洞”。
如果您可以使应用程序脱机，另一种选择是将所有数据迁移到相同结构的新数据库中。如果您的构建过程可靠，您应该能够快速构建该空白数据库，如果不能从当前数据库创建一个（恢复当前数据库的备份，截断/删除表中的所有内容并执行完全收缩）。
您可能仍然希望删除目标中的所有索引并在之后重新创建它们，因为在更改大量索引数据（在这种情况下为 100%）时，这会更有效率。为了加快复制过程，将不同物理驱动器上的目标数据库的数据文件复制到源（除非您使用的是 SSD，在这种情况下您不需要关心减少头部移动），您可以移动它们完成后到源位置。
此外，如果将目标创建为新的（而不是通过清空源的副本）创建它的初始大小将包含所有当前数据加上几个月的增长 - 这将使数据复制再次快一点它不会在整个过程中时不时地分配新空间。
这可能比使用收缩更好，因为将数据迁移到新数据库会复制收缩操作的预期操作，但碎片可能少得多（这是重组和收缩的意外结果）。收缩只是从文件末尾附近取出块并将它们放在靠近开头的第一个空间中，而无需努力将相关数据保持在一起。
我怀疑结果在空间方面也会更有效，因为之后可能会减少部分使用的页面。收缩只会移动部分使用的页面，移动数据更有可能导致完整页面，特别是如果您按照表的聚集键/索引（表有一个）的顺序插入目标并创建其他索引数据全部迁移后。
当然，如果您根本无法将应用程序脱机，那么仅执行收缩是您唯一的选择，因此如果您真的需要回收空间，请使用它。根据您的数据、访问模式、通用工作集大小、服务器有多少 RAM 等等，额外的内部碎片最终可能并不那么重要。
对于复制操作，SSIS 或基本 T-SQL 都可以正常工作（SSIS 选项可能效率较低，但以后可能更容易维护）。如果您在最后创建 FK 关系以及索引，您可以在任何一种情况下执行简单的“对于每个表，复制”。当然，对于一次性的，收缩+重组可能也很好，但我只是想吓唬人们不要考虑定期收缩！（我知道人们每天都安排他们）。