局部变量能缓解参数嗅探但破坏基数估算，使优化器依赖失真的统计直方图估算；在数据倾斜、统计滞后、函数谓词或多列过滤无联合统计时，执行计划反而更差。
局部变量如何切断参数嗅探但同时破坏基数估算
用局部变量（如 DECLARE @local_id INT = @input_id）确实能缓解参数嗅探，但它不是“免费午餐”——它会让优化器彻底失去对输入值的感知能力，只能退回到基于统计直方图的平均估算。一旦数据分布严重倾斜（比如 95% 的订单属于 3 个客户），这个“平均值”就毫无意义。
- 优化器看到的是
@local_id，不是@input_id；它无法做“值敏感编译”，只能查status列的直方图，按“该值出现概率 × 总行数”粗略估算 - 如果直方图桶太少（SQL Server 默认最多 200 个），或采样率低（大表未
WITH FULLSCAN），估算偏差会直接放大到下游 JOIN、排序、聚合节点 - 这种误差不是线性增长：上游估算错 5 倍，嵌套循环里驱动表扫 5 倍行数，被驱动表每行再查 5 倍，总开销可能差 25 倍
什么时候局部变量反而让执行计划更糟
局部变量只在“参数值差异极大且统计信息尚可”的场景下表现稳健。但如果遇到以下任一情况，它大概率会生成比原参数嗅探更差的计划：
- 表的统计信息已滞后（
Modification Counter≥Rows Sampled × 0.2），此时平均估算连“大致靠谱”都做不到 - 查询条件含函数或表达式（如
WHERE YEAR(order_date) = 2025），统计信息本就无法覆盖，再加一层局部变量等于双重失明 - 多列组合过滤（
WHERE region = @r AND status = @s），而数据库没建联合统计（CREATE STATISTICS s1 ON t(region, status)） - 使用了
OPTION (RECOMPILE)却又套了局部变量——编译时仍看不到真实值，白耗 CPU
替代方案比硬切局部变量更精准
与其靠局部变量“一锅端”地屏蔽参数，不如按需干预估算源头。这些做法不破坏缓存，还能让优化器在关键节点拿到更准的基数：
- 对倾斜列（如
customer_type只有 'VIP'/'NORMAL' 两类但比例 1:99），手动提高统计采样精度：UPDATE STATISTICS Customers WITH FULLSCAN, COLUMNS (customer_type) - 高频组合条件（如
WHERE tenant_id = @tid AND deleted = 0）补联合统计：CREATE STATISTICS st_tenant_del ON Customers (tenant_id, deleted)，再ANALYZE或UPDATE STATISTICS - 函数谓词改写为可走索引+可估算形式：把
UPPER(name) = 'TOM'改成name = 'tom' COLLATE SQL_Latin1_General_CP1_CI_AS，并确保列上有对应排序规则的统计 - 真要保留局部变量逻辑，至少在赋值后加一句
UPDATE STATISTICS #temp_work（如果涉及临时表），否则临时表统计永远是空的
最容易被忽略的验证点：plan_generation_num 和实际行数比
改完局部变量后别急着上线。先查 sys.dm_exec_query_stats 确认 plan_generation_num 没飙升——否则说明每次都在重编译，局部变量反而成了性能累赘。再打开 SET STATISTICS XML ON，逐节点比对 EstimatedRows 和 ActualRows，只要有一个节点差超 10 倍，就得回头检查统计信息或谓词写法。局部变量本身不解决估算问题，它只是把问题从“参数值依赖”转嫁到了“统计质量依赖”上。
