语句级触发器性能优势源于仅执行1次，避免N次上下文切换；它不可访问NEW/OLD，须用REFERENCING过渡表（仅AFTER中可用）并强制RETURN NULL。
语句级触发器不能靠“写得快”来提升性能，关键在于避免在 FOR EACH STATEMENT 触发器里做行级操作或访问 NEW/OLD —— 它们在语句级触发器中是 NULL，强行引用会直接报错。
为什么语句级触发器常被误用为“批量版行级触发器”
很多人以为 FOR EACH STATEMENT 是“一次处理多行”的捷径，结果在函数里循环遍历 NEW 或拼 SELECT * FROM ... WHERE ctid = ANY(...) 来模拟行访问。这完全违背语句级触发器的设计意图：它只感知“发生了什么语句”，不感知“影响了哪些具体行”。
常见错误现象：
- 在语句级触发器函数中引用
NEW.phone_number→ 报错record "new" is not assigned - 试图用
tg_trigger.tg_argv传入行数据 → 该字段只对EXECUTE FUNCTION ... (args...)有效，而语句级触发器不支持带参数调用 - 在
AFTER UPDATE ON orders语句级触发器里查pg_stat_statements反推修改内容 → 不可靠、不可重复、无事务一致性
真正适合语句级触发器的高性能场景
语句级触发器的价值，在于轻量、确定、低开销的全局响应。它适合做“开关类”“计数类”“审计头信息类”操作，而不是数据校验或同步。
典型使用场景：
- 记录某张表本小时被更新了多少次（
INSERT/UPDATE/DELETE各自计数） - 在
AFTER TRUNCATE时清空对应缓存表或重置序列 - 配合
pg_notify发送“全量刷新”信号给应用层，而非逐条推送变更 - 在
BEFORE INSERT语句级触发器中检查系统时间是否允许写入（如禁止夜间导入）
示例：一个零开销的写入拦截器
CREATE OR REPLACE FUNCTION block_offhours() RETURNS TRIGGER AS $$
BEGIN
IF EXTRACT(HOUR FROM NOW()) BETWEEN 22 AND 5 THEN
RAISE EXCEPTION 'Inserts prohibited between 22:00 and 05:59';
END IF;
RETURN NULL; -- 语句级 BEFORE 触发器返回 NULL 表示继续执行
END;
$$ LANGUAGE plpgsql;
<p>CREATE TRIGGER trg_block_offhours
BEFORE INSERT ON logs
FOR EACH STATEMENT
EXECUTE FUNCTION block_offhours();
FOR EACH STATEMENT 的性能陷阱与绕过方案
语句级触发器本身很快，但容易因“想干太多”而变慢。根本矛盾在于：你想知道“改了什么”，但它只告诉你“改了”。要获得行级上下文，必须换思路。
可行路径：
- 如果真需基于语句行为做聚合统计（如“本次 UPDATE 影响了多少用户等级变化”），改用
AFTER STATEMENT+ 物化日志表 + 异步消费（例如用pg_notify触发外部 worker） - 若必须数据库内闭环，放弃语句级，改用行级触发器 +
pg_advisory_xact_lock控制并发聚合写入，避免锁表 - 用
WITH HOLD游标暂存语句影响的ctid集合？不行 ——ctid在语句执行过程中可能变动，且无法在触发器中安全获取
性能影响提示：语句级触发器在高并发 DML 下几乎无额外延迟；但一旦你在其中执行 INSERT INTO audit_log SELECT ... FROM pg_stat_progress_vacuum 这类动态视图查询，就会引入不可控的锁和解析开销。
最容易被忽略的兼容性细节
PostgreSQL 12+ 对语句级触发器做了关键加固：在 TRUNCATE 和 ALTER TABLE 等 DDL 场景下，tg_event 的值更严格，且 tg_relation 可能指向临时关系。不要依赖 tg_trigger.tg_name 做条件分支，应始终用 TG_OP 和 TG_TABLE_NAME 判断上下文。
另一个盲点：RETURN NULL 在语句级 BEFORE 触发器中表示“放行”，而在行级中表示“跳过当前行”——语义完全不同，混用会导致逻辑断裂。
