幻读：听说有人认为我是被MVCC干掉的

た入场券 2022-11-14 15:58 88阅读 0赞

### 文章目录 ###

*  前言
 *  系列文章
 *  一、我是谁？
 *  二、为什么有人会认为我是被MVCC干掉的
 *  三、我真的是被MVCC解决的？
 *  四、再聊当前读、快照读
 *   *  当前读
     *  快照读
 *  五、告诉你们吧！当前读的情况下我是被next-key locks干掉的
 *  六、幻读解决方案
 *  七、扩展
 *   *  事务ID是在何时分配的？
     *  为什么事务ID差异特别大？

![幻读][20210427110558215.png]

# 前言 #

我是幻读，听说有人认为我是MVCC解决的，为了让大家更全面地理解我，只能亲自来解释一下。

# 系列文章 #

[`1. 揭开MySQL索引神秘面纱`  
][1. _MySQL_]  
[`2. MySQL查询优化必备`  
][2. MySQL_]  
[`3. 上来就问MySQL事务，瑟瑟发抖...`  
][3. _MySQL_..._]  
[`4. MVCC：听说有人好奇我的底层实现`  
][4. MVCC_]

# 一、我是谁？ #

先给大家做一个简单的自我介绍，我就是事务并发时会产生的三大问题之一。

我的其它俩兄弟脏读、不可重复读被MVCC在上一个回合无情的干掉了，至于上个回合发生了什么可以去看剧情回顾。

我的由来就是因为主人在操作一组数据时还有很多人也在对这组数据进行操作。

举一个简单的案例：

根据条件在对一组数据进行过滤返回的结果为100个，但是在主人操作的同时其他人又新增了符合条件的数据，然后主人再次进行查询时返回结果为101。第二次返回的数据跟第一次返回数据不一致。

于是我诞生了，大家还给我起了个很好听的名字`幻读`。

为什么会给我起这个名字呢！那是因为我给人们的现象好像出了幻觉一样。

# 二、为什么有人会认为我是被MVCC干掉的 #

为了演示方便，就直接使用之前的测试表来进行操作。

![表结构][20210330152556840.png]

同时大家可以看到此表还有一些测试数据，一切从头开始，清空表。

清空表的命令`truncate table_name`

执行这个命令会使表的数据清空，并且自增ID会从1开始。

从执行过程来看，truncate table类似于drop table然后在create table，这里的环境都是测试环境，千万不要在线上进行操作，因为它绕过了DML方法，是不能回滚的。

![清空表][20210330152733505.png]

进行了一点小插曲，进入正题。

![执行结果][20210330155113852.png]

根据上图的执行步骤，预期来说左边事务的第一条select语句查询结果为空。

第二个select查询结果为1条数据，包含右边事务提交的数据。

但在实际测试的情况下，第一次执行select和第二次执行select返回结果一致。

从这个案例中，可以得出结论确实在不可重复隔离级别下会解决幻读问题(在快照读的前提下)。

# 三、我真的是被MVCC解决的？ #

通过上述测试案例来看，貌似在MySQL中通过MVCC就解决我的引来的问题，那既然都解决了我的问题，为什么还有串行化的隔离级别呢！好疑惑啊！

带着这个疑问继续进行实验，为了方便就不再使用上边表结构了，建立一个简单的表结构。

![表结构][20210410103227380.png]

再进入一个小插曲你知道在MySQL终端如何清屏吗？

执行命令system clear即可

![清屏][20210330161345459.png]

接着开始新一轮的测试

![案例一][20210410103730342.png]

上图案例事务1几次查询数据都是空。

此时事务2已经成功将数据插入并且提交。

但当事务1几次查询数据为空之后进行数据插入时，提示主键重复。

**再来看一个案例**

![案例二][20210410105507680.png]

*  step1：事务1开启事务
 *  step2：事务2开启事务
 *  step3：事务1查询数据只有一条数据
 *  step4：事务2添加一条数据
 *  step5：事务1查询数据为一条
 *  step6：事务2提交事务
 *  step7：事务1查询数据为一条
 *  step8：事务1修改name
 *  step9：猜想一下此时表内数据会发生什么改变

![返回结果][2021041011002298.png]

此案例中事务1始终读取数据都是一条数据，但是在修改数据时影响数据行数却是2，再次进行查看数据时竟然出现了事务2添加的数据。这也可以看作是一种幻读。

**小结**

通过以上俩个案例得知在MySQL可重复读隔离级别中并没有完全解决幻读问题，而只是`解决了快照读下的幻读问题`。

而对于`当前读的操作依然存在幻读问题`，也就是说MVCC对于幻读的解决是不彻底的。

# 四、再聊当前读、快照读 #

在上一回合中快照读、当前读已经被消化了，为了防止消化不良这里再简单说明一下。

## 当前读 ##

所有操作都加了锁，并且锁之间除了共享锁都是互斥的，如果想要增、删、改、查时都需要等待锁释放才可以，所以读取的数据都是最新的记录。

简单来说，当前读就是加了锁的，增、删、改、查，不管锁是共享锁、排它锁均为当前读。

在MySQL的Innodb存储引擎下，增、删、改操作都会默认加上锁，所以增、删、改操作默认就为当前读。

## 快照读 ##

快照读的出现旨在提高事务并发性，实现基于我的敌人MVCC

简单来说快照读就是不加锁的非阻塞读，即简单的select操作（select \* from user）

在Innodb存储引擎下执行简单的select操作时，会记录下当前的快照读数据，之后的select会沿用第一次快照读的数据，即使有其它事务提交也不会影响当前的select结果，这就解决了不可重复读问题。

快照读读取的数据虽然是一致的，但有可能不是最新的数据而是历史数据。

# 五、告诉你们吧！当前读的情况下我是被next-key locks干掉的 #

第二小节中得知在快照读下由于我引发的问题已经被MVCC消灭了。

但是在小节三进行案例测试发现在当前读下我又满血复活了。

我要是那么容易被干掉还怎么被称为打不死的小强，这不是闹笑话呢！

说归说，闹归闹如果MVCC把它的小弟next-key locks带上那我就完了，就不再像灰太狼说经典语录“我一定会回来的”

此时就要思考一个问题，在Innodb存储引擎下，是默认给快照读加next-key locks，还是说需要手动加锁。

通过官方文档对于`next-key locks`的解释。

> To prevent phantoms, InnoDB uses an algorithm called next-key locking that combines index-row locking with gap locking. InnoDB performs row-level locking in such a way that when it searches or scans a table index, it sets shared or exclusive locks on the index records it encounters. Thus, the row-level locks are actually index-record locks. In addition, a next-key lock on an index record also affects the “gap” before that index record. That is, a next-key lock is an index-record lock plus a gap lock on the gap preceding the index record. If one session has a shared or exclusive lock on record R in an index, another session cannot insert a new index record in the gap immediately before R in the index order.

> 大致意思，为了防止幻读，Innodb使用next-key lock算法，将行锁(record lock)和间隙锁(gap lock)结合在一起。Innodb行锁在搜索或者扫描表索引时，会在遇到的索引记录上设置共享锁或者排它锁，因此行锁实际是索引记录锁。另外， 在索引记录上设置的锁同样会影响索引记录之前的“间隙(gap)”。即next-key lock是索引记录行加上索引记录之前的“gap”上的间隙锁定。

并且还给了一个案例`SELECT * FROM child WHERE id > 100 FOR UPDATE;`

当Innodb扫描索引时，会将id大于100地上锁，阻止任何大于100的数据添加。

到这里就回答了上边问题，在Innodb下解决当前读产生的幻读问题需要手动加锁来解决。

**再来看一个案例**

下图为此时的数据情况

![当前数据][20210411170231411.png]

下图的这个案例就解决了在第三节中第一个案例的幻读问题。

![解决幻读第一个问题][20210411170528889.png]

*  step事务1：开启事务
 *  step事务2：开启事务
 *  step事务1：查询ID为4的这条数据并且加上排它锁
 *  step事务2：添加ID为4的数据，并且等待事务1释放锁
 *  step事务1：添加ID为4的数据，添加成功
 *  step事务1：查询当前数据
 *  step事务1：提交事务
 *  step事务2：报错，返回主键重复问题。

这个案例查询的索引列是主键并且是唯一的，此时Innodb引擎会对next-key lock做降级处理，也就是只锁定当前查询的索引记录行，而不是范围锁定。

**案例二**

还是使用上边的数据，但是这次我们进行一次范围查找。

![回滚数据][20210411172121268.png]

此时的数据为1，3，5，查找的范围为大于3。

从下图可以看出当事务2执行添加ID为2的是可以添加成功的。

但是当添加 ID 6时需要等待。

此时若事务1不提交事务，事务2添加ID为6的这条数据就执行不成功。

![添加区间数据][20210411172414681.png]

对于上述的SQL语句`select * from user where id > 3 for update;`执行返回的只有5这一行数据。

此时锁定的范围为(3，5\]，(5，∞)，所以说id为2的可以插入，ID为4或者大于5的都是插入不了的。

以上就是在Innodb中解决幻读问题最终方案。

# 六、幻读解决方案 #

为了方便大家直观了解幻读的解决方案，这里咔咔进行简单的总结。

通过MVCC解决了快照读下的幻读问题，为什么能解决？在第一次执行简单的select语句就生成了一个快照，并且在后边的select查询都是沿用第一次快照读的结果。所以说快照读查询到的数据有可能是历史数据。

通过next-key lock解决当前读的幻读问题，next-key lock是record lock和gap lock的结合，锁定的是一个范围，如果查询数据为索引记录行，则只会锁定当前行，也就是说降级为record lock。若为范围查找时就会锁定一个范围，例如上例中ID为1，3，5查询大于3的数据，则会把(3,5\]，（5，∞）进行范围锁定，其它事务在锁未释放之前是无法插入的。

从官方文档还可得知如果需要验证数据唯一性只需要给查询加上共享锁即可，也就是给select 语句加上 in lock share mode，如果返回结果为空，则可以进行插入，并且插入的这个值肯定是唯一的。同样也可以添加next key lock防止其他人同时插入相同数据，小节5的所有案例就是使用的next-key lock，从这一点可以得知next-key lock是可以锁定表内不存在的索引。

根据上述结论来看，如果想要检测数据唯一性使用共享锁，那么多个事务同时开启共享锁，又同时添加相同的数据怎么办，会不会出现问题呢？明确地说明是不会的，如果多个事务同时插入相同数据只会有一个事务添加成功，其它事务会抛出错误，这个就是一个新的概念“死锁”。

# 七、扩展 #

## 事务ID是在何时分配的？ ##

在本文或者其它资料中都能得到一个信息就是当执行一条简单的select语句同时也会生成read-view。

虽然快照读、read-view都是基于事务启动的前提下，但是read-veiw是通过未提交事务ID组成的。

那么到底是在何时分配事务ID的呢？

事务的启动方式有两种，分别为显示启动、另一种是设置autocommit=0后执行select就会启动事务。

在显示启动中最简单的就是以begin语句开始，也可以使用start transaction开启事务。

若使用start trancaction开启事务也可以选择开始只读事务还是读写事务。

看了很多资料都说当开启一个事务时会分配一个事务ID，那么来验证一下是这个样子的吗？

![查询事务ID][ID]

通过上图可以看到当执行一个begin语句之后查询事务ID是空的，也就说当执行begin后并没有分配trx\_id。

那么当执行begin后在支持DML语句呢！

![查询事务ID][ID 1]

根据文档得知

`执行begin命令并不是真正开启一个事务，仅仅是为当前线程设定标记，表示为显式开启的事务。`

所以要明白对数据进行了增、删、改、查等操作后才算真正开启了一个事务，此时会去引擎层开启事务。

## 为什么事务ID差异特别大？ ##

![事务ID][ID 2]

上图中查询了当前活跃的事务ID，但是两个事务ID的差异特别大。

相信很多小伙伴都遇到过这个问题，有问题不害怕，害怕的是没有问题。

事实上在这两条数据中只有20841是真正的事务ID，那么第二条数据中的ID是什么呢！

想知道这个数字是什么的前提是知道是怎么来的。

![查询事务id][id]

从上图可以看出，当执行select语句后会产生一个非常大的事务ID，那能不能理解为这种差异非常大的事务ID是通过快照读的方式才会生成的。

接着再这个事务下面在执行一个insert语句，然后再查看一下事务ID的状态

![insert之后的事务id][insert_id]

不可思议的是在事务中先执行select语句，然后执行insert语句，事务ID发生了变化，这是什么原因呢？

经过资料查询得知当执行一个简单的select语句时，被称之为只读事务，为了避免给只读事务分配trx\_id带来不必要的开销就没有对其分配事务ID。只读事务没有分配undo segment也不会分配LOCK锁结构，本质上只读事务的trx\_id的值就是0，但是为了执行`select * from information_schema.INNODB_TRX`或者`show engine innodb status`时就会通过reinterpret\_cast(trx) | (max\_trx\_id + 1)将指针转换为一个64字节非负整数然后位或(max\_trx\_id + 1) 就是这么个值。

关于这个值的生成过程就不用再去深究了，只需要知道在只读事务下是不会分配事务ID，而查询出来的这个值只是为了显示而存在的没有实际意义。

但是当你执行`select * from information_schema.INNODB_TRX`查询出来的事务ID，再通过`show engine innodb status`查询是查不到的。在Innodb下如果事务为只读事务则不会在Innodb数据结构中显示，因此你是看不到的。

> 坚持学习、坚持写作、坚持分享是咔咔从业以来一直所秉持的信念。希望在偌大互联网中咔咔的文章能带给你一丝丝帮助。我是咔咔，下期见。

[20210427110558215.png]: /images/20221022/44ac74ed1d0f4766927693ed696dfb66.png
[1. _MySQL_]: https://blog.csdn.net/fangkang7/article/details/113447632
[2. MySQL_]: https://blog.csdn.net/fangkang7/article/details/113633367
[3. _MySQL_..._]: https://blog.csdn.net/fangkang7/article/details/114852468
[4. MVCC_]: https://blog.csdn.net/fangkang7/article/details/114987135
[20210330152556840.png]: /images/20221022/ce1f467c841542b5a9066046e1006b4e.png
[20210330152733505.png]: https://img-blog.csdnimg.cn/20210330152733505.png
[20210330155113852.png]: https://img-blog.csdnimg.cn/20210330155113852.png
[20210410103227380.png]: https://img-blog.csdnimg.cn/20210410103227380.png
[20210330161345459.png]: https://img-blog.csdnimg.cn/20210330161345459.png
[20210410103730342.png]: https://img-blog.csdnimg.cn/20210410103730342.png
[20210410105507680.png]: https://img-blog.csdnimg.cn/20210410105507680.png
[2021041011002298.png]: https://img-blog.csdnimg.cn/2021041011002298.png
[20210411170231411.png]: https://img-blog.csdnimg.cn/20210411170231411.png
[20210411170528889.png]: https://img-blog.csdnimg.cn/20210411170528889.png
[20210411172121268.png]: https://img-blog.csdnimg.cn/20210411172121268.png
[20210411172414681.png]: https://img-blog.csdnimg.cn/20210411172414681.png
[ID]: https://img-blog.csdnimg.cn/20210409142841521.png
[ID 1]: https://img-blog.csdnimg.cn/20210409143336146.png
[ID 2]: https://img-blog.csdnimg.cn/20210411184232112.png
[id]: https://img-blog.csdnimg.cn/20210411190722454.png
[insert_id]: https://img-blog.csdnimg.cn/20210411191113142.png