在 Oracle 19c 里，很多人写触发器时并不是语法出了问题，而是逻辑放错了阶段：一边在 FOR EACH ROW 中处理当前行，一边又去查或改正在变动的那张表，结果立刻遇到 ORA-04091。这类问题的关键不在“怎么绕过报错”，而在于理解 Oracle 的读一致性规则，以及为什么复合触发器能把危险操作安全地后移。
下面按实际开发最容易踩坑的顺序来拆解：先说明为什么普通行级触发器不行，再看 COMPOUND TRIGGER 的四段结构应该各自承担什么职责，最后补上 Oracle 19c 下容易忽略的实现细节和边界限制。
为什么 ORA-04091 往往只能用复合触发器解决
出现 ORA-04091 的根本原因，是 Oracle 不允许你在行级触发器里再次访问当前正在被 DML 修改的那张表。只要在 FOR EACH ROW 阶段对触发表执行 SELECT、UPDATE 或 DELETE，就可能触发表变异错误。
这不是语法限制，而是读一致性在发挥作用。因为当前事务尚未提交，表处于变化中的中间状态，Oracle 不会把这张“半成品”表再暴露给同一个行级触发器去读写。即使只是下面这种看起来很轻量的查询，也一样会报错：
SELECT COUNT(*) FROM orders WHERE order_id = :NEW.order_id普通的 BEFORE ROW 或 AFTER ROW 触发器没有合适的阶段来规避这个问题，但 COMPOUND TRIGGER 不一样。它把逻辑拆成多个执行阶段，其中 BEFORE STATEMENT 和 AFTER STATEMENT 可以承担安全访问原表的工作，把真正的表查询、汇总和更新从行级阶段挪出去。
为什么常见“绕过方案”不适合替代
PRAGMA AUTONOMOUS_TRANSACTION并不是可靠补丁。它会开启独立事务，可能造成主 DML 回滚了，但审计日志已经写入，最终留下数据不一致。GLOBAL TEMPORARY TABLE看起来能中转数据，但并发场景下维护成本更高，还会增加解析与 I/O 开销。即使不是在触发器主体里直接查询，只要函数被 SQL 调用，而函数内部又访问了正被修改的表，同样可能触发
ORA-04091，与是否写成普通触发器无关。
复合触发器的四个关键阶段怎么分工
COMPOUND TRIGGER 真正有效的地方，不只是多了一个关键字，而是它允许你把逻辑拆成“先收集、后处理”的结构。要避免 ORA-04091，通常离不开这三件事：结构分段、局部变量暂存、表操作后移。
BEFORE STATEMENT：预读可复用的数据
这个阶段适合做整条语句级别的准备工作，例如提前读取聚合值、父表记录数或其他后续会复用的数据，再存入局部变量，供后面的行处理逻辑使用。
BEFORE EACH ROW：只做轻量校验或赋值
这一段仍然属于行级阶段，适合处理 :NEW、:OLD 的简单判断，例如校验 :NEW.status 是否合法，或者补齐默认值。这里不应该访问触发表。
AFTER EACH ROW：只收集 ID，不做查询
这是复合触发器中最容易写歪的部分。它的职责不是查表，而是把后续要处理的主键或关联键先记录下来，例如：
TYPE t_ids IS TABLE OF orders.order_id%TYPE INDEX BY PLS_INTEGER随后在行级处理中把当前键值放进集合，等语句执行完再统一处理。这里推荐使用 TYPE ... INDEX BY PLS_INTEGER，相比 VARRAY 或嵌套表，它更适合这类临时收集场景：支持稀疏索引，也不会因为 EXTEND 带来额外的内存重分配问题。
AFTER STATEMENT：把真正的表操作放到这里
所有需要安全访问触发表的动作，都应该集中到 AFTER STATEMENT。包括统一查询、批量更新、汇总、写日志、刷新计数等，都应放在这一阶段执行。
也就是说，复合触发器的核心模式其实很明确：行级阶段只负责记下“要处理谁”，语句级阶段再负责“如何真正处理”。
为什么 AFTER EACH ROW 里只能存 ID，不能顺手查关联数据
实际项目里最常见的错误，是在 AFTER EACH ROW 里一边收集主键，一边顺手去查客户名、订单明细或其他关联字段。只要查询路径最终碰到当前正在修改的表，还是会再次落入 ORA-04091。
因此，行级阶段应该遵守一个简单原则：只记账，不查账。
正确做法是只保存
:NEW.order_id、:NEW.customer_id这类后续处理所需的键值到 PL/SQL 集合变量中。如果确实需要客户姓名等关联字段，应该留到
AFTER STATEMENT统一查询，再用FORALL或游标做批量处理。不要使用包变量暂存数据。包变量是会话级的，在并发事务下可能互相污染；这里必须使用定义在触发器体内的局部变量。
下面这类写法是安全的：
l_ids(l_ids.COUNT + 1) := :NEW.order_id但如果在 AFTER EACH ROW 里直接写下面的查询，就会出问题：
SELECT c.name INTO l_name FROM customers c WHERE c.id = :NEW.customer_idOracle 19c 下的实操注意事项
Oracle 19c 对 COMPOUND TRIGGER 语法没有大的变化，但实现时仍有几个很容易被忽略的细节。
1. 事件声明必须写完整
触发事件需要明确列出，例如：
FOR INSERT OR UPDATE OR DELETE ON orders这里的 OR 连接词不能省略。
2. 使用 INDICES OF 前先确认集合已初始化
如果在 AFTER STATEMENT 中写了 FORALL i IN INDICES OF v_ids，必须先确保 v_ids 已初始化且非空。否则会触发 ORA-06531，也就是“引用未初始化集合”。
3. 大批量更新时尽量限制更新范围
如果一次语句可能影响上万行数据，AFTER STATEMENT 里的批量更新最好带上明确过滤条件，例如：
WHERE id IN (SELECT COLUMN_VALUE FROM TABLE(v_ids))这样可以减少全表扫描风险。
4. 复合触发器不能替代 INSTEAD OF 触发器
COMPOUND TRIGGER 无法定义 INSTEAD OF 行为。如果目标是视图触发器场景，仍然需要单独使用 INSTEAD OF 触发器。
5. 变量声明位置必须统一放在触发器体开头
这一点在排错时特别关键。复合触发器中，供各阶段共享的变量必须声明在触发器主体开头，不能分散写在不同阶段里。否则 AFTER STATEMENT 根本拿不到 AFTER EACH ROW 阶段收集到的数据。
写法判断标准：先收集，再处理
在 Oracle 19c 中，只要你的触发器需求涉及“行级处理时还要回头访问当前触发表”，就应该优先考虑 COMPOUND TRIGGER。判断一段逻辑是否安全的标准也很简单：
行级阶段只处理
:OLD、:NEW和轻量校验，不访问触发表；需要查询、汇总、更新原表的逻辑，统一放到
AFTER STATEMENT；阶段之间靠触发器体内的局部集合变量传递键值，而不是靠包变量或独立事务“补丁式”规避。
按这个思路组织代码，ORA-04091 这类问题通常就不是“难修”，而是“从一开始就能避开”。
