唯一能真正解决 ORA-04091 的方式，是在行级触发逻辑中彻底避免对本表的任何 SELECT、UPDATE 或 INSERT；所有表访问必须移到语句级阶段（BEFORE STATEMENT 或 AFTER STATEMENT），并用局部集合变量暂存中间数据。
唯一能真正解决 ORA-04091 的方式，是在行级触发逻辑中彻底避免对本表的任何 SELECT、UPDATE 或 INSERT；所有表访问必须移到语句级阶段（BEFORE STATEMENT 或 AFTER STATEMENT），并用局部集合变量暂存中间数据。
为什么行级触发器里查本表必报 ORA-04091
Oracle 不是禁止你写 SQL，而是禁止在 BEFORE EACH ROW 或 AFTER EACH ROW 中访问正被当前 DML 修改的同一张表。哪怕只写 SELECT COUNT(*) FROM orders WHERE id = :NEW.id，也会触发该错误。这不是语法限制，而是读一致性机制在起作用：事务尚未提交，表处于不可见、不可定义的“中间态”。
以下操作全会触发错误：
-
FOR rec IN (SELECT * FROM orders WHERE ...)游标遍历 - 调用一个内部含
SELECT的自定义函数 - 查一个基于本表的视图
COMPOUND TRIGGER 必须严格分离收集与处理
加 COMPOUND 关键字本身不解决问题——关键在于把逻辑拆到不同阶段：
- 声明局部集合变量，例如
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中统一执行，此时行集已确定，表状态稳定
别碰 PRAGMA AUTONOMOUS_TRANSACTION 和 GLOBAL TEMPORARY TABLE
它们能让代码“不报错”，但代价明确且不可接受：
-
PRAGMA AUTONOMOUS_TRANSACTION开启独立事务：查不到当前事务未提交的数据，也无法回滚主事务失败。比如靠它校验子记录数，主事务最后ROLLBACK了，校验却已生效 -
GLOBAL TEMPORARY TABLE需额外建表、INSERT、清理；无索引时AFTER STATEMENT阶段JOIN效率低；并发下若触发器递归调用（A→B→A），临时表数据可能混入无关行
两者都让逻辑变分散、难调试、难测试，Oracle 官方文档明确推荐 COMPOUND TRIGGER 为首选方案。
最容易被忽略的一点
复合触发器里只要有一处 SELECT 漏进 EACH ROW 块，整个触发器就还是变异的——哪怕其他部分都写对了。检查时重点盯住所有 AFTER EACH ROW 和 BEFORE EACH ROW 块，确保里面没有一句对本表的访问语句。
