初学者从源码理解MySQL死锁问题

通过好多个深夜艰难的单步调试，终于找到了一个理想的断点，可以看到大部分获取锁的过程
代码在lock0lock.c的static enum db_err lock_rec_lock() 函数中，这个函数会显示，获取锁的过程，以及获取锁成功与否。

场景1：通过主键进行删除

表结构

CREATE TABLE `t1` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `name` varchar(10) NOT NULL DEFAULT '',
 PRIMARY KEY (`id`)
) ENGINE=InnoDB;

delete from t1 where id = 10;

可以看到，对索引 PRIMARY 加锁，mode = 1027，1027是什么意思呢？1027 =  LOCK_REC_NOT_GAP + LOCK_X（非 gap 的记录锁且是 X 锁）

过程如下

结论：根据主键 id 去删除数据，且没有其它索引的情况下，此 SQL 只需要在 id = 10 这条记录上对主键索引加 X 锁即可

场景2：通过唯一索引进行删除

表结构做了微调，增加了 name 的唯一索引

构造数据
CREATE TABLE `t2` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `name` varchar(10) NOT NULL DEFAULT '',
 PRIMARY KEY (`id`),
 UNIQUE KEY `uk_name` (`name`)
) ;
INSERT INTO `t2` (`id`, `name`) VALUES
 (1,'M'),
 (2,'Y'),
 (3,'S'),
 (4,'Q'),
 (5,'L');

测试sql语句
delete from t2 where name = "Y"

来看实际源码调试的结果

第一步：

第二步：

结论：这个过程是先对唯一键 uk_name 加 X 锁，然后再对聚簇索引（主键索引）加 X 锁

过程如下

场景3：通过普通索引进行删除

构造数据
CREATE TABLE `t3` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `name` varchar(10) NOT NULL DEFAULT '',
 PRIMARY KEY (`id`),
 KEY `idx_name` (`name`)
);
INSERT INTO `t3` (`id`, `name`) VALUES
 (1,'N'),
 (2,'G'),
 (3,'I'),
 (4,'N'),
 (5,'X');

测试语句：
delete from t3 where name = "N";

调试过程如图：

结论：通过普通索引进行更新时，会对满足条件的所有普通索引加 X 锁，同时会对相关的主键索引加 X 锁

过程如下

场景4：不走索引进行删除

CREATE TABLE `t4` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `name` varchar(10) NOT NULL DEFAULT '',
 PRIMARY KEY (`id`)
)

INSERT INTO `t4` (`id`, `name`) VALUES
 (1,'M'),
 (2,'Y'),
 (3,'S'),
 (4,'Q'),
 (5,'L');

delete from t4 where name = "S";

总共有 5 把 X 锁，剩下的 3 把就不一一放上来了

结论：不走索引进行更新时，sql 会走聚簇索引（主键索引）对全表进行扫描，因此每条记录，无论是否满足条件，都会被加上X锁。还没完...

但是为了效率考量，MySQL做了优化，对于不满足条件的记录，会在判断后放锁，最终持有的，是满足条件的记录上的锁，但是不满足条件的记录上的加锁/放锁动作不会省略。

过程如下

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持我们。

赞 (0)

相关推荐

  • 一次神奇的MySQL死锁排查记录

    一次神奇的MySQL死锁排查记录

    背景 说起Mysql死锁,之前写过一次有关Mysql加锁的基本介绍,对于一些基本的Mysql锁或者死锁都有一个简单的认识,可以看下这篇文章为什么开发人员需要了解数据库锁.有了上面的经验之后,本以为对于死锁都能手到擒来,没想到再一个阳光明媚的下午报出了一个死锁,但是这一次却没想象的那么简单. 问题初现 在某天下午,突然系统报警,抛出个异常: 仔细一看好像是事务回滚异常,写着的是因为死锁回滚,原来是个死锁问题,由于我对Mysql锁还是有一定了解的,于是开始主动排查这个问题. 首先在数据库中查找Inn

  • 一个mysql死锁场景实例分析

    一个mysql死锁场景实例分析

    前言 最近遇到一个mysql在RR级别下的死锁问题,感觉有点意思,研究了一下,做个记录. 涉及知识点:共享锁.排他锁.意向锁.间隙锁.插入意向锁.锁等待队列 场景 隔离级别:Repeatable-Read 表结构如下 create table t ( id int not null primary key AUTO_INCREMENT, a int not null default 0, b varchar(10) not null default '', c varchar(10) not n

  • 详解MySQL（InnoDB）是如何处理死锁的

    详解MySQL（InnoDB）是如何处理死锁的

    一.什么是死锁 官方定义如下:两个事务都持有对方需要的锁,并且在等待对方释放,并且双方都不会释放自己的锁. 这个就好比你有一个人质,对方有一个人质,你们俩去谈判说换人.你让对面放人,对面让你放人. 二.为什么会形成死锁 看到这里,也许你会有这样的疑问,事务和谈判不一样,为什么事务不能使用完锁之后立马释放呢?居然还要操作完了之后一直持有锁?这就涉及到 MySQL 的并发控制了. MySQL的并发控制有两种方式,一个是 MVCC,一个是两阶段锁协议.那么为什么要并发控制呢?是因为多个用户同时操作 M

  • MySQL 死锁套路：唯一索引 S 锁与 X 锁的爱恨情仇

    在初学者从源码理解MySQL死锁问题中介绍了使用调试 MySQL  源码的方式来查看死锁的过程,这篇文章来讲讲一个常见的案例. 毫不夸张的说,有一半以上的死锁问题由唯一索引贡献,后面介绍的很多死锁的问题都跟唯一索引有关.这次我们讲一段唯一索引 S 锁与 X 锁的爱恨情仇 我们来看一个简化过的例子 # 构造数据 CREATE TABLE `t1` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(10), `level` int(11),

  • 初学者从源码理解MySQL死锁问题

    初学者从源码理解MySQL死锁问题

    通过好多个深夜艰难的单步调试,终于找到了一个理想的断点,可以看到大部分获取锁的过程 代码在lock0lock.c的static enum db_err lock_rec_lock() 函数中,这个函数会显示,获取锁的过程,以及获取锁成功与否. 场景1:通过主键进行删除 表结构 CREATE TABLE `t1` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(10) NOT NULL DEFAULT '', PRIMARY KEY (

  • 通过底层源码理解YOLOv5的Backbone

    通过底层源码理解YOLOv5的Backbone

    目录 YOLOv5的Backbone设计 1 Backbone概览及参数 1.1 Param 1.2 backbone 1.3 Exp 2 Backbone组成 3.1 CBS 3.2 CSP/C3 3.2.1 CSP结构 3.2.2 Bottleneck 3.3 SSPF YOLOv5s的Backbone总览 总结 YOLOv5的Backbone设计 在上一篇文章<YOLOV5的anchor设定>中我们讨论了anchor的产生原理和检测过程,对YOLOv5的网络结构有了大致的了解.接下来,我

  • CentOS 7中源码安装MySQL 5.7.6+详细教程

    配置说明 Linux版本:Centos7 MySQL版本:MySQL5.7.16 该文档适用于MySQL版本>=5.7.6 一.卸载CentOS7默认携带的mariadb包 # 检查mariadb安装包 [root@wing ~]# rpm -qa | grep -i mysql [root@wing ~]# rpm -qa | grep -i mariadb mariadb-libs-5.5.50-1.el7_2.x86_64 # 卸载mariadb安装包 [root@wing ~]# rpm

  • 基于Spring Boot的Environment源码理解实现分散配置详解

    基于Spring Boot的Environment源码理解实现分散配置详解

    前提 org.springframework.core.env.Environment是当前应用运行环境的公开接口,主要包括应用程序运行环境的两个关键方面:配置文件(profiles)和属性.Environment继承自接口PropertyResolver,而PropertyResolver提供了属性访问的相关方法.这篇文章从源码的角度分析Environment的存储容器和加载流程,然后基于源码的理解给出一个生产级别的扩展. 本文较长,请用一个舒服的姿势阅读. Environment类体系 Pr

  • 通过唯一索引S锁与X锁来了解MySQL死锁套路

    通过唯一索引S锁与X锁来了解MySQL死锁套路

    在初学者从源码理解MySQL死锁问题中介绍了使用调试 MySQL  源码的方式来查看死锁的过程,这篇文章来讲讲一个常见的案例. 这次我们讲一段唯一索引 S 锁与 X 锁的爱恨情仇 我们来看一个简化过的例子 # 构造数据 CREATE TABLE `t1` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(10), `level` int(11), PRIMARY KEY (`id`), UNIQUE KEY `uk_name` (`na

  • Linux CentOS6.6系统中安装mysql源码包的方法

    这里以CentOS6.6系统中安装MySQL的源码包,进行讲解. 1. mysql源码包的下载 mysql安装包的官方下载地址为:http://dev.mysql.com/downloads/mysql/5.6.html#downloads 打开该下载地址后,在 "Select Version:"处,选择要下载的mysql的版本,我选择的是5.6.34:在"Select Platform:"处,选择适用的操作系统类型,由于是下载源码包,故这里我们要选择Source

  • RC级别下MySQL死锁问题的解决

    RC级别下MySQL死锁问题的解决

    目录 背景 死锁分析 死锁解决 背景 在工作中碰到一次死锁问题,业务背景是在mq接收商品主数据时会更新商品其他数据,由于商品主数据和商品其他信息是一对多的关系,所以采用先删后增的方式,结果异常监管平台报出来死锁警告. 这是商品其他信息表,数据库隔离级别是RC,表有一个唯一联合索引,这个唯一索引就是引起死锁的关键. 死锁分析 下面是线上的一个死锁日志 2021-03-15 16:40:49 0x7f17e97ff700 *** (1) TRANSACTION: TRANSACTION 212057

  • jQuery-1.9.1源码分析系列（十）事件系统之事件体系结构

    又是一个重磅功能点. 在分析源码之前分析一下体系结构,有助于源码理解.实际上在jQuery出现之前,Dean Edwards的跨浏览器AddEvent()设计做的已经比较优秀了:而且jQuery事件系统的设计思想也是基于该思想的,所以我们先分析一下Dean Edwards前辈的事件绑定. a. jQuery事件原型--Dean Edwards的跨浏览器AddEvent()设计 源码解读 //事件添加方法 function addEvent(element, type, handler) { //

  • 彻底了解java中ReentrantLock和AQS的源码

    彻底了解java中ReentrantLock和AQS的源码

    一.前言 首先在聊ReentrantLock之前,我们需要知道整个JUC的并发同步的基石,currrent里面所有的共享变量都是由volatile修饰的,我们知道volatile的语义有2大特点,可见性以及防止重排序(内存屏障,volatie写与volatile读) 1.当第二个操作为volatile写操做时,不管第一个操作是什么(普通读写或者volatile读写),都不能进行重排序.这个规则确保volatile写之前的所有操作都不会被重排序到volatile之后; 2.当第一个操作为volat

随机推荐