为什么在线重建一个主键聚集索引在占用几乎等于未触及的非聚集索引大小的空间。
细节：
- 我们有一个索引大小为 7GB 的主键聚集索引（bigint 类型）的表。
- 我们在同一个表（varchar(36) 类型）上有另一个非聚集过滤索引，索引大小接近 1.5TB。
- 主键聚集索引的在线重建消耗了将近 1.6TB 的事务日志大小。用于重建的选项 - (DATA_COMPRESSION = PAGE, ONLINE = ON, SORT_IN_TEMPDB = ON)
- 另一个观察结果是，之前的索引是在没有压缩的情况下创建的，不确定这是否是导致如此巨大增长的原因。
- 有人可以透露一些内部信息吗？
聚集索引就是表。它包括所有列。聚集索引（基本上）不可能小于任何一个非聚集索引。当您读取 7GB 大小时，您可能只查看了聚集键列大小或仅查看非叶级别。
因此，如果您重建聚集索引，那么您将重建所有列 - 包括压缩设置。最后重建聚集索引将数据复制到新位置，完成后，它会从旧位置删除数据。
如果您在 2017 年，您可以进行可恢复索引重建，这允许您暂停重建，清空日志，然后再次恢复重建。
REBUILD 是一个原子事务操作，因此这是意料之中的。如果您要取消，则需要回滚记录的信息。
一种可能的替代方法是设置一个打开压缩的复制表，然后分批复制行 - 当然，您仍然会占用数据文件中的额外空间。完成后，您可以使用 sp_rename 更改复制表的名称