MySQL——多版本并发控制

核心心知识点：

（1）MVCC的优点和缺点

（2）MVCC的工作机制

之前在提及幻读的时候，提到过InnoDB的多版本并发控制可以解决幻读问题。

大多数MySQL的事务性存储引擎，例如InnoDB、Falcon和PBXT，不是简单地使用行加锁的机制，

而是选用一种叫做多版本并发控制（MVCC，Multiversion Concurrency Control）的技术，和行加锁机制关联使用，以应对更多的并发处理问题。

MVCC不是MySQL独有的技术，Oracle、PostgreSQL及其他一些数据库系统也使用同样的技术。

可以将MVCC设想成一种行级加锁的变形，它避免了很多情况下的加锁操作，大大降低了系统开销。

依赖于具体技术实现，它可以在读取期间锁定需要的记录的同时，还允许非锁定读取。

MVCC是通过及时保存在某些时刻的数据快照而得以实现的。这意味着同一事务的多个实例，在同时运行时，无论每个实例运行多久，它们看到的数据视图是一致的。而同一时间，对于同一张表，不同事务看到的数据却是不同的。

每种存储引擎实现MCVV的方式是不同的，例如乐观并发控制，悲观并发控制。

下面通过描述InnDB简化版的行为方式，举例说明MVCC的工作原理。

InnoDB通过为每个数据行增加两个隐含值的方式来实现MVCC，这两个隐含值记录了行的创建时间，以及它的过期时间（或者叫删除时间），

每一行都存储了事件发生时的系统版本号，用来替代事件发生时的实际事件。关于系统版本号长啥样我们不用去追求，可以看作行数据的唯一标识符。

每一次，开始一个新事务时，版本号都会自动递增。每个事务都会保存它在开始时的“当前系统版本”的记录，而每个查询都会根据事务的版本号，检查每行数据的版本号。

下面看一下，当事务隔离级别设置为REPEATABLE READ（可重复度）时，MVCC在实际操作中的应用方式：

SELECT：

InnoDB检查每行数据，确保它们符合两个标准：

（1）InnoDB只查找版本早于当前事务版本的数据行（也就是数据行的版本必须小于等于事务的版本），

　　这确保了当前事务读取的行都是在事务开始前已经存在的，或者是由当前事务创建或修改的行。

（2）数据行的删除本必须是未定义的，或是大于事务版本的，这保证了事务读取的行，在事务开始是未被删除的。

只有通过上述两项测试的数据行，才会被当做查询结果返回。

INSERT：

InnoDB为每个新增行记录当前系统版本号，行的更新版本被修改为该事务的事务号。

DELETE：（标记删除）

InnoDB直接把该行的被删除版本号设置为当前事务号，相当于标记为删除，而不是实际删除。

UPDATE：

InnoDB会为每个需要更新的行，建立一个新的行拷贝，记录当前的系统版本号，同时，也为更新前的旧行，记录系统的版本号，作为旧行的删除版本标识。

保存这些额外记录的好处是使大多数读操作都不必申请加锁，这使都操作变得尽可能的块，因为读操作只要选取符合标准的行数据即可。这种方式的缺点是，存储引擎必须为每行数据存储更多的额外数据，做更多的行检查工作，以及处理一些额外的整理操作。

MVCC只工作在REPEATABLE READ和READ COMMITTED两个隔离级别。

READ UNCOMMITTED隔离级别不兼容MVCC，因为在任何情况下，该隔离级别下的查询，不读取符合当前事务版本的数据行，而读取最新版本的数据行，

SERIALIZABLE隔离级别也不兼容MVCC，因为该级下的读操作会对每一个返回行都进行加锁。