before触发器中new.id为null，因自增id尚未生成；after触发器无法修改new字段，因其仅为只读快照；跨表操作需确保全为innodb以保障事务一致性；mysql 8.0严格校验old/new引用合法性。
BEFORE 触发器里不能用 NEW.id 插入后才有的值
MySQL 的 BEFORE INSERT 触发器中，NEW 是待插入行的副本，但自增主键（如 id）此时还没生成，直接读 NEW.id 会是 NULL 或默认值。这不是 bug，是执行时序决定的。
常见错误现象：想在插入前基于 id 生成关联编号（比如 order_no = CONCAT('ORD-', NEW.id)），结果得到 'ORD-' + NULL。
- 正确做法：改用
AFTER INSERT，此时NEW.id已确定 - 若必须在 BEFORE 阶段生成唯一标识，用
UUID()或CONCAT('TMP-', UNIX_TIMESTAMP(), '-', FLOOR(RAND()*1000))等不依赖自增 ID 的方式 - 注意：MySQL 8.0+ 支持在
BEFORE INSERT中对NEW.id赋值（绕过自增），但会覆盖 AUTO_INCREMENT 行为，慎用
AFTER 触发器修改 NEW 字段无效
AFTER 触发器里对 NEW.column 赋值不会影响已写入的数据——因为行已经落盘。这是很多开发者踩坑的根源，尤其想“补全字段”或“修正格式”。
使用场景：比如用户注册后，想在 AFTER INSERT 里自动设 NEW.status = 'active'，却发现查出来还是默认值。
- 根本原因：
NEW在AFTER阶段只是只读快照，不是可回写引用 - 解决方案：改用
UPDATE显式更新，例如UPDATE users SET status = 'active' WHERE id = NEW.id - 性能提醒：额外
UPDATE会引发二次 I/O 和可能的锁等待，高并发下需评估；不如把逻辑前置到应用层或BEFORE触发器
跨表操作时触发器里的事务边界容易失控
触发器天然运行在父语句的事务中，但开发者常误以为它有独立事务。一旦 AFTER 触发器里执行失败（比如外键冲突、磁盘满），整个原始 INSERT/UPDATE 会一起回滚——这本是设计预期，但常被忽略。
典型错误现象：在 AFTER INSERT 中写日志表，日志表引擎是 MyISAM（不支持事务），导致主表插入成功、日志丢失，且无报错提示。
- 检查所有被触发器操作的表是否同为 InnoDB，否则事务一致性无法保障
- 避免在触发器里调用存储过程或外部服务（如 HTTP 请求），超时或失败会拖垮主事务
- MySQL 不允许在触发器里显式使用
COMMIT或START TRANSACTION，会直接报错ERROR 1305 (42000): SAVEPOINT does not exist
MySQL 5.7 和 8.0 对触发器中 OLD/NEW 的权限校验差异
MySQL 8.0 加强了触发器上下文权限检查：即使你有 INSERT 权限，在 BEFORE INSERT 里访问 OLD.column（本不该存在）也会报错 ERROR 1356 (HY000): View 'db.v' references invalid table(s) or column(s)；而 5.7 可能静默忽略。
这导致迁移时触发器突然失效，尤其是从旧版本 dump 导出再导入 8.0 的场景。
- 排查方法：在 8.0 中执行
SHOW CREATE TRIGGER trigger_name，确认语法没混用OLD（INSERT 场景）或NEW（DELETE 场景） - 兼容写法：用
IF NOT ISNULL(OLD.id) THEN ... END IF包裹非安全访问，但更推荐直接删掉冗余引用 - 关键点：触发器体内的列引用必须严格匹配触发事件类型，MySQL 8.0 不再宽容
真正麻烦的是那些隐式依赖执行顺序的嵌套触发器——比如 A 表的 AFTER UPDATE 触发 B 表 INSERT，B 表又有 BEFORE INSERT 去查 A 表，循环依赖或幻读就很难 debug。
