mysql rec gap_记一次mysql死锁解析

最新推荐文章于 2024-10-22 10:38:34 发布

原创最新推荐文章于 2024-10-22 10:38:34 发布

· 551 阅读

0 ·

版权

文章标签：

#mysql rec gap

本文详细分析了一次由gap锁和插入意向锁引起的MySQL死锁情况。事务在尝试插入数据时，因加锁顺序不同导致双方等待对方释放gap锁，从而形成死锁。死锁涉及RR隔离级别下的GAP锁机制，防止幻读但可能影响并发。选择RC或RR隔离级别需考虑业务需求。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

从日志中我们可以看出死锁发生在表T_ORDERBILL_TASK上而且是两条相同类型的针对表T_ORDERBILL_TASK插入的insert语句！检查T_ORDERBILL_TASK表结构如下：

可见ORG_CODE上有二级索引。

(1) TRANSACTION也就是第一个事务的信息中：

lWAITING FOR THIS LOCK TO BE GRANTED，表示的是这个事务在等待的锁信息；

lindex ORG_CODE of table `T_BSE_QUERY_SCHEME`.`T_ORDERBILL_TASK`表示等的是表T_ORDERBILL_TASK上ORG_CODE索引上面的锁；

llock_mode X locks gap before rec insert intention waiting Record lock 表示这个语句要加一个插入意向锁但是还在等待状态，Record lock说明这是一个记录锁。

(2) TRANSACTION 也就是第二个事务中：

l(2) HOLDS THE LOCK(S)中lock_mode X locks gap before rec 表示了持有GAP锁

l(2) WAITING FOR THIS LOCK TO BE GRANTED中lock_mode X locks gap before rec insert intention waiting同(1)TRANSACTION等待加插入意向锁

结合业务开发提供的该模块儿的业务逻辑和发生死锁时间上下文业务日志可以整理出事务1和事务2的执行顺序为：

或者

可以看出在插入一条数据前先执行当前读锁住该条数据，若不存在则插入该条数据，否则执行update。

由于索引是顺序存储的，查出110026介于110019和110036之间：

由此可知：

当session 1执行select … for update当前读，由于ORG_CODE = 110026的数据不存在，因此会加上gap锁(110019,110036)。

Session 2执行select … for update当前读,同样也会加上gap锁(110019,110036)，由于gap锁不互斥，所以该语句也可成功执行。

但是到第三步时无论是session 1先插入还是session 2先插入都会等待对方的gap锁，第四步时后插入的也会被对方的gap锁阻塞。两个session进入互相等待状态形成死锁，最后死锁检测将session2回滚。

[

结论

]

其实GAP锁，就是RR隔离级别相对于RC隔离级别不会出现幻读的关键。在RR隔离级别下，条件列上为非唯一索引时，当前读通过条件列未定位到满足条件的记录时会加GAP锁，保证后续的insert不能插入相同值的数据，以防止出现幻读。需要注意的是GAP锁并不互斥但是和插入意向锁互斥。相同语句的情况下RR模式由于会加GAP锁可能锁住更多的数据，虽然防止了幻读，但是会影响一定的并发。在配置RC和RR隔离级别的时候一定要根据业务场景进行选择。