如何处理MySQL死锁问题
小编给大家分享一下如何处理MySQL死锁问题,相信大部分人都还不怎么了解,因此分享这篇文章给大家参考一下,希望大家阅读完这篇文章后大有收获,下面让我们一起去了解一下吧!
创新互联从2013年开始,先为泰顺等服务建站,泰顺等地企业,进行企业商务咨询服务。为泰顺企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。
MySQL里的锁兼容列表大体是这样的关系,如果第一次看会有些晕,感觉抓不住重点,其实有一点小技巧。
首先InnoDB实现了两种类似的行锁,即S(共享锁)和X(排他锁),而InnoDB层面的表级意向锁有IS(意向共享锁)和IX9意向排他锁),意向锁之间是互相兼容的,这句话很重要,按照这个思路里面一半的内容就明确了。而另外一部分则是S和X的兼容性。带着S锁和X锁的组合都是互相排斥,只有一类场景例外,那就是都是S锁,是兼容的。所以这个图按照这个思路几乎不用记就能基本理解了。
看起来S锁的组合是很柔和的,从这种场景来看保持兼容,那么出死锁的概率应该很低吧,其实在RR,RC隔离级别下我们可以逐步扩展然后举一反三。
如果S锁的组合在两个会话中是互相兼容,那么接下来的X锁的组合就是互相排斥的。
那么在两个会话并发的场景下,死锁的步骤如下:
mysql> create table dt1 (id int unique
Query OK, 0 rows affected (0.03 sec)
会话1:
begin;
select *from dt1 lock in share mode; --显式共享锁
会话2:
begin;
select *from dt1 lock in share mode; --显式共享锁
会话1:
insert into dt1 values(1); --阻塞
会话2:
insert into dt1 values(2); --触发死锁
所以上面的语句特点很明显,插入的数据分别是1和2,看起来互补冲突也不行。
我们进度稍快一些,我们可能很少看到直接声明share mode的方式,但是有很多时候由其他的场景会触发,其中的一个主要原因就在于对于duplicate数据的检查会开启S锁。这是比较特别的一点,需要注意。
按照这一点来扩展,很容易就可以扩展到3个会话中。
会话1只是负责插入一条数据,会话2,3也紧接着插入一条记录(会话2,3自动提交),但是因为唯一性索引的检查,会导致会话2和会话3都开启了S锁,因为兼容,所以暂时还没影响。如果会话1正常提交,会话2,3的检查会生效,导致数据插入不了,违反唯一性约束,但是我们反其道而行,就可以用一个rollback来释放锁,紧接着会话2和会话3都会获得S锁成功,紧接着获得X锁,细节算法就不说了。这个时候互相阻塞,导致会话3产生死锁,会话2的数据插入依然会成功。
会话1:
begin;
insert into dt1 values(1);
会话2:
insert into dt1 values(1);
会话3:
insert into dt1 values(1);
会话1:
rollback;
看起来很精巧的小测试,但是里面蕴含这大道理,比如按照这个思路,如果后面的两个语句都是delete,也会触发死锁。有的时候我们可以正面来图例,或者通过死锁日志来推理。给我的一个启发是太极。
放在锁的角度来理解就会好很多。
用一张不太形象的图表示就是,左边的部分是insert操作在会话1中,右边的是在会话2和会话3中,都持有S锁,然后会因为同样的原因事务回滚后,他们的S锁会升级为X锁导致死锁发生。
按照这个思路,我们可以继续扩展出几个场景。比如delete的方式。
按照这样的思路,可以构建出很多的死锁场景来。
以上是“如何处理MySQL死锁问题”这篇文章的所有内容,感谢各位的阅读!相信大家都有了一定的了解,希望分享的内容对大家有所帮助,如果还想学习更多知识,欢迎关注创新互联行业资讯频道!
网站栏目:如何处理MySQL死锁问题
文章链接:http://pwwzsj.com/article/ipcieo.html