一次诡异的数据库“死锁”，题目毕竟在那边？

措施死锁的题目，很难调试，看历程仓库，看各个线程与锁的环境，比较代码举办排查。

数据库死锁的题目，更难，看不了数据库仓库，也看不了数据库线程与锁，更难以比较代码排查。

前段时刻，和一个伴侣接头了一个“疑似”数据库死锁的题目，最后举办试验与排查，找到了题目地址。

场景如下：

统一个表，高并发事宜，事宜内先插入一笔记录，再更新这笔记录：

• 假如更新的是独一索引，有非常;
• 假如更新的是自增主键，就没有非常;

画外音：先不要被“dead lock”描写所疑惑，是死锁题目，阻塞题目，照旧其他非常，还另说。

并且，据伴侣所述，还可以或许复现：

• 开启事宜;
• 插入记录;
• sleep 5秒;
• 修改被插入的记录;

在并发时不变复现。

按照伴侣的描写，在线下开了多个MySQL客户端举办了并发模式测试，功效还挺出乎料想的。

第一步：数据筹备

create table t ( 
id int(20) primary key AUTO_INCREMENT, 
cell varchar(20) unique 
)engine=innodb; 

新建表：

• 存储引擎是innodb，MySQL版本是5.6;
• id字段，自增主键;
• cell字段，独一索引;

start transaction; 
insert into t(cell) values(11111111111); 
insert into t(cell) values(22222222222); 
insert into t(cell) values(33333333333); 
commit; 

插入一些测试数据。

第二步：session参数配置

事宜的断绝级别，事宜的自动提交等参数配置不妥，城市对尝试的功效发生影响，扣问了伴侣，事宜的断绝级别是RR(repeatable read)。

set session autocommit=0; 
set session transaction isolation level repeatable read; 

每一个session启动后：

• 封锁自动提交;
• 把事宜断绝级别设为RR;

show session variables like "autocommit"; 
show session variables like "tx_isolation"; 

不安心的话，可以用上面两个语句查询确认。

第三步：多个终端session模仿并发事宜

如上图，用SecureCRT开启两个窗口：

• 窗口A，先启动事宜，并插入记录;
• 窗口B，再启动事宜，也插入记录;
• 窗口A，修改插入的记录;
• 窗口B，也修改插入的记录;

稀疏的征象产生了，假如并发事宜的update语句：

• 更新前提是cell，就会产生非常;
• 更新前提是id，就统统正常;

按原理，插入不斗嘴的记录，然后修改这笔记录，行锁不该该斗嘴呀?独一索引，主键索引怎么会有差别呢?是否有关?是死锁，照旧其他缘故起因?

各人资助说明说明，到底题目在那边呢?

【本文为51CTO专栏作者“58沈剑”原创稿件，转载请接洽原作者】

戳这里，看该作者更多好文

【编辑保举】

1. 办理线上数据库死锁，就是这么简朴！
2. 呆板进修能革了数据库索引的命吗?
3. 漫衍式时序数据库QTSDB的计划与实现
4. 干货 | MySQL数据库安详之审计
5. 墨菲定律视角下的数据库入侵防止

（编辑：河北网）

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