ORA-04091 是Oracle变异表错误，因行级触发器中直接查询/修改被DML的同一张表导致；复合触发器通过分阶段（BEFORE/AFTER STATEMENT等）将表访问移至语句级阶段，并用PL/SQL变量暂存数据，从而规避该错误。
什么是 ORA-04091 及为什么复合触发器能解决它
ora-04091 是 oracle 在触发器中尝试查询或修改“正在被 dml 操作的同一张表”时抛出的变异表错误。根本原因是：oracle 为保证语句级一致性，禁止在 for each row 触发器里直接查该表（哪怕只是 select count(*)），因为此时表状态未提交、不可见、也不稳定。
复合触发器（COMPOUND TRIGGER）之所以有效，是因为它把执行逻辑拆成四个明确阶段：BEFORE STATEMENT → BEFORE EACH ROW → AFTER EACH ROW → AFTER STATEMENT，其中只有 STATEMENT 级别阶段允许安全访问原表——此时语句尚未提交但行集已确定，不会“变异”。
怎么写一个真正能用的 COMPOUND TRIGGER
关键不是加个 COMPOUND 关键字，而是把“要查表”的动作挪到 BEFORE STATEMENT 或 AFTER STATEMENT 块里，并用 PL/SQL 变量暂存中间结果。不能在 AFTER EACH ROW 中直接 SELECT 当前表。
- 用
BEFORE STATEMENT预读聚合值（如当前父表统计数），存在触发器级变量中 - 在
AFTER EACH ROW里只做轻量操作：收集 ID、更新关联缓存变量、或发通知，不碰原表 - 所有最终写回逻辑（比如更新父表计数）统一放到
AFTER STATEMENT，这时再UPDATE blatranscript安全 - 若需跨行传递数据（如多个子记录对应同一个父 ID），必须用 PL/SQL 关联数组（
TYPE ... IS TABLE OF ... INDEX BY ...）或嵌套表，不能依赖包变量——包变量在并发事务中不隔离
示例片段：
CREATE OR REPLACE TRIGGER tr_blatchildren_upd
FOR INSERT OR UPDATE OR DELETE ON blatchildren
COMPOUND TRIGGER
TYPE t_transcript_ids IS TABLE OF blatranscript.id%TYPE;
v_ids t_transcript_ids := t_transcript_ids();
AFTER EACH ROW IS
BEGIN
IF INSERTING OR UPDATING THEN
v_ids.EXTEND;
v_ids(v_ids.LAST) := :NEW.blatranscriptid;
END IF;
END AFTER EACH ROW;
AFTER STATEMENT IS
BEGIN
FORALL i IN INDICES OF v_ids
UPDATE blatranscript
SET child_count = (SELECT COUNT(*) FROM blatchildren WHERE blatranscriptid = v_ids(i))
WHERE id = v_ids(i);
END AFTER STATEMENT;
END;
常见踩坑点：你以为避开了，其实没躲过
即使用了 COMPOUND TRIGGER，仍可能报 ORA-04091，原因很具体：
-
AFTER EACH ROW里写了SELECT ... FROM blatchildren—— 这仍是变异表访问，立刻报错 - 在
BEFORE STATEMENT或AFTER STATEMENT中用了INSERT INTO ... SELECT FROM blatchildren，但忘了加WHERE条件过滤当前事务影响行，导致读到未提交脏数据（虽不报 ORA-04091，但逻辑错） - 误把
BEFORE EACH ROW当成“可以安全赋值”的地方，往包变量里写值，结果多个并发 INSERT 互相覆盖——包变量是会话级共享的，不是触发器实例私有 - 在
AFTER STATEMENT执行复杂子查询时，又间接引用了当前表的视图或物化视图，而该视图底层含blatchildren，照样变异
还有没有更简单的替代方案？
复合触发器不是银弹。如果业务允许，优先考虑这些更稳、更易维护的方式：
- 用
PRAGMA AUTONOMOUS_TRANSACTION开自治事务——适合日志记录、审计等“旁路写入”，但不能用于校验或反向更新主业务表，否则破坏事务原子性 - 把校验逻辑提到应用层：插入子记录前先查父表状态，由应用决定是否继续，避免在数据库内绕弯
- 改用物化视图 + 快速刷新，让父表统计值异步衍生，彻底脱离触发器链
- Oracle 12c+ 可考虑使用
EDITION-BASED REDIFINITION或DBMS_SCHEDULER延后处理，但引入调度延迟，不适合强实时场景
真正难的从来不是写对语法，而是判断哪一层该承担哪部分职责——数据库触发器越重，越容易变成黑盒和性能瓶颈。复合触发器只是给了你一把更精细的手术刀，但切哪儿、切多深，还得看业务脉络。
