MySQL触发器中SET语句生效需满足：仅BEFORE触发器可修改NEW字段，AFTER中禁止赋值；NEW/OLD是只读行别名，不可赋给@用户变量；应使用DECLARE声明局部变量临时存储；须确保SET位于有效执行路径且避免隐式类型转换失效。
触发器里写了 SET @var = 1; 或 SET NEW.field = 'x';，但后续逻辑没按预期走——问题大概率出在变量类型混淆或赋值时机错位，而不是语法写错了。
NEW 和 OLD 不是用户变量，不能用 @ 符号引用
常见误写：SET @new_id = NEW.id; 看似合理，但 NEW 和 OLD 是只读行别名，不是变量容器。你无法把它们赋给用户变量再间接操作；更关键的是，@var 是会话级用户变量，在触发器中跨语句存活，但容易被其他并发操作覆盖，不可靠。
-
NEW.id必须直接使用，比如IF NEW.status = 'draft' THEN SET NEW.status = 'pending'; - 想临时存值？用局部变量：
DECLARE tmp_status VARCHAR(20); SET tmp_status = NEW.status; - 避免混用：
@var在触发器里基本没意义，删掉；所有字段操作一律走NEW.xxx或OLD.xxx
SET 语句在 BEFORE 触发器中才影响最终写入
SET NEW.field = ... 只有在 BEFORE INSERT 或 BEFORE UPDATE 中才生效。放到 AFTER 里会直接报错：ERROR 1362 (HY000): Updating of NEW row is not allowed in after trigger。
-
BEFORE：可安全修改NEW字段，这些值会覆盖原始 SQL 中的赋值 -
AFTER：NEW和OLD只读，只能做日志、通知、更新其他表等副作用操作 - 检查触发器定义：
SHOW CREATE TRIGGER trigger_name;确认 Timing 是BEFORE还是AFTER
赋值语句被 IF 条件跳过，或提前 LEAVE
触发器里写了 SET NEW.amount = OLD.amount + NEW.delta;，但实际没变——大概率是前面的 IF 判断为假，整块逻辑被跳过，或者中间 LEAVE 退出了当前标签块。
- 不要依赖“默认执行”，每个
SET都得落在明确的执行路径上 - 避免单分支
IF：比如只写IF NEW.delta > 0 THEN SET NEW.amount = ...;，那 delta ≤ 0 时 amount 就保持原 SQL 值，不是清零 - 加调试日志：
INSERT INTO debug_log VALUES (NOW(), 'before_set', NEW.id, NEW.delta);，确认是否真进到赋值前
隐式类型转换让 SET 表面成功，实际失效
字段是 DECIMAL(10,2)，但你写了 SET NEW.amount = '1000.5'; ——MySQL 会尝试转换，但如果 sql_mode 含 STRICT_TRANS_TABLES，转换失败就报错中断；不含则可能静默转成 0 或截断，导致赋值结果和预期不符。
- 显式转换：
SET NEW.amount = CAST('1000.5' AS DECIMAL(10,2)); - 始终用数值字面量或已知类型变量，避免字符串参与算术赋值
- 查当前模式：
SELECT @@sql_mode;，若不含 STRICT，建议加上以暴露潜在问题
最常被忽略的是：你以为 SET 执行了，其实它根本没走到那行；或者你改了 NEW.field，但主 SQL 语句里又显式指定了同字段值，最终以触发器为准——这种覆盖关系必须在业务逻辑里明确设计，不能靠猜测。
