两个小工具，MySQL死锁分析，新技能又Get！

数据库死锁，是最难调试与追踪的。

场景如下：

同一个表，事务内先插入一条记录，再更新这条记录，并发时会死锁。

并且能够复现。

可以通过什么工具模拟并发事务，查看信息，解决问题呢?这是今天要分享的内容。

一、前置准备

set session transaction isolation level repeatable read; 
set session autocommit=0; 
  
create table t ( 
id int(20) primary key AUTO_INCREMENT, 
cell varchar(20) unique 
)engine=innodb; 
  
start transaction; 
insert into t(cell) values(11111111111); 
insert into t(cell) values(22222222222); 
insert into t(cell) values(33333333333); 
commit; 

说明：

• 案发时，事务隔离级别RR;
• 多终端实验，需要关闭事务自动提交;
• 建表，设置PK与unique，初始化数据;

二、并发事务模拟

Session A： 
start transaction; 
insert into t(cell)values(44444444444);  [1] 
        Session B： 
        start transaction; 
        insert into t(cell) values(55555555555); [2] 
update t set cell=123 where cell=44444444444; [3]    
        update t set cell=456 where cell=55555555555; [4] 

开启两个终端模拟并发事务：

• 红色SQL为事务A;
• 黑色SQL为事务B;
• [1][2][3][4]为执行时序;

三、实验现象

insert into t(cell)values(44444444444);  [1] 

事务A插入数据，最先执行

结果：插入成功

insert into t(cell) values(55555555555); [2] 

事务B插入数据，第二执行

结果：插入成果

update t set cell=123 where cell=44444444444; [3] 

事务A修改[1]中插入的数据，第三执行

结果：阻塞，等待执行结果

画外音：修改一条自己插入的数据，在等待什么呢?

update t set cell=456 where cell=55555555555; [4] 

事务B修改[2]中插入的数据，最后执行

结果：

• 事务B死锁，事务B被回滚;



• 事务A中，[3]语句阻塞结束，执行成功;

画外音：说明事务A中阻塞的语句，确实在等事务B中的某个锁。

四、结果分析

两个事务，各自修改自己插入的数据，却产生了死锁，确实诡异。

上述实验现象的两个核心问题是：

• 语句[3]阻塞，在等待什么锁?
• 语句[4]死锁，此时事务A和事务B一定是彼此占住一把锁，请求彼此的锁，这些锁又是什么呢?

工具一：

show engine innodb status; 

执行之后，显示的内容如下(放大仔细看)：

信息很多，别急，楼主娓娓道来。

第一部分，关键词是：

• Transaction 1，事务3998;
• 在执行

update t set cell=123 where cell=44444444444; 

• 正在等待锁释放(waiting for this lock to be granted)，记录锁(record locks)，主键索引上(index primary)，互斥锁(lock_mode X)，物理记录(physical record)，asc 55555555555;

画外音：英文比较差没事，抓关键词。

画外音，InnoDB存储引擎，聚集索引与非聚集索引的实现方式，决定了锁会加在聚集索引上，详见文章：

《1分钟了解MyISAM与InnoDB的索引差异》。

（编辑：济南站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!