SQL FOR EACH ROW 与 STATEMENT 使用区别

for each row 触发器在sql语句影响的每一行上单独执行一次，如update users set status='active' where created_at

FOR EACH ROW 触发器到底在什么时候执行

它会在 SQL 语句影响的每一行上单独触发一次。比如 UPDATE users SET status = 'active' WHERE created_at 修改了 127 行，<code>FOR EACH ROW 触发器就会执行 127 次——每次都能通过 NEW 和 OLD 访问当前这行修改前后的值。

• 适合做行级校验（如禁止将 price 设为负数）、自动填充字段（如更新 updated_at）、级联更新关联表
• 不能在触发器里写 COMMIT 或 ROLLBACK（除非显式声明自治事务），否则会报错 ORA-04092: cannot COMMIT in a trigger（Oracle）或 ERROR: cannot execute INSERT in a trigger function（PostgreSQL）
• 大批量 DML 时性能开销明显——10 万行更新，就调用 10 万次触发器逻辑

FOR EACH STATEMENT 触发器只跑一次，但拿不到具体行数据

不管一条 INSERT 插入 1 行还是 100 万行，FOR EACH STATEMENT 触发器只执行一次，且无法访问 NEW/OLD ——它看到的是“整条语句完成了”，而不是“哪几行变了”。

医真AI+开放平台

医真AI+ 医学AI开放平台

下载

• 适合做语句级审计（如记录谁在什么时间执行了 DELETE FROM logs）、清空缓存、触发异步任务（如发 MQ 消息通知）
• PostgreSQL 中可配合 pg_trigger_depth() 避免递归；Oracle 不支持该语法，需靠 DBMS_UTILITY.FORMAT_CALL_STACK 判断上下文
• MySQL 完全不支持 FOR EACH STATEMENT，只认行级触发器；openGauss / GaussDB 默认就是 STATEMENT 级，不写 FOR EACH ROW 就是它

不写 FOR EACH 时，默认行为因数据库而异

这个细节很多人踩坑：不是所有数据库都默认按行触发。Oracle 和 PostgreSQL 明确要求显式写 FOR EACH ROW 才是行级；而 openGauss / DM / GaussDB 默认是 FOR EACH STATEMENT，漏写就等于没做行级控制。

• Oracle：不加 FOR EACH ROW → 语句级，且 NEW/OLD 不可用，直接报错 PLS-00049: bad bind variable 'NEW.id'
• PostgreSQL：不加 FOR EACH → 默认 STATEMENT，同样不能引用 NEW，报错 record "new" is not assigned
• DM7：必须显式写 FOR EACH ROW，否则建触发器会失败

混合使用场景：一个操作既要行级处理又要语句级汇总

真实业务常需要两者共存：比如订单表更新时，每行要刷新 last_modified（行级），同时还要把本次修改总数写进统计表（语句级）。这时得建两个触发器，不能塞进一个里。

• 别试图在一个触发器里“模拟”语句级逻辑——比如用包变量累加计数，会因并发导致数据错乱
• PostgreSQL 支持在 FOR EACH STATEMENT 触发器中查 pg_stat_statements 获取影响行数，但 Oracle 没等效视图，得靠应用层传参或临时表
• 触发顺序有隐含依赖：BEFORE FOR EACH ROW → 实际 DML → AFTER FOR EACH ROW → AFTER FOR EACH STATEMENT，跨级别调试时注意断点位置

行级和语句级触发器不是“选哪个更好”，而是“解决不同问题的工具”——混淆它们，轻则逻辑失效，重则锁表或死循环。尤其在迁移数据库时，FOR EACH 的默认行为差异最容易被忽略。