You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

PK约束设为Initially Deferred时重复插入为何仍出现阻塞?

为什么设置Initially Deferred的主键仍会导致插入重复ID时事务阻塞?

Initially Deferred 主键的作用只是把唯一性约束的验证时机从语句执行阶段推迟到事务提交阶段,但这和Oracle的行级锁机制是两回事,这就是你遇到阻塞的核心原因:

  • 当T1插入ID=1的记录后,会在这条记录(以及对应的索引条目)上加排他锁(X锁),目的是防止其他事务修改或插入冲突数据,这个锁和约束是否延迟无关。
  • T2尝试插入相同ID=1的记录时,必须获取该数据对应的锁,但T1还没提交,锁没释放,所以T2会被阻塞,直到T1提交或回滚。

关于索引从唯一变非唯一的逻辑

Oracle里,不可延迟的主键是靠唯一索引实现即时唯一性检查的——因为唯一索引会在插入/更新时直接拦住重复值。但延迟主键需要推迟检查,这种即时校验就和需求冲突了,所以Oracle会自动把对应的唯一索引改成非唯一索引,这样插入时不会触发即时校验,符合延迟约束的设计。

提交T1后T2不再阻塞的原因

T1提交后,它持有的排他锁会释放,T2能拿到锁,所以插入语句能正常执行(注意:这只是语句执行完成,不是最终通过约束验证)。如果T1已经提交了ID=1的记录,T2自己提交时会触发延迟的主键唯一性检查,这时候会抛出ORA-00001: unique constraint violated错误,你看到的“插入执行成功”只是语句执行阶段完成,并非事务最终提交成功。

内容的提问来源于stack exchange,提问作者Blocked

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.07.17 12:20:14