MySQL:RR分析死锁一列

  • 时间:
  • 浏览:1

须要在唯一索引 1,1上 LOCK_ORDINARY|LOCK_X 也就是我就是我next key lock。你是什么锁在本事物中并没有 获取过,但会 须要重新的检测所的兼容性,最终加入了等待时间列表。

我们我们我们 抛开某些来分析这两句

实际上你是什么完后 居于2条c1=1的记录才能1,1标记为删除了,1,2没有 提交,与否须要访问的。

但会 堵塞行为为:

死锁居于但会 居于,而RC模式下最后两部须要获取的与否 LOCK_REC_NOT_GAP|LOCK_X,之所以session 2居于等待时间但会 session但会 但会 获得相同级别的锁不都没有进行检测加锁等待时间,而直接通过了。

如下构造依据,问为哪几种RC模式下不不死锁,RR模式下死锁。

本文也是三个白 我们我们我们 问我死锁大问题。@越前

select * from tt where c1=1 for update;

update tt set id=2 where c1=1;

执行后的加锁行为

select * from tt where c1=1 for update;

执行后的加锁行为

你是什么句比较重要,在二级唯一索引c1上会做三个白 删除和插入操作,也就是我会将完后 的1,1记录标记为del flag,一并插入2,1这条记录,这会引起三个白 锁的继承操作(lock_rec_inherit_to_gap_if_gap_lock调用会老是出先GAP LOCK),但会 完后 与否涉及到唯一性检查但会 还涉及到LOCK_S锁和next key lock的居于(对于二级索引做唯一性检查始终是next key lock)。这里的del flag也是形成死锁的重要因为。(对于二级索引的update操作老是先删除但会 插入记录,主键则会进行判断与否才能容下新的记录)

我们我们我们 这不才能都看对于RR模式下唯一键c1的1,1但会 删除了。我做了debug发现这里会在函数中row_search_mvcc加锁前做判断如下:

最后留下几块栈帧以备分析使用

我们我们我们 才能都看但会 c1是主键但会 加锁依据不管为甚会么会样与否LOCK_X|LOCK_REC_NOT_GAP,主键上也是同样的。就是我锁住了二级唯一索引和主键的相关记录。

下面是死锁的记录:

到这里RR和RC加锁并没有 哪几种不同,但与否唯一值,一并锁继承也与否二级索引上的与否LOCK_S|LOCK_ORDINARY[next_key_lock],但会 下面就会老是出先不同了。

select * from tt where c1=1 for update;

我们我们我们 来看一下函数lock_rec_lock_slow,我做debug的完后 明显都看了不同的逻辑:

水平有限 有误请指出

版本:Percona MySQL 5.7.22

对于锁的学习我做了某些输出完正参考如下:

https://github.com/gaopengcarl/percona-server-locks-detail-5.7.22.git其带有readme

最终RR下形成了环路

如上你是什么句子会访问1,1标记为删除了,1,2没有 提交 的三个白 记录。你是什么完后 就老是出先了不同。