SQL Server执行计划缓存存在参数敏感性问题，即同一查询因不同参数值导致优化器生成低效计划并被复用；根源在于首次编译时基于具体参数估算数据分布，后续复用时不重评估；常见场景包括数据分布不均、谓词失效统计信息等；缓解策略有OPTIMIZE FOR、OPTION(RECOMPILE)、分支逻辑拆分及更新统计信息。
SQL Server 的执行计划缓存确实存在参数敏感性（Parameter Sensitivity）问题，本质是同一个参数化查询因不同参数值导致优化器生成了“看似通用、实则低效”的执行计划，并被缓存复用，从而在后续某些参数下性能急剧下降。
为什么会出现参数敏感性？
SQL Server 在首次执行带参数的查询时，会基于本次传入的具体参数值来估算数据分布、选择索引、决定连接方式等，生成一个执行计划并缓存。这个计划后续会被相同结构（即“语义一致”）的查询复用——无论新参数是否导致实际数据量差异巨大。
例如：
WHERE Status = @status AND CreatedDate > @date
若首次调用是 @status = 'Active'（占95%行数），优化器可能选全表扫描；之后调用 @status = 'Cancelled'（仅0.1%行数），却仍复用全表扫描计划，严重浪费I/O。
常见触发场景
- 列上数据分布极度不均（如状态码、开关标志、地区代码）
- 查询含 OR、LIKE '%xxx'、函数包装列（如 YEAR(OrderDate) = 2023）导致统计信息失效
- 使用 OPTION (RECOMPILE) 缺失，且未启用“强制参数化”或查询提示干预
- 数据库兼容级别较低（如 < 120），缺少自适应查询处理（AQH）等缓解机制
实用缓解策略
- 针对性使用 OPTIMIZE FOR 或 OPTIMIZE FOR UNKNOWN：在存储过程中显式引导优化器按典型值或平均分布生成计划
- 对高敏感查询加 OPTION (RECOMPILE)：避免缓存，每次编译适配当前参数（适用于执行频次不高但参数差异极大的场景）
- 拆分逻辑，用 IF/ELSE 分支走不同查询路径：例如对高频小结果集参数走索引查找，对低频大结果集走覆盖扫描
- 更新统计信息 + 启用自动更新（AUTO_UPDATE_STATISTICS_ASYNC OFF 更稳妥）：确保优化器有较新的数据分布依据
如何快速识别？
查 sys.dm_exec_query_stats 和 sys.dm_exec_cached_plans，结合 sys.dm_exec_sql_text 和 sys.dm_exec_query_plan，筛选出 avg_logical_reads 高、execution_count 高、plan_handle 复用频繁 的语句；再对比不同参数下的实际执行计划，看是否物理操作（如扫描 vs 查找）、预估行数（EstimatedRows）与实际行数（ActualRows）偏差极大。
