参数化查询是执行计划复用的前提而非性能优化手段；真正影响计划稳定性的主因是参数敏感性、统计信息滞后与索引缺失，需结合optimize for、局部变量、查询存储等机制综合治理。
参数化查询本身不是性能优化手段，而是安全与可维护性的基础。真正影响执行计划波动的，是SQL Server（或类似数据库）如何复用执行计划——而参数化只是让复用成为可能的前提。执行计划波动的根本原因，往往在于参数敏感性（Parameter Sniffing）、数据分布倾斜、统计信息滞后，以及未合理使用查询提示或计划稳定性机制。
参数化只是起点，不是万能解药
把硬编码值换成参数（如 WHERE OrderDate = '2024-01-01' → WHERE OrderDate = @date），只解决了SQL注入和计划缓存查找匹配的问题。但如果不同参数值对应的数据量差异极大（例如查“2024-01-01”返回10行，查“2020-01-01”返回50万行），SQL Server仍可能为某个“典型”参数生成并缓存一个次优计划，后续其他参数就沿用它，导致性能抖动。
- 确认是否真存在计划复用：查
sys.dm_exec_query_stats+sys.dm_exec_sql_text，看同一查询文本的execution_count是否远大于1 - 检查实际执行计划中的“Parameter Compiled Value”和“Parameter Runtime Value”，比对二者是否显著偏离
- 避免在参数化语句中混用字面量（如
AND Status = 'Active'），否则可能破坏计划复用一致性
应对参数敏感性：有节制地干预编译行为
不建议全局禁用参数嗅探（如启动跟踪标志4136），而应按需选择更精准的控制方式：
- 对已知“高危”语句，加
OPTION (OPTIMIZE FOR (@param = 'typical_value'))，锁定常用值的估算路径 - 若某参数常为空或极小范围，用
OPTION (OPTIMIZE FOR (@param UNKNOWN))让优化器按统计信息平均密度估算 - 存储过程中，对关键查询段使用局部变量赋值（
DECLARE @local_date DATE = @input_date，再用@local_date查询），可绕过嗅探——但仅适用于确实需要稳定计划且数据分布稳定的场景
配合统计信息与索引策略，堵住波动源头
执行计划波动常是表层现象，底层多源于统计信息不准或缺失关键筛选列的索引支持：
- 确保涉及参数列（如
OrderDate、CustomerID）的统计信息是自动更新的，且采样率足够（尤其大表）；必要时手动UPDATE STATISTICS ... WITH FULLSCAN - 在高频参数列上建立合适索引，避免因缺少索引导致优化器被迫选择低效嵌套循环或全表扫描
- 对多条件组合参数（如
WHERE A=@a AND B=@b），考虑创建包含两列的复合统计信息（CREATE STATISTICS）或覆盖索引，提升基数估算精度
长期稳定方案：查询存储 + 强制计划
对于核心业务查询，推荐启用查询存储（Query Store），它能自动捕获历史计划、运行时性能，并支持人工强制绑定最优计划：
- 开启后，通过
sys.query_store_plan找出响应快、CPU低的稳定计划 - 用
sp_query_store_force_plan将该计划与查询ID绑定，后续所有参数都走此计划 - 定期检查
sys.query_store_runtime_stats中的回归情况，及时解绑异常计划
参数化查询是减少执行计划波动的必要条件，但不是充分条件。真正稳住执行计划，靠的是理解参数如何影响基数估算、主动管理统计信息与索引、并在必要时用查询存储等机制锁定优质计划。不复杂但容易忽略。
