MySQL:RR分析死锁一列

  • 时间:
  • 浏览:1

select * from tt where c1=1 for update;

执行后的加锁行为

时要在唯一索引 1,1上 LOCK_ORDINARY|LOCK_X 也可是我可是我next key lock。你这人锁在本事物中并这样获取过,但会 时要重新的检测所的兼容性,最终加入了听候列表。

如下构造最好的土土办法,问为哪几种RC模式下不不死锁,RR模式下死锁。

到这里RR和RC加锁并这样哪几种不同,机会完正都是唯一值,一并锁继承也完正都是二级索引上的完正都是LOCK_S|LOCK_ORDINARY[next_key_lock],但会 下面就会再次出現不同了。

死锁所处但会 所处,而RC模式下最后两部时要获取的完正都是 LOCK_REC_NOT_GAP|LOCK_X,虽然session 2所处听候但会 session机会机会获得相同级别的锁不这样了进行检测加锁听候,而直接通过了。

亲戚朋友 这里还还后能 看后对于RR模式下唯一键c1的1,1机会删除了。我做了debug发现这里会在函数中row_search_mvcc加锁前做判断如下:

本文也是有另一个亲戚朋友 问我死锁难题。@越前

如上你这人的话会访问1,1标记为删除了,1,2这样提交 的有另一个记录。你这人完后 就再次出現了不同。

亲戚朋友 抛开你这人来分析这两句

亲戚朋友 还还后能 看后机会 c1是主键但会 加锁最好的土土办法不管如保会样完正都是LOCK_X|LOCK_REC_NOT_GAP,主键上也是同样的。可是我锁住了二级唯一索引和主键的相关记录。

实际上你这人完后 所处2条c1=1的记录必须1,1标记为删除了,1,2这样提交,完正都是时要访问的。

但会 堵塞行为为:

亲戚朋友 来看一下函数lock_rec_lock_slow,我做debug的完后 明显看后了不同的逻辑:

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

水平有限 有误请指出

版本:Percona MySQL 5.7.22

对于锁的学习我做了你这人输出完正参考如下:

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

select * from tt where c1=1 for update;

下面是死锁的记录:

update tt set id=2 where c1=1;

执行后的加锁行为

最终RR下形成了环路

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操作总是先删除但会 插入记录,主键则会进行判断有无还还后能 容下新的记录)