在PostgreSQL中，一个表上可以同时挂载多个触发器，比如同时存在审计日志触发器、数据校验触发器、默认值填充触发器等。当一条INSERT语句执行时，这些触发器并不是随机执行的，而是遵循一套严格的规则。理解这套规则，是排查“为什么我的触发器没生效”“为什么数据被另一个触发器覆盖”这类问题的关键。本文将从触发器的分类、执行顺序规则、查看方法以及实践建议几个方面，完整讲清楚PostgreSQL多触发器的执行顺序机制。
一、触发器执行顺序的基本规则
PostgreSQL官方文档对触发器执行顺序给出了明确说明。当同一事件（比如同一条UPDATE语句）触发了多个触发器时，规则可以概括为三点：第一，如果是同一种触发时机和同一种级别的触发器，则按照触发器名称的字典序（字母顺序）执行；第二，如果名称的字典序无法区分（理论上不同触发器名称不同，但过去某些版本中存在特殊情况），则会按触发器创建时间先后，即oid的大小顺序执行；第三，不同时机、不同级别的触发器之间存在固定的先后关系，不受名称影响。
具体到一次完整的DML操作，各阶段触发器的执行次序是固定的。以UPDATE为例，假设表上同时存在各种类型的触发器，执行顺序为：BEFORE语句级触发器最先执行，然后对每一行被更新的数据依次执行BEFORE行级触发器、执行行数据本身的更新、执行AFTER行级触发器（严格说是AFTER行级触发器会被排队到语句末尾统一触发，这一点后面会讲），所有行处理完后，最后执行AFTER语句级触发器。
需要注意的是，名称排序只在“同组”触发器之间生效。所谓同组，是指触发时机（BEFORE/AFTER/INSTEAD OF）、触发事件（INSERT/UPDATE/DELETE/TRUNCATE）、级别（语句级/行级）都相同的触发器。跨组的触发器之间不存在名称竞争，比如一个叫aaa的AFTER触发器永远在一个叫zzz的BEFORE触发器之后执行，无论名称多靠前。
二、BEFORE与AFTER以及语句级与行级的关系
BEFORE触发器和AFTER触发器的语义差异直接决定了它们的执行位置。BEFORE行级触发器在每行数据被实际修改之前运行，它可以检查并修改NEW值，甚至可以通过返回NULL跳过对该行的操作；AFTER行级触发器在行操作完成之后运行，通常用于记录日志、同步其他表等不需要回写本行数据的场景。所以BEFORE一定在对应行操作之前，AFTER一定在行操作之后，这是硬性约束。
语句级和行级的区别也需要弄清楚。语句级触发器对每条SQL语句只触发一次，不管这条语句影响了多少行；行级触发器则每一行触发一次。如果一个UPDATE语句更新了100行，那么BEFORE UPDATE FOR EACH STATEMENT触发器执行1次，BEFORE UPDATE FOR EACH ROW触发器执行100次。执行次序上，BEFORE语句级触发器先于所有BEFORE行级触发器，AFTER语句级触发器晚于所有AFTER行级触发器。
还有一个容易被忽视的细节：AFTER行级触发器实际上是“延迟到语句结束前”执行的。PostgreSQL会将AFTER行级触发器排队，在整条语句的所有行都处理完毕、且没有发生错误时才统一按顺序调用。这意味着AFTER行级触发器看到的是语句执行完成后的最终数据状态，这也是它适合做审计的原因。下面用一段SQL演示多触发器的定义：
-- 创建测试表
CREATE TABLE orders (
id serial PRIMARY KEY,
amount numeric,
status text
);
-- 按名称顺序，aa_check 先于 bb_audit 执行（同为 BEFORE 行级触发器）
CREATE TRIGGER aa_check
BEFORE UPDATE ON orders
FOR EACH ROW
EXECUTE FUNCTION fn_check_amount();
CREATE TRIGGER bb_audit
BEFORE UPDATE ON orders
FOR EACH ROW
EXECUTE FUNCTION fn_fill_audit();
三、如何查看和控制触发器顺序
想知道一个表上到底挂了哪些触发器、顺序如何，可以查询系统表pg_trigger。其中tgrelid是所属表的oid，tgname是触发器名称，tgoldtable和tgnewtable可以看过渡表配置。配合pg_class和information_schema.triggers视图，可以清晰列出全部触发器。查询示例如下：
-- 查看表 orders 上所有触发器，按名称排序即实际执行顺序（同组内）
SELECT tgname,
tgfired, -- 触发时机描述
CASE WHEN tgtype & 1 <> 0 THEN 'ROW' ELSE 'STATEMENT' END AS level
FROM pg_trigger
WHERE tgrelid = 'orders'::regclass
AND NOT tgisinternal
ORDER BY tgname;
控制执行顺序的核心手段是命名。既然同组触发器按名称字典序执行，就可以用统一前缀来编码顺序，比如用t01_、t02_这样的数字前缀，让触发器的执行顺序一目了然。这在触发器之间存在依赖关系时尤其重要，例如“默认值填充触发器”必须在“非空校验触发器”之前运行，就可以分别命名为t01_fill_default和t02_validate_null。
另外要注意排序是字典序而不是数字序，t10_会排在t2_前面。如果触发器数量可能超过9个，建议用t01_、t02_、...、t10_这种固定位数的命名方式，保证排序与预期一致。如果触发器逻辑复杂到需要精细控制多个触发器之间的调用次序，也可以考虑合并成一个触发器函数，在函数内部明确编排各段逻辑的执行顺序，这样更可控也更容易维护。
四、实践中的常见坑与建议
第一个常见的坑是误以为触发器按创建顺序执行。很多人直觉上认为先创建的先执行，但实际上同组触发器是按名称排序的，即使后创建的触发器名称更靠前，它也会先执行。第二个坑是BEFORE触发器之间的数据覆盖问题：如果两个BEFORE行级触发器都修改NEW的同一个字段，后执行的会覆盖先执行的结果，如果顺序不符合预期，最终数据就会出错，而这类bug往往很难排查。
第三个坑是触发器中的异常处理。任何一个行级触发器抛出错误，整个语句都会回滚，包括已经成功执行的行。对于排队的AFTER触发器，一旦语句失败，它们根本不会被调用。因此不要在AFTER触发器中做任何假定“前面的逻辑一定成功”的操作之外的外部副作用，比如调用外部接口，否则可能出现数据回滚了但接口已经调用过的不一致情况。
总结几条实践建议：给触发器命名时统一采用带顺序编号的前缀；优先用BEFORE触发器做数据校验和修改，用AFTER触发器做审计和通知；能合并的逻辑尽量合并到同一个触发器函数中，减少跨触发器的隐式依赖；上线前用pg_trigger核对实际顺序；文档中明确记录触发器之间的执行依赖关系。遵循这些规则，多触发器的行为就可以完全预期，避免因为顺序问题导致隐蔽的数据错误。
PostgreSQL触发器触发器执行顺序触发器优先级修改时间：2026-09-07 19:50:53