为什么PostgreSQL中的WHEN条件触发器能显著提升性能？-SQL-PHP中文网

when子句在触发前过滤70%以上无效行，由执行引擎预判跳过函数调用；仅支持简单比较，不支持子查询、函数、null安全比较需显式处理，且语句级触发器不可用。

为什么postgresql中的when条件触发器能显著提升性能？

WHEN子句在触发前就过滤掉70%以上无效行

PostgreSQL 的 WHEN 子句不是“函数里加个if”，而是由执行引擎在调用触发器函数前就完成的谓词判断。只要条件不满足，整行根本不会进入触发器函数——连 PL/pgSQL 环境都不初始化，更不会产生函数栈、变量解析、WAL 日志等开销。

合法写法：WHEN (NEW.status != OLD.status)，简单比较，零额外开销
非法写法：WHEN (SELECT is_active FROM users WHERE id = NEW.user_id)，语法报错，WHEN 不支持子查询
批量更新 10,000 行时，若只有 2,800 行状态实际变化，WHEN 可直接跳过其余 7,200 次函数调用

BEFORE 触发器 + WHEN + 直接赋值，避免 UPDATE 递归和锁表

很多人想“自动更新时间戳”，却在 BEFORE UPDATE 触发器里写 UPDATE orders SET updated_at = NOW() WHERE id = NEW.id——这会触发自身再次调用、锁表、违反单表限制，还绕过 WHEN 过滤。

正确做法：在 BEFORE UPDATE 中直接赋值 NEW.updated_at := NOW();
必须搭配 WHEN (OLD.updated_at IS NULL OR OLD.updated_at 避免无意义重写
最后别忘 RETURN NEW;，否则修改丢失（PostgreSQL 15 仍要求显式返回）

WHEN 不等于校验，它只是第一道开关

WHEN 能拦住明显不相关的行，但无法替代业务逻辑校验。比如你想阻止 status 从 'draft' 跳到 'archived'，WHEN 只能筛出 status 变更的行，真正的合法性检查必须放在触发器函数体里。

WHEN 无法处理 NULL：NEW.status = 'completed' 在 NEW.status 为 NULL 时结果是 UNKNOWN，整行被跳过；需显式写成 NEW.status IS NOT DISTINCT FROM 'completed'
复杂逻辑（如查配置表、调用校验函数）必须放函数体内，但代价是：哪怕最终 RETURN NULL，函数也已调用一次
WHEN 不支持 CURRENT_USER、now() 等函数（少数稳定函数虽被允许，但行为不可控，建议避开）

语句级触发器不能用 WHEN，别混用粒度

FOR EACH STATEMENT 触发器没有 NEW 或 OLD，所以 WHEN (NEW.status = 'done') 会直接报错：ERROR: transition tables not allowed in statement-level triggers。语句级触发器靠的是整体操作发生与否来决定是否执行，不是靠行数据过滤。

想统计批量更新影响了多少行？用 AFTER UPDATE ... FOR EACH STATEMENT REFERENCING NEW TABLE AS new_rows，再在函数里 SELECT COUNT(*) FROM new_rows
语句级触发器末尾必须 RETURN NULL，写 RETURN NEW 会建触发器失败
如果你把行级触发器代码复制过去改写成语句级，忘了删 RETURN NEW，就会卡在语法验证阶段

真正省开销的地方，从来不是“函数里少写几行if”，而是让数据库压根不进那个函数。WHEN 子句的位置、语法限制、与触发时机的配合，每一步都得踩准——错一处，70% 的收益就没了。