一个MySQL死锁问题的复现_这样分析一个死锁问题

之前也列举了几期的MySQL死锁问题，光有操作演练，还缺少一些自己的分析，所以我就打算补充一下。

首先对于死锁问题，我们分析的背景是基于MySQL事务隔离级别为RR,存储引擎为InnoDB,在MySQL 5.6,5.7版本均可复现问题。

怎么来分析一个死锁问题呢，我一直在琢磨这个问题，自己也总结了不少出现的场景，但是感觉还是有一些欠缺或者不完善的地方。那么我们就换一个思路来分析死锁问题，通过日志来反推死锁产生的可能场景，然后依次深入，扩展，这样一来，这个问题的分析就带有通过很多不确定性分析判断，得到确定性的结果，然后分析和预期一致，这个问题就算基本搞明白了。

所以在此我不给出表结构，只给出死锁的日志来。这样一段日志，是在MySQL设置了死锁检测，输出日志的参数后得到的。

通过一段死锁日志来挖掘一些有价值的信息。

整个死锁的日志分为了两个事务，Transaction 1和Transaction

2，这里需要指出的是，这其实是发生死锁的临界状态的事务信息，就好似一个印章。我们看到的是最后得到的一个状态信息(类似盖上印章的一瞬间)，而完整的过程是没法通过日志体现出来的，还有一个，如果仔细看上面的日志就会发现，事务1的日志还是不够完整，持有的锁，等待的锁，只打印出了等待的锁，有很多业内朋友是通过修改内核代码来把这个信息补充完整的。