ORA-04091本质是Oracle为保障读一致性而禁止在行级触发器中查询正被修改的表；COMPOUND TRIGGER通过分阶段（如AFTER STATEMENT）避开变异限制，自治事务虽可行但有副作用。
ORA-04091 报错本质是啥？不是 bug，是 Oracle 在拦你读“半成品”
当你在 after update each row 或 before insert each row 触发器里写了一句 select count(*) from orders where order_id = :new.order_id，oracle 立刻抛出 ora-04091: table orders is mutating——这不是它不讲情面，而是它在严格执行“读一致性”：当前事务还没提交，表正处在“被修改中”的中间态，不允许任何查询去窥探这个不稳定快照。
常见触发场景包括：
- 行级触发器里查本表（哪怕只查一行）
- 函数被 SQL 调用，而该函数内部又查了正在被 UPDATE 的表
- 级联触发器中，A 表触发器改 B 表，B 表触发器再回头查 A 表
COMPOUND TRIGGER 是怎么绕过变异限制的？靠分阶段+上下文隔离
复合触发器（COMPOUND TRIGGER）不是“强行读”，而是把逻辑拆到四个明确阶段：BEFORE STATEMENT、BEFORE EACH ROW、AFTER EACH ROW、AFTER STATEMENT。关键在于：BEFORE STATEMENT 和 AFTER STATEMENT 阶段访问表是完全允许的，因为此时整条 DML 还没开始或早已结束，表状态稳定。
实操建议：
- 把需要查表的逻辑挪到
BEFORE STATEMENT（如预统计总数）或AFTER STATEMENT（如汇总日志、刷新物化视图） - 行级逻辑只做轻量赋值、校验，别碰 SELECT/INSERT/UPDATE 同一表
- 要用到每行数据时，靠声明局部变量或
COLLECT INTO+INDEX BY表暂存:NEW/:OLD值，留到AFTER STATEMENT统一处理
示例片段（记录发货后审计日志）：
CREATE OR REPLACE TRIGGER orders_shipped_audit
FOR UPDATE ON orders
COMPOUND TRIGGER
TYPE t_order_ids IS TABLE OF orders.order_id%TYPE INDEX BY PLS_INTEGER;
l_ids t_order_ids;
AFTER EACH ROW IS
BEGIN
IF :NEW.status = 'SHIPPED' AND :OLD.status != 'SHIPPED' THEN
l_ids(l_ids.COUNT + 1) := :NEW.order_id;
END IF;
END AFTER EACH ROW;
AFTER STATEMENT IS
BEGIN
FOR i IN 1..l_ids.COUNT LOOP
INSERT INTO order_audit (order_id, action, audit_message)
SELECT l_ids(i), 'SHIPPED', 'Order shipped to customer ' || c.customer_id
FROM orders o JOIN customers c ON o.customer_id = c.customer_id
WHERE o.order_id = l_ids(i);
END LOOP;
END AFTER STATEMENT;
END;
自治事务（AUTONOMOUS_TRANSACTION）能用，但得清楚代价
加 PRAGMA AUTONOMOUS_TRANSACTION 确实能让你在行级触发器里直接查本表，因为它开了一个独立事务分支，不受主事务“变异”影响。但它不是银弹：
- 自治事务提交/回滚不影响主事务，但主事务回滚时，它已提交的数据不会撤回 → 审计日志写了就写了，哪怕订单更新最终失败
- 频繁调用会增加事务管理开销，尤其高并发下可能成性能瓶颈
- 调试困难：两个事务并行，锁行为、时序、日志落盘都更难追踪
仅建议用于强需求且副作用可控的场景，比如写审计日志、发告警、调外部接口——且必须显式 COMMIT，否则报 ORA-06519。
别踩这些坑：全局变量、版本兼容性、测试盲区
老方案用包变量（instructor_pack.g_instructor_id）缓存值，在 11g+ 已非首选：它依赖触发器执行顺序，多行 DML 下易覆盖；且无法区分 INSERT 和 UPDATE 的不同语义。
注意点：
-
COMPOUND TRIGGER是 Oracle 11g 引入的，10g 及更早不支持，升级前务必确认版本 - 测试时别只跑单行 SQL；必须用
UPDATE orders SET status='SHIPPED' WHERE order_id IN (1,2,3)多行验证，否则发现不了INDEX BY越界或集合未初始化问题 - 触发器里调用的函数，如果也查了本表，同样会触发
ORA-04091——复合触发器只保护自身，不递归保护被调函数
真正麻烦的从来不是语法怎么写，而是你得想清楚：这条日志到底该在“事务开始前”查，还是“所有行处理完后”查，抑或“必须和每一行强绑定”——选错阶段，再对的语法也救不回逻辑漏洞。
