BEFORE INSERT触发器中修改:NEW字段未生效，因赋值须在触发器结束前完成且不能覆盖、不可在AFTER中修改；:OLD/:NEW在UPDATE中可共用作审计，但:OLD在INSERT中不存在；AFTER DELETE中:OLD仍有效，无需查表；触发器内调用过程同步执行，禁止COMMIT。
BEFORE INSERT 触发器里改 :NEW 字段，为什么没生效？
因为 :new 是可写的“副本”，改它只影响即将插入的行，但必须在触发器结束前完成赋值，且不能对主键或非空约束字段赋 null。常见错误是写成 :new.col := ... 后又在后续逻辑里覆盖，或者在 after 里试图改它——after 中 :new 已只读。
- 只在
BEFORE INSERT或BEFORE UPDATE中修改:NEW - 避免在条件分支外漏写赋值，比如
IF ... THEN :NEW.x := 1; END IF;没ELSE就可能留空 - 如果字段有
NOT NULL约束，又没显式赋值，会报ORA-01400: cannot insert NULL
UPDATE 触发器中 :OLD 和 :NEW 能不能都用？
能，而且这是审计和业务校验最常用的组合。比如检查价格是否被异常调高、记录修改前后的状态差异。关键点在于：二者都是只读快照（除了 :NEW 在 BEFORE 中可写），且字段类型与表定义严格一致——哪怕表里是 NUMBER(10,2)，:OLD.price 也按同样精度参与比较。
-
:OLD在INSERT触发器里不存在，直接引用会报PLS-00201: identifier ':OLD.xxx' must be declared - 比较字符串时注意空格和大小写：
:OLD.name != :NEW.name可能因尾部空格失效，建议用TRIM(:OLD.name) != TRIM(:NEW.name) - 对
DATE字段做差值计算，别直接减，用EXTRACT或ROUND(:NEW.ts - :OLD.ts, 6)避免毫秒级误差干扰判断
为什么 AFTER DELETE 触发器查不到被删的行？
不是查不到，而是行物理删除已完成，:OLD 仍可用，但不能再 SELECT 它对应的真实行（因为已从表中移除）。如果你在触发器里写 SELECT * FROM t WHERE id = :OLD.id，会查不到结果——这不是 bug，是设计使然。
-
:OLD在DELETE触发器中始终有效，直接用:OLD.xxx即可取值 - 需要关联其他表做清理时，用
:OLD值驱动即可，无需反查原表 - 误写成
SELECT ... INTO ... FROM t WHERE id = :OLD.id会导致NO_DATA_FOUND异常，必须加EXCEPTION WHEN NO_DATA_FOUND THEN NULL;或改用:OLD
触发器里调用存储过程，执行顺序怎么算？
触发器体内的 PL/SQL 代码是同步执行的，包括调用的存储过程。也就是说，BEFORE INSERT 触发器里的 my_proc(:NEW.id) 会在 INSERT 执行前跑完；而 AFTER 里的调用则一定在 DML 提交之后（但仍在同一事务内）。
- 如果存储过程中有
COMMIT或ROLLBACK，会直接报ORA-04092: COMMIT not allowed in trigger - 跨 schema 调用需确保权限已通过
GRANT EXECUTE ON xxx TO xxx显式授予，依赖角色权限无效 - 触发器调用链过深（A→B→C）容易触发
ORA-00604: error occurred at recursive SQL level，建议单个触发器只做轻量协调，重逻辑下沉到过程
事情说清了就结束。触发器的时机本质是“数据变更生命周期”的切片，BEFORE 是干预窗口，AFTER 是反应窗口，:OLD/:NEW 不是变量，是上下文快照——这点最容易被当成普通变量来用。
