根本原因是参数嗅探：sql server首次执行时基于具体参数生成并缓存执行计划，后续参数分布差异大时复用旧计划导致性能劣化；优先用option (recompile)语句级重编译、option (optimize for unknown)生成通用计划或with recompile过程级重编译，辅以系统视图验证与统计信息更新。
为什么存储过程会突然变慢，而SQL语句本身没改？
根本原因通常是参数嗅探（Parameter Sniffing）：SQL Server在首次执行存储过程时，根据传入的具体参数值生成并缓存一个执行计划；后续调用若参数分布差异大（比如首次传@BeginDate = '2025-02-24'，第二次传@BeginDate = '2020-01-01'），旧计划可能完全不适用——比如该走索引却选了全表扫描，或该走嵌套循环却用了哈希连接。
典型现象是：直接执行SELECT * FROM F WHERE Createtime > '2025-02-24' 1秒完成，但用变量@BeginDate执行同一逻辑却要20+秒；DBCC SHOWPLAN 显示未走索引，且sys.dm_exec_query_stats 中该存储过程的avg_logical_reads 和 avg_elapsed_time 突然飙升。
三种应对方式，按风险和适用场景排序
不要一上来就清空整个计划缓存（DBCC FREEPROCCACHE），那会影响所有查询。优先选择粒度更细、副作用更小的方案：
-
加
OPTION (RECOMPILE)：仅对卡顿的语句级重编译，每次执行都生成新计划。适合参数差异极大、数据分布不均的场景（如时间范围跨度从1天到5年）。缺点是每次执行多一次编译开销，CPU压力略升。 -
加
OPTION (OPTIMIZE FOR UNKNOWN)：让优化器忽略实际参数值，基于统计信息的平均分布生成“通用”计划。适合参数变化频繁但无明显倾斜的场景。比RECOMPILE更轻量，但可能不如后者精准。 -
用
WITH RECOMPILE创建存储过程：整个存储过程每次调用都重编译。适用于逻辑简单、执行频率低、但参数组合极不确定的场景。不推荐用于高频调用的SP，否则CPU易打满。
示例写法：SELECT * FROM F WHERE Createtime > @BeginDate OPTION (RECOMPILE);
验证是否真由计划缓存引起
别靠猜，用系统视图交叉验证：
- 查当前正在跑的慢请求：
SELECT session_id, total_elapsed_time, statement_text FROM sys.dm_exec_requests CROSS APPLY sys.dm_exec_sql_text(sql_handle) WHERE total_elapsed_time > 5000（单位毫秒） - 查历史平均耗时：
SELECT t.text, qs.avg_elapsed_time FROM sys.dm_exec_query_stats qs CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) t WHERE t.text LIKE '%F%' AND qs.avg_elapsed_time > 10000000（单位微秒） - 对比两次执行的
query_plan哈希值是否一致：如果语句相同但哈希不同，说明计划已更新；如果哈希相同但耗时突增，基本锁定是参数嗅探导致旧计划劣化。
容易被忽略的细节
加 OPTION 后仍慢？检查这几个点：
- 变量类型是否与字段类型严格匹配？比如
datetime字段传date变量，隐式转换会废掉索引——确认@BeginDate是datetime而非date或varchar。 - 统计信息是否过期？
UPDATE STATISTICS比重建索引更轻量，尤其对大表，过期统计会让优化器误判行数，导致错误计划。 - 是否存在“计划缓存污染”？比如某次执行因超时被中止，残留的半成品计划可能干扰后续编译。可针对性清除：
DBCC FREEPROCCACHE (@plan_handle)，而非全局清空。
真正棘手的不是加不加 RECOMPILE，而是得判断：这次是临时波动，还是数据分布已永久改变——后者意味着你该重新审视索引设计或分区策略了。
