Oracle里的触发器（trigger）这东西，很多人一开始把它想成“数据库里的监控摄像头”，这句话大方向没错，但真在数据库战场上摸爬滚打过几年的人，听到“触发器”三个字，往往会不自觉皱一下眉。它能做到在表上发生插入、更新、删除等操作时自动执行一段PL/SQL代码，听起来确实很方便，可生产环境里不少让人抓狂的“灵异事件”，最后追根溯源都藏在一个不起眼的trigger里。
这篇文章就是想把Oracle触发器讲透：它到底能解决什么问题，有哪些类型，怎么写才靠谱，生产环境里会踩哪些坑，以及什么时候你根本不该用它。内容对于刚接触Oracle的开发同学、日常要维护数据库的DBA、还有正在做数据审计和同步方案的数据工程师，都有参考价值。废话不多说，我直接按自己实操的积累往下讲。
1. 触发器到底是什么，解决什么问题
1.1 一句话解释触发器
用生活里的东西做个类比，触发器其实就像一个门铃。你在门口按门铃，屋里的人就知道有人来了，然后会自动做出回应，可能是开门，可能是喊一声。触发器也一样：你在表上做了一条INSERT操作，Oracle就会“按响门铃”，自动执行预先写好的那一段PL/SQL代码。
从数据库角度定义，触发器（trigger）是一种存储在数据字典里的独立PL/SQL程序单元，它和表、视图、数据库事件绑定，当指定的事件发生时，由数据库自动隐式调用。它跟普通存储过程最大的区别是：存储过程得有人主动去CALL，触发器不需要，它自己“蹦出来”执行。
这个“自动、隐式”的特性是触发器的价值，也是它最大的危险源。价值在于你可以在应用代码不感知的情况下完成审计、校验、数据同步等操作；危险在于一旦触发器里有问题，所有走到这张表的操作都会中招，而且问题往往特别难定位。
1.2 它能解决哪些实际问题
结合真实的项目经验，触发器最常见的应用场景大概有这么几类。
第一类是操作审计与留痕。我做过一个模拟项目X，业务部门要求知道员工表里每一次工资调整是谁改的、改之前是多少、改之后是多少、什么时候改的。这种需求如果全靠业务应用去写日志，很容易漏，而且老系统的应用代码改动成本很高。用触发器挂在员工表上，任何针对工资字段的更新都会被记录到一张独立的日志表里，无须动业务代码。
第二类是复杂完整性约束。Oracle里的CHECK约束能管简单的规则，比如年龄大于0，但管不了跨行、跨表的规则。比如“订单明细的总金额必须等于订单主表的总金额”这种，单靠一个表的CHECK约束搞不定，就可以用触发器在明细表上维护主表的汇总值。
第三类是派生字段的自动维护。很多系统里会存冗余字段，比如订单表里存了商品单价和数量，又冗余一个总金额字段。如果靠应用层每次计算再写进去，容易出现计算逻辑不一致的问题。通过BEFORE行级触发器自动计算并写入，应用层就不用总记着这茬儿了。
第四类是数据库层面的统一规则落地。比如所有表插入数据时自动填充创建时间、修改时间；所有删除操作都需要先写一条删除原因。诸如此类的基础规则，放在触发器里能保证任何入口都绕不开，不管是正规接口还是某个维护人员直连数据库手改数据。
1.3 为什么DBA对触发器爱恨交加
触发器的优点确实明显：集中、隐式、安全，能保证规则在数据库层面无条件生效。但我在实际工作中见过太多触发器引发的意外，总结下来主要是三个问题。
一是可观测性差。触发器是隐式执行的，一条UPDATE语句看着只影响了一张表，实际上背后可能还更新了日志表、发了消息、调了存储过程。没有经验的人排查问题时，很难想到去查触发器。
二是性能隐患。行级触发器在批量操作时会被执行成千上万次，如果触发器内部的逻辑还很重，哪怕每条只多几毫秒，整体性能影响就会被放大得非常恐怖。
三是维护难度高。触发器存储在数据库里，很多人不知道它的存在，等某天系统报错了才发现原来这里还挂着一个三年前的trigger。数据库表结构一调整，触发器往往就变成INVALID状态，连带整个DML操作都会失败。
所以我现在做方案时，对触发器的态度是：不排斥，但一定要经过充分评估。能用约束解决的事，别用触发器；能用应用层显式处理的事，也尽量别用触发器。真到了非用不可的场景，再好好设计它。
2. 触发器的分类与运行机制
2.1 事件-条件-动作：触发器的三段式骨架
Oracle里任何触发器都可以拆成三段来理解：事件、条件、动作。
事件指触发时机和触发操作。操作一般是DML语句，比如INSERT、UPDATE、DELETE，也可以是DDL操作（CREATE、ALTER）、数据库级事件（数据库启动、登录等）。时机分为BEFORE和AFTER，也就是操作发生前还是发生后执行触发器。
条件指WHEN子句，只有满足这个条件，动作才会执行。比如你只想在工资大于10000的时候记录日志，就可以把判断条件写在WHEN里。这样数据库在内部判断条件不满足时，连PL/SQL块的执行上下文都不会进入，性能上会好很多。
动作就是真正要执行的PL/SQL代码块，可以包含变量声明、异常处理、数据操作、调用存储过程等等。
用伪代码来表示就是：
CREATE OR REPLACE TRIGGER 触发器名 {BEFORE | AFTER} {INSERT | UPDATE | DELETE} ON 表名 [FOR EACH ROW] [WHEN (条件)] DECLARE -- 变量声明 BEGIN -- 执行动作 END;注意FOR EACH ROW是可选的，有没有这一行，决定了触发器是行级还是语句级，差别非常大。
2.2 行级和语句级的区别，别再混淆
很多初学者在这里被绕晕。简单说：如果一条UPDATE语句影响了1000行，不写FOR EACH ROW的语句级触发器只执行一次；写了FOR EACH ROW的行级触发器会执行1000次。
语句级触发器适合做“这类操作发生了，我需要处理一次”的需求，比如记录一条操作日志，统计今天这张表发生过多少次修改。它不关心具体是哪行数据被改了。
行级触发器适合做逐行校验、逐行记录变化的需求，比如检查每一行的工资是否合法、把每一行的旧值和新值都写进审计表。
| 对比项 | 语句级触发器 | 行级触发器 |
|---|---|---|
| 触发次数 | 每条DML语句只触发1次 | 每行数据变化触发1次 |
| 关键语法 | 不加FOR EACH ROW | 加FOR EACH ROW |
| 能否访问:NEW/:OLD | 不能直接访问 | 可以访问 |
| 典型场景 | 操作级审计、防误操作 | 字段校验、数据留痕、同步关联表 |
| 性能影响 | 相对较小 | 批量操作时影响极大 |
我要特别提醒一点：当你需要访问:NEW和:OLD这两个系统变量时，必须写成行级触发器。这一点几乎是写审计算法时的基本前提，后面会专门展开讲。
2.3 按触发主体分类
Oracle的触发器按触发主体划分，主要有三类。
DML触发器是最常用的，挂在表上，对INSERT、UPDATE、DELETE操作生效。前面说的审计、字段维护、业务校验基本都是这一类。
INSTEAD OF触发器比较特殊，它挂在视图上。因为视图本身不是一个实体表，很多DML操作无法直接在视图上执行，INSTEAD OF触发器就扮演了“视图操作的转译器”，你把对视图的INSERT写进触发器，在触发器内部再把它转换成对底层表真正的操作。这在一些规范化设计的系统里很常见。
系统触发器则绑定数据库实例级或模式级的事件，比如DDL事件（CREATE、ALTER、DROP）、用户登录登出（LOGON、LOGOFF）、数据库启动与关闭（STARTUP、SHUTDOWN）。这类触发器通常由DBA用来做安全监控或操作审计。
| 触发器类型 | 可绑定对象 | 常见使用场景 |
|---|---|---|
| DML触发器 | 表、视图（配合INSTEAD OF） | 审计、校验、字段维护、同步 |
| INSTEAD OF触发器 | 视图 | 复杂视图的数据写入转换 |
| 系统触发器 | 数据库、Schema | DDL操作审计、登录日志、启动通知 |
3. 手把手：从零写一个能落地的触发器
3.1 语法骨架与第一个实例
真正动手写触发器前，建议先搭一个最小的骨架跑通，再逐步加逻辑。下面这个例子是做操作审计，我把完整过程拆开讲。
假设有员工表emp：
CREATE TABLE emp ( emp_id NUMBER PRIMARY KEY, emp_name VARCHAR2(50), salary NUMBER );再建一张审计日志表emp_audit，用来记录员工表上的每次DML操作：
CREATE TABLE emp_audit ( audit_id NUMBER GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY, emp_id NUMBER, old_salary NUMBER, new_salary NUMBER, action_type VARCHAR2(10), op_time TIMESTAMP DEFAULT SYSTIMESTAMP );然后创建行级审计触发器：
CREATE OR REPLACE TRIGGER trg_emp_audit AFTER INSERT OR UPDATE OR DELETE ON emp FOR EACH ROW DECLARE v_action VARCHAR2(10); BEGIN IF INSERTING THEN v_action := 'INSERT'; ELSIF UPDATING THEN v_action := 'UPDATE'; ELSIF DELETING THEN v_action := 'DELETE'; END IF; INSERT INTO emp_audit (emp_id, old_salary, new_salary, action_type) VALUES (:NEW.emp_id, :OLD.salary, :NEW.salary, v_action); END;几个关键点说一下。
IF INSERTING、IF UPDATING、IF DELETING这三个条件判断是Oracle触发器里内置的“状态开关”，用来识别当前是什么操作，比在多个触发器之间拆分逻辑要省事得多，这也是我推荐把INSERT、UPDATE、DELETE合并到一个触发器里的原因之一。
AFTER表示在DML操作完成之后记录日志，这样做的好处是即使前面还有其他约束拦截，也不会留下“虚假日志”。比如插入的数据因为违反主键被拒，那触发器根本不会执行，日志表里就不会有污染数据。
3.2 :NEW和:OLD到底怎么用
:NEW和:OLD是行级触发器里最容易让人困惑，也是最重要的两个变量。
简单记忆法：:NEW代表“新值”，:OLD代表“旧值”。INSERT操作只有新值，所以只能用:NEW；DELETE操作只有旧值，所以只能用:OLD；UPDATE操作两者都有，:OLD是更新前的值，:NEW是更新后的值。如果你在INSERT触发器里去读:OLD，结果一定是NULL，这种错误排查起来确实头大。
还有一个特别容易掉进去的坑：在触发器代码主体里引用:NEW和:OLD时都要带冒号，但在WHEN子句里写条件时，冒号必须去掉。比如下面这段代码：
CREATE OR REPLACE TRIGGER trg_emp_salary_check BEFORE INSERT OR UPDATE OF salary ON emp FOR EACH ROW WHEN (NEW.salary < 0) BEGIN RAISE_APPLICATION_ERROR(-20001, '工资不能为负数'); END;这里WHEN条件里写的是NEW.salary而不是:NEW.salary，语法规定如此，写错会直接编译报错。WHEN子句的好处是：条件不满足时，Oracle不会进入PL/SQL执行，开销更小。能用WHEN做粗筛的，就别在代码块里用IF。
:NEW最实用的一个场景是给字段赋值。在BEFORE触发器中，你可以直接修改:NEW的值，这个值最终会被写入表里。比如订单明细表里有数量qty和单价price，希望总金额total自动计算：
CREATE OR REPLACE TRIGGER trg_order_item_total BEFORE INSERT OR UPDATE OF qty, price ON order_items FOR EACH ROW BEGIN :NEW.total := :NEW.qty * :NEW.price; END;这里之所以用BEFORE而不是AFTER，道理很简单：我们需要在数据真正入库前把total算出来。AFTER触发器修改:NEW是不起作用的，因为数据已经写进去了。
3.3 从零搭一个审计需求，完整验证
我在某公司的项目里就接过一个类似的审计需求。业务方要求记录员工薪资调整的全过程，但生产用的业务系统比较老旧，没法快速改造应用代码。这时候触发器几乎是唯一的选择。
具体实现步骤大概是这样的。
第一步，确认审计粒度。业务方关心的是“薪资”字段的变化，所以触发器只需要在salary字段被修改的时候记录，其他字段的变动不用管。这样可以缩小触发范围，减少不必要的开销。写法上用的是UPDATE OF salary，只有显式更新salary列时才触发，避免了所有UPDATE都进触发器的尴尬。
第二步，创建视图或直接使用日志表，把审计信息拆成操作前后对比。我在模拟项目X里建了一张日志表，字段包括员工ID、旧值、新值、操作类型、操作时间，外加一个可追溯的操作人字段。注意Oracle中要拿当前数据库会话用户，可以直接用USER函数，如果业务系统有自己的账号体系，则需要额外的参数传递机制，这个要根据实际环境设计。
第三步，测试。插一条数据，再把工资从10000改成15000，最后删除该数据。查日志表，应该看到三条记录，分别对应INSERT、UPDATE、DELETE。我实操时经常发现有人漏掉DELETING分支，导致删除操作没有留下任何记录，日志表里只显得单薄，不完整。
第四步，还要做边界测试。试试插入一条salary为NULL的记录，触发器会把NULL当成一个普通值处理。如果你不想让NULL进入审计表，就得在触发器里用NVL包一层。我一般都会在写触发器时把这些“环境杂音”处理干净，避免审计数据里全是NULL干扰业务判断。
4. 生产环境踩坑记录与排查技巧
4.1 ORA-04091：变异表问题
ORA-04091是Oracle触发器里的经典大坑，错误信息大致是：table xxx is mutating, trigger/function may not see it。意思是表正在变化中，你的行级触发器不能再去查询或修改触发它的那张表。
举个例子，我在员工表上写了一个行级触发器，目的是确保“部门里的总工资不能超过某个上限”，于是在触发器内部去查了一下emp表的总工资：
CREATE OR REPLACE TRIGGER trg_emp_dept_limit BEFORE INSERT OR UPDATE OF salary ON emp FOR EACH ROW DECLARE v_total NUMBER; BEGIN SELECT SUM(salary) INTO v_total FROM emp WHERE dept_id = :NEW.dept_id; IF v_total > 100000 THEN RAISE_APPLICATION_ERROR(-20002, '部门工资总额超限'); END IF; END;这段代码在编译时没问题，但一执行DML就会报ORA-04091。原因在于：触发器正在处理emp表的某行数据，此时表上的数据处于“变卦”状态，Oracle不允许你在同一个会话里去读它，否则结果会不稳定，可能出现幽灵数据或漏看数据。
解决变异表问题有几种常见思路。
第一种是改成compound触发器。复合触发器可以把语句级和行级逻辑结合起来，先通过行级部分收集涉及到的部门ID，再在语句级部分去统一查询和校验，避开了“正在变化的表不能读”的矛盾。
第二种是借助临时包变量。在行级触发器里只把这个部门的ID存到包变量里，不查表；然后再用一个语句级AFTER触发器统一去检查。这也是比较常见的做法，但实现起来稍显繁琐。
第三种是从设计上避开。既然行级触发器里不能查本表，那就把校验逻辑挪到语句级，或者干脆用物化视图、约束、应用层逻辑来处理。反正硬碰硬去解ORA-04091多半会越搞越复杂。
4.2 性能：行级触发器如何把在线业务拖垮
我见过一个真实案例，某业务系统本来一条UPDATE只需要几十毫秒，挂了一个行级触发器后，批量更新几千行直接超时。排查下来发现，触发器里有一条很重的SQL，每条都去查一个大表，等于几千行数据每行做一次额外查询，性能自然崩了。
行级触发器的性能问题本质上是个“放大效应”。一次更新10000行，行级触发器的PL/SQL体就被执行10000次。哪怕单次执行只要1毫秒，总耗时也会增加10秒，这还没算SQL解析、上下文切换的开销。
应对手段主要有四个。
一是能用WHEN条件过滤就尽早过滤。WHEN子句是数据库层面的判断，不满足条件的行根本不会进入PL/SQL执行，能省一大截开销。比如只对salary>10000的记录做处理，那大部分行会被直接绕过。
二是触发器内部逻辑要尽量轻量。不要在里面做复杂的查询，尤其不要做全表扫描。如果确实需要根据某个关联表取值，可以考虑把关联数据提前缓存，或者用DML语句直接更新而不是逐行查。
三是尽量少用行级触发器，改用语句级触发器加批量处理。比如要统计“本月发生过多少条订单修改”，语句级触发器就够了，根本不需要每行都触发一次。
四是监控时别被误导。一次简单UPDATE的执行计划里看不到触发器内部的SQL，需要开启SQL Trace或者通过V$SQL里查递归调用来定位。如果在V$SQL里看到很多一模一样的INSERT语句短时间大量出现，很可能就是某个表上的行级触发器在拼命写日志。
4.3 递归触发与重入问题
触发器里最隐蔽的问题，是递归触发。A表上有个触发器，在A表更新时又会去更新B表；B表上如果恰好也有个触发器，在B表更新时又回来更新A表，那就会形成触发器的递归环，轻则无限循环，重则导致Oracle报“maximum number of recursive SQL levels exceeded”。
最简单的直接递归场景，是你在一张表的触发器里继续UPDATE同一张表。比如emp表有个BEFORE触发器，每次salary变更后，你想顺手把bonus也改掉，结果这又是一个对emp表的UPDATE，于是再次触发了触发器本身：
CREATE OR REPLACE TRIGGER trg_emp_recursive BEFORE UPDATE OF salary ON emp FOR EACH ROW BEGIN UPDATE emp SET bonus = :NEW.salary * 0.1 WHERE emp_id = :NEW.emp_id; END;这段触发器一旦执行，几乎必然导致递归错误。正确做法是：如果必须更新同表，建议换成复合触发器或者包变量来辅助控制，用FLAG标识“这次的UPDATE是触发器内部发起的”，从而避免再次触发。
会话层面还有一个参数可以控制递归触发器，ALTER SESSION SET RECURSIVE_TRIGGERS = FALSE。但我建议不要把这个当银弹，生产环境里改会话参数影响面太大，而且不同版本的行为不完全一致。最可靠的办法还是从设计上切断递归路径。
顺便提一下，级联触发器也是一类隐蔽重入问题。比如emp表更新后写日志表emp_audit，而emp_audit表上恰好有个触发器也去更新emp表，这种跨表递归的链路更长，排查时要靠查询DBA_TRIGGERS把所有相关表上的触发器都列出来，才能看清全貌。
4.4 排查“数据神秘被改”的实战方法
有一次某系统反馈，订单表里的状态字段经常无缘无故从“待支付”变成“已取消”，但应用系统里没人操作。我排查的第一步就是查这个表上有没有触发器：
SELECT trigger_name, status, trigger_type, triggering_event, table_name FROM user_triggers WHERE table_name = 'ORDERS';果然，发现一个很老的触发器trg_order_cancel_flag，这个触发器在某种条件下会自动更新状态字段。后来翻了代码，发现是早期做需求时某个开发者写进去的，当时的应用场景早已下线，但触发器还留在库里，一直“勤勤恳恳”地干活。
这个案例给我的教训很深：任何排障流程的第一步，都应该查一下目标表上是否存在触发器，尤其是那些自动修改数据的问题。如果在开发环境里还可以通过对比代码版本找原因，在生产环境里，触发器就是“看不见的手”，必须先把它揪出来。
常见排查SQL我整理了一下：
| 排查目标 | SQL |
|---|---|
| 查看表上的触发器 | SELECT * FROM USER_TRIGGERS WHERE TABLE_NAME = '表名'; |
| 查看所有触发器状态 | SELECT OWNER, TRIGGER_NAME, STATUS FROM ALL_TRIGGERS; |
| 查看触发器源码 | SELECT TRIGGER_BODY FROM USER_TRIGGERS WHERE TRIGGER_NAME = '触发器名'; |
| 查看无效触发器 | SELECT TRIGGER_NAME, STATUS FROM USER_TRIGGERS WHERE STATUS = 'INVALID'; |
另外，查询DBA_SOURCE可以看触发器编译后的代码，但一般USER_TRIGGERS的TRIGGER_BODY就够用了。如果发现触发器状态是INVALID，一定要马上处理，因为表结构变更后，挂在表上的触发器会失效，而失效的DML触发器会导致所有DML操作直接报错，业务完全不可用。
5. 管理触发器与决策经验
5.1 触发器的日常运维管理
触发器写得出来是一回事，管得好是另一回事。我一般在团队里会定这么几条规范。
第一，命名规范。触发器名字要能一眼看出用途，我习惯用trg_表名_业务含义，比如trg_emp_salary_audit。千万不要取trg_test_01、trigger_aaa这种名字，等半年后回来看，根本不知道它是干嘛的，也没人敢删。
第二，启用和禁用要留痕。禁用触发器不是DBA随口说一句的事，要记录时间、原因、操作人。尤其是生产环境的触发器，禁用了之后往往就没人想起来重新启用，审计规则等于形同虚设。用下面的SQL启用或禁用触发器：
ALTER TRIGGER trg_emp_audit ENABLE; ALTER TRIGGER trg_emp_audit DISABLE;如果想一次性禁用某张表上全部触发器，可以写：
ALTER TABLE emp DISABLE ALL TRIGGERS; ALTER TABLE emp ENABLE ALL TRIGGERS;这个操作很方便，但也很危险，执行前一定要确认没有正在依赖这些触发器的业务流程。
第三，触发器代码必须纳入版本管理。把创建触发器的SQL脚本和表结构变更脚本放在一起，跟随发布流程走，避免“生产库某个触发器是某次运维临时手动加的”这种孤儿状态。
第四，加触发器必须配套监控。我建议至少在触发器里加入时间戳、操作人等信息，有条件的系统还可以把关键业务表的触发器日志定期归档，防止日志表无限膨胀。
5.2 什么时候真的不要用触发器
虽然本文讲了很多触发器的写法，但我也得说句实在话：触发器不是越用越好，很多场景根本不该用它。
第一种情况是普通的数据默认值。比如插入记录时填充创建时间，这种用DEFAULT约束就能解决，没必要上触发器。只有你需要在数据库层面做更复杂逻辑时才考虑。
第二种情况是纯粹依赖应用逻辑才能判断的规则。触发器是数据库层的东西，它拿不到应用层的上下文。比如需要判断“当前登录用户是否有权限修改这条记录”，如果权限模型完全在应用里，那触发器很难做。
第三种情况是业务中高并发、大流量的写操作路径。触发器每行都执行，性能放大效应太明显，很多团队在核心交易链路里是明确禁止用触发器的。
我个人的判断标准是：如果这个业务规则能在数据库外解决，那就别在库内加触发器；如果必须在库级强制保证，优先考虑约束、存储过程等更可控的方式；实在没得选了，再考虑触发器，同时必须做好性能测试和监控。
5.3 触发器与替代方案做个对比
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 约束（CHECK、UNIQUE、FK） | 简单可靠、性能好 | 表达能力有限 | 基础数据完整性 |
| 触发器 | 隐式自动、能写复杂逻辑 | 排查难、性能放大 | 审计、跨表一致性、复杂校验 |
| 存储过程/API层 | 显式调用、逻辑清晰 | 依赖应用正确调用 | 业务规则明确、可改造应用 |
| 物化视图/CDC | 异步解耦、报表友好 | 延迟、额外存储 | 数据同步、统计分析 |
| 消息队列/事件驱动 | 弹性扩展、业务解耦 | 体系复杂 | 非强一致的异步通知 |
从执行阶段看，约束一定是最优先的，因为它由数据库内核直接保证。触发器虽然也在数据库里，但它本质是PL/SQL逻辑，带来了不确定性。如果你的需求用一行CHECK约束能写完，但凡有人建议你用触发器，都得多想想是不是过度设计。
5.4 最后分享一点个人体会
用过几年Oracle之后，我对触发器的态度慢慢从“这功能真好用、什么都想试试”变成“能不写就不写、要写就得写干净”。这不是保守，而是生产环境真的经不起太多“隐形的自动化”。
我踩过最深的坑，是在一个老项目里接手了一套离职同事写的触发器，没文档、没注释、命名混乱，触发器里还嵌套调用存储过程。业务一上线，某张表的UPDATE速度慢得离谱，查了半天才发现是三个触发器叠加在一起，每个都做了全表扫描。后来我把这些触发器全部禁用，业务瞬间恢复正常，之后再一条一条地重构，把真正有用的规则保留了下来。
如果你现在正准备在一个新项目里引入触发器，我建议你多问自己一句：这个逻辑真的需要数据库自动执行吗？应用层能不能显式处理？有没有更简单可靠的替代方案？如果答案都是“必须用触发器”，那这篇文章里的写法、注意事项和排障方法，应该能帮你少走不少弯路。
