复合触发器是唯一合规解法，因Oracle禁止行级触发器读取正被修改的表；必须将SELECT等操作移至AFTER STATEMENT块，用局部变量暂存数据，严禁在EACH ROW块中查询触发表。
因为 Oracle 明确禁止在行级触发器中读取正被修改的表，这是读一致性机制的硬性限制，不是 bug，也不是配置问题。
ORA-04091 错误的本质是事务内“看自己改自己”不被允许
你在 BEFORE UPDATE EACH ROW 或 AFTER UPDATE EACH ROW 里写一句 SELECT COUNT(*) FROM orders WHERE status = 'SHIPPED'，哪怕只查本表、只查一行、只用 :NEW.id 做条件，也会立刻报 ORA-04091: table is mutating。这不是 Oracle “卡住了”，而是它主动拦住你——当前事务还没提交，表状态正在变化，读出来的数据既不可靠，也可能引发逻辑死循环。
常见误判点：
- 以为加个
WHERE id = :NEW.id就安全 → 不安全，只要查的是触发表，就违规 - 以为只影响单行就没事 → Oracle 不看行数，只看“是否在行级上下文查本表”
- 以为用视图或函数封装 SELECT 就能绕过 → 只要视图/函数内部查了触发表，照样报错
为什么 PRAGMA AUTONOMOUS_TRANSACTION 能“跑起来”，但不该用
它确实能让 SELECT 执行成功，代价是开启一个独立子事务：子事务看不到主事务未提交的数据，主事务回滚时，子事务已提交的操作无法撤销。
典型风险场景：
- 你在触发器里用自治事务查
T_USER做唯一性校验，返回“无重复”，主事务却因外键失败而回滚 → 校验结果失效，业务逻辑断层 - 自治事务里写的日志或计数，和主事务实际结果不一致，后续审计对不上
- 并发下多个触发器同时启动自治事务，可能互相锁表或读到过期快照
Oracle 官方文档明确将它列为“非推荐方案”，仅适用于审计日志等副作用可接受的场景。
复合触发器（COMPOUND TRIGGER）才是唯一合规解法
它不绕规则，而是把操作挪到 Oracle 允许的时间点：BEFORE STATEMENT 和 AFTER STATEMENT 阶段访问本表完全合法，因为此时整条 DML 的影响行集已确定或已执行完毕。
正确写法要点：
-
BEFORE EACH ROW或AFTER EACH ROW块里只做三件事：收集:NEW/:OLD值、轻量校验、存入局部变量（如TYPE t_ids IS TABLE OF orders.order_id%TYPE INDEX BY PLS_INTEGER） - 所有
SELECT、JOIN、聚合、写回逻辑，必须放在AFTER STATEMENT块里统一处理 - 必须用 PL/SQL 局部变量暂存数据，不能用包变量（并发不安全）
- 漏掉
FORALL或误在EACH ROW块里写SELECT，整个触发器仍会报ORA-04091
最容易被忽略的细节：只要有一处 SELECT 漏进行级块，就全盘失效
别信“我只查一行应该没事”“我加了 ROWNUM = 1 应该能绕过”——Oracle 不讲情面，只认阶段。哪怕整个触发器 99% 都按复合结构写了，只要某处 AFTER EACH ROW 里藏着一个 SELECT ... FROM orders，运行时就必然报错。检查时得逐行扫 SELECT 关键字，确认它没落在任何 EACH ROW 块内。
