自治事务内执行DML会触发父事务等待，因其虽独立提交但共享同一实例锁资源；UPDATE/DELETE等操作加X锁，与父事务持锁或后续访问同一行时形成物理锁冲突，导致enq: TX等待、阻塞甚至死锁。
自治事务内执行 DML 时为何会触发父事务等待？
自治事务看似“独立”，但底层仍共享同一数据库实例的锁资源。当 PRAGMA AUTONOMOUS_TRANSACTION 块中执行 UPDATE 或 DELETE 操作时，它会对目标行加排他锁（X 锁）；而父事务若正持有这些行的锁（比如刚查完未提交），或反过来——父事务后续也想改同一行——就会形成锁依赖链。这不是事务隔离问题，而是物理锁冲突。
常见错误现象包括：enq: TX - row lock contention 等待事件持续升高、V$SESSION_BLOCKERS 显示自治事务会话阻塞父事务、甚至触发死锁（Oracle 自动回滚其中一个，报 ORA-00060）。
- 自治事务无法看到父事务未提交的数据，但能对其已加锁的行产生真实锁竞争
- 即使父事务只执行了
SELECT FOR UPDATE（没改数据），只要没COMMIT或ROLLBACK，自治事务仍可能被阻塞 - 触发器中嵌套自治事务最危险：父事务在更新表 A，触发器启动自治事务去更新表 B，而另一个会话正持表 B 锁等表 A —— 循环等待闭环就形成了
哪些 DML 操作在自治事务里要特别小心？
不是所有 DML 都等价。高风险操作集中在“隐式锁升级”和“无明确 WHERE 条件”的场景：
-
UPDATE table_name SET col = ...（无WHERE）→ 全表扫描 + 行级 X 锁 → 极易与父事务冲突 -
DELETE FROM table_name（无WHERE）→ 同上，且可能触发大量锁等待 -
INSERT INTO ... SELECT ... FROM parent_table→ 若SELECT扫描父事务正在修改的表，可能因一致性读（CR）块构造引发额外 latch 争用，间接拖慢锁释放 -
MERGE语句 → 内部含UPDATE/INSERT分支，逻辑复杂，锁行为难预测
相对安全的操作：INSERT INTO log_table VALUES (...)（单行、目标表无业务关联）、SELECT COUNT(*) FROM audit_log（只读，不加写锁）。
如何用最小改动规避自治事务锁冲突？
核心思路是“拆锁”和“错峰”：让自治事务避开父事务活跃的数据范围，或把锁持有时间压到最低。
- 在自治事务中显式使用
SELECT ... FOR UPDATE NOWAIT替代直接UPDATE，捕获ORA-00054并重试/跳过，避免无限等待 - 对日志类表，用序列 + 批量
INSERT /*+ APPEND */减少单次锁持有时间（注意：需自治事务内COMMIT） - 父事务中，把
SELECT FOR UPDATE尽量推迟到真正需要修改前一刻，而不是开头就锁住一堆行 - 避免在自治事务中调用含 DML 的存储过程——除非你 100% 确认其目标表与父事务零交集
示例：审计触发器中记录变更，不要写 UPDATE audit_log SET last_update = SYSDATE WHERE id = :new.id，改用 INSERT INTO audit_log (id, op, ts) VALUES (:new.id, 'UPDATE', SYSDATE)。
为什么自治事务里的 COMMIT 不能解决死锁？
很多人误以为“自治事务自己 COMMIT 了，锁就全释放了，就不会影响父事务”。这是错觉。锁释放时机取决于事务结束（COMMIT 或 ROLLBACK），但关键在于：自治事务的锁与父事务的锁是并存于同一实例的，Oracle 不区分“谁的锁”，只看“谁先申请、谁在等”。
更隐蔽的问题是：自治事务 COMMIT 后，父事务仍可能因以下原因卡住：
- 父事务在自治事务
COMMIT后立即执行UPDATE同一行 → 触发新一轮锁申请，而此时行上可能还有其他会话的锁残留 - 自治事务中用了
DBMS_LOCK.SLEEP或长耗时逻辑 → 拖长整体事务窗口，增加与其他会话交叉概率 - 父事务开启时用了
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE→ 会话间可见性规则变化，加剧锁判断复杂度
真正有效的缓解点，永远落在“减少锁粒度”和“缩短锁持有时间”上，而不是依赖自治事务的独立性幻觉。
