ORA-04091不是触发器写错，而是Oracle为保障读一致性主动阻止行级触发器中查询正在修改的表；正确解法是使用COMPOUND TRIGGER，在AFTER EACH ROW阶段仅暂存数据，所有SELECT和DML操作移至AFTER STATEMENT阶段执行。
ora-04091 不是触发器写错了，而是 oracle 在告诉你：“这张表正在被改，你不能现在查它”。它不是 bug，是读一致性机制主动拦下的危险操作。
为什么行级触发器里 SELECT 本表就报错
Oracle 要保证每个查询看到的是“语句开始时的快照”，但行级触发器（AFTER EACH ROW 或 BEFORE EACH ROW）运行在 DML 执行中途——此时表状态既不是修改前、也不是修改后，而是一个不稳定的中间态。哪怕只写 SELECT COUNT(*) FROM orders WHERE order_id = :NEW.order_id，Oracle 也会立刻抛出 ORA-04091。
- 错误跟语法无关：用游标、用子查询、加
PRAGMA AUTONOMOUS_TRANSACTION都不能绕过这个检查，只要语句出现在行级块里，就触发变异表校验 - 不是“不能读”，是“不能在这个上下文里读”：语句级阶段（
BEFORE STATEMENT/AFTER STATEMENT）查同一张表完全合法 - 常见误判：以为“只查一行”或“加了 WHERE 条件”就能躲过，其实 Oracle 不看条件，只看执行阶段和对象是否为触发表
自治事务（AUTONOMOUS_TRANSACTION）真能解决吗
能，但代价明确——它把触发器逻辑放进一个独立事务，绕开主事务的读一致性约束。但这不是“修复”，而是“隔离”。
-
PRAGMA AUTONOMOUS_TRANSACTION必须配对使用COMMIT或ROLLBACK，否则会报ORA-06519 - 自治事务查不到主事务未提交的变更：比如主事务刚 INSERT 一行，自治事务里的
SELECT看不到它 - 审计类场景可用（如写日志），但业务逻辑依赖实时数据时会出错，比如用自治事务查余额再扣款，可能扣错
复合触发器（COMPOUND TRIGGER）为什么是首选
因为它不绕开规则，而是按 Oracle 的设计节奏来：把“收集”和“处理”拆到不同阶段。
- 在
AFTER EACH ROW里只做轻量操作：比如把:NEW.id存进 PL/SQL 关联数组v_ids - 所有真正要查表、UPDATE 其他行、JOIN 关联表的动作，统一挪到
AFTER STATEMENT块里执行 - 必须用局部变量暂存数据（如
TYPE t_ids IS TABLE OF orders.id%TYPE INDEX BY PLS_INTEGER），不能依赖包变量——包变量在并发下不安全 - 如果漏掉
COMPOUND关键字，或把SELECT写在AFTER EACH ROW里，照样报ORA-04091
真正难的不是写对语法，而是判断哪些逻辑必须挪到语句级阶段、哪些数据需要提前暂存、以及并发时变量生命周期是否可控。这些细节不处理好，复合触发器也会悄悄失效。
