何时重建以及何时重组索引

Question

我一直在尝试收集有关重建和重组索引的信息。从stackoverflow页面（How Often should the indexes be re-build in sql-server 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

  

问题在于，当我重建索引时，avg_fragmentation_in_percent增加而不是减少。任何指针？如果这是正常的行为，那么我在这里失踪了什么？

如果索引很小，这是正常行为。如果在没有从统一范围分配重建页面之后索引具有page_cont＆lt; 1000但是如果索引是大页面将从通知范围分配。由于页面是从混合范围分配的，因此碎片化的可能性增加。但这种分裂不会产生任何副作用。

当从混合范围分配页面时，可以将它们分配给任何特定的IAM链，这意味着它可以保存分配给可能8个单独IAM的页面。因此，它们可以分散在任何地方，从而导致逻辑上的分裂。

我在文章Why is my index still fragmanted after rebuild

中有更详细的解释