参数嗅探导致执行计划波动，因不同参数值使优化器选择失当；应通过局部变量、计划指南、拆分查询、更新统计信息等策略提升计划稳定性。
SQL报表执行计划波动，通常不是因为SQL写得不好，而是参数化查询在不同参数值下触发了不同的执行计划——这叫“参数嗅探”（Parameter Sniffing）。SQL Server、Oracle、PostgreSQL等主流数据库都会出现类似现象。关键不在于禁用参数嗅探，而在于让优化器更稳定、更可预期地选择合理计划。
为什么参数化查询会引发执行计划波动
数据库在首次执行带参数的查询时，会根据当时传入的具体参数值生成并缓存执行计划。如果这个值对应的是一个低选择性条件（比如 WHERE status = 'Active' 占表95%），优化器可能选索引扫描；而下次传入高选择性值（WHERE user_id = 123456），本该走索引查找，却复用了扫描计划，性能骤降。
常见诱因包括：
- 字段数据分布严重倾斜（如状态列只有3个值，但其中2个占99%）
- 统计信息过期或未自动更新
- 未对关键过滤列建立合适索引（尤其组合条件顺序不合理）
- 查询中混用变量与字面量，干扰参数感知逻辑
稳定执行计划的实用策略
不推荐一刀切地加 OPTION (RECOMPILE)，它虽能每次重编译，但增加CPU开销且失去计划复用收益。更平衡的做法是：
- 使用局部变量绕过首次参数嗅探：把输入参数赋值给同类型局部变量，再在WHERE中使用该变量（SQL Server有效）
- 为高频歧义参数建“计划指南”或“查询提示”：例如对 @status 值为'Pending'的场景，强制走索引查找
- 拆分高风险查询逻辑：将“查全部”和“查单条”两类语义明显不同的请求，用不同存储过程或不同SQL文本处理
- 定期更新统计信息并启用自动创建/更新：尤其对大表的过滤字段，避免优化器基于过时分布做决策
如何快速定位波动源头
别只看执行时间，要对比不同参数下的实际执行计划差异：
- 用 sys.dm_exec_query_stats + sys.dm_exec_sql_text 查找同一SQL文本但平均耗时差异大的计划句柄
- 通过 sys.dm_exec_cached_plans 找出被多次复用但逻辑读/执行次数异常的计划
- 开启查询 Store（SQL Server）或 AWR 报告（Oracle），观察同一查询ID在不同时间段的计划哈希变化
- 在SSMS中启用“包含实际执行计划”，手动用典型参数值跑两次，直接比对计划图结构与估算行数
报表场景下的特别注意点
报表查询常含多层JOIN、聚合、窗口函数，且参数组合复杂。此时：
- 避免在WHERE中对参数列做函数操作（如 YEAR(create_time) = @year），破坏索引利用
- 对常用报表筛选维度（如日期范围、部门ID、状态）建立覆盖索引，减少Key Lookup
- 考虑用 OPTION (OPTIMIZE FOR (@param = 'typical_value')) 引导优化器按典型值生成计划
- 若报表支持“预计算+增量更新”，优先将波动部分下沉到物化视图或汇总表，绕过实时优化难题
