高端品牌网站建设公司武汉疫情最新动态

MySQL如何解决事务并发的幻读问题

上篇文章我们提到过，MySql的默认存储引擎Innodb是通过MVCC来实现无锁的事务隔离级别的。脏读问题和不可重复读问题我们都可以通过Read View机制很好的解决了，但是幻读问题我简单的使用加临健锁一笔带过了，本文重点讲讲MySql具体是如何解决幻读问题的。

问题定义

MySql官方文档是这么定义幻读的：

The so-called phantom problem occurs within a transaction when the same query produces different sets of rows at different times. For example, if a SELECT is executed twice, but returns a row the second time that was not returned the first time, the row is a “phantom” row.

翻译：所谓的“幻读问题”发生在一个事务内部，当相同的查询在不同时间返回了不同的结果集时就会出现这种情况。例如，如果执行了两次 SELECT 查询，但第二次返回了一条第一次没有返回的记录，那么这条记录就被称为“幻影行”或“幻读行”。

举个例子：

如上图，事务A在第一次查询数量为5，第二次查询数量就为6了。这就是幻读问题。

乍一看，可能我们会觉得这个问题和不可重复读的问题很像，但是我们要清楚不可重复读针对的是同一条记录的前后两次读到的数据不一样，而幻读是前一次读不到这条记录，之后读到了这条记录。我们也可以从锁实现事务隔离级别去区分幻读和不可重复读：在三级封锁协议下，在修改操作的时候我们会加上排他锁（直到事务结束才释放），在读取操作的时候我们会加上共享锁，同样也是直到事务结束才释放，这很好地解决地不可重复读的问题，但是它并不可以解决幻读问题。

如何解决

在Innodb引擎下，默认支持MVCC，所以我们知道读操作有两种读：

1. 快照读（针对普通的select…语句），通过MVCC在事务发起读请求的时候通过Read View读取数据的历史版本快照，而不是去读取当前数据库中实际的数据。
2. 当前读（针对加锁的select…for updata等语句），对于加锁的语句（SELECT FOR UPDATE、SELECT LOCK IN SHARE MODE…），用户每次读的时候都会加上锁（RR级别下是临健锁、RC级别下是行锁），然后去读取数据库中关于该记录的最新数据。

为什么我们说MySql不会使用可串行化隔离级别去避免幻读问题，使用可重复读隔离级别也能很大程度地避免幻读的问题了呢？看下面的分析，都是在可重复读隔离级别下。

快照读如何避免幻读

快照读，使用了MVCC，MVCC机制本身其实已经很好地避免了幻读了。我们知道在快照读下，我们每次地读操作都会结合Read View去undo_log中读取当前记录的合适的历史版本快照，而如果一条记录在事务第一次的时候我们并没有读到，这之后另外一个事务增加了这条记录，那么当前事务再读的时候去undo_log中找，由于可重复读隔离级别使得我们每次读都会读取在当前事务开始之前就提交的事务或者是当前事务中的版本的数据，所以这条新增的记录也并不会被读到。

如上图所示，事务10在第一次查询的时候创建了一个Read View（一致性视图）记录了当前状态下的事务信息，在第二次查询的时候就会结合这个Read View去undo_log中根据具体的规则查询相应版本的记录，由于事务11并不是在事务10开始之前就提交了的事务，所以它对于数据库的操作我们查询不到。

当前读如何避免幻读

在可重复读隔离级别下，在有索引的列上执行select…for update、select…LOCK IN SHARE MODE，并且使用的是范围条件（例如 where amount>1000）,加的锁是临健锁next-key lock(行锁+间隙锁)。

还是上面的例子，如果我们执行了SELECT COUNT(*) FROM orders WHERE amount > 1000 for update; （amount 有索引，这里使用覆盖索引即可完成查询。），InnoDB 会走 amount 的索引，并对满足 amount>1000 的记录加上临键锁。其它事务就无法对这个范围（amount>1000）做任何操作了。

幻读并没有被完全解决

MySQL在可重复读隔离级别下只是很大程度地避免了幻读的问题，但是并没有完全解决。如果使用快照读的话，还是会出现幻读问题的，以下两种情况就还是会出现幻读的问题。

情形一： 如下图所示，事务10第一次查询之后，事务11插入一条id为101的数据，但是事务10又对该条记录执行了更新操作，那么在undo_log中保存的对于id为101记录的最新版本就是事务10更改的了，所以对事务10可见了，然后事务10的下一次查询就会读出该条数据。导致幻读。

情形二：

事务10第一次使用快照读查询出了5条记录，事务11添加了一条记录，事务10第二次查询使用了当前读，这就会查询出了6条记录，导致出现了幻读。

总结

经过这一通分析，我们已经了解了MySQL的innodb引擎到底是怎么避免幻读问题的，在可重复读隔离级别下就能很大程度上地避免了幻读问题了，但是如果想要完全地避免幻读，还是要在第一次读的时候就使用当前读,也就是加上next-key lock，就可以解决幻读问题了。