【MySQL】说透锁机制（二）行锁 加锁规则 之 范围查询（你知道会锁表吗？）_mysql 行锁范围

阿里云国内75折 回扣 微信号：monov8
阿里云国际，腾讯云国际，低至75折。AWS 93折 免费开户实名账号 代冲值 优惠多多 微信号：monov8 飞机：@monov6

本文会按照 聚集集索->唯一索引->普通索引 的顺序 地毯式分析 范围查询中 <、<=、>、>= 的行锁情况锁表分析在唯一索引 章节万字长文力求分析全面很硬核全网独一份记得收藏 当然如果落下什么欢迎大家评论指出

前文回顾

在上文我们介绍了 MySQL InnoDB行锁的

  • 2个模式S锁和X锁
  • 3种算法Record Lock、Gap Lock、Next-key Lock
  • 如何开启锁监视器 和 如何分辨3种锁

并对等值查询 是 3类索引 时结合案例 说明了 都加了哪些锁 以及 为什么加这些锁的分析

  • 聚集索引 和 唯一索引 Record Lock
  • 普通索引Next-key Lock + Record Lock + Gap Lock
  • 无匹配全是Gap Lock

详细案例分析和总结请见上文行锁 加锁规则 之 等值查询

文章目录

先说结论

本文我们主要分析 范围查询主要包括 <、<=、>、>= 等.

文章很长我先给出结论
聚集索引
对于 聚集索引下的范围查询 <、<=、>、>=无论是否组合都会遵循如下规则

  • 所有匹配的索引记录只有>= 的等值(=)匹配 上Record Lock其它 上Next-key Lock;
  • 对于 < 和 <=向右扫描聚集索引直到找到 不匹配 的 索引记录 上Next-key Lock.
  • 对于 > 和 >=会对supremum (上界限伪值) 上Next-key Lock锁的是 聚集索引 最大值 后面的 间隙;

详细说透结论

  • 从上锁的对象来说
    • 对所有匹配的聚集索引记录上锁是应该的;
    • 由于是范围和等值匹配不同当索引从左向右扫描到匹配记录时不能立即停止因为可能还有其它匹配记录所以 直到扫描到 [不匹配的索引记录] 才能停止然后上锁也是合理的。至于<=的等值(=)的问题文章中会有详细说明这里实际是有争议的;
    • 对于 >和>=因为会包括 索引最大值 后面的间隙所以 对上界面伪值supremum 上锁也是应该的。
  • 从上锁的类型来说
    • 咱们上文曾说过行锁默认的是Next-key Lock可能会降级为Gap Lock或Record Lock。因为这里是范围查询匹配的值会有多个所以不降级也无不妥;
    • 这里仅对 聚集索引的 >= 的等值(=)做了降级优化因为对每个索引值上Next-key Lock或Gap Lock时负责的是 前面的间隙所以<=的等值(=)不可以做降级降级就可能出现幻读问题了。

唯一索引 和 普通索引
对于 唯一索引 和 普通索引 下的范围查询 <、<=、>、>=无论是否组合都会遵循如下规则

  • 如果走了索引
    • 在该索引上所有匹配的 索引记录 上Next-key Lock对应的聚集索引 上Record Lock;
    • 对于 < 和 <=会在该索引上向右扫描 直到找到 [不匹配的索引记录] 上Next-key Lock对应的聚集索引 上Record Lock;
    • 对于 > 和 >=会对supremum (上界限伪值) 上Next-key Lock锁的是 该索引 最大值 后面的 间隙;
  • 如果没走索引那么就会把所有 聚集索引记录 和 间隙 都锁上就是所谓的锁表或叫行锁升表锁.
  • 从上锁的对象来说
    • 对所有匹配的索引记录上锁是应该的;
    • 对所有匹配的索引记录 对应的 聚集索引记录 上锁这里在等值匹配时也是如此;
    • 由于是范围和等值匹配不同当索引从左向右扫描到匹配记录时不能立即停止因为可能还有其它匹配记录所以 直到扫描到 [不匹配的索引记录] 才能停止然后上锁也是合理的;
    • 对于 >和>=因为会包括 索引最大值 后面的间隙所以 对上界面伪值supremum 上锁也是应该的。
  • 从上锁的类型来说
    • 这里仅对 对应的聚集索引记录上Record Lock也是合理的要不然锁的范围太大了;
    • 这里 并没有像 聚集索引的 >= 的等值(=)做降级优化其实唯一索引理论上是可以的。

OK给完结论接着就让我们来验证吧 先看一看我们表中的数据

+----+----------+-----+--------+--------+
| id | name     | abc | abc_uk | remark |
+----+--------- +-----+--------+--------+
| 10 | 巴西     |  10 |     10 | NULL   |
| 15 | 克罗地亚 |  10 |     15 | NULL   |
| 20 | 阿根廷   |  20 |     20 | NULL   |
| 30 | 葡萄牙   |  30 |     30 | NULL   |
| 40 | 法国     |  40 |     40 | NULL   |
+----+----------+-----+--------+--------+
5 rows in set (0.02 sec)

id 自增主键
abc 普通索引
abc_uk 唯一索引

新打开一个mysql客户端我们叫Session1并开启锁监视器

SET GLOBAL innodb_status_output=ON;
SET GLOBAL innodb_status_output_locks=ON;

说明本文基于MySQL5.7、InnoDB引擎、可重复读事务隔离级别

聚集索引

小于

新打开一个mysql客户端我们叫Session2 执行SQL如下按id < 20

begin;
update ct set remark = '巴西 爆冷 克罗地亚' 
where id < 20;

注意不要commit或rollback以便于我们分析行锁

这里匹配id < 20 的 记录有两条
![在这里插入图片描述](https://img-blog.csdnimg.cn/bacea057d038408bbce106054cd8c5a2.png
然后我们在Session1里查看锁的详细信息

show engine innodb status\G;

我们还是主要看TRANSACTIONS这段如下图
在这里插入图片描述

这里上了 3 把锁因为是 按id所以全锁在 聚集索引 上

  1. id = 20 向右扫描到的第一个不匹配记录: Next-key Lock
  2. id = 10匹配记录 : Next-key Lock
  3. id = 15匹配记录 : Next-key Lock

因为 20 刚好是临界值。如果我们换成 id < 19呢

update ct set remark = '巴西 爆冷 克罗地亚' 
where id < 19;

再来看一下

show engine innodb status\G;

在这里插入图片描述
结果依旧你可以对比一下上一个事务ID是793365
还有一个临界值 id < 16 

update ct set remark = '巴西 爆冷 克罗地亚' 
where id < 16;

结果也是一样的就不展示了。

所以对于 < 在 聚集索引 上来说我们得出的结果是

  • 聚集索引上, 所有匹配的 索引记录 上Next-key Lock;
  • 向右扫描聚集索引, 直到找到 [不匹配的索引记录] 上Next-key Lock.

小于等于

这里依旧演示两个临界值 id <=19 和 id <= 20

begin;
update ct set remark = '巴西 爆冷 克罗地亚' 
where id <= 19;

这里匹配记录有 id =10 和 id =15 两条记录。

我们来看一下

show engine innodb status\G;

在这里插入图片描述
不出所料因为 和 id < 19 的匹配记录是相同的所以锁的结果也是相同的
我们再来看一下临界值 id <=20

begin;
update ct set remark = '巴西 爆冷 克罗地亚' 
where id <= 20;

我们看一下修改的记录共3条
在这里插入图片描述
这里对于 3条匹配的 索引记录上Next-key Lock已尽在我们掌握中但id = 30 是否会上锁
如果上的话是上 Next-key Lock 还是Gap Lock

我们来看一下

show engine innodb status\G;

在这里插入图片描述
可以看出上了4把锁3条已匹配记录上了Next-key Lock向右查找到不匹配的30也上了Next-key Lock。
其实这里不知道你会不会有这个 疑问 对于聚集索引来说值是唯一的既然已经匹配到最大的20了中止是不是更好为什么还要继续向右
如果是<=21因为21不存在所以需要继续向右扫描直到查找到30上一把Next-key Lock倒可以理解

其实疑问早就存在前腾讯云数据库负责人林晓斌还曾找社区专家讨论过官方bug系统上也有提到但是并未被verified所以这个也被他称之为bug

对于 <= 在 聚集索引 上来说我们得出的结果是实际和 < 一样

  • 聚集索引上, 所有匹配的 索引记录 上Next-key Lock;
  • 向右扫描聚集索引, 直到找到 [不匹配的索引记录] 上Next-key Lock.

大于

我们再来验证 id > 10

update ct set remark = '巴西 爆冷 克罗地亚' 
where id > 10;

这时匹配的记录有 15、20、30、40所以会上4把Next-key Lock对于40后的间隙是对supremum上了Next-key Lock这个很好理解没什么特殊的请看下图
在这里插入图片描述
对于 > 在 聚集索引 上来说我们得出的结果是实际和 <, <= 类似

  • 聚集索引上, 所有匹配的 索引记录 上Next-key Lock;
  • 对supremum (上界限伪值) 上Next-key Lock锁的是最大值后的间隙;

大于等于

我们最后来看一下 id >= 10这个有点特殊

update ct set remark = '巴西 爆冷 克罗地亚' 
where id >= 10;

在这里插入图片描述

对于 >= 我们得到的结果是

  • 聚集索引上, 所有 > 的 索引记录 上Next-key Lock;
  • 聚集索引上, 等值(=) 会上Record Lock当然如果没有 等值(=) 就不会上锁我已验证 id>=11比较好理解不做赘述
  • 对supremum (上界限伪值) 上Next-key Lock锁的是最大值后的间隙;

范围组合

范围组合一 > <

update ct set remark = '匹配15' 
where id > 10 and id < 20;

在这里插入图片描述
由图可知对2条索引记录上锁匹配15next-key20
结果

  • 聚集索引上, 所有匹配的 索引记录 上Next-key Lock;
  • 向右扫描聚集索引, 直到找到 [不匹配的索引记录] 上Next-key Lock.

范围组合二 > <=

update ct set remark = '匹配15 + 20' 
where id > 10 and id <= 20;

在这里插入图片描述
由图可知对3条索引记录上锁匹配15、20next-key30

结果 和> <相同不做赘述

范围组合三 >= <

update ct set remark = '匹配10 + 15' 
where id >= 10 and id < 20;

在这里插入图片描述
由图可知对3条索引记录上锁匹配10、15next-key20
结果

  • 只有 >= 的等值(=)匹配索引记录上Record Lock其它匹配的 索引记录 上Next-key Lock;
  • 向右扫描 直到找到 不匹配 的 索引记录 上Next-key Lock.

范围组合四 >= <=

update ct set remark = '匹配10 + 15 + 20' 
where id >= 10 and id <= 20;

在这里插入图片描述
由图可知对4条索引记录上锁匹配10、15、20next-key30
结果 和>= <相同不做赘述

聚集索引 小结

对于 聚集索引下的范围查询 <、<=、>、>=无论是否组合都会遵循如下规则

  • 所有匹配的索引记录只有>= 的等值(=)匹配 上Record Lock其它 上Next-key Lock;
  • 对于 < 和 <=向右扫描聚集索引直到找到 不匹配 的 索引记录 上Next-key Lock.
  • 对于 > 和 >=会对supremum (上界限伪值) 上Next-key Lock锁的是 聚集索引 最大值 后面的 间隙;

唯一索引

小于

我们在Session2 执行SQL如下按abc_uk < 20

update ct set remark = '巴西 爆冷 克罗地亚' 
where abc_uk < 20;

在这里插入图片描述
这里共匹配2条记录abc_uk = 10 和 abc_uk = 15。

共上了 6 把锁3把锁在唯一索引上

  1. abc_uk = 20 向右扫描到的第一个不匹配记录: Next-key Lock
  2. abc_uk = 10匹配记录 : Next-key Lock
  3. abc_uk = 15匹配记录 : Next-key Lock

3把锁在聚集索引上

  1. id = 20 向右扫描到的第一个不匹配记录: Record Lock
  2. id = 10匹配记录 : Record Lock
  3. id = 15匹配记录 : Record Lock

到这我猜你肯定认为 和 聚集索引 一样有结果了请看好了好戏即将上演~
我改下sqlsql语句本身没变只是 20换成30

update ct set remark = '巴西 爆冷 克罗地亚' 
where abc_uk < 30;

这里共匹配3条记录分别是abc_uk = 10 、15、20。
我们看一下锁监视器
在这里插入图片描述
这里对聚集索引上了6把锁
表里所有的5条聚集索引记录都上了Next-key Lock还把supremum上了Next-key Lock。

你是不是会怀疑我搞错了

那咱们走着瞧~咱们先看一下explain的结果
在这里插入图片描述
possible_keys uk_abc_uk意思说可能走的索引是uk_abc_uk
keyPRIMARY意思说实际走的索引是聚集索引
typeindex意思说扫描了整个索引树

所以这条SQL并没有使用唯一索引而使用的是全表扫描。
这里其实是索引相关的知识也就是索引失效了实际是通过索引成本计算得出全表扫描的cost(3.9) 小于 走唯一索引再回表的cost(4.61)
在这里插入图片描述
全表扫描的成本计算上图

  • I/0成本1*1.0+1.1 = 2.1
  • CPU成本4*0.2+1.0 = 1.8
  • 总成本I/0成本(2.1)+CPU成本(1.8) = 3.9

在这里插入图片描述
使用唯一索引的成本计算上图

  • I/0成本1 - 范围区间的数量: 1 * 1.0 = 1.0
  • I/0成本2 - 回表成本3 * 1.0 = 3.0
  • CPU成本3 * 0.2 + 0.01 = 0.61
  • 总成本I/0成本(4.0)+CPU成本(0.61) = 4.61

说白了就是表里一共才5条记录这个范围就匹配了3条记录我用唯一索引先查id再用id回表去修改还不如直接遍历全表来的快
实际项目里表里的数据一般不会这么少所以这个示例的修改占比(60%)还是很高的所以才造成了全表扫描(全表成本低于使用索引)。

对于索引要细说的话内容很多远没有这么简单这里只是简单说明不懂不要紧先作为了解后面再安排细聊索引的成本计算

安排结果对于 < 在 唯一索引 上来说我们得出的结果是

  • 如果走了唯一索引
    • 在该索引上所有匹配的索引记录 上Next-key Lock对应的聚集索引 上Record Lock;
    • 向右扫描该索引直到找到 [不匹配的索引记录] 上Next-key Lock对应的聚集索引 上Record Lock;
  • 如果没走唯一索引那么就会把所有 聚集索引记录 和 间隙 都锁上就是所谓的锁表或叫行锁升表锁.

小于等于

update ct set remark = '巴西 爆冷 克罗地亚' 
where abc_uk <= 19;

在这里插入图片描述
不出所料因为 和 abc_uk < 20 的匹配记录是相同的所以锁的结果也是相同的

我们再来看一下临界值 abc_uk <=20

begin;
update ct set remark = '巴西 爆冷 克罗地亚' 
where abc_uk <= 20;

这里依然是会影响到3条记录 abc_uk = 10、15、20所以你懂的又锁表了 具体就不截图了。

所以我们改成范围小一点的临界值 abc_uk <=15

begin;
update ct set remark = '巴西 爆冷 克罗地亚' 
where abc_uk <= 15;

这里只会影响到2条记录 abc_uk = 10、15

我们来看一下

show engine innodb status\G;

在这里插入图片描述
这里共匹配2条记录abc_uk = 10 和 abc_uk = 15。

共上了 6 把锁3把锁在唯一索引上

  1. abc_uk = 20 向右扫描到的第一个不匹配记录: Next-key Lock
  2. abc_uk = 10匹配记录 : Next-key Lock
  3. abc_uk = 15匹配记录 : Next-key Lock

3把锁在聚集索引上

  1. id = 20 向右扫描到的第一个不匹配记录: Record Lock
  2. id = 10匹配记录 : Record Lock
  3. id = 15匹配记录 : Record Lock

综上对于 <= 在 聚集索引 上来说我们得出的结果 实际和 < 一样不做赘述

大于

我们先来验证 abc_uk > 10

update ct set remark = '阿根廷 3:0 克罗地亚' 
where abc_uk > 10;

这里共匹配4条记录abc_uk = 15、20、30、40所以你懂的又锁表了 具体就不截图了。

所以我们改成范围小一点的 abc_uk > 20

update ct set remark = '阿根廷 3:0 克罗地亚' 
where abc_uk > 20;

这里只会影响到2条记录 abc_uk = 30、40

我们来看一下

show engine innodb status\G;

在这里插入图片描述
这里共匹配2条记录abc_uk = 30 和 abc_uk = 40。

共上了 5把锁3把锁在唯一索引上

  1. abc_uk = supremum 上界限伪值锁的是最大值后的间隙: Next-key Lock
  2. abc_uk = 30匹配记录 : Next-key Lock
  3. abc_uk = 40匹配记录 : Next-key Lock

2把锁在聚集索引上

  1. id = 30匹配记录 : Record Lock
  2. id = 40匹配记录 : Record Lock

对于 > 在 唯一索引 上来说我们得出的结果是实际和 <, <= 类似

  • 如果走了唯一索引
    • 在该索引上所有匹配的索引记录 上Next-key Lock对应的聚集索引 上Record Lock;
    • 在该索引上对supremum (上界限伪值) 上Next-key Lock锁的是最大值后的间隙;
  • 如果没走唯一索引那么就会把所有 聚集索引记录 和 间隙 都锁上就是所谓的锁表或叫行锁升表锁.

大于等于

因为 abc_uk >= 10匹配了所有记录所以你懂的又锁表了 具体就不截图了。

我们直接来看不锁表的 abc_uk >= 30

update ct set remark = '阿根廷 3:0 克罗地亚' 
where abc_uk >= 30;

在这里插入图片描述
从上图可知abc_uk >= 30 和 abc_uk > 20 上的锁是一样的并不像 id >= 时那样将匹配值优化为Record Lock。

所以对于 >= 我们得到的结果 实际和 > 一样不做赘述

范围组合

说明索引失效 会 锁表 的规则是通用的所以这里就 统一 只演示 不锁表 的情况。

范围组合一 > <

update ct set remark = '格子军团' 
where abc_uk > 10 and abc_uk < 20;

在这里插入图片描述
不出所料由图可知对 2条唯一索引 和对应的 2条聚集索引 上锁匹配15next-key20

结果和单个规则相同

  • 如果走了唯一索引
    • 在该索引上所有匹配的索引记录 上Next-key Lock对应的聚集索引 上Record Lock;
    • 向右扫描该索引 直到找到 [不匹配的索引记录] 上Next-key Lock对应的聚集索引 上Record Lock.
  • 如果没走唯一索引那么就会把所有 聚集索引记录 和 间隙 都锁上就是所谓的锁表或叫行锁升表锁.

范围组合二 > <=

update ct set remark = '格子军团' 
where abc_uk > 10 and abc_uk <= 20;

》TODO
不出所料由图可知对 3条唯一索引 和对应的 3条聚集索引 上锁匹配15、20next-key30

结果和单个规则相同

  • 如果走了唯一索引
    • 在该索引上所有匹配的索引记录 上Next-key Lock对应的聚集索引 上Record Lock;
    • 向右扫描该索引 直到找到 [不匹配的索引记录] 上Next-key Lock对应的聚集索引 上Record Lock.
  • 如果没走唯一索引那么就会把所有 聚集索引记录 和 间隙 都锁上就是所谓的锁表或叫行锁升表锁.

范围组合三 >= <

update ct set remark = '梅西加油' 
where abc_uk >= 10 and abc_uk < 20;

在这里插入图片描述

不出所料由图可知对 3条唯一索引 和对应的 3条聚集索引 上锁匹配10、15next-key20
结果和单个规则相同

  • 如果走了唯一索引
    • 在该索引上所有匹配的索引记录 上Next-key Lock对应的聚集索引 上Record Lock;
    • 向右扫描该索引 直到找到 [不匹配的索引记录] 上Next-key Lock对应的聚集索引 上Record Lock.
  • 如果没走唯一索引那么就会把所有 聚集索引记录 和 间隙 都锁上就是所谓的锁表或叫行锁升表锁.

范围组合四 >= <=

update ct set remark = '梅西加油' 
where abc_uk >= 10 and abc_uk <= 15;

在这里插入图片描述
不出所料由图可知对 3条唯一索引 和对应的 3条聚集索引 上锁匹配10、15next-key20
结果和单个规则相同

  • 如果走了唯一索引
    • 在该索引上所有匹配的索引记录 上Next-key Lock对应的聚集索引 上Record Lock;
    • 向右扫描该索引 直到找到 [不匹配的索引记录] 上Next-key Lock对应的聚集索引 上Record Lock.
  • 如果没走唯一索引那么就会把所有 聚集索引记录 和 间隙 都锁上就是所谓的锁表或叫行锁升表锁.

唯一索引 小结

对于 唯一索引下的范围查询 <、<=、>、>=无论是否组合都会遵循如下规则

  • 如果走了唯一索引
    • 在该索引上所有匹配的 索引记录 上Next-key Lock对应的聚集索引 上Record Lock;
    • 对于 < 和 <=会在该索引上向右扫描 直到找到 [不匹配的索引记录] 上Next-key Lock对应的聚集索引 上Record Lock;
    • 对于 > 和 >=会对supremum (上界限伪值) 上Next-key Lock锁的是 该索引 最大值 后面的 间隙;
  • 如果没走唯一索引那么就会把所有 聚集索引记录 和 间隙 都锁上就是所谓的锁表或叫行锁升表锁.

普通索引

说明索引失效 会 锁表 的规则是通用的所以这里就 统一 只演示 不锁表 的情况。

小于

我们在Session2 执行SQL如下按abc < 20

update ct set remark = '梅西加油' 
where abc < 20;

在这里插入图片描述

这里共匹配2条abc=10的记录。

所以共上了 6 把锁3把锁在普通索引上

  1. abc = 20 向右扫描到的第一个不匹配记录: Next-key Lock
  2. abc = 10id = 10匹配记录 : Next-key Lock
  3. abc = 10id = 15匹配记录 : Next-key Lock

3把锁在聚集索引上

  1. id = 20 向右扫描到的第一个不匹配记录: Record Lock
  2. id = 10匹配记录 : Record Lock
  3. id = 15匹配记录 : Record Lock

可以看出和唯一索引上锁规则没什么两样!

锁表只需要把范围扩大就可以复现比如

update ct set remark = '梅西加油' 
where abc < 30;

所以对于 < 在 普通索引 上来说我们得出的结果是和唯一索引的 < 相同

  • 如果走了普通索引
    • 在该索引上所有匹配的 索引记录 上Next-key Lock对应的聚集索引 上Record Lock;
    • 向右扫描该索引直到找到 [不匹配的索引记录] 上Next-key Lock对应的聚集索引 上Record Lock.
  • 如果没走普通索引那么就会把所有 聚集索引记录 和 间隙 都锁上就是所谓的锁表或叫行锁升表锁.

小于等于

update ct set remark = '梅西加油' 
where abc <= 19;

在这里插入图片描述
不出所料因为 和 abc < 20 的匹配记录是相同的所以锁的结果也是相同的

所以对于 <= 在 普通索引 上来说我们得出的结果实际和 < 一样不做赘述.

大于

update ct set remark = '梅西加油' 
where abc > 20;

在这里插入图片描述

这里共匹配2条记录abc = 30、40

共上了 5把锁3把锁在普通索引上

  1. abc = supremum 上界限伪值锁的是最大值后的间隙: Next-key Lock
  2. abc = 30匹配记录 : Next-key Lock
  3. abc = 40匹配记录 : Next-key Lock

2把锁在聚集索引上

  1. id = 30匹配记录 : Record Lock
  2. id = 40匹配记录 : Record Lock

对于 > 在 普通索引 上来说我们得出的结果是实际和唯一索引的相同

  • 如果走了普通索引
    • 在该索引上所有匹配的 索引记录 上Next-key Lock对应的聚集索引 上Record Lock;
    • 在该索引上对supremum (上界限伪值) 上Next-key Lock锁的是最大值后的间隙;
  • 如果没走唯一索引那么就会把所有 聚集索引记录 和 间隙 都锁上就是所谓的锁表或叫行锁升表锁.

大于等于

update ct set remark = '梅西加油' 
where abc >= 30;

在这里插入图片描述

从上图可知abc >= 30 和 abc > 20 的上锁是一样的和唯一索引规则相同并不像id>=时那样将匹配值优化为Record Lock。

所以对于 >= 在 普通索引 上来说我们得出的结果实际和 > 一样不做赘述.

范围组合

范围组合一 > <

update ct set remark = '格子军团' 
where abc > 10 and abc < 20;

在这里插入图片描述
不出所料由图可知无匹配记录所以只对next-keyabc=20以及对应的id = 20上了锁

结果和单个规则相同

  • 如果走了普通索引
    • 在该索引上所有匹配的 索引记录 上Next-key Lock对应的聚集索引 上Record Lock;
    • 在该索引上向右扫描 直到找到 [不匹配的索引记录] 上Next-key Lock对应的聚集索引 上Record Lock.
  • 如果没走唯一索引那么就会把所有 聚集索引记录 和 间隙 都锁上就是所谓的锁表或叫行锁升表锁.

因为其它范围组合实际都和单个规则相同所以不做赘述

普通索引 小结

对于 普通索引下的范围查询 <、<=、>、>=无论是否组合都会遵循如下规则

  • 如果走了普通索引
    • 在该索引上所有匹配的 索引记录 上Next-key Lock对应的聚集索引 上Record Lock;
    • 对于 < 和 <=会在该索引上向右扫描 直到找到 [不匹配的索引记录] 上Next-key Lock对应的聚集索引 上Record Lock;
    • 对于 > 和 >=会对supremum (上界限伪值) 上Next-key Lock锁的是 该索引 最大值 后面的 间隙;
  • 如果没走普通索引那么就会把所有 聚集索引记录 和 间隙 都锁上就是所谓的锁表或叫行锁升表锁.

总结

这里需要补充说明的是因为对于范围查询都会有个边界所以如果没有任何匹配就会只对边界加锁规则不变

结论开篇就给出了结论传送门.

最后

如果感觉不错请收藏本专栏后面还有更详细的锁机制陆续放出。
关注我 天罡gg 分享更多干货 https://blog.csdn.net/scm_2008
大家的「关注 + 点赞 + 收藏」就是我创作的最大动力谢谢大家的支持我们下文见

阿里云国内75折 回扣 微信号：monov8
阿里云国际，腾讯云国际，低至75折。AWS 93折 免费开户实名账号 代冲值 优惠多多 微信号：monov8 飞机：@monov6
标签: mysql
返回列表

上一篇：MySQL表的增删查改

下一篇：讲解Redis的主从复制

“【MySQL】说透锁机制（二）行锁 加锁规则 之 范围查询（你知道会锁表吗？）_mysql 行锁范围” 的相关文章

MySQL必知必会第五章-排序检索数据1年前 (2023-02-02)
CentOS7安装MySQL（完整版）_centos7安装mysql1年前 (2023-02-02)
【MySQL进阶教程】SQL优化1年前 (2023-02-02)
MySQL复合查询1年前 (2023-02-02)
MySQL基础——多表查询1年前 (2023-02-02)
Mysql8.0.11 远程用户访问权限设置1年前 (2023-02-02)
数据库实践丨使用MTK迁移Mysql源库后主键自增列导致数据无法插入问题1年前 (2023-02-02)
【MySQL】详解MySQL数据库事务1年前 (2023-02-02)
MySQL进阶——存储引擎1年前 (2023-02-02)
远程连接centos下的mysql1年前 (2023-02-02)

阿里云国际版