RR模式下NEXT-KEY LOCK范围到底有多大

我们知道MYSQL NEXT-KEY LOCK是用来防止幻读,在RR模式下就有了用武之地
实际就是当前行锁+前后的一个区间,但是这个区间到底有多大?
是简单的一个辅助索引列上的闭区间吗?
测试全部是在RR模式下RC模式不存在

建立测试表:
CREATE TABLE `test` (
  `a` int(11) NOT NULL DEFAULT '0',
  `b` int(11) DEFAULT NULL,
  PRIMARY KEY (`a`),
  KEY `b` (`b`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

插入几行数据

mysql> insert into test values(10,2);
Query OK, 1 row affected (0.01 sec)

mysql> insert into test values(15,2);
Query OK, 1 row affected (0.02 sec)

mysql> insert into test values(20,4);
Query OK, 1 row affected (0.01 sec)

mysql> insert into test values(25,6);
Query OK, 1 row affected (0.02 sec)

mysql> insert into test values(99,8);
Query OK, 1 row affected (0.00 sec)

mysql> commit;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from test;
+----+------+
| a  | b    |
+----+------+
| 10 |    2 |
| 15 |    2 |
| 20 |    4 |
| 25 |    6 |
| 99 |    8 |
+----+------+
5 rows in set (0.00 sec)

会话A:
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from test where b=4 for update;
+----+------+
| a  | b    |
+----+------+
| 20 |    4 |
+----+------+
1 row in set (0.00 sec)

会话B:
mysql> select * from test where b=2 for update;
+----+------+
| a  | b    |
+----+------+
| 10 |    2 |
| 15 |    2 |
+----+------+
2 rows in set (0.00 sec)

mysql> select * from test where b=6 for update;
+----+------+
| a  | b    |
+----+------+
| 25 |    6 |
+----+------+
1 row in set (0.00 sec)

都没有问题,那显然这些列都没加X锁,那是不是可以简单的理解锁定是
一个2-6的区间不包含2和6呢?
看下面的语句:
mysql> insert into test values(16,2);
^CCtrl-C -- sending "KILL QUERY 3" to server ...
Ctrl-C -- query aborted.
ERROR 1317 (70100): Query execution was interrupted
mysql> insert into test values(16,6);
^CCtrl-C -- sending "KILL QUERY 3" to server ...
Ctrl-C -- query aborted.
ERROR 1317 (70100): Query execution was interrupted
均锁定了

但是
mysql> insert into test values(14,2);
Query OK, 1 row affected (0.21 sec)
mysql> insert into test values(26,6);
Query OK, 1 row affected (0.02 sec)
是可以执行的。

这也证明了我们刚才的结论是不正确的,我们分析一下

| 15 |    2 |
| 20 |    4 |
| 25 |    6 |
这是原始的记录我们对4进行了for update,为了更小的缩小范围
实际上INNODB把锁的方位定义到了
b列2 a列(15到正无穷) b列4 全部 b列6 a列(负无穷到25) 
之间全部的范围,这看起来好像不是一个连续的区间,但是如果理解B+树索引
同时INNODB在处理相同的值的时候按照主键升序进行排列就出现了一个连续的
区间,我们来画一下,假设叶子节点如下排列,

实际上这样我们就能看出这样一个范围,如果我们插入的是

 values(16,2)显然在这个范围内它应该插入在2 15 和4 20 之间,所以锁定

 values(16,6)显然也在范围,他应该插入到4 20和6 25 之间,所以锁定

 values(14,2)显然不在这个范围,他应该在2 10 和 2 15之间插入,所以OK

 values(26,6)在6 25和8 99 之间当然也可以。

如果要插入(3,3)显然不行,因为首先是按照key排序的他肯定在这个范围内。

最后我们得出我们的结论:

b列2 a列(15到正无穷)

b列4 全部

b列6 a列(负无穷到25)

这样一个范围的插入全部不允许,当然2 15  6 25本身不包含因为可以for update.

其实这样做也是为了最小化锁定范围提高并发,所以辅助索引上的gap lock不仅取决

于辅助索引列还取决于主键列的值,但是要注意这个锁是在辅助索引上的,而不是
主键上。
还有一点需要提醒:
如果锁定是边界记录如上图的
b=2 for update

b=8 for update
那么锁定的范围将变大
b=2 for update锁定的是 b列负无穷 到 b列4 a列(负无穷到20) 
如图:
这里将虚拟行infimum写出来代表负无穷

b=8 for update锁定的是b列 6 a列(25 到正无穷) 到 b列 正无穷
如图:
这里将supremum虚拟行列出来代表正无穷

实际就是看图就理解了

最后就是需要验证:

验证从2个方面

1、对辅助索引的页中链表进行分析,如果在辅助索引页内的链表按照首先是KEY排序然后KEY相同的按照PRIMARY KEY排序那么基本就验证了我们的说法
   这个随后可以补上

2、源码查看,源码过于庞大就是B+树索引数据结构的建立,查找,插入,删除都非常难看懂,如果要到我们需要的证据非常困难,以后尽力。

时间: 2024-10-17 09:22:48

RR模式下NEXT-KEY LOCK范围到底有多大的相关文章

关于叶老师一个RR模式下UPDATE锁范围扩大案例的研究

原创转载请注明出处有误请指出 一.前言 叶金荣老师分享了一篇文章如下:https://mp.weixin.qq.com/s/09DJCyMq8kBn4mlezgzUgg 这里只研究下锁的模式,借用叶老师的表和语句 mysql> select * from t1; +----+----+----+----+ | c1 | c2 | c3 | c4 | +----+----+----+----+ | 0 | 0 | 0 | 0 | | 1 | 1 | 1 | 0 | | 3 | 3 | 3 | 0

【MySQL】可重复读模式下 unique key失效案例

一 [背景]    今天上午文能提笔安天下,武能上马定乾坤的登博给团队出了一道题目,谁先复现问题,奖励星巴克一杯.激起了一群忙碌的屌丝DBA的极大热情.问题是这样滴,如下图登博提示了几个细节:   1. code上的uk并未失效.   2. rr隔离级别.   3. 有并发线程的操作.二 [原理分析]1 事务隔离级别的基础知识:  未提交读(Read Uncommitted):允许脏读,也就是可能读取到其他会话中未提交事务修改的数据.  提交读(Read Committed):只能读取到已经提交

MYSQL INNODB replace into 死锁 及 next key lock 浅析

原创:全文带入了大量自我认知和理解,可能错误,因为水平有限,但是代表我努力分析过. 一.问题提出问题是由姜大师提出的.问题如下:表:mysql> show create table c \G*************************** 1. row ***************************       Table: cCreate Table: CREATE TABLE `c` (  `a` int(11) NOT NULL AUTO_INCREMENT,  `b` in

Oracle IMU模式下REDO格式详解

1. 什么是IMU?IMU的主要作用是什么,也就是说为了解决什么问题? IMU--->In Memory Undo,10g新特性,数据库会在shared pool开辟独立的内存区域用于存储Undo信息, 每个新事务都会分配一个IMU buffer(私有的),一个buffer里有很多node,一个node相当于一个block(回滚块). IMU特性: IMU顾名思义就是在内存中的undo,现在每次更改data block,Oracle 不用去更改这个undo block(也不会生成相应的redo了

并发与实例上下文模式: WCF服务在不同实例上下文模式下的并发表现

由于WCF的并发是针对某个封装了服务实例的InstanceContext而言的,所以在不同的实例上下文模式下,会表现出不同的并发行为.接 下来,我们从具体的实例上下文模式的角度来剖析WCF的并发,如果对WCF实例上下文模式和实例上下文提供机制不了解的话,请参阅<WCF 技术剖析(卷1)>第9章. 在<实践重于理论>一文中,我写一个了简单的WCF应用,通过这个应用我们可以很清楚了监控客户端和服务操作的执行情况下.借此 ,我们可以和直观地看到服务端对于并发的服务调用请求,到底采用的是并

android系统在静音模式下关闭camera拍照声音的方法

话说为了防止偷拍,业内有不成文规定,手机公司在做camera时,点击拍照和录像键的时候,必须要有提示音.因此,google也就非常人性化的将播放 拍照声音的函数,放到了cameraService中,防止开发者能开发出不响的camera,从而只要调用拍照函数,一定会响,这是写死在 framework中的. 话说这个规定在当今有点不合时宜,这不,今天我收到测试提的一个BUG,说是公司的新需求,要求在静音模式下拍照声音也得取消.这么无耻的需求,也许就在我们中国最大的山寨手机公司才会提到.废话不多说,看

directx-Directinput立即模式下为什么按一键却收到多条纪录

问题描述 Directinput立即模式下为什么按一键却收到多条纪录 大家好,代码如下: //开始准备循环接收数据 BYTE diks[256]; while(g_pKeyboard->GetDeviceState(sizeof(diks),&diks) == DI_OK) { for(int i=0;i<256;i++) { if((diks[i] & 0x80) >0 ) { std::cout<<"The Key of NO."<

互联网模式下的测试数据中心,小白也能高效构造数据

11月2日,云效第三期Work Like Alibaba系列直播开启,阿里巴巴研发效能事业部云效技术专家何卫龙,分享了<测试数据中心-互联网模式下新型的数据准备引擎>,主要解决测试过程中数据准备困难,以及如何提升数据准备效率的思路和方法. 主播简介 何卫龙:阿里巴巴技术专家.一直从事软件开发测试及系统架构设计工作,对测试工具平台的开发架构有一定的经验.目前是云效持续集成平台Amon.测试用例管理系统pivot和测试数据中心databank的技术负责人,主要负责平台的技术规划和产品建设.在此期间

Self Host模式下的ASP. NET Web API是如何进行请求的监听与处理的?

构成ASP.NET Web API核心框架的消息处理管道既不关心请求消息来源于何处,也不需要考虑响应消息归于何方.当我们采用Web Host模式将一个ASP.NET应用作为目标Web API的宿主时,实际上是由ASP.NET管道解决了这两个问题.具体来说,ASP.NET自身的URL路由系统借助于HttpControllerHandler这个自定义的HttpHandler实现了ASP.NET管道和ASP.NET Web API管道之间的"连通",但是在Self Host寄宿模式下,请求的