MySQL:Innodb 一个死锁案例

RR隔离级别

问：

image.png

这种情况会产生死锁，如果将

insert into ty(a,b) values(2,10);

改为：

insert into ty(a,b) values(5,10);

则不会产生死锁为什么？

本死锁的堵塞主要集中在二级索引中，我们将二级索KEY

idxa

(

a

)和主键的数据按照Innodb引擎存储的方式大概排列一下则如图：

image.png

T2 步骤1：delete from ty where a=5;

根据这个记录我们可以画图如下，红色部分为锁定的部分箭头为g开发云主机域名ap lock：

image.png

T2 步骤1：delete from ty where a=5; 堵塞

根据这个记录我们可以画图如下，黄色部分为事务T1准备上锁但是被堵塞的部分，包含黄色部分和红色部分的记录说明它既被T2锁定了并且T1拿不到这条记录的锁，它实际上就是一个next key lock的堵塞：

image.png

insert into ty(a,b) values(2,10);

则发生死锁，实际上这一条记录记录在二级索引的值为(2,11)，11是主键的值，则画图如下：

image.png

这种情况下则T2也被堵塞，因为这个区域T1也处于堵塞下，则发生死锁。死锁记录如下：

及插入印象锁堵塞

insert into ty(a,b) values(5,10);

不会发生死锁，，实际上这一条记录记录在二级索引的值为(5,11)，11是主键的值，则画图如下：

image.png

如果是这种情况，不会发生死锁，我们可以看到对于二级索引而言这个区域没有其他事物堵塞，只是T2最开始获取过，本事务再次获取不会有问题。

本案例实际上就是看最后触发死锁的插入操作插入的记录到底落在二级索引的哪个区域。

作者微信：

相关推荐: 急中生智~利用Spark core完成”ETL”!

背景介绍：今天接到老板分配的一个小任务：开发一个程序，实现从数据库中抽取数据并生成报表（这是我们数据库审计平台准备上线的一个功能）。既然是要生成报表，那么首先得有数据，于是便想到从该业务开发云主机域名系统的测试环境抽取业务表的数据，然后装载至自己云主机上的My…