记一次MySQL死锁排查过程

0: len 4; hex 00000002; asc ;;

1: len 4; hex 00000002; asc ;;

以前接触到的数据库逝世锁，都是批量更新时加锁次序不一致而导致的逝世锁，然则上周却竽暌滚到了一个很难解得的逝世锁。借着这个机会又从新进修了一下 mysql 的逝世锁常识以及常见的逝世锁场景。在多方调研以及和同事们的评论辩论下终于发清楚明了这个逝世锁问题的成因，收成颇多。固然是后端法度榜样员，我们不须要像 DBA 一样深刻地去分析与锁相干的源码，然则如不雅我们可以或许控制根本的逝世锁排查办法，对我们的日常开辟照样大年夜规语益的。

浏览逝世锁日记

碰到逝世锁，第一步就是浏览逝世锁日记。逝世锁日记平日分为两部分，上半部分辩清楚明了事务 1 在等待什么锁：

170219 13:31:31 
 
*** (1) TRANSACTION: 
 
TRANSACTION 2A8BD, ACTIVE 11 sec starting index read 
 
mysql tables in use 1, locked 1 
 
LOCK WAIT 2 lock struct(s), heap size 376, 1 row lock(s) 
 
MySQL thread id 448218, OS thread handle 0x2abe5fb5d700, query id 18923238 renjun.fangcloud.net 121.41.41.92 root updating 
 
delete from test where a = 2 
 
*** (1) WAITING FOR THIS LOCK TO BE GRANTED: 
 
RECORD LOCKS space id 0 page no 923 n bits 80 index `a` of table `oauthdemo`.`test` trx id 2A8BD lock_mode X waiting 
 
Record lock, heap no 3 PHYSICAL RECORD: n_fields 2; compact format; info bits 32 
 
0: len 4; hex 00000002; asc     ;; 
 
1: len 4; hex 00000002; asc     ;;

【限时免费】岁尾最强一次云计算大年夜会，看传统、社区、互联网企业若何碰撞？

大年夜日记里我们可以看到事务 1 当前正在履行 delete from test where a = 2，该条语灸┞俘在申请索引 a 的 X 锁，所以提示 lock_mode X waiting。

然后日记的下半部分辩清楚明了事务 2 当前持有的锁以及等待的锁：

大年夜日记的 HOLDS THE LOCKS(S) 块中我们可以看到事务 2 持有索引 a 的 X 锁，并且是记录锁（Record Lock）。该锁是经由过程事务 2 在步调 2 履行的 delete 语句申请的。因为是 RR 隔离模式下的基于独一索引的等值萌芽（Where a = 2），所以会申请一个记录锁，而非 next-key 锁。

大年夜日记的 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 锁必须等待，所以形成了轮回等待，逝世锁出现了。

5/6 首页上一页 3 4 5 6 下一页尾页

　　推荐阅读

　　惠普战66上手：八代轻薄本中的性能王者

大年夜家之所以会去选择轻薄本，无疑是看中了便携这一特点，但这类标记本往往为了续航和散热等方面推敲，机能会有大年夜幅缩水，要想比较流畅地处理大年夜数据量的工作文件或玩游戏都是根本不太行的。 >>>详细阅读

本文标题：记一次MySQL死锁排查过程

地址：http://www.17bianji.com/lsqh/39935.html

1/2 1