何时重新生成和何时重新组织索引

Question

我一直试图收集有关重建和重新组织索引的信息。从堆栈溢出页面(应该多久在sql服务器DB中重新构建索引？)我有这样的疑问：

SELECT 
    t.NAME 'Table name',
    i.NAME 'Index name',
    ips.index_type_desc,
    ips.alloc_unit_type_desc,
    ips.index_depth,
    ips.index_level,
    ips.avg_fragmentation_in_percent,
    ips.fragment_count,
    ips.avg_fragment_size_in_pages,
    ips.page_count,
    ips.avg_page_space_used_in_percent,
    ips.record_count,
    ips.ghost_record_count,
    ips.Version_ghost_record_count,
    ips.min_record_size_in_bytes,
    ips.max_record_size_in_bytes,
    ips.avg_record_size_in_bytes,
    ips.forwarded_record_count
FROM 
    sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'DETAILED') ips
INNER JOIN  
    sys.tables t ON ips.OBJECT_ID = t.Object_ID
INNER JOIN  
    sys.indexes i ON ips.index_id = i.index_id AND ips.OBJECT_ID = i.object_id
WHERE
    AVG_FRAGMENTATION_IN_PERCENT > 0.0  
ORDER BY
    AVG_FRAGMENTATION_IN_PERCENT, fragment_count

问题是，当我重建索引时，avg_fragmentation_in_percent增加而不是减少。有什么建议吗？？如果这是正常行为，那我在这里遗漏了什么？？

以前，avg_fragmentation_in_percent是30，在重建后，它已经增加到66。

Answer 1

按照遵循的实践，您可以在碎片>30 %时重建索引，在碎片在10 %至30 %之间时可以重新组织索引。您还应该在查询中包含page_count值。如果page_count值(在DMV sys.dm_db_index_physical_stats中有) <1000，则不需要重新构建或重新组织这些索引，即使它们显示出很大的碎片。我曾见过，当重建的指数碎片增加时，有时会出现这样的指数，但这无关紧要。

在您的例子中，page_count是3，所以绝对不需要重建或重新组织索引。

我还希望看到您的完整重建脚本--很有可能您使用了较少的填充因子值来重建索引，这将导致重建后的页面数增加，从而增加碎片。

下面是来自Microsoft的Bob写的一篇文章，他实际上指出，由于在索引重建期间使用MAXDOP设置会导致碎片的增加，我确信它不适用于您的环境，但请看一看：链接。

请使用下面的查询，然后查找需要重建的索引：

select
    ips.index_type_desc,
    ips.index_depth,
    ips.index_level,
    ips.avg_fragmentation_in_percent,
    ips.fragment_count,
    ips.page_count,
    ips.avg_page_space_used_in_percent,
    ips.record_count
FROM 
    sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'DETAILED') ips
INNER JOIN  
    sys.tables t ON ips.OBJECT_ID = t.Object_ID
INNER JOIN 
    sys.indexes i ON ips.index_id = i.index_id AND ips.OBJECT_ID = i.object_id
WHERE
    AVG_FRAGMENTATION_IN_PERCENT > 0.0 and page_count >1000 
ORDER BY
    AVG_FRAGMENTATION_IN_PERCENT, fragment_count