ALTER INDEX REORGANIZE - 问题

Question

我有几个表的索引高度碎片化（超过 90% 碎片化）并且大小足够大（数十 GB）
对这些表进行碎片整理的目标是减少上述表的空间消耗

我想避免执行 REBUILD 操作，因为它太资源密集
还试图避免记录到事务日志和日志增长，以及大事务日志备份大小作为结果

这就是为什么选择 REORGANIZE 操作而不是 REBUILD 来处理高碎片化
关于 REORGANIZE，有以下问题：

1. 如果同时在单独的索引上运行多个 REORGANIZE 操作（比如 10+，在单独的 SSMS 窗口/会话中） - 是否会导致数据损坏或任何其他已知问题？

2. REORGANIZE 操作是否以任何方式/根本没有记录到事务日志中？

3. REORGANIZE 持有什么样的锁？哪些查询会受到影响？

Answer 1

如果同时在单独的索引上运行多个 REORGANIZE 操作（比如 10+，在单独的 SSMS 窗口/会话中） - 是否会导致数据损坏或任何其他已知问题？

不，不会。关于任何其他问题 AFAIK，如果您的 SQL Server 已修补到最新的 SP 和 CU，您应该非常安全。

REORGANIZE 操作是否以任何方式/根本没有记录到事务日志中？

是的，它们实际上已记录在所有恢复模型中。引自SQLskills.com

在所有恢复模式中，重新组织索引都是完全记录的，但作为一系列小事务执行，因此不应导致事务日志过度增长。当然，事务日志只为执行的操作生成，对于重组来说可能更少，因为它只处理存在的碎片。

REORGANIZE 持有什么样的锁？哪些查询会受到影响？

再次引用上面分享的 Paul Randals 博客

索引重组在整个操作过程中持有一个意向排他表锁，它只会阻塞共享、排他和模式修改表锁。我为 SQL Server 2000 编写 DBCC INDEXDEFRAG 的主要原因之一是作为 DBCC DBREINDEX 的在线替代品。

还试图避免记录到事务日志和日志增长，以及因此导致的大事务日志备份大小

请注意，如上所述，索引重组是完全记录的，因此会生成日志，但由于 SQL 引擎一次在一个数据库页面上工作，因此日志增长不会广泛膨胀，并且会受到控制。