唯一能彻底避开 ORA-04091 的做法是在行级触发器中不查本表；Oracle 禁止在 FOR EACH ROW 中执行任何本表 SELECT、JOIN 或调用含 SELECT 的函数，因事务中表状态未固化；PRAGMA AUTONOMOUS_TRANSACTION 虽可绕过但导致数据不一致；COMPOUND TRIGGER 必须将收集逻辑放 AFTER EACH ROW、查表与更新放 AFTER STATEMENT，并严格禁用包变量和行级查询。
别在行级触发器里查本表，这是唯一能彻底避开 ORA-04091 的做法。 Oracle 不是卡语法，而是拒绝读取事务中途的“半成品表”。任何 SELECT、JOIN、甚至调用含 SELECT 的函数，只要发生在 FOR EACH ROW 触发器中，就必然报错。
为什么 PRAGMA AUTONOMOUS_TRANSACTION 是个危险捷径
它确实能让 SELECT 执行成功，但代价是脱离主事务上下文：
- 查不到当前事务中尚未提交的行——比如你正批量插入 100 条订单，自治事务里查
orders表永远只看到旧数据 - 主事务回滚时，自治事务已提交的写操作（如日志、校验失败抛错）无法撤销，导致状态不一致
- 无法用于依赖新值做聚合或跨行判断的场景，例如“同一客户本次插入不能超 3 单”
COMPOUND TRIGGER 必须这样写才真正安全
关键不在关键字，而在阶段隔离。漏掉任意一条规则，仍会触发 ORA-04091：
- 声明局部集合变量，例如
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、INSERT、UPDATE同表语句 - 所有查表逻辑必须挪到
AFTER STATEMENT块中，此时 DML 已完成，表状态固化，SELECT安全 - 若需批量更新，用
FORALL i IN INDICES OF l_ids，别手写循环——否则性能差且易漏处理
容易被忽略的硬性限制
Oracle 对阶段边界极其严格：
- 哪怕只在
AFTER EACH ROW里加了一行SELECT COUNT(*) FROM orders WHERE id = :NEW.id，整个触发器就失效 -
WHEN子句、游标FOR rec IN (SELECT ...)、视图查询（只要底层依赖触发表），全算违规 - 级联触发场景（A 表改 B 表，B 表触发器再查 A 表）同样触发变异检查，COMPOUND 也得逐层改写
最常出问题的地方不是逻辑多复杂，而是某处 SELECT 被悄悄塞进了行级块——Oracle 不看意图，只认位置。
