MySQL:RR分析死锁一列

  • 时间:
  • 浏览:1
  • 来源:大发5分6合_大发5分6合官方

select * from tt where c1=1 for update;

执行后的加锁行为

最后留下好多个栈帧以备分析使用

如下构造最好的办法,问为哪些地方RC模式下无需死锁,RR模式下死锁。

死锁处于否则处于,而RC模式下最后两部前要获取的都在 LOCK_REC_NOT_GAP|LOCK_X,我人太好session 2处于在等待否则session肯能肯能获得相同级别的锁无需在进行检测加锁在等待,而直接通过了。

大伙 抛开很多来分析这两句

实际上这个 时候处于2条c1=1的记录没有1,1标记为删除了,1,2没有提交,都在前要访问的。

否则堵塞行为为:

select * from tt where c1=1 for update;

最终RR下形成了环路

下面是死锁的记录:

update tt set id=2 where c1=1;

执行后的加锁行为

这个 句比较重要,在二级唯一索引c1上会做5个 删除和插入操作,也也不我会将原来的1,1记录标记为del flag,同时插入2,1这条记录,这会引起5个 锁的继承操作(lock_rec_inherit_to_gap_if_gap_lock调用会再次出显GAP LOCK),否则时候都在涉及到唯一性检查否则还涉及到LOCK_S锁和next key lock的处于(对于二级索引做唯一性检查始终是next key lock)。这里的del flag也是形成死锁的重要原因分析。(对于二级索引的update操作突然 先删除否则插入记录,主键则会进行判断否是是都前要容下新的记录)

select * from tt where c1=1 for update;

水平有限 有误请指出

版本:Percona MySQL 5.7.22

对于锁的学习我做了很多输出完全参考如下:

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

到这里RR和RC加锁并没哪些地方地方不同,肯能都在唯一值,同时锁继承也都在二级索引上的都在LOCK_S|LOCK_ORDINARY[next_key_lock],否则下面就会再次出显不同了。

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

大伙 都前要看多肯能 c1是主键否则加锁最好的办法不管为什会 样都在LOCK_X|LOCK_REC_NOT_GAP,主键上也是同样的。也不我锁住了二级唯一索引和主键的相关记录。

前要在唯一索引 1,1上 LOCK_ORDINARY|LOCK_X 也也不我也不我next key lock。这个 锁在本事物中并没有获取过,否则前要重新的检测所的兼容性,最终加入了在等待列表。

大伙 来看一下函数lock_rec_lock_slow,我做debug的时候明显看多了不同的逻辑:

本文也是5个 大伙 问我死锁什么的问题。@越前

如上这个 语录会访问1,1标记为删除了,1,2没有提交 的5个 记录。这个 时候就再次出显了不同。