存储过程性能取决于编写、使用与维护方式，核心考察执行计划、参数嗅探、统计信息、事务设计等底层机制；需警惕执行计划固化、隐式转换、表变量误用、长事务锁阻塞及统计信息过期等问题。
存储过程本身不直接决定性能好坏，关键看怎么写、怎么用、怎么维护。面试中常被问到“为什么存储过程变慢了”“如何优化”，其实是在考察你对执行计划、参数嗅探、统计信息、事务设计等底层机制的理解，而不是背诵几个调优口诀。
执行计划固化与参数嗅探是高频坑点
SQL Server在首次执行存储过程时生成执行计划并缓存，后续调用默认复用该计划。如果首次传入的参数导致优化器选择了低效的索引（比如查了大量数据却用了非选择性索引），后续即使传入高选择性参数，仍可能沿用错误计划。
- 用 OPTION (RECOMPILE) 强制每次重编译——适合参数差异大、执行频率不高的场景
- 用 OPTIMIZE FOR (@p = value) 提示优化器按典型值生成计划
- 避免在 WHERE 中对字段做函数操作（如 WHERE YEAR(OrderDate) = 2023），会跳过索引
- 检查实际执行计划中的“警告”图标（黄色感叹号），常见于隐式转换或缺失统计信息
临时表 vs 表变量：别只看语法，要看数据量和使用模式
表变量（@table）无统计信息、不参与并行、适合小数据（通常＜100行）；临时表（#temp）有统计信息、可建索引、支持重编译，适合中大型中间结果。
- 若在存储过程中多次 JOIN 表变量，且数据量上升后性能断崖下跌，大概率是优化器误估了行数
- 对临时表及时加索引（尤其在 INSERT 后、JOIN 前），比依赖聚集索引更有效
- 避免在循环内反复创建/删除临时表——改用 TRUNCATE + 重用，减少编译开销
事务范围与锁行为直接影响并发能力
存储过程里一个长事务不仅拖慢自己，还会阻塞其他会话。面试官喜欢问“更新10万行卡住了，怎么定位”，本质是考你是否关注事务粒度和锁升级。
- 把 BEGIN TRAN 尽量靠近实际修改语句，而非包裹整个逻辑流程
- 用 XACT_ABORT ON 确保出错时自动回滚，避免悬挂事务
- 批量更新用 TOP + WHILE 循环分批提交（如每次5000行），降低单次锁持有时间
- 查询时加 WITH (NOLOCK) 要谨慎——仅限允许脏读的报表类场景，业务核心流程禁用
统计信息过期和索引碎片是沉默杀手
即使SQL写得再规范，底层数据分布变了、索引页分裂严重，执行计划也会逐渐劣化。这往往不是代码问题，而是运维盲区。
- 检查统计信息更新时间：SELECT name, auto_created, modified_count, rows, rows_sampled FROM sys.dm_db_stats_properties(OBJECT_ID('Orders'), STATS_ID)
- 对高频更新的大表，考虑开启 AUTO_UPDATE_STATISTICS_ASYNC，避免查询被阻塞
- 重建索引（ALTER INDEX ... REBUILD）比重组（REORGANIZE）更彻底，但需更多空间和时间
- 定期用 sp_BlitzIndex（Brent Ozar工具包）扫描低效索引和缺失索引建议
