MySQL存储过程中没有MSET语法，变量赋值仅支持单条SET或SELECT...INTO；多变量赋值应使用SELECT...INTO，要求列数与变量数严格一致，并注意作用域、类型转换及NULL处理。

MySQL存储过程中不能用MSET，这是个常见误解

先说一个核心判断：MySQL压根就没有MSET这个语句或语法。它既不是Redis里的那个MSET，也不是MySQL支持的任何变量批量赋值关键字。不少开发者，尤其是从Redis迁移过来的朋友，会下意识地在存储过程里写下MSET @a = 1, @b = 2这样的代码，结果呢？迎面而来的就是一个经典的语法错误：ERROR 1064 (42000): You ha ve an error in your SQL syntax。事实就是，MySQL的变量赋值只支持单条SET语句，或者SELECT ... INTO这种形式，想用逗号分隔一次性给多个变量赋值？这条路走不通。

真正可用的多变量赋值方式：用SELECT ... INTO

那么，有没有一种写法能接近“批量赋值”的效果呢？答案是肯定的，SELECT ... INTO就是最简洁、语义上也最接近的方案。当你需要一次性把查询结果塞进多个用户变量或局部变量时，它就能派上用场。不过，这里有个硬性规定：查询返回的列数，必须和你要赋值的变量数**严格一致**，一个萝卜一个坑，多了少了都不行。

具体操作时，有几个细节得留心：

• 对于局部变量，你得先用DECLARE声明好，再用SELECT ... INTO赋值。用户变量（带@前缀的）虽然可以免去声明，但在存储过程里混用两种变量，通常不是个好主意。
• 务必确保你的SELECT查询只返回一行数据。否则，你会碰到ERROR 1172 (42000): Result consisted of more than one row这个错误。稳妥起见，加上LIMIT 1或者用聚合函数兜底，是个好习惯。
• 如果查询结果里某一列是NULL，那么对应的变量也会被设为NULL。这个过程是自动的，不需要额外处理，但后续的业务逻辑是否能容忍NULL值，这就需要你提前想清楚了。

来看一个典型的例子：

DECLARE v_id INT DEFAULT 0;
DECLARE v_name VARCHAR(50);
DECLARE v_status TINYINT;

SELECT id, name, status INTO v_id, v_name, v_status
FROM users WHERE email = 'test@example.com' LIMIT 1;

为什么不用多个SET？性能和可读性差异在哪

你可能会想，不就是多赋几个值嘛，我写三行独立的SET v_id = (SELECT id FROM ...)不也一样？看起来是直观，但问题就藏在这里：

• 每一次SET里的子查询，都是一次独立的数据库查询。这意味着同一张表可能被反复扫描，I/O开销和执行计划成本直接翻倍。
• 如果子查询里包含了非确定性函数，比如NOW()或RAND()，多次调用得到的结果很可能不一致，这就埋下了数据不一致的隐患。
• 代码会变得冗长。当需要赋值的字段多到8个甚至10个时，维护起来简直就是一场噩梦。

相比之下，单次SELECT ... INTO只查询一次表，所有变量都能原子性地一次性获取。语义清晰，性能也更优。话说回来，它当然也能用于跨表查询（比如SELECT a.x, b.y INTO ... FROM t1 a JOIN t2 b...），只要你的业务逻辑允许。

容易被忽略的坑：局部变量作用域与INTO的隐式类型转换

使用SELECT ... INTO时，有两个“坑”特别容易被忽略，值得警惕。

首先是类型转换。MySQL在这里不会做强制的类型校验，而是进行静默转换。比如，把字符串'123abc'赋值给一个INT变量，它会直接截取前面的数字部分，变成123。更棘手的是NULL值：如果你把一个NULL赋给一个声明为NOT NULL但没有设置DEFAULT值的局部变量，程序会在运行时直接报错：ERROR 1326 (HY000): Variable 'v_x' must be declared as NOT NULL。

其次是作用域。局部变量在BEGIN...END块内声明后，就只在这个块内有效。如果存在嵌套块，并且内层声明了同名的变量，那么内层变量会“遮蔽”外层变量。此时，INTO操作影响的，仅仅是当前作用域的那个变量。

所以，最佳实践是什么？别过度依赖自动转换。对于关键数据，显式地使用CAST()函数或者增加条件判断，会更稳妥。同时，在声明变量时顺手加上合理的DEFAULT值，能有效避免NULL引发的意外中断，让代码更加健壮。