在MySQL语句中使用变量，核心在于利用用户自定义变量（User-Defined Variables）来暂存数据，以便在后续的查询或操作中复用。这在处理复杂逻辑、需要跨多条语句传递值，或者在单条语句中进行某种计算并复用的场景下，显得尤为方便。不过，我个人觉得，虽然它提供了极大的灵活性，但如果滥用，也可能让SQL代码变得难以阅读和维护，甚至在并发环境下引发一些难以察觉的问题。所以，理解其工作原理和适用边界，远比单纯知道怎么用要重要。
解决方案
MySQL允许我们使用两种主要方式来定义和赋值用户变量：
SET语句和
SELECT ... INTO或
SELECT @var_name := value语法。
1. 使用 SET
语句定义和赋值：
这是最直观的方式。
@符号是MySQL用户变量的标识符。
SET @my_variable = 10; SET @user_name = 'Alice'; SET @total_price = (SELECT SUM(price) FROM orders WHERE user_id = 1); SELECT @my_variable, @user_name, @total_price;
2. 使用 SELECT ... INTO
或 SELECT @var_name := value
赋值：
当你想从查询结果中直接将值赋给变量时，这种方式非常有用。
:=是赋值操作符，与
=在
SET语句中功能类似，但在
SELECT语句中，
=通常被解释为比较操作符。
-- 从查询结果中赋值 SELECT @order_count := COUNT(*) FROM orders WHERE status = 'completed'; SELECT @max_id := MAX(id) FROM products; -- 也可以直接赋值一个字面量 SELECT @another_var := 'Hello World'; SELECT @order_count, @max_id, @another_var;
3. 在语句中使用变量：
一旦变量被定义并赋值，你就可以在后续的SQL语句中像使用字面量一样使用它们，但有一些限制，比如不能直接用作表名或列名（除非通过预处理语句
PREPARE和
EXECUTE）。
SET @min_quantity = 5; SELECT product_name, price FROM products WHERE quantity > @min_quantity; SET @user_id_to_find = 101; UPDATE users SET last_login = NOW() WHERE id = @user_id_to_find; -- 结合子查询 SET @avg_salary = (SELECT AVG(salary) FROM employees); SELECT name, salary FROM employees WHERE salary > @avg_salary;
注意事项：
用户变量是会话级别的，这意味着它们只在当前客户端连接中有效。当连接关闭时，变量就会消失。 用户变量不区分大小写（例如@my_var和
@my_var是同一个变量）。 变量的类型是动态的，MySQL会根据赋值自动推断。 在
PREPARE语句中，变量可以用来动态构建SQL语句的某些部分，比如表名或列名，这为更复杂的动态SQL提供了可能，但同时也增加了SQL注入的风险，需要格外小心。
MySQL用户变量的会话生命周期与并发陷阱
当我们谈论MySQL的用户变量时，理解其“会话生命周期”是绕不开的一个话题。简单来说，一个用户变量从你用
SET或
SELECT :=赋值的那一刻起，就存在于你当前的数据库连接会话中。这个变量会一直保留它的值，直到你显式地再次赋值、当前会话结束（比如你关闭了客户端，或者连接超时），或者服务器重启。这听起来挺方便的，对吧？我个人在调试一些复杂查询逻辑时，就经常用它来暂存中间结果，省去了反复执行子查询的麻烦。
然而，这种会话级别的特性也带来了一个潜在的“陷阱”，尤其是在高并发或者使用连接池的环境下。想象一下，如果你的应用程序从连接池中获取了一个连接，在这个连接上设置了一个用户变量，然后执行了一些操作。接着，这个连接被释放回连接池。如果连接池没有清理这个连接上的用户变量，那么当另一个请求从连接池中获取到同一个连接时，它可能会“意外”地继承了上一个请求设置的变量值。这可能导致非常难以追踪的逻辑错误，甚至数据不一致。在我看来，这就是为什么在生产环境中，我们应该尽量避免在业务逻辑代码中过度依赖用户变量来传递关键业务数据。它们更适合作为临时的辅助工具，或者在存储过程内部进行局部计算。
存储过程中的局部变量：提升代码可读性与性能的关键
相比于全局会话级别的用户变量，MySQL存储过程（Stored Procedure）中的局部变量是另一番景象，也是我个人更推荐在复杂业务逻辑中使用的。局部变量通过
DECLARE关键字定义，它们的作用域仅限于其所在的存储过程或函数块内部。一旦存储过程执行完毕，这些局部变量就会被销毁，完全不会影响到其他会话，也不会有前面提到的连接池问题。
这不仅大大提高了代码的封装性和安全性，也让存储过程的逻辑更加清晰。你可以用它们来暂存查询结果、进行条件判断、循环迭代等等，而不用担心变量名冲突或者意外的副作用。
示例：
DELIMITER //
CREATE PROCEDURE GetEmployeeSalaryDetails(IN emp_id INT)
BEGIN
-- 声明局部变量
DECLARE employee_name VARCHAR(255);
DECLARE current_salary DECIMAL(10, 2);
DECLARE bonus_percentage DECIMAL(5, 2) DEFAULT 0.10; -- 默认奖金比例
-- 从表中获取数据并赋值给局部变量
SELECT name, salary INTO employee_name, current_salary
FROM employees
WHERE id = emp_id;
-- 进行计算
IF current_salary IS NOT NULL THEN
SELECT employee_name AS '员工姓名',
current_salary AS '当前薪资',
current_salary * bonus_percentage AS '预计奖金',
current_salary * (1 + bonus_percentage) AS '总收入';
ELSE
SELECT '员工未找到或薪资信息缺失' AS '提示';
END IF;
END //
DELIMITER ;
-- 调用存储过程
CALL GetEmployeeSalaryDetails(1);在这个例子中，
employee_name、
current_salary和
bonus_percentage都是局部变量。它们只在
GetEmployeeSalaryDetails这个存储过程执行期间存在，并且不会对外部环境造成任何影响。这种方式，在我看来，才是真正提升SQL代码可读性和可维护性的有效途径。它使得存储过程能够像独立的程序模块一样工作，减少了外部依赖，也降低了出错的概率。
深入理解MySQL变量的类型与赋值规则
MySQL变量的类型推断机制，有时会让人觉得既方便又有点“魔幻”。用户变量（
@var_name）没有固定的数据类型声明，它们的类型会根据你赋给它们的值动态变化。比如，你先给
@my_var赋一个整数，它就是整数；接着赋一个字符串，它就变成了字符串。这种灵活性在某些场景下确实能简化代码，但话说回来，也可能导致一些隐式类型转换的问题，尤其是在进行比较或计算时。
类型推断示例：
SET @val = 10; -- @val 是整数 SELECT @val + 5; -- 结果是 15 SET @val = '20'; -- @val 变成了字符串 SELECT @val + 5; -- MySQL 会尝试将 '20' 转换为数字，结果是 25 SET @val = 'hello'; -- @val 仍然是字符串 SELECT @val + 5; -- 'hello' 无法转换为数字，结果是 5 (非数字字符串转换为0)
可以看到，当字符串无法完全转换为数字时，MySQL会将其视为0进行计算。这可能不是你期望的行为，所以在使用变量进行算术运算时，确保其类型是可转换的数字类型非常重要。
而存储过程中的局部变量（
DECLARE var_name type;）则不同，它们在声明时就明确了数据类型。这意味着MySQL会强制执行类型检查和转换。如果尝试将不兼容类型的值赋给局部变量，可能会收到警告或错误，这在某种程度上提供了更好的类型安全性。
赋值规则：
=操作符： 在
SET语句中，
=用于赋值。在
SELECT语句中，
=用于比较。
:=操作符： 这是一个通用的赋值操作符，可以在
SET和
SELECT语句中使用。在
SELECT语句中，它明确表示赋值，避免了与比较操作符
INTO的混淆。我个人更倾向于在
SELECT语句中使用
:=来赋值给用户变量，因为它更清晰地表达了意图。
理解这些细微的差别，有助于我们更精准地控制变量的行为，避免不必要的隐式转换带来的潜在问题。在我看来，虽然MySQL的变量系统看起来有点随意，但只要掌握了这些基本规则，就能有效地驾驭它，让它成为我们开发过程中的得力助手。
