我所理解的MySQL之四：事务、隔离级别及MVCC

幻读会发生在读未提交、读已提交、可重复读的隔离级别中。

这里需要额外注意的是：幻读和不可重复读都是说在一个事务中的同一个查询语句结果不同，但幻读更侧重于查询到其他事务新插入的数据（insert）或其他事务删除的数据（delete），而不可重复读的范围更广，只要结果不同就可以认为是不可重复读，但一般我们认为不可重复读更侧重于其他事务对数据的更新（update）。

4.4 小结

通过上面的描述，我们已经知道四种隔离级别的概念以及它们分别会遇到的问题，事务的隔离级别越高，隔离性就越强，所遇到的问题也就越少。但同时，隔离级别越高，并发能力就越弱。

下表是对隔离级别的概念不同隔离级别会发生的问题情况的小结：

5. MVCC

MVCC（Multi-Version Concurrency Control）即多版本并发控制，这是 MySQL 为了提高数据库并发性能而实现的。它可以在并发读写数据库时，保证不同事务的读-写操作并发执行，同时也能解决脏读、不可重复读、幻读等事务隔离问题。

在前文讨论幻读的时候提到过当前读的概念，正是由于当前读，才会在可重复读的隔离级别下也会发生幻读的情况。

在解释可重复读隔离级别下发生幻读的原因之前，首先介绍 MVCC 的实现原理。

5.1 MVCC 的实现原理

首先我们需要知道，InnoDB 的数据页中每一行的数据是有隐藏字段的：

每一条修改语句都会相应地记录一条回滚语句（undo log），如果把每一条回滚语句视为一条数据表中的记录，那么通过事务ID和回滚指针就可以将对同一行的修改记录看作一个链表，链表上的每一个节点就是一个快照版本，这就是 MVCC 中多版本的意思。

举个例子，假设对 user 表中唯一的一行「刺猬」进行多次修改。

update user set name='重塑' where id=1;update user set name='木马' where id=1;update user set name='达达' where id=1;复制代码

那么这条记录的版本链就是：

在这个版本链中，头结点就是当前记录的最新版本。DB_TRX_ID 事务ID 字段是非常重要的属性，先 Mark 一下。

除此之外，在读已提交（RC，Read Committed）和可重复读（RR，Repeatable Read）的隔离级别中，事务在启动的时候会创建一个读视图（Read View），用它来记录当前系统的活跃事务信息，通过读视图来进行本事务之间的可见性判断。

在读视图中有两个重要的属性：

需要注意下一个事务I的值，并不是事务ID列表中的最大值+1，而是当前系统中已存在过的事务的最大值+1。例如当前数据库中活跃的事务有(1,2)，此时事务2提交，同时又开启了新事务，在生成的读视图中，下一个事务ID的值为3。

我们通过将版本链与读视图两者结合起来，来进行并发事务间可见性的判断，判断规则如下（假设现在要判断事务A是否可以访问到事务B的修改记录）：

如果事务B对于事务A来说是不可见的，就需要顺着修改记录的版本链，从回滚指针开始往前遍历，直到找到第一个对于事务A来说是可见的事务ID，或者遍历完版本链也未找到（表示这条记录对事务A不可见）。

这就是 MVCC 的实现原理。

5.2 读视图的创建时机

这里需要注意的是读视图的创建时机，在上面的论述中我们已经知道事务在启动时会创建一个读视图（Read View），而开启一个事务有两种方式，一是 begin/start transaction，二是start transaction with consistent snapshot，通过这两种方式开启事务，创建读视图的时机也是不同的：

5.3 MVCC 的运行过程

为了详细说明 MVCC 的运行过程，下面举个例子，假设当前存在有两个事务（事务隔离级别为 MySQL 默认的可重复读）：

这里需要注意的是事务的启动时机，在上面的论述中我们已经知道事务在启动时会创建一个读视图（Read View），而开启一个事务有两种方式，一是 begin/start transaction，二是start transaction with consistent snapshot，通过这两种方式开启事务，创建读视图的时机也是不同的：

然后根据上面所描述的版本链以及两个事务开启时的读视图来分析 MVCC 的运行过程。

上图是两个事务开启时的读视图，而当事务B的更新语句执行之后，id=1行的版本链如下所示。

先来看N1处的查询语句，事务B的当前事务ID=2，其值等于事务A的下一个事务ID，所以按照上文中所论述的可见性判断，事务B对于事务A来说是不可见的，需要循着当前行的版本链网上检索。

于是循着版本链来到DB_TRX_ID=1事务ID=1的历史版本，恰巧等于事务A的事务ID值，也就是事务A开启时该行的版本，此版本对于事务A来说当然是可见的，所以读取到了id=1行的name='刺猬'，即最终N1=刺猬。

再来看N2处的查询语句，此时事务B已提交，版本链还是如上图所示，由于当前版本的事务ID等于事务A读视图中的下一个事务ID，所以当前版本的记录对于事务A来说是不可见的，所以同样N2=刺猬。

这里需要注意的是，若例子中事务A的时刻4语句变更为对该行的更新语句，那么事务A便会等待事务B提交之后再执行更新语句，这是因为事务B未提交，即事务B对于id=1行的写锁未释放，而事务A也要更新该行，必须是更新当前的最新版本（当前读）才可以，所以事务A就被阻塞了，必须等待事务B对该行的写锁释放，才会继续执行更新语句。

5.4 RC 与 RR 生成读视图的时机对比

上面所讨论的 MVCC 运行过程都是针对可重复读（RR, Repeatable Read）隔离级别的，如果是读已提交（RC, Read Committed）级别呢？

上文中已经讨论过读已提交隔离级别中关于不可重复读的情况了，这里就不再举例，直接给出结论就可以了。

对于上文中描述 MVCC 执行过程中的例子，如果隔离级别是读已提交（RC, Read Committed）：

5.5 当前读与快照读

5.6 可重复读发生幻读的原因

在理解了 MVCC 之后，我们再来看在可重复读隔离级别下发生幻读的原因。上文中说到正是由于当前读，才会在可重复读的隔离级别下发生幻读的情况，首先来回顾一下例子。

N1，N2处的查询想必已经十分明确都是「刺猬」了。而在N3处所使用的查询语句是for update，使用它进行查询就会对目标记录添加一把「行级锁」，行级锁的意义以后再说，现在只需要知道for update能够锁住目标记录就可以了。

加锁自然是防止别人修改，那么理所当然，锁住的当然也就是记录的最新版本了。所以，在使用for update进行查询的时候，会使用当前读，读到目标记录的最新版本，所以在N3处的查询语句就会把事务B中本对于事务A来说不可见的记录也查询出来，也就发生了幻读。

使用当前读的语句有：

6. 温故知新

1. 事务的ACID四大特性
2. 自动提交与隐式提交（隐式提交的语句）
3. 事务的隔离级别
4. 事务各个隔离级别可能出现的问题
5. MVCC 的实现原理与过程
6. RC 与 RR 生成读视图的时机

更多相关免费学习推荐：mysql教程(视频)