MS-SQL：重建与重新创建的空间开销答案

【问题标题】：MS-SQL: Space overhead for rebuild vs. recreateMS-SQL：重建与重新创建的空间开销
【发布时间】：2018-11-05 08:41:52
【问题描述】：

我们需要每年从一个巨大的表中删除一次旧数据。表的行相当紧凑（大约 40 字节），表上只有一个聚集索引。

数据库总共大约 750 GB，处理的表大小为 640 GB，在清理之前包含 87 亿行。删除后，只剩下 37 亿行，数据大小降至 500 GB 左右。

这些数字看起来很奇怪，但它们很好：每个页面都删除了一些行。一些页面被清空和丢弃，一些没有改变，仍然 100% 满，但现在大部分页面都被部分填满了，每个页面上都有很多无人认领的空间。

要回收这个空间，我需要重建索引。我的问题是：如何对数据库中与索引本身大小差不多的索引进行碎片整理？

如果我没记错的话，INDEX DEFRAG REBUILD 需要的可用空间是其工作大小的 1.3 倍，因为它以排序方式复制数据。数据库将增长近 1 TB，碎片整理完成后将不再需要这个新空间。

在碎片整理后收缩并没有帮助，因为它会引入新的（大量）碎片。

我知道“SORT_IN_TEMPDB”设置。是否估计此设置需要多少数据库中的可用空间？

作为替代方案，我可以删除并重新创建聚集索引，但我不确定该操作的空间要求是什么。

重新组织索引不会回收每个页面上的空间（？），所以这个操作也不是我想要的。

感谢您的任何想法！拉尔夫

【问题讨论】：

【解决方案1】：

我们需要每年从一个巨大的表中删除一次旧数据。

这正是分区的用例。每年分区，删除子表，完成。停机时间？如果你做得聪明，毫秒。

【讨论】：

谢谢 - 但是...我遗漏了一些关键信息，使得分区很难处理这种情况。该数据库是一个时间序列存储，但完全版本化。这意味着，每个数据点都有 2 个时间戳：该值所在的日期，以及当日知道的最新值的起始日期范围。清理意味着删除不再范围内的数据（业务）和删除数据历史记录（纯技术）。您的集群键需要考虑“旧”数据的两个方面。
提出的问题是：重建与重建的空间开销。答案根本不包含有关重建/重组操作的空间要求的信息。