Oracle触发器不直接级联，但设计不当会引发逻辑级联；关键在于用COMPOUND TRIGGER将收集（AFTER EACH ROW）与执行（AFTER STATEMENT）严格分离，禁用行级查询/DML及包变量，确保仅依赖:NEW/:OLD。
Oracle 触发器本身不直接产生级联删除或更新，但容易因设计不当引发“逻辑级联”——比如一个触发器里执行 UPDATE 又触发另一个触发器，或在行级触发器中查本表导致 ORA-04091，进而被迫用自治事务绕过，结果造成数据不一致。避免的关键不是堵住某条语句，而是切断隐式依赖链。
为什么 AFTER INSERT 里 UPDATE 同表会形成隐式级联
这不是外键级联，而是触发器链式激活：AFTER INSERT ON orders 执行 UPDATE order_summary SET total = total + :NEW.amount，而 order_summary 上又有 BEFORE UPDATE 触发器去写日志表，日志表再触发审计规则……一层套一层，最终锁等待飙升、执行路径不可控。
- AFTER 触发器仍在原事务内，
UPDATE操作会持有新行 X 锁，同时尝试获取目标行锁，极易与外部业务 SQL 形成死锁循环 - 哪怕只加一行
SELECT COUNT(*) FROM orders WHERE user_id = :NEW.user_id，也会触发变异表检查（ORA-04091），逼你用PRAGMA AUTONOMOUS_TRANSACTION，结果查不到当前事务未提交数据 - Oracle 不区分“有意级联”和“无意嵌套”，只要触发器体里出现 DML 或 SELECT 到任何可能被当前事务修改的表，就进入高风险区
COMPOUND TRIGGER 怎么写才真正阻断级联链
复合触发器不是语法糖，是 Oracle 唯一能物理隔离阶段的机制。但很多人只写 FOR EACH ROW 和 AFTER STATEMENT，却在中间塞了包变量或行级查询，等于没用。
- 所有收集动作必须放在
AFTER EACH ROW块里，且仅做轻量赋值：l_ids(l_ids.COUNT + 1) := :NEW.order_id；禁用任何SELECT、INSERT、函数调用 -
AFTER STATEMENT块才是唯一允许查表和 DML 的地方，此时事务已固化，SELECT安全，FORALL i IN INDICES OF l_ids批量更新也安全 - 绝对禁用包变量（如
g_order_list）——并发下多个事务共享同一内存块，数据互相污染；也不允许用游标FOR rec IN (SELECT ...)，哪怕它看起来只读
哪些操作看似无害实则重启级联
很多开发者以为“只是读个配置表”“只是调个纯函数”，结果仍触发连锁反应。Oracle 的变异检查和执行计划绑定的是位置，不是意图。
-
WHEN子句里写:NEW.status IN (SELECT code FROM status_config WHERE active = 'Y')—— 行级块里含子查询，直接报ORA-04091 - 视图查询：哪怕
SELECT * FROM v_user_summary，只要该视图底层JOIN了orders表，就等同于查本表 - 级联触发场景：A 表触发器改 B 表，B 表触发器又去查 A 表的某个字段——Oracle 会全程跟踪跨表依赖，同样触发变异检查
- 自定义函数里藏了
SELECT：即使函数声明为DETERMINISTIC，只要运行时实际执行了 SQL，就会被拦截
真正阻断级联效应，靠的不是更复杂的触发器语法，而是把“查”和“改”严格分到不同阶段、不同事务上下文，并接受一个事实：行级触发器里，:NEW 和 :OLD 是你唯一能安全依赖的数据源，其余一切外部访问都必须推迟到语句级完成之后。
