IN_ROW_DATA 与 LOB DATA 对索引重建有何影响

Question

我正在使用 Ola Hallengren 的脚本来维护我的数据库。其中一些指标似乎没有从维护中受益。我知道他的脚本有一个较低的门槛（我相信 1000 页），低于这个门槛它不会尝试重建或重组。

对于一个索引，在 dm_db_index_physical_stats 中，聚集索引显示在 2 行上。一种是PK_DATA，分配单元类型IN_ROW_DATA，16页，93.75%碎片化。其他PK数据，LOB_DATA的分配单元类型，57200页，0%碎片化。

我应该期望这个索引被重新组织还是由于不同分配单元类型的不同页数而被跳过？或者它可能会重组失败？

预先感谢您的任何建议。

Answer 1

在 Ola Hallengren 的脚本中，他使用MAX碎片并仅考虑IN_ROW_DATA分配单元类型。请参阅他的脚本摘录：

ALTER PROCEDURE [dbo].[IndexOptimize]
-- ...
-- Is the index fragmented?
-- ...
-- Note his use of the following below:
---- @ParamFragmentationLevel = MAX(avg_fragmentation_in_percent)
---- WHERE alloc_unit_type_desc = ''IN_ROW_DATA''
  SET @CurrentCommand05 = @CurrentCommand05 + 'SELECT @ParamFragmentationLevel = MAX(avg_fragmentation_in_percent), @ParamPageCount = SUM(page_count) FROM sys.dm_db_index_physical_stats(@ParamDatabaseID, @ParamObjectID, @ParamIndexID, @ParamPartitionNumber, ''LIMITED'') WHERE alloc_unit_type_desc = ''IN_ROW_DATA'' AND index_level = 0'

如果不进一步深入了解脚本的确切逻辑，索引似乎不会被重组，因为页数低于最小值 1000。

• Github 脚本
• 链接到上面的脚本行