死锁实现以及日志解读

moernagedian

于 2024-09-06 09:35:31 发布

阅读量440

点赞数 5

文章标签：数据库 java 开发语言

本文链接：https://blog.csdn.net/moernagedian/article/details/141950023

版权

死锁实现环境

前置准备

select @@tx_isolation;

set autocommit=0;

CREATE TABLE `account` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  `balance` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_name` (`name`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8;

INSERT INTO `axon_bank`.`account` (`id`, `name`, `balance`) VALUES (1, 'Eason', 100);
INSERT INTO `axon_bank`.`account` (`id`, `name`, `balance`) VALUES (2, 'Wei', 100);

创建死锁

第一个事务

begin;
UPDATE account set balance = 1000 WHERE name = 'Wei'

在这里插入图片描述
第二个事务

begin;
UPDATE account set balance = 1000 WHERE name = 'Eason'

在这里插入图片描述
在第一个事务中执行

insert into account values(null,'Jay',100);

在这里插入图片描述
陷入阻塞，查看锁的状况

select * from information_schema.innodb_locks;

在这里插入图片描述
在第二个事务中执行

insert into account values(null,'Yan',100);

事务B执行插入操作，插入成功，同时事务A的插入由阻塞变为死锁error。
在这里插入图片描述

排查

show engine innodb status

在这里插入图片描述
事务1910745
正在执行sql insert into account values(null,‘Yan’,100)

间隙锁(lock_mode X locks gap before rec)
区间（未知，Wei）

等待锁释放(waiting for this lock to be granted)
插入意向锁(lock_mode X insert intention waiting)
间隙区间（未知，+∞）;
在这里插入图片描述
事务1回滚

结论

事务A执行完Update Wei的语句，持有（E，W]的Next-key Lock，（W，+∞）的Gap Lock ，插入成功~
事务B执行完Update Eason语句，持有（-∞，E]的 Next-Key Lock，（E，W）的Gap Lock，插入成功~
事务A执行Insert Jay的语句时，因为需要（E，W）的插入意向锁，但是（E，W）在事务B怀里，所以它陷入阻塞~
事务B执行Insert Yan的语句时，因为需要(W,+∞) 的插入意向锁，但是(W,+∞) 在事务A怀里，所以它也陷入阻塞。
事务A持有（W，+∞）的Gap Lock，在等待（E，W）的插入意向锁，事务B持有（E，W）的Gap锁，在等待(W,+∞) 的插入意向锁，所以形成了死锁的闭环_{（Gap锁与插入意向锁会冲突的，可以看回锁介绍的锁模式兼容矩阵哈}）
事务A,B形成了死锁闭环后，因为Innodb的底层机制，它会让其中一个事务让出资源，另外的事务执行成功，这就是为什么你最后看到事务B插入成功了，但是事务A的插入显示了Deadlock found ~