SET @var := (SELECT ...) 报错因用户变量仅支持单行标量值，多行需用临时表或加 LIMIT 1；推荐 SELECT ... INTO @var 或存储过程内 DECLARE 局部变量确保安全性和可读性。
SET @var := (SELECT ...) 会报错：Subquery returns more than 1 row
MySQL 不允许把多行结果直接赋给用户变量。只要 SELECT 返回超过一行，SET @var := (SELECT ...) 就会炸，错误信息是：Subquery returns more than 1 row。
这不是语法写错了，是设计如此——用户变量只能存单个标量值（一个数字、一个字符串、一个 NULL）。
- 如果真要存多行，得用临时表：
CREATE TEMPORARY TABLE tmp AS SELECT ... - 想取第一行？加
LIMIT 1，但得确认业务上是否允许丢数据 - 想聚合后存？比如
SET @sum := (SELECT SUM(amount) FROM orders)，这是安全的
SELECT ... INTO @var 是更稳妥的写法
SELECT ... INTO @var 和 SET @var := (SELECT ...) 表面效果一样，但行为更明确：它天然要求查询结果恰好一行一列，否则报错（ERROR 1138: Invalid use of NULL value 或类似），比子查询报错更早暴露问题。
- 正确写法：
SELECT id INTO @user_id FROM users WHERE name = 'Alice' LIMIT 1 - 没匹配到行？
@user_id变成NULL，不是保持旧值 —— 这点常被忽略 - 不能用在存储函数里直接返回变量，因为
INTO是语句级操作，不是表达式
在存储过程里用 DECLARE + SELECT ... INTO 更清晰
如果逻辑复杂、变量多、还要做判断，硬塞 @var 容易混乱。用 DECLARE 声明局部变量，配合 SELECT ... INTO，可读性和作用域都更可控。
- 声明：
DECLARE v_count INT DEFAULT 0 - 赋值：
SELECT COUNT(*) INTO v_count FROM logs WHERE status = 'error' - 局部变量不会污染会话级
@var，多个并发调用互不干扰 - 注意：局部变量只能在存储过程/函数内用，不能在普通会话中
SELECT @var查看
别在 WHERE 或 ORDER BY 里动态引用刚赋值的 @var
MySQL 的执行顺序导致 @var 在同一语句中「赋值」和「使用」可能不同步。比如：SELECT *, @x := @x + 1 AS seq FROM t1, (SELECT @x := 0) init WHERE @x —— 这种写法不可靠，<code>WHERE 条件里的 @x 可能用的是旧值。
- 变量赋值发生在 SELECT 列计算阶段，但 WHERE 是更早的过滤阶段
- 类似陷阱还有：
ORDER BY @x := @x + 1，排序结果不可预测 - 真要生成序号，优先用窗口函数
ROW_NUMBER()（MySQL 8.0+）
SELECT ... INTO，多值就走临时表或改用窗口函数，别指望 @var 能当通用容器使。 
