优化存储过程需综合评估执行时间分布（如P95/P99）、执行计划复用率（usecounts）、锁等待与资源争用、端到端延迟及错误率，避免仅依赖平均耗时或索引使用判断效果。
看执行时间变化，但不能只看平均值
执行时间是最直观的指标，但单看 AVG 容易误判。比如一个存储过程优化后平均耗时从 1200ms 降到 800ms，看似提升 33%，但如果 P95 从 2500ms 降到 1800ms、P99 却卡在 4200ms 不动，说明少数参数组合仍触发糟糕执行计划——这恰恰是 SQL Server 参数嗅探没处理好的典型表现。
实操建议：
- 用
sys.dm_exec_procedure_stats查最近 7 天的统计，重点关注total_elapsed_time / execution_count（平均耗时）、max_elapsed_time和cached_time（计划缓存时间） - 对比前后
last_execution_time是否集中，若重构后执行时间分布明显右偏，说明新计划对某些参数不友好 - 避免只测“干净环境”：在生产库低峰期抓取真实调用链路的耗时，包括应用层打点（如 .NET 的
Stopwatch或 Java 的Timer），而非仅在 SSMS 里单独执行
盯住执行计划是否复用，而不是有没有走索引
很多人看到执行计划里出现了预期的索引就以为优化成功，其实更关键的是这个计划能不能被反复复用。SQL Server 对存储过程的执行计划缓存非常敏感，字段增删、统计信息更新、甚至 SET ARITHABORT 开关变化都会导致缓存失效。
实操建议：
- 查
sys.dm_exec_cached_plans+sys.dm_exec_sql_text，确认重构后该存储过程对应的缓存条目usecounts是否稳定增长（理想情况是每次执行都复用，usecounts累加） - 如果
usecounts == 1频繁出现，立刻检查是否用了EXEC(@sql)、是否漏加SET NOCOUNT ON、是否在过程中修改了临时表结构（会强制重编译） - 用
DBCC FREEPROCCACHE清空缓存后首次执行，再立即查sys.dm_exec_query_plan获取 plan_handle，后续对比是否一致
观察锁等待和资源争用是否下降
性能提升不等于更快，有时只是“不卡别人”。比如把原来一个事务里塞 5 个 UPDATE 改成只更新必要字段，执行时间可能只快 10%，但 sys.dm_os_wait_stats 里的 LCK_M_U（更新锁等待）下降 60%，说明并发能力实质改善。
实操建议：
- 重点监控
sys.dm_exec_requests中wait_type和wait_time，尤其关注LCK_*、PAGEIOLATCH_*、ASYNC_NETWORK_IO这三类 - 对比重构前后相同业务时段的
batch requests/sec（来自sys.dm_os_performance_counters），若该值上升而 CPU 使用率未同步飙升，说明吞吐改善真实有效 - 留意
tempdb压力：如果原过程大量用#tmp表且没显式DROP，重构后改用 CTE 或物理表，tempdb的page life expectancy应明显回升
别忽略客户端感知的延迟变化
存储过程跑得再快，如果它被嵌在一个需要串行调用 3 次的 Web API 里，而第三次调用因网络抖动超时，最终用户看到的仍是“慢”。真正的提升必须落到端到端链路。
实操建议：
- 在应用日志里埋点，记录从发起调用到收到结果的完整耗时（含序列化、反序列化、网络传输），对比重构前后该链路的 P95/P99
- 检查是否引入新瓶颈：比如把游标改成集合操作后，单次执行变快，但内存占用翻倍，触发 SQL Server 内存压力，反而让其他查询排队
- 确认错误率是否同步下降：有些“性能提升”其实是掩盖了问题，比如加了
OPTION (RECOMPILE)后耗时降低，但编译频率过高导致SQL Server的compilations/sec指标异常升高，长期可能引发 CPU 尖刺
