唯一能真正避开 ora-04091的方式是在行级触发器中完全不查本表；所有“绕开”方案都只是让代码跑起来，不是真解决。
唯一能真正避开 ORA-04091 的方式，是在行级触发器中完全不查本表；所有“绕开”方案都只是让代码跑起来，不是真解决。
为什么 AFTER EACH ROW 里查本表必报 ORA-04091
Oracle 不是禁止你写 SELECT，而是禁止在行级上下文（BEFORE EACH ROW 或 AFTER EACH ROW）中访问正被 DML 修改的同一张表。哪怕只写 SELECT COUNT(*) FROM orders WHERE id = :NEW.id，也会触发变异表检查——这不是语法错误，是读一致性机制在起作用：事务未提交，表状态不可见、不可定义。
常见错误现象：
-
FOR rec IN (SELECT * FROM orders WHERE id = :NEW.id) LOOP→ 仍报错，游标不是例外 - 函数被 SQL 调用，而函数内部查了正在被
UPDATE的表 → 同样触发ORA-04091 - 在
AFTER EACH ROW中用子查询更新另一张表，但子查询里又SELECT本表 → 报错
怎么写一个真正不报错的 COMPOUND TRIGGER
关键不是加 COMPOUND 关键字，而是把“收集”和“处理”彻底分开：行级阶段只存 ID 或标记，语句级阶段再统一查表。
- 声明局部集合变量，如
TYPE t_ids IS TABLE OF orders.order_id%TYPE INDEX BY PLS_INTEGER；不能用包变量（并发不安全） - 在
AFTER EACH ROW中只做轻量操作：l_ids(l_ids.COUNT + 1) := :NEW.order_id，绝不出现SELECT、UPDATE、INSERT同表语句 - 所有查表、
JOIN、聚合、写回动作，必须放在AFTER STATEMENT块里，此时行集已确定，表不“变异” - 示例中若漏掉
FORALL或误在AFTER EACH ROW写SELECT，仍会报ORA-04091
为什么别碰 PRAGMA AUTONOMOUS_TRANSACTION 和 GLOBAL TEMPORARY TABLE
它们能“让代码跑起来”，但代价是引入隐性风险，不是修复，是掩盖问题。
-
PRAGMA AUTONOMOUS_TRANSACTION开启独立事务，查不到当前事务的未提交变更，也无法回滚主事务的失败——比如你靠它校验子记录数，结果主事务最后ROLLBACK了，校验却已生效 -
GLOBAL TEMPORARY TABLE要额外建表、INSERT、清理；无索引时AFTER STATEMENT阶段JOIN效率低；并发下若触发器递归调用（A→B→A），临时表数据可能混入无关行 - 两者都让逻辑变分散、难调试、难测试，且 Oracle 官方文档明确推荐
COMPOUND TRIGGER为首选方案
最容易被忽略的一处硬伤
复合触发器里只要有一处 SELECT 漏进 AFTER EACH ROW，哪怕只查一行、只加 WHERE ROWNUM = 1，照样触发 ORA-04091。这不是 Oracle 的 bug，是设计使然——它根本不会去分析你的 SQL 是否真的会读到“变异”数据，只要语法上允许访问本表，就直接拦截。
