前面已经介绍了主键索引的加锁范围和非主键唯一索引的加锁范围。
主键索引:
X,REC_NOT_GAP
;
X,GAP
;
前开后开
区间;
<=
查询时,8.0.17 会锁住下一个 next-key 的前开后闭区间,而 8.0.18 及以后版本,修复了这个 bug。
非主键唯一索引:
这篇文章来一起看一下普通索引和普通字段的加锁范围是什么?
CREATE TABLE `t` (
`id` int NOT NULL COMMENT '主键',
`a` int DEFAULT NULL COMMENT '唯一索引',
`c` int DEFAULT NULL COMMENT '普通索引',
`d` int DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `uniq_a` (`a`),
KEY `idx_c` (`c`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
数据库数据如下:
思路和非主键唯一索引相同,只不过唯一的区别是这里看的是 c 和 d 字段。
因为前面小伙伴对 data_locks 应该有了一定的了解,这里就直接分析 data_locks 的数据信息。
mysql> begin; select * from t where c = 210 for update;
直接分析 data_locks
X,GAP
;
X,REC_NOT_GAP
。
主要是因为普通索引不能唯一锁定一条记录,所以要锁定该字段的前后范围。
mysql> begin; select * from t where c = 211 for update;
直接分析 data_locks
分析是因为数据不存在,只需要锁住 215 间隙就可以了,因为 215 和 210 肯定不属于这个范围。
mysql> begin; select * from t where c > 210 and c <= 215 for update;
对于锁住 idx_c 索引的 215 的前开后闭区间是可以理解的,但是锁住了 220 就不太理解了,应该也是那个 bug 没有完全修复。
普通字段就更好理解了。
对普通字段而言,无论是哪个查询,都需要扫描全部记录,所以这个锁直接加在了主键上,并且是锁住全部的区间。
本文在基于第一篇和第二篇的基础上,直接通过分析 data_locks 的信息,进行判断加锁范围。
select * from performance_schema.data_locks;
LOCK_MODE |
LOCK_DATA |
锁范围 |
---|---|---|
X,REC_NOT_GAP |
15 |
15 那条数据的行锁 |
X,GAP |
15 |
15 那条数据之前的间隙,不包含 15 |
X |
15 |
15 那条数据的间隙,包含 15 |
LOCK_MODE = X
是前开后闭区间;
X,GAP
是前开后开区间(间隙锁);
X,REC_NOT_GAP
行锁。
从而得出普通索引和普通字段的结论。
普通字段查询,会查询全表,这里锁的话就会锁住主键的所有区间。
- <End /> -