UPDATE触发器中OLD和NEW仅能访问表中真实存在的字段，列名错误会报“Unknown column 'OLD.xxx'”，INSERT只能用NEW、DELETE只能用OLD、UPDATE两者皆可；字段比较须用<=>处理NULL以准确判断值是否真变化。
UPDATE触发器里OLD和NEW到底能访问哪些字段
只有表里真实存在的列，才能用OLD.column或NEW.column引用。写错列名会直接报错Unknown column 'OLD.xxx' in 'field list'。比如表没有phone字段，却在触发器里写OLD.phone，语句就建不成功。
INSERT只允许用NEW，DELETE只允许用OLD，UPDATE两者都可用——这是硬性限制，不是风格问题。
字段值比较必须用或!=，不能用IS NOT来比NULL；如果字段可能为NULL，得显式用IS NULL/IS NOT NULL判断，否则OLD.name != NEW.name在任一端为NULL时结果为NULL，导致IF不成立。
如何安全判断“字段值真的变了”
UPDATE语句哪怕没改任何值（比如UPDATE users SET name=name WHERE id=1），也会触发一次AFTER UPDATE。不加判断就执行逻辑，容易造成日志爆炸、重复同步或误扣库存。
推荐用以下结构做真变更检测：
IF (OLD.status <=> NEW.status) = 0 THEN -- status确实变了，才执行后续 END IF;
使用而不是!=，是因为它能正确处理NULL：当OLD.status和NEW.status都是NULL时，返回1（相等），!=返回NULL（条件不成立）。
- 只监控关键字段：比如只关心
status、amount、email，别对整行所有字段做OR判断 - 避免在IF里调用函数：如
NOW()、UUID()本身没问题，但SELECT COUNT(*) FROM ...这类子查询会极大拖慢性能，且可能引发锁等待 - 字符串比较注意大小写：默认校对规则下
'A' = 'a'可能为true，如需严格区分，显式用BINARY OLD.name != BINARY NEW.name
BEFORE UPDATE中修改NEW值的常见误用
BEFORE UPDATE允许你给NEW.column赋新值，从而影响最终入库的数据。但很多人误以为这能“拦截非法更新”，其实不行——MySQL不会因BEFORE里的逻辑而自动回滚主SQL，除非你主动抛异常。
典型错误写法：
IF NEW.amount < 0 THEN SET NEW.amount = 0; -- 只是设默认值，不是拒绝 END IF;
如果目标是阻止负数写入，必须用SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'amount cannot be negative';。否则用户看到的是“更新成功”，实际数据被悄悄修正，业务层无法感知。
另一个坑是：在BEFORE中修改了NEW.id这类主键或唯一键字段，可能导致后续AFTER触发器查不到原记录，或违反约束报错。
AFTER UPDATE里更新其他表的事务一致性风险
AFTER触发器运行在主UPDATE已成功写入InnoDB buffer pool之后、事务尚未提交前。此时它和主SQL共享同一事务上下文，所以写日志、同步库存、发消息等操作天然具备原子性——主事务回滚，这些操作也一起回滚。
但要注意两个硬限制：
- 不能UPDATE/INSERT/DELETE触发器所在表本身，否则报错
Can't update table 'xxx' in stored function/trigger - 如果同步的目标表在另一个数据库实例（比如跨库同步），那就不在同一个事务里，必须自己实现补偿或幂等，MySQL不帮你兜底
- 大量写日志或远程调用（比如HTTP请求）会延长事务持有时间，增加锁冲突概率，尤其在高并发UPDATE场景下
真正难的从来不是写对语法，而是想清楚“这个逻辑该不该放触发器里”。比如状态机流转、金额校验、权限检查，更适合放在应用层；而审计日志、缓存失效、简单字段派生，才是触发器的舒适区。
