ora-04091报错是因for each row触发器中查询本表违反读一致性，正确解法是用compound trigger分离收集（after each row存id）与处理（after statement查表），禁用自治事务和临时表。
别在 FOR EACH ROW 触发器里查本表，Oracle 19c 仍严格执行读一致性规则，ORA-04091 不是 bug，是明确拒绝你读“半成品”。
为什么 SELECT 本表就报 ORA-04091？
Oracle 19c 的 MVCC 机制要求：只要触发器类型是 FOR EACH ROW，且内部出现对触发表的任何 SELECT（哪怕只查一行）、UPDATE 或 DELETE，就会拦截。这不是语法问题，而是阶段限制——行级上下文里表状态未固化，查询结果不可定义。
-
FOR rec IN (SELECT * FROM orders WHERE id = :NEW.id) LOOP→ 仍触发检查，游标不是例外 - 函数被 SQL 调用，而函数内
SELECT了正被UPDATE的表 → 同样报错 - 加了
PRAGMA AUTONOMOUS_TRANSACTION能跑通，但查不到当前事务未提交的数据，且需手动COMMIT/ROLLBACK，破坏原子性
怎么写一个真正不报错的 COMPOUND TRIGGER
关键不是加 COMPOUND 关键字，而是把“收集”和“处理”彻底分离：行级阶段只存 ID 或标记，语句级阶段再统一查表。
- 声明局部集合变量，如
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或误在AFTER EACH ROW写SELECT，仍会报ORA-04091
为什么别碰 GLOBAL TEMPORARY TABLE 和 PRAGMA AUTONOMOUS_TRANSACTION
它们能“让代码跑起来”，但代价是引入隐性风险，不是修复，是掩盖问题。
-
GLOBAL TEMPORARY TABLE要额外建表、INSERT、清理；无索引时AFTER STATEMENT阶段JOIN效率低；并发下若触发器递归调用（A→B→A），临时表数据可能混入无关行 -
PRAGMA AUTONOMOUS_TRANSACTION开启独立事务，查不到当前事务的未提交变更，也无法回滚主事务的失败——比如你靠它校验子记录数，结果主事务最后ROLLBACK了，校验却已生效 - 两者都让逻辑变分散、难调试、难测试，Oracle 官方文档明确推荐
COMPOUND TRIGGER为首选方案
最易被忽略的一点：复合触发器里只要有一处 SELECT 漏进 AFTER EACH ROW，整个触发器就还是变异的。别信“我只查一行应该没事”，Oracle 不讲情面，只认阶段。
