ORA-04091 是 Oracle 为防止读取未提交的中间态表而强制报错，唯一安全解法是使用 COMPOUND TRIGGER，将 SELECT 等查表操作严格限制在 BEFORE/AFTER STATEMENT 块中，行级块仅收集数据标识。
ORA-04091 不是代码写错了，而是 Oracle 在阻止你读一个“还没定型”的表——只要你在行级触发器（BEFORE EACH ROW 或 AFTER EACH ROW）里对正在被修改的本表执行 SELECT，就必然触发。唯一真正安全、可维护的解法是用 COMPOUND TRIGGER，并把所有查表逻辑严格挪到 AFTER STATEMENT 或 BEFORE STATEMENT 块中。
为什么 SELECT 本表就报 ORA-04091
Oracle 的读一致性机制要求：每个查询必须基于某个确定的 SCN 快照。而 DML 正在进行时，目标表处于中间态——既不是修改前，也不是修改后，无法构建一致视图。所以哪怕只写 SELECT COUNT(*) FROM orders WHERE id = :NEW.id，也会被拦下。
- 游标遍历（
FOR rec IN (SELECT ...)）照样报错 - 调用一个内部含
SELECT的函数，只要该函数被行级触发器调用，也触发检查 - 查一个基于本表的视图，等同于查本表，同样变异
-
WHEN子句里嵌套子查询（如:NEW.status IN (SELECT code FROM status_config...)）也会触发，因为子查询在行级上下文中执行
为什么 PRAGMA AUTONOMOUS_TRANSACTION 和临时表不是解法
它们能让代码“不报错”，但代价是破坏事务语义和并发安全，属于掩盖问题而非修复。
-
PRAGMA AUTONOMOUS_TRANSACTION开启独立事务：查不到当前事务未提交的数据，也无法响应主事务的ROLLBACK。比如你靠它校验子记录数，主事务失败回滚了，校验却已生效 -
GLOBAL TEMPORARY TABLE需额外建表、INSERT、清理；无索引时AFTER STATEMENT阶段 JOIN 效率低；并发下若触发器递归调用（A→B→A），临时表数据可能混入无关行 - 两者都让逻辑分散、难调试、难测试，Oracle 官方文档明确推荐
COMPOUND TRIGGER为首选方案
怎么写一个真正不报错的 COMPOUND TRIGGER
关键不是加 COMPOUND 关键字，而是把“收集”和“处理”物理隔离：行级块只存 ID 或标记，语句级块才查表、JOIN、更新。
- 声明局部集合变量，如
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中统一执行；此时行集已确定，表状态稳定 - 批量更新优先用
FORALL，避免隐式循环性能下降
最容易被忽略的一处致命细节
复合触发器里只要有一处 SELECT 漏进 EACH ROW 块（哪怕藏在函数里、视图里、WHEN 条件里），整个触发器就还是变异的。截至 2026 年 9 月，这个限制没有例外，也没有绕过路径——分阶段是硬性前提，不是可选优化。
