如果不是，那么从数据库中删除如此大量的数据后，应该采取哪些适当的步骤来清理房子？我可以想到两个：重建索引和更新统计信息。还有什么？
#1 楼
绝对不建议进行重组和收缩。如果您可以脱机使用正在数据库服务的应用程序，则可以通过删除所有索引和主键/外键来加快此过程并减少索引碎片收缩之前的约束（这意味着要移动的数据较少，因为仅数据页将被改组，而不是现在不存在的索引页被改组，这加快了处理速度），然后重新创建所有索引和键。
在收缩之后重新创建索引意味着不应将它们显着分散，而在收缩过程中将其移走则意味着对其进行重建不会在文件分配的页面分配中留下很多小的“漏洞”，而这些孔可能会在以后引起碎片。
如果可以使应用程序脱机，另一个选择是将所有数据迁移到具有相同结构的新数据库中。如果您的构建过程是可靠的，那么您应该能够快速构建该空白数据库，如果不从当前数据库创建一个空白数据库（还原当前数据库的备份，则截断/删除表中的所有内容并执行完全收缩）。
您可能仍希望将所有索引放到目标中，然后再重新创建它们，因为在更改许多索引数据（在这种情况下为100％）时，效率会更高。为了加快复制过程，请将目标数据库的数据文件放在不同的物理驱动器上，再到源（除非您使用的是SSD，在这种情况下您无需担心减少磁头移动），可以移动它们
此外，如果将目的地创建为新目的地（而不是通过空白地复制来源副本），则以初始大小创建目的地，该大小将包含所有当前数据以及需要几个月的增长-这将使数据复制更快一点，因为在整个过程中不会一次又一次分配新空间。
这可能比使用收缩更好，因为将数据迁移到新的数据库可以复制收缩操作的预期操作，但可能会产生更少的碎片（这是重组和收缩的意外结果）。收缩只是从文件末尾获取块，然后将其放在靠近开始处的第一个空间中，而不用努力将相关数据保持在一起。也可能会减少部分使用的页面。收缩只会移动部分使用的页面，移动数据更有可能导致整页，特别是如果您按照表的集群键/索引（表有一个）的顺序插入目标并创建其他索引数据全部迁移之后。取决于您的数据，访问模式，通用工作集大小，服务器有多少RAM等，最终额外的内部碎片可能并不那么重要。
对于复制操作，无论是SSIS还是基本的T-SQL都可以正常工作（SSIS选项的效率可能较低，但以后可能更易于维护）。如果您在末尾随索引一起创建FK关系，则在两种情况下都可以执行简单的“对于每个表复制”。当然，一次性进行收缩+重组可能也不错，但我只是想吓people人们不要考虑定期收缩！ （我知道人们每天都会安排它们。）
#2 楼
数据库会再次增长吗？如果是这样，那么您要进行收缩操作的工作将只是浪费，因为当您减小文件大小然后添加更多数据时，文件将不得不再次增大，交易必须等待这种增长发生。如果您的自动增长设置不够理想和/或驱动器速度较慢，那么这种增长活动将非常痛苦。磁盘空间用于？同样，如果您要保持该空间自由以防该数据库再次增长，那么您就在旋转轮子。现在，您已经在文件中拥有所有可用空间，现在您可以考虑做的是重建索引，以便更好地优化索引（这样做时的痛苦将大大减轻）您有这样做的自由空间-考虑尝试在小衣柜和大卧室里换一件毛衣）。
因此，除非这是一个主要的清理操作，并且您真的不会再次提升到相同级别的数据，否则我将把它保持不变，并专注于其他优化领域。 br />
#3 楼
晚点回到这条路。尽管如此，我们也一直在思考和测试在我们的测试环境中使用缩小方法。根据主题，有时收缩是一个可行的选择。但是知道何时以及如何应用它对于长期和短期的正确执行至关重要。归档和简单删除冗余数据。结果，我们的主数据文件的使用部分已减少到不到以前的一半。但是携带所有行李的目的是什么？特别是由于与网络上的某些文章相反，数据文件的大小与备份/恢复时间直接相关。这是因为与许多文章所假定的不同，现实生活中的场景在任何给定页面上加载的数据都不仅仅是您已删除的内容。创建一个脚本，该脚本将查找数据库中的所有对象及其文件组（大量在线示例），使用此脚本创建drop子句以及为每个对象创建定义索引和约束。
创建一个新的文件和文件组，并使其成为默认文件。
丢弃所有非聚集索引（注意，某些索引可能是约束）。具有DROP_EXISTING = ON的文件组（顺便说一句，与许多替代方法相比，这是一个非常快速且最少记录的操作）。 ）。
这样，剩下的唯一数据将是数据库的系统对象，统计信息，过程以及诸如此类的东西。收缩应该很大，而且速度要快得多，并且不需要对主数据对象进行任何进一步的索引维护，这些索引将被整齐地创建，从而将将来发生碎片的风险降至最低。
#4 楼
如果空间不足，并且数据本不该变大，那么请收缩，但是请在使用适当的填充因子后重建索引，以实现典型的增长。实际上要减小备份大小，请确保您实施了全面的备份策略以清除事务日志，并且在备份数据库时，请使用compress选项。创建完整数据库备份SQL Server）
事务日志备份（SQL Server）
我不建议自动增长5GB，除非您通常希望经常增长5GB。否则，您可能会遇到间歇性的性能问题。首先，应将数据大小设置为您认为一年所需的大小，然后将“自动增长”设置为已测试的大小，这不会影响操作性能。请参见不要触摸SQL Server中的缩小数据库按钮！作者：Mike Walsh。
在缩小索引之前重建索引会导致索引布局不正确。重建然后收缩是不好的。收缩会导致索引被破坏以恢复空间-因此事先重建然后收缩是没有意义的。请参阅何时使用Thomas LaRock的“自动收缩”。
评论
如果缩小然后重建索引，则数据文件将不得不再次增长以容纳用于重建的数据副本。虽然在这种情况下，它不会像原始数据文件那样大，但它仍会增长，并且似乎适得其反。在有可用空间的情况下进行重建会更快（不需要自动增长），并且通常仍比您建议的要好得多，因为它如何安排索引的新副本的页面布局，而且我怀疑在大多数情况下，总体而言会更短并导致相同或更好的磁盘空间恢复。也许是时候进行一些测试了。
–亚伦·伯特兰（Aaron Bertrand）
2012年5月1日晚上11:38
当然，这是假设保留的数据上的索引实际上将需要重建-也许它们已经处于良好状态。
–亚伦·伯特兰（Aaron Bertrand）
2012年5月1日，11：40
评论
@Aarron Bertrand好了，花了10年的时间才使它变大，而磁盘却有点令人担忧，因为我想将其置于固态。我当时正在考虑将5gb的自提压缩到60gb。真的，您唯一推荐的方法是重建索引，对吧？我以为人们会有更多建议。
–bumble_bee_tuna
2012年5月1日下午2:09
而且，我只建议他们在需要时进行重建。但是我会在缩小文件之前这样做。我真的想不出什么可以在一般情况下提供性能优化的可用空间...
–亚伦·伯特兰（Aaron Bertrand）
2012年5月1日，2：10