Parameter sniffing导致执行计划变慢，因SQL Server基于首次参数值生成缓存计划；确认需比对EstimateRows与实际行数偏差；缓解可用OPTION(RECOMPILE)、本地变量赋值或查询存储；同时须更新统计信息并处理索引碎片。
存储过程执行计划突然变慢，大概率不是代码改了，而是执行计划“记错了”——Parameter sniffing 在作祟。SQL Server 2022 默认仍启用该机制，它会基于**首次调用时传入的参数值**生成并缓存执行计划；若该参数值极特殊（比如返回 1 行 vs 返回 50 万行），后续哪怕传入完全不同的参数，SQL Server 也照搬这个“偏科”的计划，性能断崖式下跌。
怎么确认是 Parameter sniffing 导致的？
别猜，直接比对执行计划和实际运行行为：
- 用
sys.dm_exec_query_stats+sys.dm_exec_sql_text找出该存储过程最近几次执行的plan_handle和last_execution_time - 用
sys.dm_exec_query_plan(plan_handle)提取各次执行的 XML 计划，重点看<RelOp>节点里的EstimateRows和实际扫描/查找行数是否严重偏离（比如预估 1 行，实际读 40 万页） - 手动执行一次：先
EXEC your_proc @param = '典型值'，再EXEC your_proc @param = '边缘值'，观察两次的total_elapsed_time差异是否达数量级
绕过或缓解 Parameter sniffing 的实操方式
不是所有场景都适合禁用 sniffing，得按需选：
- 临时救急：在存储过程开头加
OPTION (RECOMPILE)—— 每次都重编译，代价是 CPU 上升，但能立刻见效；仅建议用于执行频次低、逻辑关键的存储过程 - 稳定折中：把参数赋值给本地变量再参与查询，例如
DECLARE @local_param INT = @input_param，之后 WHERE 条件用@local_param；SQL Server 对本地变量不 sniff，会走更通用的计划 - SQL Server 2022+ 可启用查询存储自动捕获计划回归：确保
QUERY_STORE开启，并设置OPERATION_MODE = READ_WRITE，它能自动识别性能骤降的计划并建议强制使用历史好计划
别忽略统计信息和索引碎片的连锁影响
Parameter sniffing 是导火索，但底层往往是统计信息过期或索引碎片高导致计划选择失准：
-
UPDATE STATISTICS必须定期跑，尤其在大批量数据导入/删除后；2022 默认的自动更新阈值（20%+500 行变化）对大表太宽松，可手动触发UPDATE STATISTICS table_name WITH FULLSCAN - 检查碎片：用
sys.dm_db_index_physical_stats查avg_fragmentation_in_percent > 30的索引；碎片超 30% 建议REBUILD，5–30% 可REORGANIZE - 注意：重建索引会自动更新统计信息，但
REORGANIZE不会，后者之后得补一手UPDATE STATISTICS
真正难缠的，是 sniffing 和统计信息老化叠加出现——第一次执行用了过期统计信息生成的劣质计划，缓存住后，后续所有调用都被拖累。这类问题不会报错，只默默变慢，查起来得同时盯住计划缓存、统计信息时间和索引健康度三个维度。
