简介：这份PDF资料面向Oracle数据库开发与运维人员，系统讲解PL/SQL触发器的编程方法，帮助读者掌握用触发器弥补完整性约束不足、实现复杂业务规则与审计跟踪的技能。内容涵盖触发器的基本概念，包括DML触发器、INSTEAD OF触发器与系统触发器的分类，触发事件、WHEN触发条件、触发对象、BEFORE/AFTER触发时机，以及行级与语句级触发子类型和NEW、OLD表的用法；同时给出创建触发器的完整语法与示例代码，演示如何通过条件谓词INSERTING、UPDATING、DELETING记录操作类型，并说明DROP TRIGGER删除触发器的写法。资源包为1个PDF文件，大小约39KB，篇幅精炼、示例可直接参考。目前已有262人学习，适合希望快速理解触发器机制并应用于实际数据库逻辑设计的开发者查阅。
1. 触发器不是“自动执行的存储过程”：先厘清它到底解决什么问题
很多人第一次接触 ORACLE PL/SQL 触发器，是因为遇到一个绕不开的场景：业务表的数据被改了，但审计日志没写；或者订单状态更新了，库存表却没联动。你不可能要求每个应用端都记得多写一条 INSERT，这时候触发器就成了数据库层的最后一道保险。它的本质是绑定在表、视图或系统事件上的 PL/SQL 代码块，由 DML 语句或 DDL、登录事件自动唤醒，而不是被人显式调用。这和 oracle存储过程 最大的区别在于：存储过程是“你叫它才动”，触发器是“条件到了它自己动”。适合谁？适合需要在数据库层强制约束数据一致性、做审计留痕、做跨表联动，又不想把逻辑散落到各个应用里的开发者。但正因为它“自己动”，一旦写错，排查成本远高于普通存储过程，这也是后面要重点讲的坑。
2. 行级触发器与语句级触发器：选错类型，性能直接翻车
2.1 两种触发器的执行粒度差异
ORACLE 触发器按触发次数分为行级（FOR EACH ROW）和语句级。语句级触发器对一条 DML 语句只执行一次，不管这条语句影响了 1 行还是 100 万行；行级触发器则对每一行都执行一次。这个区别在数据量小的时候感觉不出来，一旦批量更新几十万行，行级触发器里的逻辑会被反复调用几十万次，性能差距可能是秒级和分钟级的区别。
我一般这样判断：如果逻辑只跟“这条语句发生了”有关，比如记录“某张表在某个时间被更新过”，用语句级；如果逻辑依赖具体某一行的新旧值，比如“当工资涨超过 20% 时写审计”，必须用行级。很多人图省事全用行级，结果在 oracle ebs wip 非标工单 这类批量处理场景里，触发器成了性能瓶颈，这就是典型的选型翻车。
2.2 创建第一个行级触发器的完整步骤
下面这个例子实现一个最常见的需求：往员工表插入或更新工资时，自动把变更记录写入审计表。先建审计表，再建触发器。
-- 1. 创建审计表，记录变更前后值和操作时间 CREATE TABLE emp_audit ( audit_id NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY, emp_id NUMBER, old_sal NUMBER, new_sal NUMBER, oper_type VARCHAR2(10), oper_time DATE DEFAULT SYSDATE, db_user VARCHAR2(30) ); -- 2. 创建行级触发器，绑定在 emp 表的 INSERT 和 UPDATE 上 CREATE OR REPLACE TRIGGER trg_emp_sal_audit AFTER INSERT OR UPDATE OF sal ON emp FOR EACH ROW DECLARE v_oper VARCHAR2(10); BEGIN -- 根据触发事件判断操作类型 IF INSERTING THEN v_oper := 'INSERT'; ELSIF UPDATING THEN v_oper := 'UPDATE'; END IF; INSERT INTO emp_audit (emp_id, old_sal, new_sal, oper_type, db_user) VALUES ( :NEW.empno, :OLD.sal, -- INSERT 时 :OLD.sal 为 NULL :NEW.sal, v_oper, USER ); END; /逻辑说明：AFTER INSERT OR UPDATE OF sal表示只在插入或更新 sal 列之后触发，更新其他列不会唤醒它，这比笼统的 UPDATE 更精准。FOR EACH ROW让它逐行执行。:NEW和:OLD是行级触发器特有的伪记录，分别代表操作后的新值和操作前的旧值，INSERT 时:OLD全为 NULL，DELETE 时:NEW全为 NULL。
参数说明：UPDATE OF sal里的列名可以写多个，用逗号分隔；AFTER换成BEFORE可以在数据落盘前修改:NEW的值，但 BEFORE 行级触发器里不能对触发它的表做查询，否则容易触发变异表错误，这个后面避坑章节会细说。
2.3 语句级触发器的典型用法
语句级触发器拿不到:NEW和:OLD，它适合做“动作级”的记录。比如记录某张表今天被更新过几次：
CREATE OR REPLACE TRIGGER trg_emp_stmt_log AFTER UPDATE ON emp BEGIN INSERT INTO table_oper_log (table_name, oper_time, oper_user) VALUES ('EMP', SYSDATE, USER); END; /这条触发器不管 UPDATE 影响了多少行，只写一条日志。如果你把它误写成 FOR EACH ROW，更新 10 万行就会往日志表插 10 万条，日志表瞬间膨胀，这就是语句级和行级选错的直接代价。
3. 把触发器写对：:NEW/:OLD、WHEN 条件与 INSTEAD OF 的实战边界
3.1 :NEW 和 :OLD 能改什么、不能改什么
:NEW在 BEFORE 行级触发器里可以被赋值，这是实现“自动补全字段”的关键。比如插入时自动把创建时间填上：
CREATE OR REPLACE TRIGGER trg_emp_default BEFORE INSERT ON emp FOR EACH ROW BEGIN -- 如果应用没传 hiredate，就用当前时间兜底 IF :NEW.hiredate IS NULL THEN :NEW.hiredate := SYSDATE; END IF; -- 统一把姓名转大写，避免大小写不一致 :NEW.ename := UPPER(:NEW.ename); END; /注意：在 AFTER 行级触发器里给:NEW赋值是无效的，因为数据已经写入了，改不了。另外:NEW和:OLD只能在行级触发器里用，语句级触发器里引用会直接编译报错。这个点新手经常踩，编译不过还找不到原因。
3.2 WHEN 子句：把过滤条件从 PL/SQL 里提出来
如果触发逻辑只对特定行生效，用 WHEN 子句比在 BEGIN 里写 IF 更高效，因为不满足条件的行根本不会进入 PL/SQL 引擎：
CREATE OR REPLACE TRIGGER trg_emp_high_sal BEFORE UPDATE OF sal ON emp FOR EACH ROW WHEN (NEW.sal > 20000) -- 注意这里没有冒号 BEGIN -- 只有新工资超过 20000 才记录 INSERT INTO high_sal_log (empno, new_sal, log_time) VALUES (:NEW.empno, :NEW.sal, SYSDATE); END; /WHEN 子句里的NEW和OLD不带冒号，这是语法规定，写:NEW.sal会报错。WHEN 里也不能用子查询，只能写简单的比较和逻辑表达式。
3.3 INSTEAD OF 触发器：让视图也能被更新
视图默认不可更新，但如果业务需要像操作表一样操作视图，INSTEAD OF 触发器就是唯一出路。它只建在视图上，用触发器体内的 DML 替代原本无法执行的视图更新：
-- 创建一个连接 emp 和 dept 的视图 CREATE OR REPLACE VIEW v_emp_dept AS SELECT e.empno, e.ename, e.sal, d.deptno, d.dname FROM emp e JOIN dept d ON e.deptno = d.deptno; -- 创建 INSTEAD OF 触发器，让视图支持插入 CREATE OR REPLACE TRIGGER trg_v_emp_dept_ins INSTEAD OF INSERT ON v_emp_dept FOR EACH ROW BEGIN -- 先确保部门存在，再插入员工 INSERT INTO dept (deptno, dname) VALUES (:NEW.deptno, :NEW.dname); INSERT INTO emp (empno, ename, sal, deptno) VALUES (:NEW.empno, :NEW.ename, :NEW.sal, :NEW.deptno); END; /INSTEAD OF 触发器只能是行级的，不能加 FOR EACH ROW 以外的粒度选项。它体内可以自由查询和修改基表，不受变异表限制，这是它和普通 DML 触发器的重要区别。
4. 触发器避坑排查：变异表、递归触发与编译失效的 5 个血泪教训
4.1 现象：更新表时报 ORA-04091 变异表错误
原因：在行级触发器里查询或修改了触发它的表本身。比如在 emp 的 UPDATE 行级触发器里写SELECT COUNT(*) FROM emp，ORACLE 会直接抛 ORA-04091，因为表正在被修改，状态不一致。
解决：把查询逻辑挪到语句级触发器里，或者用包变量在行级触发器里暂存数据，在 AFTER STATEMENT 里统一处理。常见做法是建一个包，行级触发器只往包变量里塞值，语句级触发器再读出来做批量操作。
4.2 现象：触发器里更新另一张表，结果又触发了自己，无限递归
原因：触发器 A 更新表 B，表 B 上的触发器又更新表 A，形成循环。或者同一个表上的触发器在体内又更新了自己。
解决：用PRAGMA AUTONOMOUS_TRANSACTION把日志写入独立事务，避免递归；或者在触发器开头用包变量做“是否已进入”的标志位判断。更根本的办法是重新审视逻辑，能不用触发器联动就不用，把联动放到应用层或存储过程里显式调用。
4.3 现象：触发器编译成功，但执行时报 ORA-04098 无效状态
原因：触发器依赖的表或视图被 ALTER 了，比如给表加了列、改了列类型，触发器变成 INVALID 状态，没有自动重新编译。
解决：执行ALTER TRIGGER 触发器名 COMPILE;手动编译，或者查USER_ERRORS看具体报错。批量处理可以写个脚本查USER_OBJECTS里 STATUS='INVALID' 的触发器统一编译。DDL 之后养成检查无效对象的习惯，这是 oracle 等保命令 里也常提到的运维动作。
4.4 现象：批量导入时触发器拖慢整体速度，几万行跑了半小时
原因：行级触发器逐行执行，每行都做一次 INSERT 审计或查询，开销被放大。批量场景下触发器里的每一点逻辑都会被乘以行数。
解决：导入前ALTER TRIGGER 触发器名 DISABLE;，导入完再 ENABLE。或者用ALTER TABLE 表名 DISABLE ALL TRIGGERS;一次性禁用。注意禁用期间数据一致性要靠其他手段保证，导入后要补做审计或校验。
4.5 现象：触发器里调用存储过程，存储过程报错但触发器没报，数据却不对
原因：触发器体内的异常如果没有显式处理，默认会把整个 DML 语句回滚，但有些异常被 WHEN OTHERS 吞掉了，导致主操作成功、附属逻辑静默失败。
解决：触发器里尽量不写 WHEN OTHERS 兜底，或者兜底时必须RAISE重新抛出。如果确实要记录错误又不影响主流程，用自治事务写错误日志，然后决定是否继续。我一般会在触发器里只处理明确知道的异常，未知异常一律让它冒出来，宁可失败也不要数据悄悄不一致。
5. 用 USER_TRIGGERS 做体检：上线前必查的字段与一个自治事务日志技巧
触发器写完不是结束，上线前我习惯查一遍USER_TRIGGERS，确认状态、触发事件和体内逻辑都符合预期。这个视图里几个字段最值得看：STATUS必须是 ENABLED，TRIGGER_TYPE告诉你它是 BEFORE STATEMENT 还是 AFTER EACH ROW，TRIGGERING_EVENT列出绑定的 DML 类型，WHEN_CLAUSE是 WHEN 条件的原文，TRIGGER_BODY是触发器体。一条查询就能把关键信息拉出来：
SELECT trigger_name, status, trigger_type, triggering_event, when_clause, table_name FROM user_triggers WHERE table_name = 'EMP' ORDER BY trigger_name;如果STATUS是 INVALID，或者TRIGGERING_EVENT跟你以为的不一样，比如你只想让它响应 UPDATE，结果写成了 INSERT OR UPDATE OR DELETE，这条查询能立刻暴露问题。上线前跑一遍，比出了事故再回头查要省事得多。
再分享一个我常用的技巧：在触发器里写日志时，用自治事务避免污染主事务。普通触发器里的 INSERT 如果失败，会把主 DML 一起回滚；而自治事务是独立提交的，主事务回滚了日志还在，适合做“后悔药”式的操作留痕：
CREATE OR REPLACE TRIGGER trg_emp_del_log AFTER DELETE ON emp FOR EACH ROW DECLARE PRAGMA AUTONOMOUS_TRANSACTION; -- 声明自治事务 BEGIN INSERT INTO emp_del_log (empno, ename, del_time, del_user) VALUES (:OLD.empno, :OLD.ename, SYSDATE, USER); COMMIT; -- 自治事务必须显式提交 END; /注意自治事务里必须显式 COMMIT，否则日志不会落盘。但也要清楚它的代价：自治事务和主事务之间没有一致性保证，主事务回滚了，日志却已经提交，所以它只适合记录“发生过什么”，不适合记录“最终生效了什么”。这个边界想不清楚，审计数据反而会误导排查。
我自己踩过最深的坑，是在一个批量结算场景里给主表加了行级触发器做联动，测试环境几千行跑得飞快，生产上百万行直接超时。后来改成语句级加临时表批量处理，才把时间压回可接受范围。触发器这东西，写起来简单，用对地方才值钱。希望帮到你。
本文还有配套的精品资源，点击获取
