重建索引能降低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临时缓解，长期需拆分逻辑或用局部变量绕过
什么时候不该重建索引
盲目重建反而拖慢性能：
- 表数据量 < 1000 行：B树深度太浅，碎片影响几乎为零
- 索引列是
GUID且用NEWID()生成：重建后下次插入又快速碎片化，应改用NEWSEQUENTIALID()或整型代理键 - 存储过程本身逻辑有严重缺陷：比如在循环里反复调用
SELECT（N+1 问题），此时优化索引收益远小于改写逻辑
重建索引是手术刀，不是创可贴。真正卡住存储过程的，常常是那条没走索引的 JOIN，或是缓存里那个已经失效的执行计划。
