行级触发器性能差的根本原因是执行次数随影响行数线性增长，如10万行UPDATE触发10万次函数调用，每次需初始化环境、解析变量、压栈及WAL写入；语句级仅执行1次，配合REFERENCING过渡表可高效处理批量变更。
行级触发器每次变更都调用一次函数
根本原因不是函数写得差，而是执行次数爆炸式增长。一条影响 10 万行的 UPDATE，FOR EACH ROW 就会调用触发器函数 10 万次；FOR EACH STATEMENT 只调 1 次。每次调用都要初始化 PL/pgSQL 执行环境、压栈、解析 NEW/OLD、分配内存——这些开销在批量场景下远超函数体本身。
常见错误现象：pg_stat_statements 显示该触发器函数调用次数等于 DML 影响行数；EXPLAIN ANALYZE 看不到触发器内逻辑，但实际 INSERT INTO audit_log 耗时占总事务 70% 以上。
- 行级触发器中哪怕只写一行
PERFORM pg_sleep(0.001)，10 万行就拖慢 100 秒 - 语句级触发器里同样逻辑，耗时基本恒定在几毫秒到几十毫秒
- WAL 写入量也线性放大：每行触发一次 INSERT，就多一次 mini-transaction 和 WAL 记录
语句级触发器拿不到 NEW/OLD，但有 REFERENCING 补位
很多人复制行级触发器代码改语句级，直接报错 ERROR: record "new" is not assigned yet——因为语句级不提供 NEW/OLD 变量。必须用 REFERENCING OLD TABLE AS old_rows NEW TABLE AS new_rows 显式声明过渡表，且仅限 AFTER 语句触发器可用。
过渡表是临时关系，结构与原表一致，但无索引。大结果集时 SELECT COUNT(*) FROM new_rows 很快，但 SELECT * FROM new_rows JOIN users ON new_rows.user_id = users.id 可能极慢。
-
REFERENCING只能在AFTER触发器中使用，BEFORE语句触发器无法访问变更数据 - 过渡表字段名大小写敏感，若原表字段为
"UserId"，过渡表里也得写"UserId" - 别在语句级触发器里写
RETURN NEW或RETURN OLD，必须RETURN NULL，否则建触发器失败
行级触发器里查关联表极易全表扫描
你看到主 SQL 的 EXPLAIN 很干净，不代表触发器安全。行级触发器中一句 SELECT name FROM users WHERE id = NEW.user_id，会在每一行更新时独立执行一次——如果 users(id) 没索引，就是 10 万次全表扫描。
更隐蔽的是隐式类型转换：比如 NEW.user_id 是 bigint，而 users.id 是 integer，就会强制类型转换，索引失效。
- 触发器内所有
SELECT必须走索引，且字段类型严格匹配 - 避免
IN (SELECT ...)、NOT IN、OR条件，它们很难命中索引 - 用
pg_stat_all_tables查n_tup_hot_upd和n_tup_del，确认是否因触发器频繁更新导致 HOT 更新失效
禁用触发器只是诊断手段，不是解法
执行 ALTER TABLE t DISABLE TRIGGER ALL 后导入变快，只能说明问题出在触发器，不能长期禁用。PostgreSQL 会连外键约束触发器一起关，后续插入可能违反约束却不报错。
真正要解决，得看触发器到底在干什么：如果是审计日志，优先换语句级 + REFERENCING；如果是状态校验，保留行级但加 WHEN 子句过滤；如果是聚合计算，干脆移到应用层或物化视图。
- 别在行级触发器里调存储过程——每次调用都重做权限校验和执行计划解析
- 别在触发器里解析大 JSON 字段，先用
jsonb_typeof(NEW.data)判类型再取值 - 批量操作前，评估是否真需要实时性；非强一致场景，异步写日志表更稳
实际最常被忽略的一点：性能瓶颈往往不在触发器函数第一行，而在它调用的第二层查询里——那个没加索引的 WHERE email = NEW.email，才是让整条 UPDATE 卡住的真凶。
