为何在SQL触发器中使用全局变量会导致不可预知的错误

MySQL触发器中不可靠的是全局用户变量@var，因其会话级生命周期、跨语句共享及并发覆盖风险；应改用DECLARE声明的局部变量存储NEW/OLD字段值，且必须在BEGIN后首行声明。

全局变量 @var 在触发器里根本不可靠

MySQL 触发器中用 @var 存临时值，99% 的情况是错的。它不是局部变量，而是会话级用户变量，生命周期跨语句、跨触发器、甚至跨多个 DML 操作——只要同一个连接没断，@var 就一直挂着。并发插入时，A 用户的 @counter 可能被 B 用户的同名赋值覆盖，结果 A 最后读到的是 B 的值。

• NEW 和 OLD 是只读行别名，不能赋给 @var：写 SET @id = NEW.id; 语法合法但毫无意义，后续无法用 @id 安全参与计算或条件判断
• 触发器执行路径不唯一：IF 分支没走、LEAVE 提前退出、或者多条 INSERT 同时触发，@var 值可能来自上一次调用，而不是当前行
• 调试时看不出问题：SELECT @var 返回某个值，你以为它“生效了”，其实只是碰巧没被别的操作改掉

该用什么替代 @var？必须声明局部变量

想存 NEW.status、OLD.amount 这类中间值，唯一可靠方式是 DECLARE 局部变量，且必须紧贴 BEGIN 后第一行声明。

• 正确写法：BEGIN DECLARE l_status VARCHAR(20); SET l_status = NEW.status;
• 命名加前缀（如 l_）避免和参数、字段名冲突；不要和 @var 同名，否则 SELECT l_total 和 SELECT @total 容易混淆
• 嵌套 BEGIN END 块也得各自 DECLARE，外层声明的变量在内层不可见，不会自动继承

为什么 PREPARE 动态 SQL 里也不能用局部变量？

PREPARE 语句根本不识别 DECLARE 变量，传参只能用 @ 用户变量，这是 MySQL 的硬限制。

• 错误写法：PREPARE stmt FROM 'UPDATE t SET x = ? WHERE id = ?'; EXECUTE stmt USING v_id, v_val; → v_id 是局部变量，EXECUTE 时当 NULL 处理
• 可行方案：先 SET @v_id = v_id;，再 EXECUTE stmt USING @v_id;
• 注意 @ 变量在 PREPARE 场景下是必要妥协，但仅限这一处；其他逻辑一律回归 DECLARE + SET

BEFORE 和 AFTER 触发器对变量使用的根本差异

变量本身没区别，但使用场景被 Timing 严格限定：只有 BEFORE 触发器才能通过 SET NEW.field = ... 修改即将写入的值；AFTER 里连 NEW 都是只读的，更别说拿 @var 去间接改了。

• 写在 AFTER 里的 SET NEW.status = 'done' 直接报错：ERROR 1362 (HY000)
• 如果逻辑需要“先查旧值、再算新值、最后更新”，必须拆成两步：BEFORE 里用 DECLARE 存 OLD/NEW 字段，AFTER 里用这些值去更新其他表
• 千万别为了图省事，在 BEFORE 里塞一堆 @var 赋值，再在 AFTER 里读——两个触发器共享不了局部变量，@var 又不可靠，纯属自找麻烦

真正容易被忽略的点是：**局部变量作用域和声明位置是硬性语法要求，不是风格建议**。哪怕只差一行（比如 BEGIN 后先写了 SELECT 再 DECLARE），整个触发器就创建失败；而 @var 表面能跑通，实际已在生产环境埋下并发脏数据隐患。