MySQL 存储过程：用户定义变量与局部变量性能差异解析

2024-03-04 18:18:47

在 MySQL 8.0 存储过程中，我们经常需要使用参数来构建灵活的查询。你可能会发现，即使查询逻辑相同，仅仅是参数传递方式的不同，性能却可能有天壤之别。具体来说，当使用用户定义变量传递参数时，查询速度飞快；而使用局部变量或直接硬编码参数时，查询速度却慢如蜗牛。这究竟是怎么回事呢？

这其中的奥秘在于 MySQL 优化器如何处理不同类型的变量。当我们使用 SET @var = value 的方式定义用户定义变量，并在查询中使用 @var 时，MySQL 优化器会将 value 直接“嵌入”到查询语句中。这就好像我们直接把值写死在 SQL 语句里一样。优化器可以提前知道所有条件，从而选择最优的执行计划，例如使用合适的索引。

但如果我们在存储过程中声明局部变量 DECLARE var_name datatype DEFAULT value，并在查询中使用 var_name，情况就不同了。MySQL 优化器无法在编译阶段确定 var_name 的值，只能在执行阶段动态获取。这就导致优化器无法提前优化查询，只能选择一个相对通用的执行计划，可能会导致全表扫描等低效操作。直接硬编码参数值也会遇到同样的问题。

通过 EXPLAIN 命令，我们可以清楚地看到这种差异。使用用户定义变量时，EXPLAIN 的输出通常行数较少，表示优化器选择了高效的执行计划；而使用局部变量或硬编码值时，EXPLAIN 的输出行数可能会很多，表示优化器不得不进行更多操作。

那么，如果我们必须使用局部变量或硬编码值，又该如何提升性能呢？这里提供几种解决方案：

1. 临时表： 我们可以先将参数值插入到临时表中，然后在查询中关联临时表。这样，优化器就能像处理用户定义变量一样，提前知道参数值，从而优化查询。例如：

CREATE TEMPORARY TABLE tmp_params (start_date DATE);
INSERT INTO tmp_params VALUES ('2023-01-01');

SELECT * FROM my_table WHERE date_column >= (SELECT start_date FROM tmp_params);

2. Prepared Statements： Prepared Statements 可以将 SQL 语句的结构和参数值分开传递给 MySQL 服务器。虽然参数值仍然是在执行阶段传递，但 MySQL 服务器可以缓存查询计划，避免重复解析 SQL 语句，从而提升性能。例如：

SET @start_date = '2023-01-01';
SET @sql = 'SELECT * FROM my_table WHERE date_column >= ?';
PREPARE stmt FROM @sql;
EXECUTE stmt USING @start_date;
DEALLOCATE PREPARE stmt;