在SQL Server中，用局部变量是规避参数嗅探导致性能崩溃的正确手段，但需满足前提：首次传入非典型值、统计信息新鲜、无分支逻辑且不混用OPTION (RECOMPILE)或OPTIMIZE FOR；MySQL中该技巧几乎无效。
它不会导致性能下降——相反，**在多数参数嗅探场景下，用局部变量是主动规避性能崩溃的正确手段**。真正导致性能下降的，是误用、滥用或在错误上下文中套用这个技巧。
为什么有人觉得“用了局部变量反而变慢”
常见错误现象：
- 执行计划从“精准适配某参数值”退化为“平均估算”，对常规参数响应变钝（比如原本 50ms 的查询变成 120ms）
- 后续调用中，因统计信息陈旧或直方图缺失，局部变量导致优化器选错索引（例如该走
IX_Status_CreatedDate却走了PK_Orders） - 在 MySQL 中误以为有类似 SQL Server 的参数嗅探机制，给本就不具备该行为的存储过程强行加局部变量，反而干扰了原本稳定的计划复用
根本原因不是局部变量本身有问题，而是它把问题从“极端参数引发计划错配”转移到了“通用计划质量不足”——后者暴露的是更底层的缺陷：统计信息不准、索引不覆盖、数据分布偏斜未建直方图。
SQL Server 中局部变量生效的前提条件
这个技巧只在以下组合成立时才稳定有效：
- 存储过程首次执行时传入的是“非典型值”（如客户ID=999999，该客户只有3条订单），而后续高频调用的是“主流值”（如客户ID=1001，有50万条订单）
- 表上已有合理统计信息（
STATS_DATE()近期更新过），且直方图桶数足够（尤其对高基数列） - 查询本身不依赖参数值做分支逻辑（例如没有
IF @status = 1 ... ELSE ...），否则局部变量会掩盖执行路径差异 - 没混用
OPTION (RECOMPILE)或OPTIMIZE FOR——它们和局部变量逻辑冲突，会导致计划生成策略混乱
反例：DECLARE @local_id INT = @input_id; SELECT * FROM Orders WHERE CustomerID = @local_id AND Status IN (1,2,3) OPTION (RECOMPILE); —— 局部变量断开了嗅探，但 OPTION (RECOMPILE) 又强制重编译，白白增加CPU开销。
MySQL 里用局部变量几乎没意义
MySQL 存储过程没有参数嗅探机制，它的查询计划缓存基于语句文本+会话级环境（如 sql_mode、optimizer_switch）。在过程中写 SET @v = p_id; 再查 WHERE id = @v，优化器仍会在首次调用时按该 @v 值生成计划并缓存，后续复用——这和直接用 p_id 行为一致。
- 真正影响 MySQL 存储过程计划稳定性的，是
ANALYZE TABLE是否及时、optimizer_switch设置是否匹配业务特征、以及是否启用了直方图 - 若发现升级后变慢，优先跑
ANALYZE TABLE orders;，而不是改变量声明方式
最易被忽略的一点：局部变量只解决“计划复用错配”，不解决“计划本身质量差”。如果统计信息半年没更新、索引缺失关键列、或者查询里有 OR / LIKE '%xxx' 这类必然触发全表扫描的写法，加再多层局部变量也救不回来。
