索引重建与碎片优化需依查询模式、数据变更频率及碎片程度综合判断，不可盲目执行；应先分析avg_fragmentation_in_percent和avg_page_space_used_in_percent，结合索引使用率、表大小、约束依赖及高可用环境限制决策，并在操作后验证效果。
索引重建和碎片优化不是“定期执行就万事大吉”的操作，而是要结合实际查询模式、数据变更频率和碎片程度来判断是否需要、何时需要、如何执行。盲目重建可能加重I/O压力，不加分析地只看碎片率也可能误判。
先看碎片，再决定是否处理
SQL Server中，索引碎片分为内部碎片（页内空闲空间多）和外部碎片（逻辑顺序与物理顺序不一致）。关键指标是avg_fragmentation_in_percent（外部碎片）和avg_page_space_used_in_percent（内部填充度）。
- 碎片率
- 碎片率 5%–30%：建议REORGANIZE（在线、低开销、不释放空间但整理页顺序）
- 碎片率 > 30%：考虑REBUILD（离线或在线、重建整个B树、重设填充因子、释放空间）
重建 vs 重组：别只看碎片率
即使碎片率高，也要看表的使用场景：
- 读多写少、且有大量范围扫描的索引：高外部碎片影响明显，优先考虑REORGANIZE或REBUILD
- 高频插入/更新的小表：可能内部碎片更关键——avg_page_space_used_in_percent过低（如FILLFACTOR更有效
- 含LOB列（text、varchar(max)、xml等）的索引：REORGANIZE不移动LOB数据，REBUILD才能真正整理；若LOB分散严重，仅看常规碎片率会低估实际问题
自动化维护要带“判断逻辑”，不能硬编码阈值
用脚本自动维护时，避免写死“碎片>30%就REBUILD”。推荐加入以下判断：
- 检查该索引是否被查询计划高频引用（可通过sys.dm_db_index_usage_stats看user_seeks/scans）
- 确认表大小：小于1000页的索引，碎片影响极小，重建收益几乎为零
- 识别是否为唯一聚集索引或主键约束依赖的索引——REBUILD可能触发约束验证，需评估业务窗口
- 对Always On可用组中的数据库，REBUILD需注意是否启用ONLINE = ON及是否满足版本限制（如SQL Server 2016 SP2+才支持部分场景下的在线主键重建）
重建后别忘了验证效果
执行完REBUILD或REORGANIZE，不能只看命令成功就结束：
- 再次运行sys.dm_db_index_physical_stats，对比前后avg_fragmentation_in_percent和page_count变化
- 观察关键查询的执行计划是否仍走该索引、预估行数是否更准确（避免因统计信息未更新导致优化器误判）
- 检查sys.dm_db_index_operational_stats中leaf_insert_count、leaf_delete_count等，确认维护后写入效率是否改善
- 留意tempdb使用量激增（尤其大索引REBUILD默认排序在tempdb），避免维护期间引发其他阻塞
