如何处理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死锁问题”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注创新互联行业资讯频道！