应使用COMPOUND TRIGGER，将查表逻辑移至AFTER STATEMENT阶段；FOR EACH ROW中访问本表会因读一致性机制触发ORA-04091，即使仅SELECT一行或使用游标、自治事务亦无效。
直接结论：别在 FOR EACH ROW 触发器里查或改本表，改用 COMPOUND TRIGGER，把查表逻辑挪到 AFTER STATEMENT 阶段。
为什么 SELECT 本表就报 ORA-04091
Oracle 不是“不让你写”，而是明确禁止你在行级上下文（BEFORE/AFTER EACH ROW）中访问正被 DML 修改的同一张表——哪怕只查一行、只用游标、只算 COUNT(*)。这不是语法错误，是读一致性机制在起作用：事务未提交，表状态不可见、不可定义。
-
FOR rec IN (SELECT * FROM orders WHERE id = :NEW.id) LOOP→ 仍触发检查，游标不是例外 -
PRAGMA AUTONOMOUS_TRANSACTION能绕过报错，但查不到当前事务未提交的数据，且需手动COMMIT/ROLLBACK，破坏事务原子性 - 函数被 SQL 调用，而函数内部查了正被 UPDATE 的表 → 同样触发
ORA-04091
怎么写一个真正不报错的 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 不讲情面，只认阶段。
