BEFORE INSERT触发器可修改NEW行数据，AFTER INSERT中NEW只读；BEFORE适用于插入前校验或生成字段值，AFTER适用于主键确定后的跨表操作；二者事务内执行但锁行为与时机不同，复杂逻辑建议移至应用层。
BEFORE INSERT 触发器能改新数据，AFTER INSERT 不能
如果你需要在插入前校验、修正或生成字段值（比如自动填充 created_at、标准化 email、计算 slug），必须用 BEFORE INSERT。它拿到的是 NEW 行的可写副本，你可以直接赋值：SET NEW.updated_at = NOW()。而 AFTER INSERT 里的 NEW 是只读的，任何修改都会报错：Can't update table 'xxx' in stored function/trigger because it is already used by statement which invoked this stored function/trigger。
常见错误现象：
- 在
AFTER INSERT里写UPDATE xxx SET ... WHERE id = NEW.id—— 看似合理，但 MySQL 会直接拒绝执行 - 想用
AFTER INSERT补充主键自增后的关联 ID（比如写日志表），却误以为能顺手改原记录
跨表写入只能用 AFTER INSERT
BEFORE INSERT 执行时，当前行还没真正落盘，主键（尤其是自增 ID）可能尚未确定。此时如果触发器试图用 NEW.id 去插入另一张表，会出问题：InnoDB 在严格模式下可能报 Unknown column 'NEW.id' in 'field list'，或者更隐蔽地写入 0 或 NULL。
正确做法是等数据真正提交后再操作：
- 用
AFTER INSERT触发器，此时NEW.id是确定值，可安全用于外键关联 - 典型场景：用户注册后自动创建默认配置行、订单插入后同步写入审计日志表
- 注意：如果目标表有外键约束且引用原表主键，
BEFORE INSERT必然失败，因为原行尚未存在
性能和事务边界差异很实在
两个触发器都在同一事务中执行，但时机不同直接影响锁行为和耗时：
-
BEFORE INSERT在写行数据前运行，逻辑越重，行锁持有时间越长；简单校验没问题，但别在里面调用慢查询或远程 API -
AFTER INSERT虽然晚，但已拿到稳定主键，适合做异步感操作（如写日志、发消息）；不过它仍属于当前事务，失败会导致整个插入回滚 - MySQL 8.0+ 支持在
AFTER INSERT里调用存储过程，但若该过程含INSERT INTO ... SELECT，可能引发额外锁竞争
触发器嵌套和递归容易被忽略
无论是 BEFORE 还是 AFTER，只要触发动作又引起另一张表的触发器，就可能形成链式调用。MySQL 默认限制嵌套深度为 25，超限报错：Too many levels of nesting for triggers。
真实踩坑点：
- 在
AFTER INSERT里更新另一张表，而那张表也有BEFORE UPDATE触发器，又去更新第三张表……很容易绕晕 -
sql_mode中是否启用STRICT_TRANS_TABLES会影响触发器内类型转换失败时是警告还是报错，进而影响事务是否中断 - 测试时只看单条语句 OK，但批量
INSERT ... SELECT可能一次性激活上百次触发器，性能毛刺明显
复杂业务逻辑别硬塞进触发器，尤其涉及多表状态协同时，应用层控制更清晰、更易测、更可控。
