Oracle触发器性能瓶颈主因是滥用FOR EACH ROW执行查表、发通知等重操作；应优先用FOR EACH STATEMENT，配合WHEN子句和UPDATE OF精准过滤，禁用事务控制与远程调用，并考虑存储过程替代。
oracle触发器本身不慢，慢的是你让它干了不该干的事——比如在 for each row 里查表、发通知、调函数，或者没控制好触发条件，让本该跳过的行也进了逻辑体。
BEFORE/AFTER + FOR EACH ROW 这种组合最容易拖垮性能
这是最常用也最容易出问题的配置。每次 DML 影响 N 行，它就执行 N 次完整 PL/SQL 上下文切换 + 触发器体解析 + SQL 执行。哪怕触发器体只有一行 INSERT INTO log_table，10 万行更新也会产生 10 万次 INSERT。
- 优先考虑
FOR EACH STATEMENT：适合统计、日志汇总、权限校验后置等不依赖单行数据的场景 -
BEFORE更适合拦截（如校验、默认值填充），AFTER更适合级联或异步解耦（但别在AFTER里直接改同表数据，容易递归） - 如果必须用
FOR EACH ROW，务必配合WHEN子句和UPDATE OF列表做第一道过滤
WHEN 子句写错等于没写
WHEN 看似简单，但 Oracle 对它的限制极严：只支持行级触发器、不能调函数、不能引用会话变量、不能用 SYS_CONTEXT 或 SYSDATE。写错不仅无效，还可能让优化器放弃谓词下推。
- 正确写法：
WHEN (:NEW.status != :OLD.status)或WHEN (:NEW.amount IS NOT NULL) - 错误写法：
WHEN (my_pkg.is_active(:NEW.id))→ 报PLS-00436；WHEN (USER = 'ADMIN')→ 报ORA-04076 - 必须搭配
UPDATE OF salary才能真正避免“改 email 也进触发器”——否则WHEN再轻量也白搭 - 列名大小写要跟表定义完全一致，
UPDATE OF SALARY对小写salary列不生效，且 Oracle 不报错
触发器里别碰远程调用、复杂查询和事务控制
触发器运行在主 DML 事务上下文中，所有操作共享同一事务。一旦在里面做 COMMIT、ROLLBACK、调 DBLink、查大表、跑分析函数，轻则锁表，重则阻塞整个业务链路。
- 禁止出现：
COMMIT、DBMS_SCHEDULER.CREATE_JOB、UTL_HTTP.REQUEST、SELECT COUNT(*) FROM big_table - 日志类操作统一走自治事务（
PRAGMA AUTONOMOUS_TRANSACTION），但注意自治事务无法看到主事务未提交数据 - 真需要异步处理（如发消息、刷新缓存），写入中间表 + 由外部作业轮询，而不是在触发器里直接调用
- 批量更新时，避免在触发器里用游标循环查关联数据——应改用
MERGE或提前BULK COLLECT关联结果集
别信“合并触发器就能提速”，先看是否真有必要存在
很多生产库里的触发器，其实是历史遗留的“应用层缺失逻辑”的补丁。它们长期没人维护，字段变更后条件失效，日志表常年不清理，监控告警也没配。这种触发器比慢，更危险。
- 用
DBA_TRIGGERS查启用状态，用v$session_longops或 AWR 报告确认触发器语句的实际执行耗时 - 检查是否有多个触发器对同一事件重复响应（比如两个
AFTER UPDATE都在写日志）→ 合并前先确认逻辑是否真可合并 - 评估替代方案：物化视图（
ON COMMIT REFRESH）、应用层事件（Spring ApplicationEvent）、CDC 工具（Oracle GoldenGate / Debezium） - 最狠但最有效的一招：把触发器逻辑抽成存储过程，让应用显式调用——虽然改代码，但可控、可观测、可压测
触发器真正的性能瓶颈，往往不在语法多复杂，而在于它隐式执行、难以监控、修改成本高。上线前没压测 FORALL 更新 5 万行的触发器行为，上线后才发现每行都触发了一次远程 HTTP 调用——这种坑，EXPLAIN PLAN 看不见，AWR 里藏得深，只能靠设计阶段就掐断可能性。
