必须用compound trigger，因为行级触发器（for each row）中任何对触发表的select/update/delete均触发ora-04091；oracle强制读一致性，未提交的表状态不可见。compound trigger通过分阶段（尤其after statement）将表操作后移，配合局部集合变量暂存id，实现安全访问。
ORA-04091报错时，为什么必须用COMPOUND TRIGGER而不是普通触发器
因为行级触发器（FOR EACH ROW）里任何对触发表的SELECT、UPDATE或DELETE都会触发ORA-04091——Oracle不是在挑语法毛病，而是死守读一致性：你正在改的表还没提交，状态是“半成品”，它不让你查。哪怕只写SELECT COUNT(*) FROM orders WHERE order_id = :NEW.order_id，照样报错。
普通BEFORE/AFTER ROW触发器没地方躲；而COMPOUND TRIGGER把逻辑拆成四个阶段，其中BEFORE STATEMENT和AFTER STATEMENT允许安全访问原表——此时DML的行集已确定，表未处于“变异态”。
- 别指望
PRAGMA AUTONOMOUS_TRANSACTION救场：它会开独立事务，绕过主事务隔离，导致审计日志写进去了但主DML回滚了，数据不一致 -
GLOBAL TEMPORARY TABLE看似可行，但并发下不同事务可能互相覆盖临时表数据，且增加解析和I/O开销 - 函数被SQL调用时内部查了正被修改的表，同样触发
ORA-04091，跟触发器类型无关
COMPOUND TRIGGER必须写的四个关键部分
不是加个COMPOUND关键字就完事。真正起作用的是结构分段 + 变量暂存 + 表操作后移。缺一不可。
-
BEFORE STATEMENT：适合预读聚合值，比如提前查出当前父表总记录数，存在局部变量里供后续校验 -
BEFORE EACH ROW：只做轻量赋值或校验，比如检查:NEW.status是否合法，不能碰表 -
AFTER EACH ROW：只收集需要后续处理的数据，如把:NEW.order_id塞进TYPE t_ids IS TABLE OF orders.order_id%TYPE INDEX BY PLS_INTEGER -
AFTER STATEMENT：唯一能安全SELECT/UPDATE触发表的地方，所有汇总、写日志、刷新计数逻辑都放这儿
注意：TYPE ... INDEX BY PLS_INTEGER比VARRAY或嵌套表更合适——支持稀疏索引，且不会因EXTEND引发内存重分配问题。
AFTER EACH ROW里只能存ID，不能查关联数据
常见错误是想在AFTER EACH ROW里JOIN查客户名、订单明细等，结果又掉进ORA-04091坑里。行级阶段只负责“记账”，不负责“查账”。
- 正确做法：只存
:NEW.order_id或:NEW.customer_id到PL/SQL集合变量中 - 如果需关联字段（如客户姓名），必须留到
AFTER STATEMENT统一查，用FORALL或游标批量处理 - 别用包变量暂存数据：包变量是会话级的，并发事务会互相污染；必须声明在触发器体内的局部变量
- 示例中
l_ids(l_ids.COUNT + 1) := :NEW.order_id是安全的，但SELECT c.name INTO l_name FROM customers c WHERE c.id = :NEW.customer_id在AFTER EACH ROW里直接报错
Oracle 19c下COMPOUND TRIGGER的实操注意事项
19c对复合触发器语法无重大变更，但几个细节容易踩坑：
- 触发事件声明要明确，比如
FOR INSERT OR UPDATE OR DELETE ON orders，不能省略OR连接词 -
AFTER STATEMENT块里若用FORALL i IN INDICES OF v_ids，确保v_ids非空，否则INDICES OF会报ORA-06531（引用未初始化集合） - 如果触发器要处理大量数据（如单次更新上万行），
AFTER STATEMENT里的UPDATE建议加WHERE id IN (SELECT COLUMN_VALUE FROM TABLE(v_ids))，避免全表扫描 -
COMPOUND TRIGGER无法定义INSTEAD OF行为，视图场景仍需单独用INSTEAD OF触发器
最常被忽略的一点：复合触发器里所有变量声明必须放在触发器主体开头，不能分散在各阶段块内——否则AFTER STATEMENT根本看不到AFTER EACH ROW里存的数据。
