DB2 INSERT触发器校验顺序疑问：BEFORE/AFTER与约束校验先后

先搞清楚核心执行流程 #

不管你用的是哪种主流关系型数据库，这个执行顺序是通用的：

• BEFORE INSERT触发器：触发时机是数据还没写入表，但所有触发器逻辑跑完之后，才会执行表的原生约束校验（比如非空、唯一、外键这些），最后才是实际插入操作。这就是你观察到约束校验在触发器之后的原因。
• AFTER INSERT触发器：必须等数据成功写入表（也就是约束校验已经通过了）才会触发，所以约束校验自然在触发器之前执行。

AFTER INSERT做校验到底合不合理？ #

这得看你的校验目的：

• 如果你的校验是为了拦住非法数据不让插入，那AFTER INSERT其实不太合适——因为数据已经写到表里了，这时候发现问题只能回滚事务，不仅有额外性能开销，要是碰到自动提交的场景，还可能出现数据先写入再被回滚的尴尬情况，远不如BEFORE触发器直接掐断插入高效。
• 但如果你的校验逻辑必须依赖已经合法插入的数据（比如要关联其他表的现有数据做校验，或者是基于插入后的数据状态做统计类校验），那AFTER INSERT是合理的选择。

多INSERT触发器的执行顺序问题 #

当表上有多个同类型的INSERT触发器时，数据库会按以下规则执行：

• 多个BEFORE INSERT触发器：按创建顺序依次执行，全部跑完后才会做约束校验和插入操作。
• 多个AFTER INSERT触发器：约束校验通过、数据插入完成后，按创建顺序依次执行所有AFTER触发器。

要是你坚持用AFTER INSERT做校验，得注意两点：

1. 要是你的校验逻辑需要在其他AFTER触发器之前执行，记得指定触发器的执行顺序（比如PostgreSQL支持CREATE TRIGGER ... ORDER 1;这种语法，数字越小越先执行）。
2. 一旦校验失败，必须在触发器里执行ROLLBACK回滚整个事务，不然其他AFTER触发器会基于非法数据执行操作，最后导致数据不一致。

更推荐的方案 #

如果你的核心需求是保证数据合法性，阻止非法数据插入：

1. 优先用数据库原生约束——这是数据库层面最高效、最可靠的校验方式，能搞定大部分简单校验场景。
2. 复杂校验用BEFORE INSERT触发器：先在触发器里做自定义校验，失败就抛出异常直接阻止插入；之后数据库还会再做原生约束校验，相当于双重保障。

只有当你的校验逻辑离不开已插入的合法数据时，再考虑AFTER INSERT触发器，同时要处理好事务回滚和多触发器的顺序问题。

内容的提问来源于stack exchange，提问作者survivor