after insert触发器本身非性能瓶颈，但行级执行、上下文开销及不当操作（如查/写表、函数调用）会导致吞吐量断崖下跌；应仅做最必要轻量操作，优先用异步或替代方案。
直接说结论：AFTER INSERT 触发器本身不是性能瓶颈，但写法稍有不慎，就会让插入吞吐量断崖式下跌。关键不在“要不要用”，而在“怎么让它只做最必要、最轻量的事”。
BEFORE vs AFTER：为什么AFTER INSERT更容易失控
AFTER INSERT 触发器在数据已落盘后才执行，意味着它无法阻止非法数据写入（校验必须放 BEFORE），也天然绕不开事务开销——哪怕触发器里只写一行日志，整个 INSERT 也得等它完成才能提交。更麻烦的是，它默认是行级（FOR EACH ROW），1000 行插入 = 1000 次函数调用 + 1000 次上下文切换。
- 常见错误现象：批量插入变慢、应用端超时、
v$session_event中SQL*Net message from client等待时间异常高 - 真正耗时的往往不是你的逻辑，而是每次调用触发器时 Oracle 重建 PL/SQL 上下文、解析伪记录、分配内存的固定开销
- 如果你只是想记日志或同步状态，优先考虑
INSERT ... SELECT+LOG ERRORS或异步队列，而不是 AFTER INSERT
WHEN 子句必须配 UPDATE OF？不，但 INSERT 场景要防误触发
WHEN 子句对 INSERT 有效，但它的作用被严重低估：它不能过滤“哪些行该插”，只能决定“插完后哪些行触发”。Oracle 仍会为每一行执行 INSERT，再逐行判断 WHEN 条件是否为真——所以别指望靠 WHEN (:new.status = 'active') 来加速插入本身。
- 正确用法：只放简单布尔表达式，如
:new.id IS NOT NULL、:new.created_date > SYSDATE - 7；禁止调用函数、子查询、SYS_CONTEXT或包变量 - 容易踩的坑：
WHEN (UPPER(:new.name) = 'ADMIN')→ 失去谓词下推能力，且每次都要执行 UPPER，10 万行就是 10 万次函数调用 - INSERT 不支持
UPDATE OF，所以无需纠结列名匹配问题；但若你混用了 INSERT 和 UPDATE 触发器，务必分开定义，避免一个触发器承担多职责
触发器体里禁止出现的三类操作
只要触发器体里出现以下任一行为，基本就宣告它不适合高频 INSERT 场景：
-
查其他表：比如
SELECT COUNT(*) FROM audit_config WHERE enabled = 1—— 这会让每行插入都多一次一致性读，锁竞争加剧 -
写其他表：尤其是
INSERT INTO log_table—— 它把单次 DML 变成分布式事务，redo/undo 压力翻倍，还可能触发外键或触发器级联 -
调用非 IMMUTABLE 函数：如
CURRENT_TIMESTAMP、DBMS_RANDOM.VALUE—— 让触发器变成 VOLATILE，影响物化视图刷新和函数索引使用
如果真需要这些逻辑，必须移到应用层或用异步机制解耦。触发器体里只允许：赋值、简单计算、RAISE_APPLICATION_ERROR（仅限 BEFORE）、或极轻量的序列号生成（如 :new.seq_id := my_seq.NEXTVAL）。
替代方案比优化触发器更有效
很多所谓“高性能触发器”的需求，本质是选错了技术路径。AFTER INSERT 的最大价值是收尾动作，不是业务主干。
- 审计日志：改用 Oracle Unified Audit 或
FLASHBACK DATA ARCHIVE，零代码侵入 - 数据同步：用 Oracle GoldenGate 或基于
DBMS_LOGMNR的 CDC，避免阻塞主事务 - 派生字段更新：用物化视图（
REFRESH FAST ON COMMIT）或应用层双写，比触发器更可控
真正难绕开的场景极少——比如必须在 COMMIT 前确保某张配置表有对应快照。这种时候，触发器不是性能问题，而是架构约束。此时唯一能做的，是把它写成空壳（只设标记位），再由后台作业批量处理，而非在触发器里做实质工作。
