MySQL 8.0存储过程中用户变量与局部变量的性能差异疑问

核心原因：执行计划生成逻辑的差异 #

• 会话变量的参数嗅探优势：当使用会话变量@start_date时，MySQL在执行查询时能直接获取到变量的实际值，会触发**参数嗅探（Parameter Sniffing）**机制。基于这个具体值，MySQL可以结合表的统计信息（比如该日期对应的数据分布）选择最优索引，精准定位目标数据，因此扫描行数极少，查询耗时仅毫秒级。
• 局部变量/硬编码的编译时限制：存储过程中的局部变量（DECLARE start_date DATE DEFAULT '2023-01-01'）或硬编码值，是在存储过程编译阶段就确定的。此时MySQL无法获取到局部变量的实际运行值（即使设置了默认值，编译阶段也会将其视为未知变量），只能基于表的整体统计信息生成保守的执行计划——比如认为需要扫描大量数据，选择全表扫描或低效索引，导致扫描行数暴增，耗时长达数百秒。

执行计划缓存的叠加影响 #

存储过程的执行计划会在第一次编译后被缓存复用。如果首次编译时用的是局部变量，缓存的计划就是基于未知值生成的低效计划，后续每次执行都会复用这个计划，持续保持低性能；而会话变量每次执行都能根据实际值重新评估并生成最优计划，不会被低效缓存计划绑定。

关于扫描行数的差异 #

会话变量的执行计划因精准匹配索引，仅扫描符合条件的少量数据；而局部变量的计划因未用到合适索引，不得不扫描大量无关数据，这就是两者扫描行数悬殊的直接原因——本质是执行计划中索引选择的差异导致的。

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