BEFORE触发器先于AFTER触发器执行，具体顺序为：BEFORE STATEMENT → BEFORE EACH ROW → 实际修改 → AFTER EACH ROW → AFTER STATEMENT；同一级别按创建顺序执行但不可依赖。
BEFORE 和 AFTER 触发器在同一条语句中谁先执行？
before 触发器一定在语句实际修改数据前运行，after 触发器一定在其后运行——但这个“前后”是按触发级别（行级 / 语句级）严格分层的，不是简单的时间先后。
比如对一行执行 UPDATE，完整顺序是：BEFORE STATEMENT → BEFORE EACH ROW → 实际更新该行 → AFTER EACH ROW → AFTER STATEMENT。中间任何一步出错（如 RAISE_APPLICATION_ERROR），后续步骤全部跳过。
- 同一级别下（如多个
BEFORE EACH ROW），执行顺序由触发器创建顺序决定，不可靠，不应依赖 -
INSTEAD OF触发器只存在于视图上，它会替代原 DML，因此没有对应的AFTER行级阶段（只有AFTER STATEMENT） - 如果触发器里调用
SELECT ... FOR UPDATE或修改其他表，要注意死锁风险——BEFORE ROW拿不到新值的锁，但可能提前锁住关联资源
为什么在 BEFORE 触发器里改 :NEW 字段有效，AFTER 里却报错？
因为 :NEW 和 :OLD 是 PL/SQL 触发器上下文变量，它们的可写性由触发时机硬性约束：BEFORE ROW 中 :NEW 可读可写，用于拦截并修正待插入/更新的值；AFTER ROW 中 :NEW 已落地，只读，试图赋值会抛出 ORA-04084: cannot change NEW values for this trigger type。
- 常见错误：在
AFTER INSERT里写:NEW.name := UPPER(:NEW.name);—— 立刻报错 - 正确做法：需要改值，必须放在
BEFORE INSERT或BEFORE UPDATE - 注意：即使
BEFORE改了:NEW.col，也不会触发该列上的虚拟列或函数索引的自动重算（那是 DML 执行时的事）
触发器里调用自治事务（PRAGMA AUTONOMOUS_TRANSACTION）有什么坑？
自治事务会让触发器里的 DML 脱离主事务上下文独立提交，表面看能“记录日志不拖累主流程”，但极易导致数据不一致和逻辑断裂。
- 主事务回滚时，自治事务已提交的日志、计数器、状态变更全保留，形成孤立项
- 如果自治事务里查了主事务尚未提交的数据（比如
SELECT ... FROM t WHERE id = :NEW.id），查不到——因为隔离级别是READ COMMITTED，它看不见未提交的:NEW - 更隐蔽的问题：自治事务中调用含触发器的表，会重新进入触发链，但此时主事务的
:NEW/:OLD不可用，直接报ORA-04091: table is mutating
多行 DML（如 INSERT INTO ... SELECT）下，行级触发器执行几次？
取决于实际影响的行数，不是 SQL 语句数量。哪怕一条 INSERT 插入 1000 行，BEFORE EACH ROW 和 AFTER EACH ROW 各执行 1000 次。
- 性能敏感场景下，频繁访问序列、查表、发消息的操作，放行级触发器里就是放大 1000 倍开销
- 替代方案：用语句级触发器 + 批量处理逻辑（如把
:NEW相关 ID 缓存到包变量，AFTER STATEMENT再统一查一次） - 注意：Oracle 12c+ 的
IDENTITY列默认值，在BEFORE ROW里不可见，要等AFTER ROW才能读到生成的值（:NEW.id此时才非 NULL）
触发器最麻烦的地方不在语法，而在于它悄无声息地嵌入执行流——你改一行数据，背后可能已跑过三张表的校验、四次序列取值、两次远程调用。一旦出问题，堆栈里根本看不到触发器的名字，只有一串 ORA-04088 或锁等待。
