重建索引能降低i/o开销，因其修复高碎片导致的物理存储不连续，减少逻辑读和数据页扫描量，提升范围查询与join效率。

为什么重建索引能降低存储过程的I/O开销

SQL Server 存储过程中频繁扫描大表时，如果索引碎片率高（比如 avg_fragmentation_in_percent > 30），页分裂和逻辑读会显著增加。物理存储不连续 → SQL Server 要读更多数据页 → 缓冲池压力变大 → READS 和 logical reads 暴涨。这不是查询写法问题，而是底层数据布局退化导致的硬伤。

• 碎片率 > 5% 就该监控，> 30% 建议重建（不是重组织）
• 重建索引会释放空闲空间、合并页、重排B树，让范围扫描更紧凑
• 对于经常被存储过程用于 JOIN 或 WHERE 条件的列，其索引质量直接影响执行计划是否选对索引

如何安全重建存储过程依赖的索引

别在业务高峰直接跑 ALTER INDEX ... REBUILD —— 它会锁表（除非加 ONLINE = ON 且企业版）。重点看存储过程实际用到哪些索引：

• 先查执行计划：在 SSMS 中右键存储过程 → “显示估计的执行计划”，找 Index Seek / Index Scan 节点，记下 Index Name
• 再查碎片：运行 sys.dm_db_index_physical_stats，过滤出对应表和索引名
• 重建命令示例：

  ALTER INDEX [IX_Order_CustomerID] ON [dbo].[Orders] 
  REBUILD WITH (FILLFACTOR = 85, ONLINE = ON);

• FILLFACTOR = 85 预留空间减少后续页分裂；ONLINE = ON 需要企业版，否则改用 OFFLINE 并安排维护窗口

重建后存储过程没变快？检查这三个地方

索引重建只是前提，不是万能解药：

• 存储过程里用了 SELECT * 或隐式转换（比如把 varchar 参数传给 nvarchar 列），会导致索引失效 → 执行计划里出现 CONVERT_IMPLICIT 就是信号
• 统计信息过期：重建索引不会自动更新统计信息（除非加 STATISTICS_NORECOMPUTE = OFF），得手动跑 UPDATE STATISTICS 或等自动更新触发
• 参数嗅探导致缓存了低效计划：同一个存储过程，不同参数值走不同路径。用 WITH RECOMPILE 或 OPTIMIZE FOR 临时缓解，长期需拆分逻辑或用局部变量绕过

什么时候不该重建索引

盲目重建反而拖慢性能：

• 表数据量
• 索引列是 GUID 且用 NEWID() 生成：重建后下次插入又快速碎片化，应改用 NEWSEQUENTIALID() 或整型代理键
• 存储过程本身逻辑有严重缺陷：比如在循环里反复调用 SELECT（N+1 问题），此时优化索引收益远小于改写逻辑

重建索引是手术刀，不是创可贴。真正卡住存储过程的，常常是那条没走索引的 JOIN，或是缓存里那个已经失效的执行计划。