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又不可靠，纯属自找麻烦
@var 表面能跑通，实际已在生产环境埋下并发脏数据隐患。
