多版本并发控制MVCC

大多数MySQL的事务性存储引擎，例如InnoDB. Falcon 和PBXT，不是简单地使用行加锁的机制，而是选用一种叫做**多版本并发控制(MVCC， Mutiversion Concurrency Control)**的技术，和行加锁机制关联使用，以应对更多的并发处理问题。MVCC不是MySQL独有的技术，Oracle， PostgreSQL 及其他一些数据库 系统也使用同样的技术。

可以将MVCC设想成一种行级加锁的变形，它避免了很多情况下的加锁操作，大大降低了系统开销。依赖于具体技术实现，它可以在读取期间锁定需要的记录的同时，还允许非锁定读取。

MVCC是通过及时保存在某些时刻的数据快照，而得以实现的。这意味着同一事务的多个实例，在同时运行时，无论每个实例运行多久，它们看到的数据视图是一致的；而同一时间，对于同一张表，不同事务看到的数据却是不同的!如果用户之前对此没有概念，这可能让人有点迷惑，但随若熟悉程度的加深，这个概念也很容易理解。

每种存储引擎实现MVCC的方式是不同的。例如乐观并发控制(Optimistic Concurrency Control).悲观并发控制(Pessimistic Concurrency Control).下面通过描述InnoDB简化版的行为方式，举例说明MVCC的工作原理。

InnoDB通过为每个数据行增加两个隐含值的方式来实现MVCC.这两个隐含值记录了行的创建时间，以及它的过期时间(或者叫删除时间)。每一行都存储了事件发生时的系统版本号(System Version Number)，用来替代事件发生时的实际时阀。每一次，开始个新事务时， 版本号都会自 动递增。每个事务都会保存它在开始时的“当前系统版本”的记录，而每个查询都会根据事务的版本号，检查每行数据的版本号。下面看一下，当事务隔离级设置为REPEATABLE READ时，MVCC在实际操作中的应用方式:

SELECT

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

• InnDB只查找版本早于当前事务版本的数据行(也就是数据行的版本必须小于等于事务的版本)，这确保了当前事务读取的行都是在事务开始前已经存在的，或者是由当前事务创建或修改的行。

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

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

INSERT

​ InnoDB为每个新增行记录当前系统版本号。

DELETE

​ InnoDB为，删除行记录当前系统版本号，作为行删除标识。

UPDATE

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

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

MVCC只工作在REPEATABLE READ和READ COMMITTED两个隔离级。READ UNCOMMITTED隔离级不兼容MVCC，

因为在任何情况下，该隔离级下的查询，不读取符合当前事务版本的数据行，而读取最新版本的数据行。SERIALIZABLE隔离级也不兼容MVCC，因为该级下的读操作会对每一个返回行都进行加锁。表1-2汇总了MySQL中的各种加锁模型和并发级别。

表1-2:使用默认隔离级的MySQL锁定模型和并发性

加锁策略	并发	系统开销	引擎
表级加锁	最低	最低	MyISAM,Merge,Memory
行级加锁	高	高	NDB Cluster
支持MVCC的行级加锁	最高	最高	InnoDB、Falcon、PBXT、solidDB