WHERE子句常量改变量会大幅改变SQL执行计划吗？

没错，这种情况在SQL Server里太常见了——把WHERE子句里的常量换成变量，真的会让执行计划发生天翻地覆的变化，核心问题出在**参数嗅探（Parameter Sniffing）**和编译阶段的基数估计逻辑上，我给你拆解清楚：

1. 常量查询的“待遇”有多好 #

当你写select * from ComplexView where id = 10000 and theDate = '1/1/2018'这种带常量的查询时，SQL Server在编译执行计划的阶段：

• 能直接拿着这两个常量值去查表的统计信息，精准算出匹配的行数（也就是“基数”）
• 基于这个精准的基数估计，优化器自然会选最优的执行计划——比如你看到的Index Seek，总开销只有7.5，速度当然快

2. 变量查询为啥拉胯 #

但换成变量declare @id int = 10000, @theDate datetime = '1/1/2018'之后，情况就完全不一样了：

• 编译阶段SQL Server根本拿不到变量的实际值（除非你强制让它重新编译），只能用一套默认的规则来预估行数——比如对整数列用平均分布估算，或者拿统计信息里的密度值来蒙
• 如果这个预估的行数和实际数据差十万八千里（比如你的id=10000其实只对应几行，但优化器预估成了几十万行），那它就会选个糟糕的执行计划——比如放弃高效的Index Seek，改用慢得要死的Table Scan或者低效的连接方式，耗时自然就炸了

3. 怎么解决这个问题？给你几个实用方案 #

• 加OPTION(RECOMPILE)：强制SQL Server执行时重新编译计划，这时它能拿到变量的实际值，生成和常量查询一样的高效计划：

  declare @id int = 10000, @theDate datetime = '1/1/2018' 
  select * from ComplexView where id = @id and theDate = @theDate
  OPTION(RECOMPILE)
  

• 用OPTIMIZE FOR指定值：如果你的变量值分布比较固定，可以告诉优化器用指定的值来生成计划：

  declare @id int = 10000, @theDate datetime = '1/1/2018' 
  select * from ComplexView where id = @id and theDate = @theDate
  OPTION(OPTIMIZE FOR (@id=10000, @theDate='1/1/2018'))
  

• 更新统计信息：如果表的统计信息过时了，优化器的基数估计肯定不准，跑一遍UPDATE STATISTICS [你的主大表名]就能让它拿到最新的数据分布
• 存储过程加WITH RECOMPILE：如果是在存储过程里用变量，可以创建时加WITH RECOMPILE，或者调用时指定，让每次执行都生成最优计划

额外提一句 #

你的ComplexView是复杂视图，里面大概率有多表连接、聚合这类逻辑，这种情况下变量带来的基数估计偏差会被放大，执行计划的开销差异也就更明显了。

内容的提问来源于stack exchange，提问作者ca9163d9