唯一能真正绕过 ora-04091的方式是使用compound trigger，将行级阶段仅用于收集id，语句级阶段统一查表处理，避免在after each row中访问本表。
唯一能真正绕过 ORA-04091 的方式，是不在 AFTER EACH ROW 或 BEFORE EACH ROW 里查本表——所有“让它跑起来”的方案，都会破坏事务一致性或并发安全。
为什么 SELECT 本表就报 ORA-04091
Oracle 不是禁止你写 SQL，而是禁止在行级上下文（比如 AFTER EACH ROW）中访问正被当前 DML 修改的同一张表。哪怕只写 SELECT COUNT(*) FROM orders WHERE id = :NEW.id，也会触发检查。这不是语法错误，是读一致性机制在起作用：事务未提交，表状态不可见、不可定义。
- 函数被 SQL 调用，而函数内部查了正在被
UPDATE的表 → 同样触发ORA-04091 -
FOR rec IN (SELECT * FROM orders WHERE id = :NEW.id) LOOP→ 仍报错，游标不是例外 - 哪怕加了
WHERE、只查一行、只用COUNT(*)，都无效
怎么写一个真正不报错的 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
为什么别碰 PRAGMA AUTONOMOUS_TRANSACTION 和临时表
它们能“让代码跑起来”，但代价是引入隐性风险，不是修复，是掩盖问题。
-
PRAGMA AUTONOMOUS_TRANSACTION开启独立事务，查不到当前事务的未提交变更，也无法回滚主事务的失败——比如你靠它校验子记录数，结果主事务最后ROLLBACK了，校验却已生效 -
GLOBAL TEMPORARY TABLE要额外建表、INSERT、清理；无索引时AFTER STATEMENT阶段JOIN效率低；并发下若触发器递归调用（A→B→A），临时表数据可能混入无关行 - 两者都让逻辑变分散、难调试、难测试，且 Oracle 官方文档明确推荐
COMPOUND TRIGGER为首选方案
最易被忽略的一点：局部集合变量必须在 AFTER STATEMENT 执行完后清空（如 l_ids.DELETE），否则下次同会话触发时可能残留旧数据；另外，FORALL 的批量操作要配对使用 INDICES OF 或 1 .. l_ids.COUNT，写错边界会导致跳过或越界。
