应优先使用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 条件、语句级触发、过渡表、静态检查——这些不是锦上添花的技巧，是控制爆炸半径的底线动作。
