唯一能真正规避 ORA-04091 的方式是将“收集”与“处理”分离：行级触发器仅存 ID，语句级触发器再查表；其本质是读一致性机制禁止查询未提交事务中的中间态数据。
唯一能真正规避 ORA-04091 的方式，是把“收集”和“处理”彻底拆开：行级阶段只存 ID，语句级阶段再查表。
为什么 SELECT 本表就报错？
Oracle 不是拦语法，而是拦读“半成品”。ORA-04091 的本质是读一致性机制在起作用：当前事务还没提交，表处于 DML 修改中的中间态，不允许任何查询去访问它——哪怕只查一行、只用 COUNT(*)、只走游标，都会触发检查。
常见踩坑点包括：
- 在
AFTER EACH ROW里写SELECT * FROM orders WHERE id = :NEW.id - 调用一个函数，而该函数内部执行了对触发表的查询
- 通过视图查触发表（如
v_orders基于orders），同样触发变异
复合触发器必须分四阶段写，但关键只用两个
复合触发器（COMPOUND TRIGGER）不是加个关键字就完事，必须严格利用其阶段隔离能力。真正起作用的是：AFTER EACH ROW 和 AFTER STATEMENT 的分工。
实操要点：
-
AFTER EACH ROW中只做三件事：判断条件、存:NEW.id到局部集合、不碰任何 SQL - 集合类型必须声明为局部变量，例如
TYPE t_ids IS TABLE OF orders.order_id%TYPE INDEX BY PLS_INTEGER;，不能用包变量（并发不安全） -
AFTER STATEMENT是唯一允许查本表的地方，所有SELECT、JOIN、UPDATE都放这里 - 若需批量更新，优先用
FORALL而非循环，避免隐式上下文切换
别碰自治事务和临时表：它们不是解法，是掩耳盗铃
PRAGMA AUTONOMOUS_TRANSACTION 和 GLOBAL TEMPORARY TABLE 确实能让代码跑起来，但代价是破坏事务语义：
- 自治事务查不到当前事务未提交的数据，校验结果可能失效；主事务回滚后，它的
INSERT或UPDATE却已生效 - 临时表要额外建表、
INSERT、清理；无索引时AFTER STATEMENT阶段JOIN效率极低；递归触发场景下数据还可能混入无关行 - 两者都让逻辑分散、难调试、难测试，且 Oracle 官方文档明确推荐
COMPOUND TRIGGER为首选方案
最容易被忽略的一点：批量 DML 下的性能塌方
一条 INSERT INTO ... SELECT 插入 10 万行，AFTER EACH ROW 就会被执行 10 万次——即使里面只做赋值，PL/SQL 引擎的上下文切换开销也很大。所以：
- 如果业务允许，优先考虑语句级触发器（不写
FOR EACH ROW） - 行级阶段绝不做任何隐式转换或函数调用（比如把
:NEW.id转成字符串再存） - 集合变量用
INDEX BY PLS_INTEGER，不用VARRAY或无索引的嵌套表，否则AFTER STATEMENT遍历时会慢
