sys.dm_db_index_physical_stats 非常慢

Question

我有一个大约 4.5TB 的数据库，因为我们在一个表（按月分区）上并行插入（以减少每日加载时间），该表上的聚集索引往往会出现严重碎片。当我在这张表上从 sys.dm_db_index_physical_stats (Limited) 中进行选择时，它需要很长时间（> 4-5 小时）。有没有更快更好的方法来检查这个表的分区上的碎片级别，这花费的当前时间是完全不可接受的。

Answer 1

不要为整个数据库运行 DMV，而是为特定的表或索引运行它。由于数据库规模庞大，因此势必需要时间。

您必须阅读Paul Randal关于此 DMV 为何需要更多时间的解释。

DMV 的想法是显示索引的物理属性（以及堆的特殊情况） - 为此，它必须扫描包含索引的页面，并在执行过程中计算统计信息。许多 DMV 支持所谓的谓词下推，这意味着如果您指定 WHERE 子句，DMV 在准备信息时会考虑到这一点。这个 DMV 没有。如果你只要求数据库中逻辑碎片 > 30% 的索引，它会扫描所有索引，然后告诉你那些符合你标准的索引。它必须这样做，因为在分析它们之前，它无法知道哪些符合您的标准——因此不能支持谓词下推。

您是否尝试过用于索引重建的Ola Hallengren解决方案。

正如他的文章中提到的，您可以尝试多种模式。但正如你所说的，有限也需要 4-5 个小时，我想这就是 DMV。它实际上很慢，甚至 MS 也相信它。

索引重建被视为维护活动，应该在服务器上的负载相对较少或在维护窗口期间完成。