复合触发器必须用 AFTER STATEMENT 处理批量 DML，因为 BEFORE/AFTER EACH ROW 在批量操作中不保证执行；需在 BEFORE STATEMENT 设置标志，在 AFTER STATEMENT 统一判断操作类型并处理。
复合触发器必须用 AFTER STATEMENT 处理批量DML
Oracle 21c 的复合触发器（COMPOUND TRIGGER）本身不支持对 INSERT/UPDATE/DELETE 的每一行单独触发——它只在语句级分阶段响应。如果你期望“每插入一行就校验一次”，直接写 FOR EACH ROW 子句是无效的；复合触发器里没有传统行级触发器那种隐式逐行上下文。
常见错误现象是：批量插入 1000 行，BEFORE EACH ROW 段完全没执行，或只执行了一次；而你实际想在每行插入前做字段校验、生成 UUID 或记录原始值。
-
BEFORE STATEMENT：整个 DML 语句开始前执行一次，适合初始化集合变量、开游标、清临时表 -
BEFORE EACH ROW：**仅当触发器被定义为复合触发器且 DML 是单行时才可靠触发**；批量 DML 下该段可能被跳过或行为未定义（尤其在 Oracle 21c 的优化路径下） -
AFTER EACH ROW：同上，不能依赖其稳定执行——官方文档明确说明“不保证在批量操作中被调用” -
AFTER STATEMENT：唯一能 100% 确保执行的阶段，此时:OLD和:NEW不可用，但你可以通过BULK COLLECT INTO预先缓存的集合做最终处理
INSERTING 和 UPDATING 判断必须放在 AFTER STATEMENT 内部
很多人误以为可以在 BEFORE EACH ROW 里用 IF INSERTING THEN ... 做分支逻辑，但批量场景下这个判断会失效。真正安全的做法是：在 BEFORE STATEMENT 阶段声明一个布尔标志，再在 AFTER STATEMENT 中统一判断操作类型并处理。
例如，你想对批量插入的每条记录生成审计日志，又想对更新记录打标记：
CREATE OR REPLACE TRIGGER tr_emp_audit
FOR INSERT OR UPDATE ON employees
COMPOUND TRIGGER
l_is_inserting BOOLEAN := FALSE;
l_is_updating BOOLEAN := FALSE;
BEFORE STATEMENT IS
BEGIN
IF INSERTING THEN l_is_inserting := TRUE; END IF;
IF UPDATING THEN l_is_updating := TRUE; END IF;
END BEFORE STATEMENT;
AFTER STATEMENT IS
BEGIN
IF l_is_inserting THEN
INSERT INTO emp_audit_log (op_type, op_time)
SELECT 'INSERT', SYSDATE FROM DUAL CONNECT BY LEVEL <= SQL%ROWCOUNT;
ELSIF l_is_updating THEN
UPDATE emp_audit_log SET updated_at = SYSDATE WHERE op_type = 'UPDATE';
END IF;
END AFTER STATEMENT;
END;
注意：SQL%ROWCOUNT 在 AFTER STATEMENT 中返回本次 DML 影响的总行数，这是唯一可靠的批量计数来源。
要用 BULK COLLECT + FORALL 替代行级逻辑
复合触发器里无法自然拿到批量 DML 的全部新旧值，必须主动捕获。标准做法是在 BEFORE STATEMENT 声明集合类型，在 AFTER EACH ROW（即使不保证执行）或更稳妥地——**改用 AFTER STATEMENT 中的查询回捞**。
但更推荐的方式是：放弃依赖触发器内部逐行收集，转而在触发器外用 PL/SQL 过程封装完整逻辑，比如：
- 先用
INSERT ... SELECT或FORALL批量写入主表 - 再用
SELECT ... BULK COLLECT INTO拉出刚插入的数据 - 最后用
FORALL批量写入日志或校验表
这样比硬塞进复合触发器更可控、可测试、易调试。Oracle 官方也建议：复杂批量逻辑不要强塞进触发器，尤其涉及事务边界和异常传播时。
复合触发器无法绕过 mutating table 限制
即使用了复合触发器，如果在 AFTER EACH ROW 或 AFTER STATEMENT 里直接查正在被修改的表（比如 SELECT COUNT(*) FROM employees），仍会报 ORA-04091: table is mutating。这不是 bug，是 Oracle 的一致性保护机制。
解决方式只有两种：
- 用自治事务（
PRAGMA AUTONOMOUS_TRANSACTION），但会脱离原事务上下文，日志可能不回滚 - 用全局临时表（
GTTS）暂存中间数据，再在AFTER STATEMENT中关联处理
别指望复合触发器自动帮你解变异表问题——它只是把触发时机拆得更细，底层约束没变。
真正复杂的批量校验或跨表联动，触发器不是首选方案。把逻辑提到应用层或用物化视图+定时任务更稳。
