唯一能真正防止 ora-04091 的方式是在 for each row 块中完全不查本表；其他如 pragma autonomous_transaction、全局临时表或调用含 select 的函数，均属掩盖问题，破坏事务一致性与并发安全。
唯一能真正防止 ORA-04091 的方式，是在 FOR EACH ROW 块里完全不查本表。其他所有“让代码跑起来”的做法——比如加 PRAGMA AUTONOMOUS_TRANSACTION、写全局临时表、调用含 SELECT 的函数——都不是修复，而是掩盖问题，且会破坏事务一致性或并发安全。
为什么行级触发器里查本表必报 ORA-04091
Oracle 不是禁止你写 SELECT，而是禁止在 BEFORE EACH ROW 或 AFTER EACH ROW 这类行级上下文中访问正被当前 DML 修改的同一张表。哪怕只写 SELECT COUNT(*) FROM orders WHERE id = :NEW.id，也会触发检查。
这不是语法错误，是读一致性机制在起作用：事务还没提交，表处于中间态，“半成品”不可见。
-
FOR rec IN (SELECT * FROM orders WHERE ...)游标遍历 → 报错 - 调用一个内部含
SELECT的自定义函数 → 报错 - 查一个基于本表的视图 → 同样触发
ORA-04091
COMPOUND TRIGGER 必须严格分离收集与处理
关键不是加 COMPOUND 关键字，而是把逻辑拆到不同阶段：行级块只存数据，语句级块才查表。
- 声明局部集合变量，如
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，避免隐式循环性能下降
别碰 PRAGMA AUTONOMOUS_TRANSACTION 和 GLOBAL TEMPORARY TABLE
它们能绕过报错，但代价明确且不可接受：
-
PRAGMA AUTONOMOUS_TRANSACTION开启独立事务：查不到当前事务未提交的数据，也无法回滚主事务失败——比如你靠它校验子记录数，主事务最后ROLLBACK了，校验却已生效 -
GLOBAL TEMPORARY TABLE需额外建表、INSERT、清理；无索引时AFTER STATEMENT阶段JOIN效率低；并发下若触发器递归调用（A→B→A），临时表数据可能混入无关行 - 两者都让逻辑变分散、难调试、难测试，Oracle 官方文档明确推荐
COMPOUND TRIGGER为首选方案
最容易被忽略的一点：复合触发器里只要有一处 SELECT 漏进 EACH ROW 块，整个触发器就还是变异的。
