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

Question

我一直试图收集有关重建和重新组织索引的信息。在堆栈溢出页面(在server中索引应该多久重新构建一次？)中，我得到了以下查询：

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 <1,000，则重建后不从统一范围分配页面，但如果索引是大的，则从通知范围分配页面。由于页面被分配的程度参差不齐，分散的可能性增加。但这种分裂不会产生任何负面影响。

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

我已经在文章为什么我的索引在重建后仍然是零碎的中详细说明了这一点。