case1(表锁的读-写-读阻塞)

上篇文档中提到过

WRITE locks normally have higher priority than READ locks to ensure that updates are processed as soon as possible. This means that if one session obtains a READ lock and then another session requests a WRITE lock, subsequent READ lock requests wait until the session that requested the WRITE lock has obtained the lock and released it.

对于读-写-读的情况,由于锁的优先级较高,如果申请写的session迟迟获取不到锁,会阻塞后续其他session申请读锁;

先看正常情况,表锁的读锁是可以加多个的,如下,通过两个查询命令也可以看到确实同时加上了,没有阻塞;

//console1
lock tables simple read;
//console2
lock tables simple read;

select * from performance_schema.metadata_locks;

show OPEN TABLES where In_use > 0;

但是在两次读中间插入一次写锁的获取,后面的读锁也会同时被阻塞

//console1
lock tables simple read;
//console2
lock tables simple write;//被console1阻塞
//console3
lock tables simple read;//被console2阻塞

实验证明确实如文档所说,原理还在研究中...

case2(元数据锁读-写-读)

mysql45讲中提到的一个问题,具体分析见mysql MDL读写锁阻塞,以及online ddl造成的“插队”现象_花落的速度的博客-CSDN博客

case3(next-key lock 和 primary key)

在分析之前,先贴一下45讲的总结,该总结版本是 5.x 系列 <=5.7.24,8.0 系列 <=8.0.13,而我测试的版本是8.0.33

原则 1:加锁的基本单位是 next-key lock。希望你还记得,next-key lock 是前开后闭区间。

原则 2:查找过程中访问到的对象才会加锁。

优化 1:索引上的等值查询,给唯一索引加锁的时候,next-key lock 退化为行锁。

优化 2:索引上的等值查询,向右遍历时且最后一个值不满足等值条件的时候,next-key lock 退化为间隙锁。

一个 bug:唯一索引上的范围查询会访问到不满足条件的第一个值为止。

目前的数据

CREATE TABLE `simple` (
`id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键',
`name` varchar(256) COLLATE utf8mb4_bin DEFAULT NULL COMMENT '字符',
`seq` bigint NOT NULL COMMENT '消息序号',
`type` tinyint NOT NULL COMMENT '类型,tinyint值',
`version` int NOT NULL DEFAULT '1' COMMENT '版本值',
`msg` text COLLATE utf8mb4_bin COMMENT '消息',
`create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
`update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '修改时间',
`yn` tinyint NOT NULL DEFAULT '1' COMMENT '是否有效',
`uni` int NOT NULL COMMENT '唯一索引',
PRIMARY KEY (`id`),
UNIQUE KEY `unidx` (`uni`),
KEY `seqidx` (`seq`)
) ENGINE=InnoDB AUTO_INCREMENT=301 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin COMMENT='简单测试表'

单一查询且查询结果存在(id=15)

存在一个意向表锁和行级读锁,理论上锁住的应该是(5, 15]这部分,但是由于是主键索引(唯一),所以只会锁15这一行,没有必要锁前面的间隙;这是优化1的体现;

LOCK_MODE为S,REC_NOT_GAP,我理解应该是说只有行锁,行锁类型是读锁;

start transaction ;
select * from simple where id = 15 lock in share mode ;
select * from performance_schema.data_locks;

单一查询且结果不存在(id=16)

将查询条件从15换成了16,理论上锁住的是(15,20]这部分,但是实验表明,20这行不会加行锁,所以最终表现为(15,20);这是优化2的体现;

LOCK_MODE为S,GAP,我理解应该是说只有间隙锁,即(15,20);

start transaction ;
select * from simple where id = 16 lock in share mode ;
select * from performance_schema.data_locks;
//console2
start transaction;
insert into simple (id,name,type,seq) value (16,5,5,5);//会被阻塞
select * from simple where id=20 for update ;//发现这行可以执行成功

既然可以成功,那就证明id = 16 的查询并没有锁20这一行,不然不可能加的上写锁

console2执行id=20后的结果

那这里如果我把id为20的更新成id为16会怎样?

update simple set id=16 where id=20;

经实验16-19都不能更新,20以后可以更,比如update simple set id=21 where id=20就可以成功;所以间隙锁是不是也能防止更新;又或者说,其实是因为更新的本质是删除再插入,再插入的被阻塞了,这里感兴趣的可以研究一下;

id>5

按照理论,应该锁住的后5往后的所有范围,即(5,15],(15,20],(20,23],(23,super..];

所以我推测LOCK_MODE只有一个S,代表加的是临键锁,类型是读锁,没有特殊表明缺少行锁或者间隙锁就是完整的临建锁,并且我在console2尝试插入id为6或者36的,都会被阻塞

//console1
start transaction ;
select * from simple where id>5 lock in share mode ;
select * from performance_schema.data_locks;
//console2
都会被阻塞
insert into simple (id,name,type,seq) value (6,5,5,5);
insert into simple (id,name,type,seq) value (36,5,5,5);

id>=5

和上面的唯一区别就是多了个等于5,那么5上是临键锁还是行锁呢?我觉得是行锁,因为优化1,而且这样和我们的认知也是比较符合的;

实际看到确实是这样;

start transaction ;
select * from simple where id>=5 lock in share mode ;
select * from performance_schema.data_locks;

id>5 and id<20

首先5<x<20,那么正常情况应该是(5,15]和(15,20],然后20因为不等于会被优化(触发了优化2),所以是(5,20)

start transaction ;
select * from simple where id>5 and id<20 lock in share mode ;
select * from performance_schema.data_locks;

id>5 and id<=20

假如是5<x<=20,那就会是(5,20];

但是注意我们前面提到过一个bug,可是我们看到目前就是锁到20为止,并不是(5,23),翻看评论区说在MySQL 8.0.18 已经修复,而我的版本是8.0.33,这里难道是修复了吗?先存疑,因为这里只能证明主键索引修复了,后面唯一索引那里还是乱的一批

id>30

应该会直接锁(23,super...)

case4(next-key lock和 unique key)

和case3唯一的区别就是将主键索引换成了唯一索引,猜测应该是一模一样的,因为文档里的特殊规则说的也都是唯一索引,而没有限制到主键上;

单一查询且查询结果存在(uni=15)

start transaction ;
select * from simple where uni = 15 lock in share mode ;
select * from performance_schema.data_locks;

理想很美好,现实很骨感;这是什么??突然想到行锁和间隙锁都是锁在索引上的锁,由于我查询结果是所有字段,所以会发生回表查询;当命中到唯一索引的时候会锁一次,然后根据主键id再锁一次;

但是现在我的uni和id字段值是一样的,所以为了区分,我将uni这一列都加了100,然后执行下面的句子

start transaction ;
select * from simple where uni = 115 lock in share mode ;
select * from performance_schema.data_locks;

可以看到primary那行应该是因为回表操作,而unidx那行应该则是对应唯一索引的查询,实际锁的范围逻辑和主键索引是一致的,只不过锁的内容我不理解,lock_data为115,15,为什么?

select id from simple where uni = 115 lock in share mode ;

而且如果我们查询的不是select *,而是select id ,锁的信息就不包含primary那行了;

单一查询且结果不存在(uni=116)

start transaction ;
select * from simple where uni = 116 lock in share mode ;
select * from performance_schema.data_locks;

由于查询不到,所以也不会回表查询,就不存在primary那行了

uni>105

start transaction ;
select id from simple where simple.uni>105 lock in share mode ;
select * from performance_schema.data_locks;

我理解到每个索引节点的时候,都会执行一次select * from simple where id = x;所以会多出几行只有行锁primary的记录;

uni>=105只是会在unidx和primary上各多一个锁,但范围和唯一索引逻辑依然一致,就不贴了

uni>105 and uni<120

//console1
commit ;
start transaction ;
select * from simple where uni>105 and uni<120 lock in share mode ;
select * from performance_schema.data_locks;
//console2
select * from simple where uni=120 for update ;//被阻塞

这里和上面不一样的是,这里把120这行也锁上了,主键索引锁20是间隙锁,这里是临键锁;为什么这里会锁上呢?就很像是bug并没有修复,依然锁到了第一个不满足条件的,并且加了临键锁

uni>105 and uni<=120

start transaction ;
select * from simple where uni>105 and uni<=120 lock in share mode ;
select * from performance_schema.data_locks;

这里更离谱,这里为什么把123都给锁上了??感觉bug依然存在,多锁了一个区间

uni>130和上面的id>30结果一样,就不贴了


总结:对于唯一索引来说,因为存在主键,那么会产生回表操作,回表操作会给主键再加一把锁;而那个bug依旧存在,只有主键索引的修复了,非主键唯一索引依然存在这个bug;

case5(索引加在哪)

//console1
start transaction ;
select id from simple where uni=105 lock in share mode ;
select * from performance_schema.data_locks;
//console2
start transaction ;
update simple set name='new' where id=5;

现在我们已经清楚,执行完console1之后,会给unidx加一个行锁,因为没有回表,所以主键上没有锁;那么console2能否成功执行呢?

答案是
可以的;

我个人理解,是因为锁是加在索引上的,而索引是列维度的,不是行维度的;console2执行语句只会去判断id这个索引上,有没有5这个锁;

接下来我们反过来

//console1
start transaction ;
select * from simple where id=5 lock in share mode ;
select * from performance_schema.data_locks;
//console2
start transaction ;
update simple set name='new' where uni=105;

你试着一起敲一下就会发现,咦,console2怎么阻塞了呢?按上面所说的,不是不应该吗?

实际上console1的执行锁的确实是id;

但是你console2的执行,会回表啊,会尝试给id加写锁,但是id已经加了读锁了,所以自然不行了;

所以,不要盲目的只看查询条件,要理解当前语句都会加什么锁,是否和已经加的锁冲突;

最后,我们再来看一个附加题,下面两个语句加的锁是否一样呢?

start transaction ;
select id from simple where uni=105 lock in share mode ;
select * from performance_schema.data_locks; start transaction ;
select id from simple where uni=105 for update ;
select * from performance_schema.data_locks;

在我没有尝试之前,我理解都没有回表,那么就应该一个是唯一索引加读锁,一个是唯一索引加写锁;

但是实际结果却是lock in share mode是对的,for update会认为你要更新语句,自动给主键加锁了

case6(next-key lock 和index)

吸取uni的教训,我给seq的值都加了200,现在这个表是这样的

seq=215

start transaction ;
select * from simple where seq=215 lock in share mode ;
select * from performance_schema.data_locks;

除了意向锁,其他三个我们一个个看;

seqidx(S)这行是普通索引执行时加的临键锁,由于不是唯一索引,所以不能优化(因为可能存在重复)

primary(S,REC_NOT_GAP)这是回表操作带来的

seqidx(S,GAP)这行是因为不是唯一索引,所以在查询到匹配的值之后不会立马停止(因为后面可能还存在相同的值),所以必须要到不符合条件的值为止,而所有查询过的都会加索引,所以存在一个间隙锁。

seq=216

start transaction ;
select * from simple where seq=216 lock in share mode ;
select * from performance_schema.data_locks;

我理解,应该是从205开始查,查到第一个不符合条件的值是215,加上中间没有回表,所以就这一个锁;理论应该是(215,220],但由于优化2,所以退化为间隙锁;

seq>215 and seq<220

start transaction ;
select * from simple where seq>215 and seq <220 lock in share mode ;
select * from performance_schema.data_locks;

从215开始匹配,第一个不符合条件的是220,所以只能是(215,220]

seq>215 and seq <=220

start transaction ;
select * from simple where seq>215 and seq <=220 lock in share mode ;
select * from performance_schema.data_locks;

这里和上面区别就是不符合条件的会到223为止,另外中间因为匹配成功会回一次表

seq>230和前面unidx>130和id>30都一样

case7(next-key和没有索引)

alter table simple drop index  seqidx;
start transaction ;
select * from simple where seq=215 lock in share mode ;
select * from performance_schema.data_locks;

前面提到过,查询条件匹配不到索引或者只是索引的一部分,这个时候为了保证数据的准确性,会给整个表“加锁”,其实给表里所有的记录都加锁(这里我不知道描述的对不对,因为表锁!=所有记录加锁,虽然效果相似,但并不是一个东西).

同时因为这个表存在意向读锁,通过lock tables simple write 加写的表锁会冲突;

参考文档:

06 | 全局锁和表锁 :给表加个字段怎么有这么多阻碍?-极客时间

mysql MDL读写锁阻塞,以及online ddl造成的“插队”现象_花落的速度的博客-CSDN博客

Mysql中的锁(case篇)的更多相关文章

  1. MySQL系列(五)---总结MySQL中的锁

    MySQL中的锁 目录 MySQL系列(一):基础知识大总结 MySQL系列(二):MySQL事务 MySQL系列(三):索引 MySQL系列(四):引擎 概述 MyISAM支持表锁,InnoDB支持 ...

  2. MySQL中InnoDB锁不住表的原因

    MySQL中InnoDB锁不住表是因为如下两个参数的设置: mysql> show variables like '%timeout%'; +-------------------------- ...

  3. MySQL中的锁、隔离等级和读场景

    一.导言 关于MySQL中的锁还有隔离等级这类话题,其概念性的解释早已泛滥.记住其概念,算不上什么.更重要的是思考:他们的区别和联系在哪儿,为什么会有这样的概念. 1)MySQL的锁(Lock)分为行 ...

  4. MySQL实战 | 06/07 简单说说MySQL中的锁

    原文链接:MySQL实战 | 06/07 简单说说MySQL中的锁 本文思维导图:https://mubu.com/doc/AOa-5t-IsG 锁是计算机协调多个进程或纯线程并发访问某一资源的机制. ...

  5. mysql中的锁表语句查看方法汇总

    mysql> show status like 'Table%'; +----------------------------+----------+ | Variable_name | Val ...

  6. 你了解MySQL中的锁吗?

    MySQL中的锁,分为全局锁.表级锁.行锁 全局锁 全局锁的意思就是,对整个数据库实例加锁,它的命令是FTWRL Flash tables with read lock 这个命令的语义是,使整个库处于 ...

  7. 谈谈MySQL中的锁

    谈谈MySQL中的锁 锁的定义 ​ 在生活中锁的例子就非常多了,所以应该很容易理解锁的含义.在计算机领域,可以这样来概述,锁是计算机协调多个进行进程并发访问某一资源的机制. ​ 在数据库中,锁也是一个 ...

  8. MySQL 中的锁有哪些类型,MySQL 中加锁的原则

    MySQL 中的锁理解 锁的类型 全局锁 缺点 适用范围 表级锁 表锁 元数据锁 意向锁 自增锁 行锁 Record Lock Gap Lock Next-Key Lock 插入意向锁 加锁的原则 1 ...

  9. 5、MySQL中的锁

    1.6. MySQL中的锁 InnoDB中锁非常多,总的来说,可以如下分类: 这些锁都是做什么的?具体含义是什么?我们现在来一一学习. 1.6.1.解决并发事务问题 我们已经知道事务并发执行时可能带来 ...

  10. mysql中的锁机制之概念篇

    锁的概念 ①.锁,在现实生活中是为我们想要隐藏于外界所使用的一种工具. ②.在计算机中,是协调多个进程或线程并发访问某一资源的一种机制. ③.在数据库当中,除了传统的计算资源(CPU.RAM.I/O等 ...

随机推荐

  1. NEMU PA 4 实验报告

    一.实验目的 在前面的PA123中,我们分别实现了基本的运算单元,实现了各种指令和程序的装载,实现了存储器的层次结构.而在PA4中,为了让NEMU可以处理异常情况以及和外设交互,我们要做的事情有以下: ...

  2. MySQL 幻象行

    当同一个查询在不同的时间产生不同的行集时,就会出现所谓的幻像问题.例如,如果执行了两次SELECT,但是第二次返回了第一次没有返回的行,那么该行就是一个"幻象"行. 假设在表chi ...

  3. Spring Boot 加载外部配置文件

    Spring Boot 允许你从外部加载配置,这样的话,就可以在不同的环境中使用相同的代码.支持的外部配置源包括:Java属性文件.YAML文件.环境变量.命令行参数. 用@Value注解可以将属性值 ...

  4. look命令

    look命令 look命令用于查询单词,仅需指定欲查询的字首字符串,它会显示所有开头字符串符合该条件的单词. 语法 look [-bdf] [-t char] string [file ...] 参数 ...

  5. win32 - Shell菜单项的创建

    #include <windows.h> #include <shobjidl_core.h> #include <windowsx.h> #include < ...

  6. Redis加Lua脚本实现分布式锁

    先讲一下为什么使用分布式锁: 在传统的单体应用中,我们可以使用Java并发处理相关的API(如ReentrantLock或synchronized)来实现对共享资源的互斥控制,确保在高并发情况下同一时 ...

  7. macOS Monterey 与以下电脑兼容下载操作流程解析

    有时在开发iOS应用时我们时常遇到各种情况,比如手机升级了Xcode不支持这时候需要安装xcode但是xcode需要依奈相应系统本人小编整理了这种情况无法解决问题. 首相打开苹果标志进入到下面界面 进 ...

  8. 【Azure Webjob + Redis】WebJob一直链接Azure Redis一直报错 Timeout Exception

    问题描述 运行在App Service上的Webjob连接Azure Redis出现Timeout Exception. 错误截图: 参考Azure Redis对于超时问题的排查建议, 在修改Min ...

  9. 【Azure 云服务】如果云服务证书过期会有什么影响,证书时间应该如何查看

    问题描述 如果云服务证书过期会有什么影响,证书时间应该如何查看 问题答案 在云服务中,有两种证书:服务证书 和 管理证书 什么是服务证书? 通过浏览器访问云服务中的服务(Web Role)时候所使用的 ...

  10. Advanced .Net Debugging 3:基本调试任务(上)

    一.简介 这是我的<Advanced .Net Debugging>这个系列的第三篇文章.这个系列的每篇文章写的周期都要很长,因为每篇文章都是原书的一章内容(太长的就会分开写).再者说,原 ...