本文是基于 极客时间——MySQL 实战 45 讲 整理的学习笔记,仅供学习参考,请勿用于商业用途,如若侵权,请联系并删除。
课程重点:
- 了解全表扫猫的加锁方式
- 认识幻读
- 了解幻读所带来的问题以及如何解决幻读
下面的示例都是基于表 t 进行展开的,建表和初始化语句如下:
1 | CREATE TABLE `t` ( |
幻读是什么
下面的语句序列,是怎么加锁的,加的锁又是什么时候释放的呢?
1 | begin; |
这个语句会命中 d=5 的这一行,对应的主键 id=5,因此在 select 语句执行完成后,id=5 这一行会加一个写锁,而且由于两阶段锁协议,这个写锁会在执行 commit 语句的时候释放。
由于字段 d 上没有索引,因此这条查询语句会做全表扫描。那么,其他被扫描到的,但不满足条件 d=5
的记录,会不会被加锁呢。
答案是,也会被锁住。
幻读指的是一个事务在前后两次查询同一个范围的时候,后一次查询看到了前一次查询没有看到的行。
幻读有什么问题
假设只在 id=5 这一行加行锁,会产生数据一致性问题。
我们把扫描过程中碰到的行,也都加上写锁,再来看看执行效果。
由于 session A 把所有的行都加了写锁,所以 session B 在执行第一个 update 语句的时候就被锁住了。需要等到 T6 时刻 session A 提交以后,session B 才能继续执行。
这样对于 id=0 这一行,在数据库里的最终结果还是 (0,5,5)。在 binlog 里面,执行序列是这样的:
1 | insert into t values(1,1,5); /*(1,1,5)*/ |
但同时你也可以看到,id=1 这一行,在数据库里面的结果是 (1,5,5),而根据 binlog 的执行结果是 (1,5,100),也就是说幻读的问题还是没有解决。为什么我们已经这么“凶残”地,把所有的记录都上了锁,还是阻止不了 id=1 这一行的插入和更新呢?
原因很简单。在 T3 时刻,我们给所有行加锁的时候,id=1 这一行还不存在,不存在也就加不上锁。
也就是说,即使把所有的记录都加上锁,还是阻止不了新插入的记录,这也是为什么“幻读”会被单独拿出来解决的原因。
幻读怎么解决
产生幻读的原因是,行锁只能锁住行,但是新插入记录这个动作,要更新的是记录之间的“间隙”。因此,为了解决幻读问题,InnoDB 只好引入新的锁,也就是间隙锁 (Gap Lock)。
顾名思义,间隙锁,锁的就是两个值之间的空隙。比如文章开头的表 t,初始化插入了 6 个记录,这就产生了 7 个间隙。
这样,当执行 select * from t where d=5 for update 的时候,就不止是给数据库中已有的 6 个记录加上了行锁,还同时加了 7 个间隙锁。这样就确保了无法再插入新的记录。
间隙锁和行锁合称 next-key lock,每个 next-key lock 是前开后闭区间。
也就是说这时候,在一行行扫描的过程中,不仅将给行加上了行锁,还给行两边的空隙,也加上了间隙锁。
现在你知道了,数据行是可以加上锁的实体,数据行之间的间隙,也是可以加上锁的实体。但是间隙锁跟我们之前碰到过的锁都不太一样。
比如行锁,分成读锁和写锁。下图就是这两种类型行锁的冲突关系。
也就是说,跟行锁有冲突关系的是“另外一个行锁”。
但是间隙锁不一样,跟间隙锁存在冲突关系的,是“往这个间隙中插入一个记录”这个操作。间隙锁之间都不存在冲突关系。
间隙锁的引入,可能会导致同样的语句锁住更大的范围,这其实是影响了并发度的。
总结
select * from t where d=5 for update;
,由于字段 d 上没有索引,因此这条查询语句会做全表扫描。不满足条件d= 5
的记录,也会被加锁,因为如果不加锁的话,会产生幻读。- 幻读是指一个事务在前后两次查询同一个范围的时候,后一次查询看到了前一次查询没有看到的行。
- 幻读所带来的问题就是,数据一致性被破坏,数据和日志在逻辑上不一致。
- 解决幻读的方式是,引入间隙锁。