记一次MySQL死锁排查过程

经由过程浏览逝世锁日记，我们可以清跋扈地知道两个事务形成了如何的轮回等待，再加以分析，就可以逆向揣摸出轮回等待的成因，也就是逝世锁形成的原因。

逝世锁形成流程图

为了让大年夜家更好地舆解逝世锁形成的原因，我们再经由过程表格的情势阐述逝世锁形成的流程：

步调
事务 1 事务 2 1 begin 2 delete from test where a = 2; 履行成功，事务 2 占领 a=2 下的 X 锁，类型为记录锁。 3 begin 4 delete from test where a = 2; 事务 1 欲望申请 a=2 下的 X 锁，然则因为事务 2 已经申请了一把 X 锁，两把 X 锁互斥，所以 X 锁申请进入锁请求队列。 5 出现逝世锁，事务 1 权重较小，所以被选择回滚（成为就义品）。 insert into test (id, a) values (10, 2); 因为 a 字段建立了独一索引，所以须要申请 S 锁以便检查 duplicate key，因为插入的 a 的值照样 2，所以排在 X 锁后面。然则前面的 X 锁的申请只有在事务 2commit 或者 rollback 之后才能成功，此时形成了轮回等待，逝世锁产生。

拓展

在排查逝世锁的过程中，有个同事还发清楚明了上述场景会产生另一种逝世锁，该场景无法经由过程手工复现，只有高并发场景下才有可能复现。

该逝世锁对应的日记这里就不贴出了，与上一个逝世锁的核心差别是事务 2 等待的锁大年夜 S 锁换成了 X 锁，也就是 lock_mode X locks gap before rec insert intention waiting。我们照样经由过程表格来具体解释该逝世锁产生的流程：

步调

总结

排查逝世锁时，起首须要根据逝世锁日记分析轮回等待的场景，然后根据当前各个事务履行的 SQL 分析出加锁类型以及次序，逆向揣摸出若何形成轮回等待，如许就能找到逝世锁产生的原因了。

PS：上述分析都是基于经验的揣摸，欲望其他小伙伴们可以或许指出傍边的缺点以及不足指出，感谢！

【编辑推荐】