应优先使用when子句过滤触发器执行条件，配合for each statement+transition tables提升批量性能，避免触发器内跨表查询，并用plpgsql_check静态检测隐患。

用 WHEN 子句过滤无意义变更

触发器不是每次 UPDATE 都该执行，比如只关心 status 字段从 'draft' 变成 'published'，其他字段改了就跳过。PostgreSQL 支持在 CREATE TRIGGER 里直接加 WHEN 条件，它在触发器函数调用前就判断，不满足条件连函数入口都不进，省掉上下文切换和 PL/pgSQL 解析开销。

常见错误是把判断逻辑写进函数体里，比如 IF NEW.status != OLD.status THEN ... END IF;——这已经进了函数，开销白花了。

• WHEN 必须用 SQL 表达式，不能调函数（如 to_timestamp()），否则报错
• 支持复合条件：WHEN (NEW.status = 'published' AND OLD.status = 'draft')
• 对 INSERT 触发器，OLD 不可用，WHEN 只能基于 NEW；DELETE 同理

优先选 FOR EACH STATEMENT + TRANSITION TABLES

批量更新 10 万行，FOR EACH ROW 触发器会调 10 万次函数；换成 FOR EACH STATEMENT，只调 1 次，性能差距可能是数量级的。PostgreSQL 10+ 支持 NEW TABLE 和 OLD TABLE 过渡表，让你在语句级触发器里拿到所有变更行，再用集合操作处理。

典型坑是误以为语句级触发器不能访问数据——其实能，只是不能用 NEW/OLD 记录变量，得查过渡表。

• 创建时必须显式声明：REFERENCING NEW TABLE AS new_rows
• 过渡表名是临时的，只在触发器函数内有效，不能被其他会话看到
• 函数里用 SELECT COUNT(*) FROM new_rows 或 INSERT INTO audit_log SELECT * FROM new_rows 是安全的
• 注意：过渡表不包含未更改的列（如 UPDATE t SET a=1，则 new_rows 里只有 a 列）

避免在触发器里查大表或 JOIN

触发器里写 SELECT ... FROM orders o JOIN users u ON o.user_id = u.id 是高危操作。同步阻塞下，哪怕只查一次，也可能拖慢主事务几十毫秒，尤其当 users 表没索引或 user_id 类型不一致（比如 INT 对 BIGINT）时，索引直接失效。

真实场景中，这类查询往往是为了补全日志字段或校验权限，但代价远超收益。

• 先用 EXPLAIN ANALYZE 单独跑触发器内的查询，确认是否走索引、是否出现 Seq Scan
• 如果必须关联，确保 JOIN 字段类型完全一致，并在两边都建索引
• 更彻底的解法：把查表逻辑移出触发器，改成异步消费 binlog 或 logical decoding 消息
• 临时方案：用 SELECT ... FROM new_rows 做轻量聚合（如统计本次更新了多少行），别跨表

用 plpgsql_check 提前发现隐性开销

有些性能问题肉眼看不出来，比如重复解析 NEW.payload::jsonb、在循环里反复取 NEW.id、或者写了死代码（RETURN 后还有语句）。plpgsql_check 能静态扫描触发器函数，提前标出这些隐患。

它不运行代码，只分析语法树，所以零风险、快得离谱。

• 安装后，用 SELECT * FROM plpgsql_check_function('update_employee_timestamp()', 'employees'); 检查，第二个参数必须是关联表名
• 会警告“unused variable”、“type mismatch in assignment”、“dead code”等
• 特别有用的是检测 EXECUTE 动态 SQL 是否有注入风险——很多触发器用拼接字符串构造日志插入语句，这里最容易翻车

真正卡住系统的，往往不是单次触发器有多慢，而是它在批量场景下被放大 N 倍，又因为嵌在事务里，把锁持有时间拉长。WHEN 条件、语句级触发、过渡表、静态检查——这些不是锦上添花的技巧，是控制爆炸半径的底线动作。