不能在触发器中直接写 UPDATE ... WHERE id = :old.id，因为会引发 mutating table error（ORA-04091）且隐式开启自治事务被 Oracle 禁止；正确做法是用 AFTER ROW 触发器调用自治过程、BEFORE ROW 修改 :NEW 值，或改用 MERGE/应用层事务确保强一致性。
为什么不能在触发器里直接写 UPDATE ... WHERE id = :old.id
因为行级触发器中执行 DML 语句（如 UPDATE emp SET id = :new.id WHERE id = :old.id）会隐式开启自治事务，而 Oracle 禁止在触发器上下文中启动新事务。更关键的是，这会导致 mutating table error（ORA-04091），即“表正在被修改，无法查询自身”。哪怕目标表不是触发器所在表，只要该操作引发递归或约束检查链，也可能触发此错误。
用 AFTER ROW 触发器 + 自治过程绕过 mutating 表限制
自治过程（AUTONOMOUS_TRANSACTION）能脱离当前事务上下文独立提交，适合做日志记录或异步级联更新，但要注意它不参与主事务回滚——如果主事务失败，自治过程已提交的更改不会自动撤销。
安全做法是把级联逻辑封装进自治过程，并在 AFTER EACH ROW 触发器中调用：
CREATE OR REPLACE PROCEDURE cascade_update_emp_dept(p_old_id VARCHAR2, p_new_id VARCHAR2) AS PRAGMA AUTONOMOUS_TRANSACTION; BEGIN UPDATE emp SET dept_id = p_new_id WHERE dept_id = p_old_id; COMMIT; -- 必须显式 commit，否则报错 END; <p>CREATE OR REPLACE TRIGGER tr_dept_after_update AFTER UPDATE OF id ON deptment FOR EACH ROW BEGIN cascade_update_emp_dept(:old.id, :new.id); END;</p>
⚠️ 注意：cascade_update_emp_dept 中的 COMMIT 是强制要求；若省略，会报 ORA-06519；若主事务后续回滚，该更新仍生效。
用 BEFORE ROW 触发器 + :NEW 绑定变量替代物理更新
如果只是想让子表字段“看起来”同步变更（例如 dept_id 改了，emp.dept_id 也应随之变），且业务允许延迟一致性，优先用 BEFORE UPDATE 修改 :NEW 值，避免任何 DML。
适用场景：父子表共用同一字段含义，且子表无其他约束依赖该字段实时值。
-
BEFORE触发器中可安全读取:OLD和:NEW，无需自治事务 - 只能影响当前正在插入/更新的行，无法批量改已有数据
- 不触发额外 DML，无 mutating 表风险，也不引入事务隔离问题
示例（假设 deptment 更新时，希望新插入的 emp 记录自动继承最新 dept_id）：
CREATE OR REPLACE TRIGGER tr_emp_before_insert BEFORE INSERT ON emp FOR EACH ROW DECLARE v_latest_dept_id deptment.id%TYPE; BEGIN SELECT id INTO v_latest_dept_id FROM deptment WHERE ROWNUM = 1 ORDER BY created_date DESC; :NEW.dept_id := v_latest_dept_id; END;
真正需要强一致级联更新？别用触发器，改用 MERGE 或应用层控制
触发器本质是“副作用机制”，Oracle 官方文档明确建议：涉及跨表强一致性逻辑（尤其需原子性保障），应由应用事务或存储过程统一控制，而不是靠触发器拼凑。
比如部门 ID 批量重命名后同步员工表，正确姿势是：
- 用
MERGE一次性完成匹配更新：MERGE INTO emp e USING deptment d ON (e.dept_id = d.old_id) WHEN MATCHED THEN UPDATE SET e.dept_id = d.new_id - 或在应用代码中开启事务，先
UPDATE deptment，再UPDATE emp，统一提交或回滚 - 外键定义
ON UPDATE CASCADE在 Oracle 中不支持（仅 MySQL/PostgreSQL 支持），切勿在 DDL 里写这个语法，会报错
最容易被忽略的一点：触发器里的级联操作，连最基本的“主事务失败时自动回滚”都做不到——这是设计边界，不是技巧问题。
