为什么我不定期运行“索引重组”？

Question

到目前为止，我尝试了多次索引重组查询。它们看起来像这样：

ALTER INDEX ALL ON TableName REORGANIZE

这样的查询可能需要几个小时，但它看起来不会干扰其他数据库操作。对于某些表，它的影响几乎为零，但对于某些表，它实际上节省了 15% 的整体数据库空间。

如果我每周左右对所有索引运行此查询会怎样？有什么理由不这样做吗？

Answer 1

当您的索引中的空白量增加（即sys.dm_db_index_physical_stats DMV 中的avg_page_space_used_in_percent列）时，应该重新组织索引。SQL Server 社区中的许多人（甚至解决方案）说您需要查看索引碎片级别（例如在同一个 DMV 中），但这取决于底层存储的类型（例如任何 RAIDed无论如何，出于冗余目的将您的数据分段）。其他人也得出了同样的结论。avg_fragmentation_in_percent

在不需要时重新组织索引的缺点是此操作将清除部分缓存，因此它可以有足够的空间在内存中执行重组。重组对缓存的破坏性不如重建操作，但它们会降低页面预期寿命 (PLE) 并可能清除您必须从磁盘重新读取的有用数据（例如增加的 I/O 操作）。此外，重组操作不会更新索引统计信息。更新统计比碎片整理索引更能产生最佳执行计划，因此如果您打算无意识地每晚运行一次操作，我会说更新统计是比重组实例更好的选择。

正确的答案是让解决方案在需要时检查您的空白阈值和重组/重建索引。让另一个进程检查您的统计数据并在需要时进行更新。有一些解决方案，例如Ola 的维护解决方案、Minionware 的 Reindex解决方案等。但我经常发现自己定制解决方案以满足我的需求。