67 mysql 的间隙锁

前言

我们这里主要是来看一下 mysql 中的间隙锁

间隙锁主要存在的地方一般就是在查询主键查询不到, 索引查询查询不到的场景

然后我们这里来调试一下这里的整个流程, 间隙锁的加锁以及间隙锁的使用, 以及间隙锁的释放

从逻辑上来说间隙锁锁定的是一个区间, 按照我们常规的理解他应该会保存区间的起始地址, 但是从实际的实现层面 mysql 这边的实现相当巧妙, 它是挂在比目标值大的下一条记录上面的, 比如主键有 1, 5, 10, 我们这里执行查询 “select * from tz_test_04 where id = 7 for update;” 间隙锁是挂在 id 为 10 的这条记录上面的一个行锁, 并且增加了一个 GAP_LOCK 的标志, 用于业务的判断

根据这个目标记录 10, 以及 10 的上一条记录 5, 改间隙锁推导出锁定的区间就是 (5, 10)

我们这里测试表结构如下

CREATE TABLE `tz_test_04` (`id` int(11) unsigned NOT NULL AUTO_INCREMENT,`field1` varchar(128) DEFAULT NULL,`field2` varchar(128) DEFAULT NULL,PRIMARY KEY (`id`) USING BTREE,KEY `field_1_2` (`field1`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT CHARSET=utf8

测试数据如下, 之所以留下一些区间是为了产生 “间隙”

添加间隙锁

为了演示, 我们这里事务1 加锁 sql 如下

此查询会在 id 为 10 的行上面增加一个行锁, 并打上 GAP_LOCK 标志, 逻辑意义上这个间隙锁锁定的区间为主键的 (5, 10)

因此我们在这个区间去增加记录会获取行排他锁, 获取失败, 如果是更新或者删除, 还不到获取行排他锁锁的地方, 因此可以正常执行

begin;
select * from tz_test_04 where id = 7 for update;
-- sleep10min
commit;

获取锁的地方如下, mode 为 515 = LOCK_GAP + LOCK_X, 间隙排他锁

锁定的记录的 heap_no 为 5, 上下文还有它的 space, page 的相关信息

在 search_mvcc 中上下文如下, 是在 cmp_dtuple_is_prefix_of_rec 的判断内部, 条件匹配不上的时候, 会添加这个间隙锁

会进入这里的比较, 我这边目前知道的有等于比较

我们再来看一下 rec 的记录信息

目标记录的上下文信息如下, 可以看到上一次更新是事务39531 处理的, 当前事务是 39537, 然后对应的记录是 id 为 10 的记录

间隙锁的使用

间隙锁区间新增记录

然后在事务2 执行sql 如下, 然后可以看到产生了阻塞

INSERT INTO `test_02`.`tz_test_04`(`id`, `field1`, `field2`) VALUES (8, 'field1', '1');

这里是判断上下文是否有存在冲突的锁是否被其他事务持有, 锁住的事务是事务39537 即上面那副截图的事务, 然后当前事务是事务39538, 是由 mysql 这边新分配的一个事务

然后期望锁定的目标记录是 5 号记录, 结合上面的信息来看是 id 为 10 的记录

持有锁的事务的 mode 为 547 为 LOCK_GAP + LOCK_RECORD + LOCK_X

当前事务尝试获取的 mode 为 2563 为 LOCK_INSERT_INTENSION + LOCK_GAP + LOCK_X

然后这里持有锁的上下文和尝试获取锁的上下文是不兼容的, 因此当前事务只能挂起, 等待目标事务释放间隙锁

我们再来看一下这里的 heap_no 为什么会是 id 为 10 的记录的 heap_no 呢?

获取锁的时候是在插入数据记录的时候, 获取当前记录的下一条记录, 比如我们这里插入的记录 id 为 8, 那么是应该放在 id 为 5 和 id 为 10 的记录之间, 下一条记录即为 id 为 10 的记录

然后因此就巧妙的实现了间隙锁, 锁是加载一个行记录上面的, 但是实际锁定的却是一个区间

间隙锁区间更新记录

然后在事务2 执行sql 如下, 然后可以看到不会产生阻塞

update tz_test_04 set field1 = 'fieldUpdated' where id = 8;

这是因为如下判断锁是否兼容的时候, 这里在间隙锁的第二个 case, 这里满足, 就是持有锁的事务是间隙锁, 并且当前事务没有 LOCK_INSERT_INTENSION, 我们这里是更新, 是满足条件的, 因此视为兼容

间隙锁区间删除记录

然后在事务2 执行sql 如下, 然后可以看到不会产生阻塞

delete from tz_test_04 where id = 8;

这是因为如下判断锁是否兼容的时候, 这里在间隙锁的第二个 case, 这里满足, 就是持有锁的事务是间隙锁, 并且当前事务没有 LOCK_INSERT_INTENSION, 我们这里是删除, 是满足条件的, 因此视为兼容

间隙锁的释放

释放同样是在事务提交的时候

间隙锁锁索引的情况

tz_test_04 的数据表数据如下, 这里更新了一下 id 为 10 的记录的 field1 的值, 让其在字符串层面增量排序

执行 sql 如下

begin;
select * from tz_test_04 where field1 = 'field7' for update;
-- sleep10min
commit;

走的索引查询, 同样如果是索引字段 field1 没有命中的情况, 会基于索引记录添加间隙锁

从 rec, 或者代码所在区域可以看出当前 rec 实际上时索引记录, 然后下面会走查询是否匹配, 匹配的话走聚簇索引的回表查询, 这里我们的事务是事务39576

执行 sql 如下 “INSERT INTO `test_02`.`tz_test_04`(`id`, `field1`, `field2`) VALUES (8, 'field8', '8');”

会添加数据记录, 索引记录, 这里阻塞是阻塞在插入索引记录的地方

当前事务39577 尝试获取 “field8” 的下一个索引记录 “field9” 的间隙锁 mode 为 2563, LOCK_INSERT_INTENSION + LOCK_GAP + LOCK_X

发现事务39576 持有 “field9” 的间隙锁 mode 为 547, LOCK_GAP + LOCK_RECORD + LOCK_X

然后当前事务有LOCK_INSERT_INTENSION 和已有的间隙锁不兼容, 因此当前事务需要等待

间隙锁锁非索引记录的情况

执行 sql 如下

begin;
select * from tz_test_04 where field2 = '7' for update;
-- sleep10min
commit;

这个效果就转换为了在每一行记录上面加上行临键锁

上下文在这里, 具体遍历了每一行记录, 以及 supremum

遍历的各个记录如下, 下图是在 row_search_mvcc 中查看的 rec 的记录信息, 可以通过 field1 字段观察出那一条记录

间隙锁锁最大值到正无穷的情况

间隙锁锁在主键上面

执行 sql 如下

begin;
select * from tz_test_04 where id = 15 for update;
-- sleep10min
commit;

这里是遍历到了 supremum 记录, 然后这里会在 supremum 记录上面添加一个行排他锁

但是它的作用和在 supremum 记录上面增加一个间隙锁的效果是一样的

然后执行 sql 如下 “INSERT INTO `test_02`.`tz_test_04`(`id`, `field1`, `field2`) VALUES (15, 'fieldc', 'c');”

然后这里可以看到是在添加数据记录的时候尝试获取锁 mode 为 2563, LOCK_INSERT_INTENSION + LOCK_GAP + LOCK_X

然后已经持有的事务 mode 为 LOCK_RECORD + LOCK_X

然后两个事务的情况不在下面的四种兼容情况内, 因此本事务需要阻塞

需要注意的是这里在 supremum 记录上面增加的是行排他锁, 而不是间隙锁

间隙锁锁在索引上面

执行 sql 如下

begin;
INSERT INTO `test_02`.`tz_test_04`(`id`, `field1`, `field2`) VALUES (8, 'fieldc', 'c');
-- sleep10min
commit;

这里是遍历到了 supremum 记录, 然后这里会在 supremum 记录上面添加一个行排他锁

但是它的作用和在 supremum 记录上面增加一个间隙锁的效果是一样的

然后执行 sql 如下 “INSERT INTO `test_02`.`tz_test_04`(`id`, `field1`, `field2`) VALUES (8, 'fieldc', 'c');”

然后这里可以看到是在添加索引记录的时候尝试获取锁 mode 为 2563, LOCK_INSERT_INTENSION + LOCK_GAP + LOCK_X

然后已经持有的事务 mode 为 LOCK_RECORD + LOCK_X

然后两个事务的情况不在下面的四种兼容情况内, 因此本事务需要阻塞

需要注意的是这里在 supremum 记录上面增加的是行排他锁, 而不是间隙锁

完