摘自：高性能MySQL（第四版）

MVCC的作用

InnoDB和XtraDB存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）解决了幻读的问题

MVCC的应用

MySQL的大多数事务型存储引擎使用的都不是简单的行级锁机制。

它们会将行级锁和可以提高并发性能的多版本并发控制（MVCC）技术结合使用。

不仅是MySQL，包括Oracle、PostgreSQL以及其他一些数据库系统也都使用了MVCC，但各自的实现机制不尽相同，因为MVCC如何工作没有统一的标准。

MVCC是什么?

可以认为MVCC是行级锁的一个变种，但是它在很多情况下避免了加锁操作，因此开销更低。根据其实现方式，不仅实现了非阻塞的读操作，写操作也只锁定必要的行。

MVCC工作原理

MVCC的工作原理是使用数据在某个时间点的快照来实现的。这意味着，无论事务运行多长时间，都可以看到数据的一致视图，也意味着不同的事务可以在同一时间看到同一张表中的不同数据！如果你之前没有这方面的概念，这句话听起来可能有点让人迷惑，熟悉了以后你会发现还是很容易理解的。
每个存储引擎实现MVCC的方式都不同。其中一些变体包括乐观并发控制和悲观并发控制

下图是MVCC的一种实现方式的序列图

InnoDB实现MVCC的方式

InnoDB通过为每个事务在启动时分配一个事务ID来实现MVCC。

该ID在事务首次读取任何数据时分配。

在该事务中修改记录时，将向Undo日志写入一条说明如何恢复该更改的Undo记录，并且事务的回滚指针指向该Undo日志记录。

这就是事务如何在需要时执行回滚的方法。

当不同的会话读取聚簇主键索引记录时，InnoDB会将该记录的事务ID与该会话的读取视图进行比较。如果当前状态下的记录不应可见（更改它的事务尚未提交），那么Undo日志记录将被跟踪并应用，直到会话达到一个符合可见条件的事务ID。这个过程可以一直循环到完全删除这一行的Undo记录，然后向读取视图发出这一行不存在的信号。
事务中的记录可以通过在记录的“info flags”中设置“deleted”位来删除。这在Undo日志中也被作为“删除标记”进行跟踪。
值得注意的是，所有Undo日志写入也都会写入Redo日志，因为Undo日志写入是服务器崩溃恢复过程的一部分，并且是事务性的。

这些Redo日志和Undo日志的大小也是高并发事务工作机制中的重要影响因素。
在记录中保留这些额外信息带来的结果是，大多数读取查询都不再需要获取锁。

InnoDB实现MVCC的方式的优缺点

它们只是尽可能快地读取数据，确保仅查询符合条件的行即可。

缺点是存储引擎必须在每一行中存储更多的数据，在检查行时需要做更多的工作，并处理一些额外的内部操作。

MVCC的适用场景

MVCC仅适用于REPEATABLE READ和READ COMMITTED隔离级别。

READ UNCOMMITTED与MVCC不兼容，是因为查询不会读取适合其事务版本的行版本，而是不管怎样都读最新版本。

SERIALIZABLE与MVCC也不兼容，是因为读取会锁定它们返回的每一行。