从日志的WAITING FOR THIS LOCK TO BE GRANTED块中我们可以看到事务2正在申请S锁，也是共享锁。该锁是insert into test (id，a) values (10，2)语句申请的。insert语句在普通情况下是会申请排他锁，也是X锁，但是这里出现了S锁。这是因为a字段是一个索引，所以insert语句会在插入前进行一次duplicate key的检查，为了使这次检查成功，需要申请S锁防止其他事务对a字段进行修改。
　　那么为什么该S锁会失败呢？这是对同一个字段的锁的申请是需要排队的。S锁前面还有一个未申请成功的X锁，所以S锁必须等待，所以形成了循环等待，死锁出现了。
　　通过阅读死锁日志，我们可以清楚地知道两个事务形成了怎样的循环等待，再加以分析，可以逆向推断出循环等待的成因，也是死锁形成的原因。
　　死锁形成流程图
　　为了让大家更好地理解死锁形成的原因，我们再通过表格的形式阐述死锁形成的流程：

　　拓展
　　在排查死锁的过程中，有个同事还发现了上述场景会产生另一种死锁，该场景无法通过手工复现，只有高并发场景下才有可能复现。
　　该死锁对应的日志这里不贴出了，与上一个死锁的核心差别是事务2等待的锁从S锁换成了X锁，也是lock_mode X locks gap before rec insert intention waiting。我们还是通过表格来详细说明该死锁产生的流程：

　　总结
　　排查死锁时，首先需要根据死锁日志分析循环等待的场景，然后根据当前各个事务执行的SQL分析出加锁类型以及顺序，逆向推断出如何形成循环等待，这样能找到死锁产生的原因了。
　　PS：上述分析都是基于经验的推断，希望其他小伙伴们能够指出当中的错误以及不足指出，谢谢！