存储过程比直接执行SQL慢大概率是参数嗅探导致执行计划失配；SQL Server缓存首次执行的计划，后续参数差异大会复用低效计划，而手动执行会重生成计划。
存储过程比直接执行SQL慢，大概率是参数嗅探（Parameter Sniffing）导致的执行计划失配，不是语句本身写得差。
为什么存储过程执行慢而单独跑SQL快
SQL Server 为存储过程缓存第一次执行时生成的查询计划，这个计划基于当时传入的参数值“嗅探”而来。如果后续传入的参数分布差异大（比如一个查10行，一个查百万行），复用旧计划就可能选错索引、误判行数、走全表扫描——但你把SQL拿出来手动执行时，SQL Server 按当前变量值重新生成计划，所以快。
常见错误现象包括：
- 同一存储过程，不同参数下耗时从毫秒级跳到分钟级
- 在 SSMS 里用
EXEC proc_name 'a'很慢，但把语句粘出来改成WHERE col = 'a'就秒出 - 刚重建存储过程或清空缓存后变快，过一阵又慢回来
WITH RECOMPILE 是最直接的开关，但别乱加
WITH RECOMPILE 强制每次调用都丢弃旧计划、重新编译整个存储过程。它能立刻解决参数嗅探，但代价明显：CPU 开销上升，尤其高并发场景下可能成为瓶颈。
使用场景和注意事项：
- 仅适用于执行频次低（比如每天几次）、且参数差异极大（如报表类、后台批处理）的存储过程
- 加在
CREATE PROCEDURE或ALTER PROCEDURE语句末尾，如：ALTER PROCEDURE sp_get_orders @cust_id INT WITH RECOMPILE AS ... - 不能加在
EXEC调用时临时生效（EXEC sp WITH RECOMPILE是合法语法，但只影响本次调用，且不解决长期缓存问题） - 对含大量逻辑、多语句的存储过程，整过程重编译开销远高于单语句重编译
更推荐用 OPTION (RECOMPILE) 精准控制
比起整过程重编译，OPTION (RECOMPILE) 只作用于某一条 SELECT/UPDATE/DELETE 语句，既规避参数嗅探，又保留其他语句的缓存收益。
典型写法：
SELECT * FROM Orders WHERE CustomerID = @cust_id OPTION (RECOMPILE);
关键点：
- 它让优化器把
@cust_id当作已知常量处理，能精准估算行数、选择索引查找而非扫描 - 适合 WHERE 条件敏感、数据分布倾斜严重的查询（比如用户ID查订单 vs 管理员查全部）
- 不建议滥用在高频小查询上，否则 CPU 压力会集中在编译阶段
- 与
WITH RECOMPILE不同，它不阻止过程其余部分使用缓存计划
OPTIMIZE FOR UNKNOWN 更适合高频稳定场景
当存储过程每秒调用多次，且多数参数下性能可接受，只是个别极端值拖慢整体——这时 OPTION (OPTIMIZE FOR UNKNOWN) 是更稳的选择。
它告诉优化器：“别看这次的参数值，按统计直方图的平均分布来估算”，生成一个中庸但稳定的执行计划。
示例：
SELECT * FROM Sales WHERE ProductID = @pid OPTION (OPTIMIZE FOR UNKNOWN);
注意：
- 它不会每次都重编译，计划被缓存并复用，因此 CPU 开销低
- 如果数据严重倾斜（比如99%的查询查前10个ID，1%查末尾ID），该计划可能对那1%极不友好
- 无法像
OPTION (RECOMPILE)那样利用运行时参数做精确优化
真正容易被忽略的是：参数嗅探不是孤立问题，它常和统计信息陈旧、缺少索引、JOIN 写法不当（比如用 LEFT JOIN 替代 NOT EXISTS）耦合出现。先确认是纯参数嗅探，再选方案；否则加了 RECOMPILE 也救不回一个本就低效的执行路径。
