BEFORE 触发器适合做数据校验和自动修正
当需要在插入或更新前拦截非法值、补全缺失字段（比如
created_at、
updated_at）、或强制转换格式时，
BEFORE INSERT或
BEFORE UPDATE是唯一选择。因为此时新行数据还在内存中，可通过
NEW.column_name直接修改。
常见错误是误用
AFTER做校验：一旦写入完成再抛错，事务已部分提交，回滚逻辑更复杂，还可能引发外键或唯一约束冲突。 想把空字符串转为
NULL？必须用
BEFORE要根据
username？只能在
BEFORE INSERT中赋值给
NEW.username检查金额不能为负数？
IF NEW.amount 必须放在 <code>BEFORE
AFTER 触发器适合做日志记录与跨表联动
AFTER触发器执行时，原语句已成功提交，主表数据确定不变，适合做副作用操作：比如写操作日志、更新统计表、调用存储过程发通知。此时读取
OLD和
NEW是安全的，且不会干扰主事务的原子性。
但要注意：如果在
AFTER里执行耗时操作（如远程 HTTP 请求），会拖慢主 SQL 响应；若触发器内部出错，默认会回滚整个事务——这点常被忽略。 向
audit_log表插入变更记录？用
AFTER UPDATE，避免主表写失败导致日志残留 用户删除后需清理其上传文件记录？
AFTER DELETE更可靠，确保
user_id确实已从主表移除 订单状态变更为
'shipped'后更新库存？必须用
AFTER，否则库存扣减可能在订单未真正落库前就发生
同一事件不能同时定义 BEFORE 和 AFTER 触发器同名
MySQL 允许对同一张表、同一事件（如
INSERT）定义多个触发器，但每个触发器必须有唯一名称。更重要的是：
BEFORE和
AFTER的执行顺序是固定的——所有
BEFORE先于语句执行，所有
AFTER在语句提交后执行。它们之间不共享变量，也不能互相跳过或中断对方。
容易踩的坑是以为能用两个触发器“接力”处理数据：比如
BEFORE校验 +
AFTER记录，结果发现
AFTER里读不到
BEFORE中对
NEW的修改——其实可以，因为
NEW的修改已生效；但若想在
AFTER中访问
BEFORE里计算出的中间值（如临时哈希），就得存到额外字段或临时表。 触发器名重复会报错：
ERROR 1359 (HY000): Trigger already exists想控制多个
BEFORE触发器的执行顺序？MySQL 不提供显式优先级，靠创建时间顺序执行，不建议依赖 在
AFTER INSERT中查询刚插入的行？可以，但不要加
FOR UPDATE，否则可能死锁
性能与调试要点：触发器不是万能胶
触发器在服务端隐式执行，不暴露在应用层，排查问题时容易遗漏。尤其当表上有多个触发器，或触发器内又调用存储函数时，堆栈深、耗时难定位。线上环境应避免在高频写入表（如日志流水）上使用复杂触发器。
调试建议：在触发器开头加
INSERT INTO debug_log VALUES (NOW(), 'trigger_fired', ...);，并确保该表是
ENGINE=BLACKHOLE或低负载环境才用真实表；生产环境更推荐用
SELECT配合
GET DIAGNOSTICS捕获上下文。
SHOW TRIGGERS LIKE 'orders';查看当前表所有触发器定义 触发器中禁止使用
COMMIT、
ROLLBACK或显式事务控制语句，否则报错
ERROR 1305 (42000): SAVEPOINT does not exist复制环境下，触发器默认不复制到从库（
binlog_format=ROW时除外），若逻辑强依赖触发器，需确认主从一致性策略
DELIMITER $$
CREATE TRIGGER orders_before_insert
BEFORE INSERT ON orders
FOR EACH ROW
BEGIN
IF NEW.status IS NULL THEN
SET NEW.status = 'pending';
END IF;
SET NEW.created_at = NOW();
END$$
DELIMITER ;
最麻烦的往往不是语法，而是触发器执行时机和事务边界的隐含假设——改一行数据，背后可能牵出三张表、两个日志、一次外部回调，而这些全藏在数据库里，连
EXPLAIN都看不到。
