ora-04091 根本原因是行级触发器中访问变异表违反oracle读一致性规则；游标和临时表只是绕行且有缺陷，推荐用compound trigger在after statement阶段批量处理。
ORA-04091 不是触发器写错了，而是 Oracle 在告诉你：“这张表正在被改，你不能现在查它”。用游标或临时表绕开它，本质上是在自欺欺人——游标查的还是变异表，临时表要额外维护、并发不安全，都不推荐作为主方案。
为什么游标在行级触发器里查本表照样报 ORA-04091
很多人以为“用游标 SELECT 就不是直接查”，其实不然。只要语句出现在 BEFORE EACH ROW 或 AFTER EACH ROW 块里，哪怕包装成 FOR rec IN (SELECT ... FROM mytable WHERE id = :NEW.id) LOOP，Oracle 仍会判定为对变异表的访问。错误不是出在语法，而是执行阶段：行级上下文里，表状态未固化，任何 SQL 查询（包括游标）都会触发检查。
- 游标本质仍是 SQL 执行，受同一套读一致性规则约束
- 即使加了
PRAGMA AUTONOMOUS_TRANSACTION，也得手动 COMMIT/ROLLBACK，且无法读到当前事务未提交的变更 - 常见误写：
SELECT COUNT(*) INTO v_cnt FROM orders WHERE order_id = :NEW.order_id;→ 即使改成游标遍历，照样报错
临时表（GLOBAL TEMPORARY TABLE）真能躲过 ORA-04091 吗
能，但代价高、场景窄。临时表数据只对当前会话可见，且可设为 ON COMMIT DELETE ROWS，所以插入后立刻可查。但它不是“规避”，而是“换地方存”。你得先在行级触发器里把 :NEW/:OLD 值 INSERT 进去，再在语句级阶段读它——这多了一次 DML、一次表定义依赖、一次清理逻辑。
- 必须显式创建 GTT：
CREATE GLOBAL TEMPORARY TABLE temp_order_ids (id NUMBER) ON COMMIT DELETE ROWS; - 行级块里只能做
INSERT INTO temp_order_ids VALUES (:NEW.id);，不能带查询 - 临时表无索引（除非手动建），大数据量下
AFTER STATEMENT阶段 JOIN 效率低 - 并发事务之间隔离靠会话级，但若触发器被递归调用（如 A 表触发 B 表，B 表又触发 A 表），临时表内容可能混入无关数据
真正该用的解法：COMPOUND TRIGGER + 变量暂存
别绕路，直接用 Oracle 官方支持的机制。复合触发器把“收集”和“处理”拆开：行级阶段只收 ID 或计数，语句级阶段再批量查原表。整个过程不碰变异表的“行级上下文”，自然不触发检查。
- 声明关联数组：
TYPE t_ids IS TABLE OF orders.order_id%TYPE INDEX BY PLS_INTEGER; - 在
AFTER EACH ROW中仅做：v_ids(v_ids.COUNT + 1) := :NEW.order_id; - 所有
SELECT必须挪到AFTER STATEMENT，此时表已稳定，可安全聚合或 JOIN - 如果需关联其他表（如查客户名），
AFTER STATEMENT里用FORALL+INSERT ... SELECT，避免循环内单条 SQL
自治事务（AUTONOMOUS_TRANSACTION）什么时候能用
只适用于“日志记录”“发通知”这类与主事务逻辑解耦的操作。它会新开一个独立事务，不受主事务回滚影响，但也看不到主事务未提交的数据。
- 必须加
PRAGMA AUTONOMOUS_TRANSACTION;，且函数/过程体里要有COMMIT;或ROLLBACK; - 典型适用：
INSERT INTO audit_log VALUES (...); COMMIT;—— 日志必须落盘，不管主事务成败 - 绝对禁用场景：需要基于
:NEW.total_amount和当前订单最新状态（比如折扣后余额）做计算再更新另一张表 - 副作用明显：增加 UNDO 段压力、可能掩盖主事务异常（日志写了但主事务滚了）
最易被忽略的一点：哪怕用了 COMPOUND TRIGGER，只要在 AFTER EACH ROW 里写了任何对本表的 SELECT、INSERT、UPDATE、DELETE，哪怕只是 SELECT 1 FROM DUAL 套了个子查询去查本表，依然会报 ORA-04091。阶段划分不是装饰，是硬性执行边界。
