RR模式下NEXT-KEY LOCK范围究竟有多大
|
这期内容当中小编将会给大家带来有关RR模式下NEXT-KEY LOCK范围到底有多大，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。 我们知道MYSQL NEXT-KEY LOCK是用来防止幻读，在RR模式下就有了用武之地 实际就是当前行锁+前后的一个区间，但是这个区间到底有多大？ 是简单的一个辅助索引列上的闭区间吗？ 建立测试表： 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) b=8 for update锁定的是b列 6 a列(25 到正无穷) 到 b列 正无穷 最后就是需要验证： 验证从2个方面 1、对辅助索引的页中链表进行分析,如果在辅助索引页内的链表按照首先是KEY排序然后KEY相同的按照PRIMARY KEY排序那么基本就验证了我们的说法 这个随后可以补上 2、源码查看，源码过于庞大就是B+树索引数据结构的建立，查找，插入，删除都非常难看懂，如果要到我们需要的证据非常困难，以后尽力。 （编辑：银川站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
