简介：这份PDF资料面向Oracle数据库开发与运维人员，系统讲解PL/SQL触发器的编程方法，帮助读者掌握用触发器弥补完整性约束不足、实现复杂业务规则与审计跟踪的技能。内容围绕基本概念展开，涵盖DML触发器、INSTEAD OF触发器与系统触发器的分类，触发事件、WHEN触发条件、触发对象、BEFORE/AFTER触发时机，以及行级与语句级子类型和NEW、OLD表的用法；并结合CREATE TRIGGER、执行触发器、DROP TRIGGER等语句给出可参考的代码示例，如教师表插入更新校验与操作日志记录。资源包为1个PDF文件，约39KB，篇幅精炼、便于随时查阅。目前已有262人学习，适合希望快速理解触发器机制并落地到实际数据库逻辑设计中的开发者参考。
1. 触发器不是“自动跑一下”那么简单：从一次数据错乱说起
ORACLE PL/SQL 触发器编程篇介绍，这个标题看着像教科书章节，但真正在生产环境里踩过坑的人都知道，触发器写错一行，排查成本可能是一整天。我见过一个库存表，因为一个行级触发器里多写了一条UPDATE，导致每次入库都触发自身递归，最终 ORA-00036 直接把会话打爆。触发器不是“自动跑一下”的语法糖，它是挂在表上的隐形逻辑，一旦上线，所有 DML 都会经过它。这篇文章面向已经会写基本 PL/SQL、但对触发器边界和落地姿势没把握的开发者，把行级/语句级选型、:NEW/:OLD 的使用、变异表绕行、自治事务、递归控制、性能排查这几件事讲透。读完你能自己判断：这个需求到底该不该用触发器，用了之后怎么保证它不翻车。
2. 先搞清 BEFORE/AFTER 与行级/语句级的选型逻辑
2.1 四种组合到底怎么选
触发器的第一层决策不是“怎么写”，而是“挂在哪、什么时候跑”。按触发时机分 BEFORE 和 AFTER，按触发粒度分 FOR EACH ROW（行级）和语句级（不写 FOR EACH ROW）。这四个组合不是随便挑的，选错了要么拿不到数据，要么性能直接塌。
BEFORE 行级触发器的典型场景是数据校验和字段补全。因为它在数据真正写入前执行，你可以直接改:NEW.column，改动会落到最终写入的行里。比如统一把:NEW.updated_at补成SYSTIMESTAMP，或者校验金额不能为负。AFTER 行级触发器拿不到修改:NEW的机会（此时数据已落盘），它适合做审计日志、级联更新其他表。语句级触发器不关心具体哪一行，适合做“这批操作前后做点什么”，比如记录一次批量导入的开始结束时间。
一个容易忽略的点：行级触发器对每行都执行一次。如果你一条INSERT INTO ... SELECT插入 10 万行，行级触发器体就被执行 10 万次。触发器体里哪怕只有一次查询，放大 10 万倍就是灾难。所以行级触发器体里要尽量只做内存计算，避免查询和 DML。
2.2 用最小可复现例子跑通行级触发器
先建两张表，一张业务表，一张审计表，把 AFTER 行级触发器的审计场景跑通。
-- 业务表 CREATE TABLE t_order ( order_id NUMBER PRIMARY KEY, customer_id NUMBER, amount NUMBER(12,2), status VARCHAR2(20), updated_at DATE ); -- 审计表 CREATE TABLE t_order_audit ( audit_id NUMBER GENERATED ALWAYS AS IDENTITY, order_id NUMBER, old_status VARCHAR2(20), new_status VARCHAR2(20), changed_by VARCHAR2(30), changed_at DATE ); -- AFTER 行级触发器：状态变化时写审计 CREATE OR REPLACE TRIGGER trg_order_audit AFTER UPDATE OF status ON t_order FOR EACH ROW WHEN (OLD.status <> NEW.status OR (OLD.status IS NULL AND NEW.status IS NOT NULL)) BEGIN INSERT INTO t_order_audit(order_id, old_status, new_status, changed_by, changed_at) VALUES (:OLD.order_id, :OLD.status, :NEW.status, USER, SYSDATE); END; /这段代码有几个关键点。AFTER UPDATE OF status限定只有 status 列被更新时才触发，避免无关更新也走一遍触发器。FOR EACH ROW表示行级。WHEN子句做条件过滤，注意 NULL 比较必须显式处理，因为NULL <> 'X'结果是 UNKNOWN 不是 TRUE，很多人在这里漏掉导致审计丢记录。触发器体里用:OLD和:NEW分别取变更前后的值，USER取当前数据库用户。
验证一下：
INSERT INTO t_order VALUES (1001, 2001, 500.00, 'NEW', SYSDATE); UPDATE t_order SET status = 'PAID' WHERE order_id = 1001; SELECT * FROM t_order_audit;你应该能看到一条 old_status=NEW、new_status=PAID 的记录。如果没看到，先检查WHEN条件里的 NULL 逻辑，再检查触发器是否处于 ENABLED 状态（查USER_TRIGGERS的 STATUS 列）。
2.3 BEFORE 行级触发器改 :NEW 的正确姿势
BEFORE 行级触发器最常用来做字段补全和校验。下面这个例子在插入前自动补 updated_at，并拒绝负金额。
CREATE OR REPLACE TRIGGER trg_order_before_ins BEFORE INSERT OR UPDATE ON t_order FOR EACH ROW BEGIN -- 补全时间戳，无论插入还是更新 :NEW.updated_at := SYSDATE; -- 金额校验，负数直接抛错 IF :NEW.amount < 0 THEN RAISE_APPLICATION_ERROR(-20001, '金额不能为负: ' || :NEW.amount); END IF; -- 插入时给个默认状态 IF INSERTING AND :NEW.status IS NULL THEN :NEW.status := 'NEW'; END IF; END; /INSERTING、UPDATING、DELETING是触发器内置的布尔函数，用来判断当前是哪种 DML，比用多个独立触发器更省维护成本。RAISE_APPLICATION_ERROR抛出的错误码必须在 -20000 到 -20999 之间，这是用户自定义错误的保留区间。注意:NEW.updated_at := SYSDATE这种赋值只在 BEFORE 行级触发器里有效，AFTER 里改:NEW不会影响已写入的数据，属于无效操作。
3. 变异表、递归与自治事务：三个最容易翻车的地方
3.1 变异表错误的成因与绕行方案
变异表（mutating table）是行级触发器里最经典的报错：ORA-04091。现象是行级触发器体里查询了正在被修改的那张表。原因很简单：行级触发器在行变更过程中执行，此时表处于“不稳定”状态，Oracle 不允许你读它，否则读到的可能是半成品数据。
-- 错误示范：行级触发器里查同一张表 CREATE OR REPLACE TRIGGER trg_bad AFTER INSERT ON t_order FOR EACH ROW DECLARE v_cnt NUMBER; BEGIN SELECT COUNT(*) INTO v_cnt FROM t_order; -- ORA-04091 END; /绕行方案有三种，按推荐程度排。第一种是改用语句级触发器配合包变量：语句级触发器在整条 DML 前后各触发一次，此时表是稳定的。第二种是用复合触发器（COMPOUND TRIGGER），它把 BEFORE STATEMENT、BEFORE EACH ROW、AFTER EACH ROW、AFTER STATEMENT 四个时机收在一个触发器里，用包变量在行级收集数据、在语句级统一处理。第三种是自治事务，但自治事务解决的是“触发器里做独立提交”的问题，不是变异表本身，别混用。
复合触发器的骨架长这样：
CREATE OR REPLACE TRIGGER trg_compound FOR INSERT ON t_order COMPOUND TRIGGER TYPE t_ids IS TABLE OF NUMBER INDEX BY PLS_INTEGER; g_ids t_ids; g_idx PLS_INTEGER := 0; BEFORE EACH ROW IS BEGIN g_idx := g_idx + 1; g_ids(g_idx) := :NEW.order_id; END BEFORE EACH ROW; AFTER STATEMENT IS v_cnt NUMBER; BEGIN SELECT COUNT(*) INTO v_cnt FROM t_order WHERE order_id MEMBER OF g_ids; -- 这里可以安全查询，表已稳定 END AFTER STATEMENT; END; /MEMBER OF用于判断元素是否在集合里，比IN更适合集合类型。包变量g_ids在行级阶段收集主键，语句级阶段统一查询，既避开了变异表，又只查一次。
3.2 递归触发与 ORA-00036 的排查
递归触发是触发器里改同一张表，导致触发器再次触发自己。Oracle 默认允许递归深度 50 层，超过就报 ORA-00036。很多人写“更新 A 表时同步更新 A 表的另一列”，结果触发器里又执行了 UPDATE，直接递归。
-- 危险：触发器里更新同一张表 CREATE OR REPLACE TRIGGER trg_recursive AFTER UPDATE OF amount ON t_order FOR EACH ROW BEGIN UPDATE t_order SET status = 'CHECKED' WHERE order_id = :NEW.order_id; END; /这段代码在更新 amount 时会触发触发器，触发器又更新 status，而 status 更新如果也命中这个触发器（取决于UPDATE OF限定），就会递归。即使UPDATE OF amount限定了列，某些场景下仍可能因为其他触发器链式触发。
解决办法：一是用UPDATING('column')判断当前更新列，避免无关更新进入逻辑；二是把同步逻辑挪到应用层或存储过程里显式调用；三是如果确实要在触发器里更新同表，用:NEW直接赋值（BEFORE 行级）而不是再发一条 UPDATE。BEFORE 行级里:NEW.status := 'CHECKED'是内存操作，不会触发递归。
3.3 自治事务的适用边界
自治事务（PRAGMA AUTONOMOUS_TRANSACTION）让触发器体里的 DML 独立于主事务提交或回滚。典型场景是“不管主事务成不成功，日志都要留下”。但自治事务有硬限制：它看不到主事务未提交的数据，主事务也看不到它未提交的数据，两边完全隔离。
CREATE OR REPLACE TRIGGER trg_audit_auto AFTER INSERT ON t_order FOR EACH ROW DECLARE PRAGMA AUTONOMOUS_TRANSACTION; BEGIN INSERT INTO t_order_audit(order_id, new_status, changed_by, changed_at) VALUES (:NEW.order_id, :NEW.status, USER, SYSDATE); COMMIT; -- 自治事务必须显式提交或回滚 END; /注意COMMIT必须写，否则自治事务挂起，主事务提交时会报 ORA-06519。另外自治事务里不要读主事务正在改的表，读到的可能是旧数据。我一般只在审计、错误日志这种“只写不读主数据”的场景用自治事务，其他情况优先考虑普通事务加应用层补偿。
4. 触发器避坑清单：5 个血泪教训
4.1 现象：批量导入后系统卡死；原因：行级触发器里做查询
某次批量导入 5 万行，每行都触发一个行级触发器，触发器体里有一条SELECT查配置表。5 万次查询把库打满，导入跑了 40 分钟。原因是行级触发器按行执行，查询被放大 5 万倍。解决：把配置查询挪到语句级触发器或包变量初始化里，行级只做内存赋值。如果必须查，用RESULT_CACHE函数缓存结果。
4.2 现象：审计表丢记录；原因：WHEN 条件里 NULL 比较
前面提过，WHEN (OLD.status <> NEW.status)在任一列为 NULL 时结果是 UNKNOWN，触发器不执行。解决：显式写WHEN (OLD.status <> NEW.status OR (OLD.status IS NULL AND NEW.status IS NOT NULL) OR (OLD.status IS NOT NULL AND NEW.status IS NULL))，或者干脆把条件挪到触发器体的 IF 里用IS NULL判断。
4.3 现象：触发器编译通过但运行报 ORA-04098；原因：触发器失效未重新编译
表结构变更（比如加列、改类型）后，依赖该表的触发器可能变成 INVALID 状态。查USER_TRIGGERS的 STATUS 列，如果是 INVALID，用ALTER TRIGGER trg_name COMPILE;重新编译。如果编译报错，查USER_ERRORS看具体行号。上线前把“编译所有 INVALID 触发器”加进发布脚本。
4.4 现象：自治事务报 ORA-06519；原因：忘记 COMMIT/ROLLBACK
自治事务必须显式结束，否则主事务提交时抛 ORA-06519。解决：在自治事务块的每个出口（正常结束、异常处理）都写 COMMIT 或 ROLLBACK。用EXCEPTION WHEN OTHERS THEN ROLLBACK; RAISE;保证异常时也回滚。
4.5 现象：触发器逻辑在测试环境正常、生产报权限错；原因：调用者权限 vs 定义者权限
触发器默认以定义者权限执行（AUTHID DEFINER），即用触发器所有者的权限访问对象。如果触发器所有者对某张表没权限，运行时就报 ORA-00942。解决：确认触发器所有者的对象权限，或者显式声明AUTHID CURRENT_USER让触发器以调用者权限执行。但后者会带来权限扩散风险，生产环境慎用。
5. 用数据字典和 EXPLAIN 验证触发器行为
5.1 查触发器状态和依赖
上线前用这几条查询确认触发器健康度：
-- 查所有触发器的状态和触发条件 SELECT trigger_name, trigger_type, triggering_event, status FROM user_triggers WHERE table_name = 'T_ORDER'; -- 查失效触发器 SELECT object_name, status FROM user_objects WHERE object_type = 'TRIGGER' AND status = 'INVALID'; -- 查触发器编译错误 SELECT name, line, position, text FROM user_errors WHERE type = 'TRIGGER' AND name = 'TRG_ORDER_AUDIT' ORDER BY sequence;USER_TRIGGERS的TRIGGER_TYPE会显示BEFORE STATEMENT、AFTER EACH ROW这类信息，TRIGGERING_EVENT显示INSERT OR UPDATE。USER_ERRORS的TEXT列直接给出编译错误原因，比在 IDE 里翻日志快。
5.2 用 DBMS_OUTPUT 和条件编译做调试
触发器调试不能像存储过程那样单步，常用手段是DBMS_OUTPUT.PUT_LINE加条件编译。但注意DBMS_OUTPUT缓冲区有限，行级触发器里大量输出会拖慢性能，只适合小数据量调试。
CREATE OR REPLACE TRIGGER trg_debug_demo AFTER UPDATE ON t_order FOR EACH ROW BEGIN $IF $$DEBUG_MODE $THEN DBMS_OUTPUT.PUT_LINE('order_id=' || :NEW.order_id || ' old=' || :OLD.status || ' new=' || :NEW.status); $END END; /$$DEBUG_MODE是条件编译标志，用ALTER SESSION SET PLSQL_CCFLAGS = 'DEBUG_MODE:TRUE';开启。生产环境编译时设为 FALSE，调试代码不会进入编译结果，零性能开销。这比手动注释代码可靠得多。
5.3 性能验证：对比触发器开关前后的执行计划
怀疑触发器拖慢 DML 时，用SET TIMING ON和AUTOTRACE对比：
SET TIMING ON ALTER TRIGGER trg_order_audit DISABLE; UPDATE t_order SET status = 'TEST' WHERE order_id = 1001; ALTER TRIGGER trg_order_audit ENABLE; UPDATE t_order SET status = 'TEST2' WHERE order_id = 1001;对比两次 UPDATE 的耗时。如果差距明显，用DBMS_PROFILER或DBMS_HPROF定位触发器体里的热点行。我一般还会查V$SQL里触发器内部 SQL 的执行次数，确认是否有意外的重复查询。
5.4 一个我坚持了多年的习惯
每次写完触发器，我一定做三件事：第一，在USER_TRIGGERS里确认 STATUS=ENABLED 且 TRIGGER_TYPE 符合预期；第二，用最小数据集跑一遍 INSERT/UPDATE/DELETE 三种路径，确认审计和校验都生效；第三，把触发器的 DISABLE/ENABLE 脚本写进发布文档，出问题时能一键摘除。触发器最大的风险不是写错，而是上线后没人记得它存在。把它当隐形逻辑管理，而不是当语法练习，能省下大量排查时间。希望帮到你。
本文还有配套的精品资源，点击获取
