ORA-04091是Oracle读一致性机制所致，非语法错误；行级触发器中禁止查本表，复合触发器通过BEFORE/AFTER STATEMENT阶段操作规避变异；禁用PRAGMA AUTONOMOUS_TRANSACTION和临时表；SQL%ROWCOUNT仅在AFTER STATEMENT阶段反映真实影响行数。
为什么行级触发器里查本表必报 ORA-04091
不是语法写错了，是 Oracle 主动拦你——它不允许在 FOR EACH ROW 触发器里对正被修改的触发表执行任何 SELECT（哪怕只查一行）、UPDATE 或 DELETE。这不是限制，而是读一致性机制在起作用：事务还没提交，表处于“中间态”，查询结果不可定义。
常见误判包括：
-
FOR rec IN (SELECT * FROM orders WHERE id = :NEW.id) LOOP→ 仍报错，游标不例外 - 函数被 SQL 调用，而该函数内部查了触发表 → 同样触发
ORA-04091 - 级联触发器中 A 表改 B 表、B 表再回头查 A 表 → 也属于变异场景
复合触发器（COMPOUND TRIGGER）怎么真正避开变异限制
它不绕开规则，而是把操作挪到 Oracle 允许的时间点：BEFORE STATEMENT 和 AFTER STATEMENT 阶段访问原表完全合法，因为此时 DML 的行集已确定、表状态稳定。
关键实操要点：
- 行级阶段（
BEFORE EACH ROW/AFTER EACH ROW）只做三件事：收集:NEW/:OLD值、轻量校验、赋值给局部变量（如TYPE t_ids IS TABLE OF orders.order_id%TYPE INDEX BY PLS_INTEGER） - 所有查表、
JOIN、聚合、写回动作，必须放在AFTER STATEMENT（或BEFORE STATEMENT）中统一处理 - 绝不能用包变量暂存 ID —— 并发下不安全；必须用触发器内声明的局部集合变量
- 漏掉
FORALL或误在AFTER EACH ROW写SELECT，照样报错
为什么别碰 PRAGMA AUTONOMOUS_TRANSACTION 和临时表
它们能让代码“跑起来”，但代价是引入隐性风险，不是修复，是掩盖问题。
具体问题：
-
PRAGMA AUTONOMOUS_TRANSACTION开启独立事务，查不到当前事务未提交的数据，也无法回滚主事务失败 —— 比如你靠它校验子记录数，结果主事务最后ROLLBACK了，校验却已生效 -
GLOBAL TEMPORARY TABLE要额外建表、INSERT、清理；无索引时AFTER STATEMENT阶段JOIN效率低；并发下若触发器递归调用（A→B→A），临时表数据可能混入无关行 - 两者都让逻辑变分散、难调试、难测试，Oracle 官方文档明确推荐
COMPOUND TRIGGER为首选方案
最易被忽略的一点：行级阶段连 SQL%ROWCOUNT 都不可信
在 AFTER EACH ROW 中调用 SQL%ROWCOUNT 返回的是该触发器体内部最近一条 SQL 的影响行数，不是当前 DML 的总行数。真要统计整批操作影响了多少行，必须在 AFTER STATEMENT 阶段用 SQL%ROWCOUNT —— 此时它才反映原始语句的真实结果。
这个细节常被跳过，导致审计日志里“本次更新了 X 行”的计数错得离谱，而且很难复现和定位。
