PostgreSQL中before/after与行级/语句级触发器适用原则正确性问询

结论 #

这两条是PostgreSQL生态中经过实践验证的通用经验原则，大部分场景下遵循可以降低触发器逻辑出问题的概率、提升执行效率，但并非绝对正确，存在不少不适用的例外场景。

第一条原则适用性分析 #

合理之处 #

Before触发器的优势非常明显：

• 可以直接修改NEW变量的值完成字段补全、格式修正等操作，无需额外执行UPDATE语句，性能开销更低
• 可以提前完成数据合法性校验，在数据库执行约束检查、写入数据之前就拦截非法请求，避免不必要的回滚操作
• 不会出现修改行数据后递归触发同类型行级触发器的问题，逻辑更可控

不适用场景 #

• 需要获取自增主键/序列生成值的场景：serial、IDENTITY列、自定义序列生成的主键值，只有在After Insert阶段才会生成，Before阶段NEW变量里对应的主键字段是空的
• 审计日志类场景：需要记录最终落库的真实数据时，用Before触发器可能拿到的是被其他前置触发器修改前的中间值，只有After触发器才能拿到最终写入磁盘的实际值
• 依赖当前记录约束校验通过的关联操作：比如插入订单后给用户加积分，必须等订单确实写入成功（约束校验通过、不会回滚）再执行关联操作，否则会出现订单写入失败但积分已经发放的一致性问题
• 跨表外键一致性校验：需要确认当前记录已经落库、外键约束生效后再做关联校验，避免校验结果失效

第二条原则适用性分析 #

合理之处 #

FOR EACH STATEMENT级别的触发器，每执行一次SQL语句仅触发一次，不管语句影响多少行，性能远高于逐行触发的行级触发器，非常适合不需要感知单条记录变化的统计、批量操作标记等场景。

不适用场景 #

• 批量修改后的全表聚合校验场景：比如批量修改库存后需要校验全库总库存不能低于0，Before语句级触发器执行时本次修改还未生效，拿到的是修改前的聚合结果，无法完成校验；如果用After语句级触发器，虽然能拿到修改后的结果，但如果修改行数极多，全表聚合的开销可能反而比行级触发器累计变化量更高
• 批量操作的行级状态感知场景：比如批量导入数据时需要统计本次导入成功、失败、跳过的行数，哪怕你不需要具体某一行的内容，也需要行级触发器累计统计值，再在语句级触发器中汇总输出，单独用语句级触发器无法感知行级的执行状态
• 分区表统一操作拦截场景：PostgreSQL分区表的语句级触发器仅能在父表上触发，部分跨分区的操作可能出现触发时机不符合预期的问题，如需覆盖所有子分区的操作，哪怕不需要单条行的信息，有时也需要用行级触发器实现

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