幻读

并发情况下，A事务读取了一条记录，此时B事务插入一条记录，A事务又读取，读到了两条数据，此时就造成了读取数据不一致，一般到这幻读通常说的是事务提交了，而且是指删除、插入带来的问题。

问题

mysql MVCC 多版本并发控制中我们介绍了什么是MVCC，MVCC会为每个事务生成一个某个时间点的快照数据，保证事务内可以避免每次读数据不一致的问题，是RC、RR隔离级别下用于提高数据库性能，避免频繁锁，读写分离实现的一种方式，既然读快照信息，那么是不是MVCC就可以避免幻读，因为事务已经有了快照数据，如果这样，那为啥RR、RC 隔离级别不能避免幻读？这个问题也有很多讨论，包括知乎上也有很多答案，本文也做一些思考和讨论，参考的文档在本文下方参考博客上。

快照读：snapshot read

MVCC针对每个事务都有一个快照数据，每次都从快照数据库读取，如果事务A内有这么一个逻辑：

• if sex =‘男’ 就执行sql:

update tb_user set type = 1 where id = 8;

因为每次都是快照读，那么每次读肯定都是男，如果在事务没commit 之前，事务B 执行结束了，它把sex改为了‘女‘，此时，你的条件不满足，但你因为读取快照信息，你也无法发现问题，所以你还是执行了sql，此时此刻，似乎也没有问题，但总体来说，这是错误的。所以当事务逻辑中有update的sql时，快照读是有问题的。

当前读：locking read

当前读是读取最新数据的一种读方式，不会从快照数据里读取，这样就可以读取到其他事务已经提交的数据，是特殊的读操作，插入/更新/删除操作属于当前读，需要加锁。

• select * from table where ? lock in share mode; （加S锁）
• select * from table where ? for update;（加X锁）
• insert into table values (…);（加X锁）
• update table set ? where ?;（加X锁）
• delete from table where ?;（加X锁）

所以MVCC为了解决快照读的问题引入了当前读，innodb 引擎实际执行的是当前读，但如果使用select for update，当前读就能看到每次读的数据就不一样了，就引起了幻读，你能看到其他事务insert的数据。

总结：快照读是没有幻读存在的，当前读才会出现幻读

幻读产生

select不会有phantom，读的是快照；可对于select for update(locking read)这种语句，被认为是写，如果：

• 事务A：select读快照(non-locking read)
• 事务B：insert 一条记录
• 事务A：select for update(locking read)

幻读就产生了，事务A两次读，数据数量变了。

如何解决幻读

很明显可重复读的隔离级别没有办法彻底的解决幻读的问题，如果我们的项目中需要解决幻读的话也有两个办法：

• 使用串行化读的隔离级别
• MVCC+next-key locks：next-key locks由record locks(索引加锁) 和 gap locks(间隙锁，每次锁住的不光是需要使用的数据，还会锁住这些数据附近的数据)

参考博客

MySQL的可重复读级别能解决幻读吗
既然MySQL中InnoDB使用MVCC，为什么REPEATABLE-READ不能消除幻读？
mysql在RR的隔离级别下,究竟是通过MVCC解决幻读的还是通过行锁的next key算法解决的?

一、前言

       建表语句和初始化语句如下：

CREATE TABLE `t`(
    `id` int(11) NOT NULL,
	`c`  int(11) DEFAULT NULL,
	`d`  int(11) DEFAULT NULL,
	PRIMARY KEY(`id`),
	KEY `c`(`c`)
)ENGINE=InnoDB;
insert into t values(0,0,0),(5,5,5),(10,10,10),(15,15,15),(20,20,20),(25,25,25);

       这个表除了主键id外，还有1个索引C，初始化语句在表中插入6行数据。

       下面的语句是怎么加锁的？加的锁又是什么时候释放的？

begin;
select * from t where d = 5 for update;
commit;

      比较好理解的是，这个语句会命中d=5这一行，对应的主键id=5，因此在select语句执行之后，id=5这一行记录会加一个写锁，而且由于两阶段锁协议，这个写锁，会在执行commit语句的时候释放。

      由于字段d上没有索引，因此这条查询会做全表扫描，那么其他被扫描到的，但是不满足条件的5行记录上，会不会加锁呢？

      众所周知，InnoDB默认的隔离级别是可重复读，所以本文在没有特殊说明的前提下，都是设定在可重复读隔离级别下的。

二、幻读是什么？

       如果只在id=5，这一行加锁，而其他行不加锁的话，会怎么样呢？首先看一下这个场景。

        可以看到session A里面执行了3次查询。分别是Q1、Q2和Q3。它们的sql相同，都是select * from t where d=5 for update;这条语句的意思是查所有d=5的行，而且使用的是当前读。并且加上写锁。接下来看下这三条SQL语句，会返回什么结果？

        1、Q1只返回id=5的这一行；

        2、在T2时刻，sessionB把id=0这一行的d值改成了5，因此T3时刻Q2查出来的是id=0和id=5这两行。

        3、 在T4时刻，sessionC又插入了一行(1,1,5)。因此T5时刻Q3查出来的是id=0、id=1和id=5这三行。

        其中，在T5时刻Q3读到id=1这一行的现象，被称为“幻读”。也就是说幻读指的是一个事务在前后两次查询同一范围的时候，后一次查询看到了前一次查询没有看到的值。

        这里，需要对幻读做一个说明：

        1、mysql在可重复读级别下，普通的查询（select * from t where id=5）是快照读，是不会看到别的事务插入的数据的的， 因此“幻读”在“当前读”下才会出现。

        2、上面sessionB的修改结果，被sessionA之后的select语句用“当前读”看到，不能成为幻读。幻读仅专指“新插入的行”。

三、幻读有什么问题？

       1、首先是语义上的。sessionA在T1时刻就声明了，“我要把所有id=5的行锁住，不准别的事务进行读写操作”。而实际上，这个语义被破坏了。

       2、其次是数据一致性的问题。这个数据不一致到底是怎么引入的？

四、如何解决幻读？

       产生幻读的原因是，行锁只能锁住行，但是新插入记录的这个动作，要更新的是记录之间的“间隙”。因此，为了解决幻读问题，InnoDB只好引入新的锁，也就是间隙锁（Gap Lock）。

       顾名思义，锁的就是两个值之间的空隙。如开头时的表t，初始化插入了6条记录。这就产生了7个间隙。

       当你执行select * from t where d=5 for update的时候，就不止是给数据库中已有的6个记录加上行锁，还同时加上了7个间隙锁。这样就确保无法再插入新记录。 也就是说在一行行的扫描过程中，不仅给行加上了行锁，还给行2边的空隙加上了间隙锁。

       间隙锁和行锁合称next-key lock，每个next-key lock都是前开后闭区间。也就是说，我们的表t初始化之后，如果用select * from t for update  要把整个表所有记录锁起来，就形成了7个next-key lock。分别是(-∞，0]、(0,5]、(5,10]、(10,15]、(15,20]、(20,25]、(25,supremum]。我们把间隙锁标记为开区间，把next-key lock标记为闭区间。

五、间隙锁导致死锁？       

      1、session A执行select ... for update语句，由于id=9这一行并不存在，因此会加上间隙锁(5,10)。

      2、session B执行select ... for update语句，同样会加上间隙锁(5,10)。间隙锁之间不会冲突，因此这个语句可以执行成功。

      3、session B试图插入一行(9,9,9),被session A的间隙锁挡住，只好进入等待状态。

      4、session A试图插入一行(9,9,9,),被session B的间隙锁挡住了。

      此时，两个session进入了相互等待状态，形成了死锁。当然InnoDB的死锁检测机制马上就发现了这对死锁，让sessionA的insert语句报错返回啦。间隙锁的引入，可能导致同样的语句，锁住了更大的范围。这其实是影响了并发度的。

      如果将隔离级别设置为读提交，就没有间隙锁了。一些公司使用读提交+ binlog_format=row的组合。这样配置是否合理呢？配置是否合理，跟业务场景有关，需要具体问题具体分析。比如说，如果大家都用读提交，可是逻辑备份的时候，mysqldump要把备份线程设置为可重复读。然后，在备份期间，备份线程用的是可重复读，而业务线程用的是读提交。同时存在两种事务隔离级别，会不会有问题呢？

六、注释

    1、两阶段锁协议：

    先举个例子，在下面的操作序列中，事务B的update语句执行时会是什么现象呢？假设字段id是表t的主键。根间隙锁存在冲突关系的，是“往这个间隙中插入1个记录”这个操作，间隙锁之间都不存在冲突关系。

       这个问题的结论取决于事务A在执行完两条update语句后，持有哪些锁，以及在什么时候释放。可以验证一下，实际上事务B的update语句会被阻塞，知道事务A执行Commit之后，事务B才能执行。事务A持有的两条记录的行锁，都是在commit的时候才释放的，也就是说，在InnoDB事务中，行锁在需要的时候才加上的，但并不是不需要了就立刻释放，而是要等到事务结束时才释放，这个就是两阶段锁协议。

    2、当前读和快照度：

     ① 快照读（snapshot read）:简单的select语句（不包括select ... lock in share mode（共享锁），select ... for update（排它锁）） 

     ② 当前读（current read） :

  select ... lock in share mode

  select ... for update

  insert

  update 

  delete 

  七、面试回答间隙锁的相关引申

相关知识： 间隙锁——>快照读——>行锁——>共享锁、排他锁——乐观锁、悲观锁。

解决幻读问题？

id d

1 1

5 5

10 10

select * from T where 1<=id<=5

对于当前读而言， 1、lock in share mode 2、for update

1、假如只有行锁，锁住的是id=1和id=的这两条。间隙锁的存在导致不能插入 id值为2,3,4的记录。

2、从乐观锁、悲观锁的角度而言，lock in share mode for update 都是悲观锁。乐观锁、悲观锁仅仅是一个概念。刚刚说的是mysql层面的乐观锁、悲观锁。也可以扩展到java层面的乐观锁、悲观锁。比如synchronized和CAS（compareandswap）

从另一个角度而言，lock in share mode叫作共享锁，也叫做读锁。for update 叫作排他锁。

InnoDB可重复读隔离级别下如何避免幻读

1.当前读和快照读

• 快照读: 最简单的select操作,属于快照读,不加锁

  select * from table where id = 1;
  

• 当前读: 特殊的读与增删改操作,属于当前读,会读取数据库原本的数据,加锁

select * from table where xxx lock in share mode; (共享锁)
select * from table where xxx for update;
insert into table values()
update table set xxx where xxx
delete form table where xxx

2. 四种隔离级别(由低到高)

Read Uncommitted读未提交：可以看到其它事务未提交的内容；

Read Commited读已提交：可以看到其它事务已提交的内容；

Repeatable Read可重复读：事务开始时和事务结束时读到的数据完全相同；

Serializable串行：事务必须逐步执行，后来的会排队。

3.隔离级别下的问题

前提条件：同时开启A和B两个事务；

脏读：

事务查询id为1的数据，num字段为1
B事务将id为1的数据num更新为2，但未commit
事务查询id为1的数据，num字段变为2
B回滚，则A读到的数据为脏数据

不可重复读：

事务查询id为1的数据，num字段为1
B事务将id为1的数据num更新为2，commit
事务查询id为1的数据，num字段变为2
A事务前后两次读到的同一条记录num字段不同，不可重复读

幻读：

A事务查询id >=1 and id <=3的数据，得到id=1和id=3两条数据（注意：没有id=2的数据）
B事务插入id=2的数据
A事务再查询id >=1 and id <=3的数据，发现多了一条id=2的数据，即两次查询数据的行数不同

各种隔离模式下会出现的问题

读未提交：脏读、不可重复读、幻读；

读已提交：不可重复读、幻读；

可重复读：幻读；

4.next-key

4.1 间隙锁(gap-key)

在一个事务中select for update查询某条记录，会锁定该条记录的前后空行，什么叫空行呢，看个例子就知道了

id num
1 2
2 4
3 6
4 7
执行select * from table where num = 4 for update

insert into table (’’, 3)和insert into table (’’, 5)都会被阻塞，即4前后的空行都无法插入

4.2 next-key

由于gay-key只能锁定记录之间的间隙，但是我们上面查询num=4的行也不能被更改，索引该行也会被加行锁，此时这种既能加行锁，又能加间隙锁的，称之为next-key。

5. MVCC

事务A：查询num>=2 and num<=4的记录，但是不加for update！不加for update！不加for update！
事务B：insert into table (’’, 3)，不会被阻塞，不会被阻塞，不会被阻塞！然后commit
事务A：查询num>=2 and num<=4的记录，和之前查询相同
事务A：提交
事务A：查询num>=2 and num<=4的记录，可以查询到num=3的记录，此时返回3条结果
原理：假如事务A在开启的时候版本号为2，当更改或者插入数据后，该条记录的版本号+1，也就是说事务B插入num=3的记录的版本号为3，事务A在提交前的所有select都只能查询到版本号<=2的记录，也就是说不会产生上面说的幻读。

6.总结

MVCC和next-key

其实，innodb采用next-key + MVCC去解决幻读问题的：

在查询加for update时，会用next-key解决幻读问题，新的insert和update会阻塞
在查询不加for update时，会用MVCC解决幻读问题，新的insert和update不会阻塞