BEFORE触发器适合数据校验和自动修正，可在插入或更新前通过NEW修改新行数据；AFTER触发器不适用于校验，因写入后抛错会导致回滚复杂及约束冲突。
BEFORE 触发器适合做数据校验和自动修正
当需要在插入或更新前拦截非法值、补全缺失字段（比如 created_at、updated_at）、或强制转换格式时，BEFORE INSERT 或 BEFORE UPDATE 是唯一选择。因为此时新行数据还在内存中，可通过 NEW.column_name 直接修改。
常见错误是误用 AFTER 做校验：一旦写入完成再抛错，事务已部分提交，回滚逻辑更复杂，还可能引发外键或唯一约束冲突。
- 想把空字符串转为
NULL？必须用BEFORE - 要根据
email自动生成username？只能在BEFORE INSERT中赋值给NEW.username - 检查金额不能为负数？
IF NEW.amount 必须放在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 都看不到。
