ORA-04091是Oracle为保障读一致性而禁止在行级触发器中查询正被修改的表；复合触发器通过将逻辑移至BEFORE/AFTER STATEMENT阶段、用PL/SQL变量暂存:NEW/:OLD值来安全绕过，避免自治事务的快照偏差与并发风险。
ora-04091 错误不是触发器写错了，而是 oracle 在严格执行读一致性——你不能在行级触发器里查正被 dml 修改的同一张表，哪怕只查 count(*) 或 max(id)。12c 的复合触发器（compound trigger）是目前最干净、最可控的解法，前提是逻辑必须严格分阶段、数据必须靠变量中转。
为什么复合触发器能绕过 ORA-04091
Oracle 禁止的是“在行级上下文中访问变异表”，而复合触发器把执行拆成四个隔离阶段：BEFORE STATEMENT、BEFORE EACH ROW、AFTER EACH ROW、AFTER STATEMENT。其中只有 BEFORE EACH ROW 和 AFTER EACH ROW 阶段受变异限制；BEFORE STATEMENT 和 AFTER STATEMENT 阶段访问原表完全合法——此时语句尚未开始或早已结束，表状态稳定。
关键不在加了 COMPOUND 关键字，而在把“查表”动作彻底移出 EACH ROW 块。
必须用 PL/SQL 变量暂存行数据
行级阶段不能碰表，但可以安全地收集 :NEW 和 :OLD 值。这些值必须存在局部变量里，留到语句级阶段统一处理。不能用包变量，它在并发事务中不隔离；推荐用 TYPE ... IS TABLE OF ... INDEX BY PLS_INTEGER 或嵌套表。
-
AFTER EACH ROW里只做三件事：判断条件、收集主键（如v_ids.EXTEND; v_ids(v_ids.LAST) := :NEW.order_id;）、更新内存缓存 - 不要在
AFTER EACH ROW里调用函数、查表、发 DBMS_OUTPUT、甚至写日志表（除非目标表与触发表无关） - 如果要跨行聚合（比如按部门统计新插入人数），必须在
BEFORE STATEMENT预读，或在AFTER STATEMENT统一查，不能边插边算
常见踩坑点：写了 COMPOUND 还报 ORA-04091
这说明你没真正避开变异上下文。典型错误包括：
- 在
AFTER EACH ROW中直接写SELECT ... FROM blatchildren WHERE blatranscriptid = :NEW.blatranscriptid - 在
AFTER EACH ROW中调用了自定义函数，而该函数内部又SELECT了触发表 - 误以为
BEFORE EACH ROW能查表——它同样受变异限制 - 用
FORALL批量更新时，WHERE 条件里仍引用了触发表字段（应只用已暂存的 ID 变量）
只要任何 SQL 语句在 EACH ROW 块里执行并触及触发表，无论是否带 COMPOUND，都会触发 ORA-04091。
对比自治事务：为什么 COMPOUND 更值得优先选
自治事务（PRAGMA AUTONOMOUS_TRANSACTION）确实能绕过变异限制，但它会开启一个独立事务，带来真实副作用：
- 它看到的是事务开始前的数据快照（即未包含当前 DML 的变更），结果可能不符合业务预期
- 它的提交/回滚与主事务无关，一旦出错，审计和恢复链断裂
- 在高并发场景下，容易引发不可见的锁竞争和性能抖动
- 违反 ACID 中的“一致性”隐含契约：你本想基于“这次修改后的状态”做判断，却查到了旧状态
复合触发器没有这些代价，它只是把操作延后到语句完成时，数据仍是本次 DML 的最终态——这才是大多数业务逻辑真正需要的。
真正难的不是写对语法，而是把线性思维的业务逻辑重新切分成“收集 → 暂存 → 批量处理”三步，并确保所有中间状态都只存在于 PL/SQL 变量中，不泄露到 SQL 层。这点一旦疏忽，错误就藏得极深。
