SQL 触发器 BEFORE INSERT vs AFTER INSERT 的业务逻辑选择

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 可能一次性激活上百次触发器，性能毛刺明显

复杂业务逻辑别硬塞进触发器，尤其涉及多表状态协同时，应用层控制更清晰、更易测、更可控。