mysql rr gap nextkey_RR模式下NEXT-KEY LOCK范围到底有多大

我的《深入理解MySQL主从原理》发布，具体可以点击：ttps://j.youzan.com/yEY_Xi

我们知道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+树索引数据结构的建立，查找，插入，删除都非常难看懂，如果要到我们需要的证据非常困难，以后尽力。