MySQL 架构 - 多版本并发控制

核心提示：多版本并发控制Multiversion Concurrency Control大部分的MySQL的存储引擎，比如InnoDB，MySQL 架构 - 多版本并发控制，Falcon，以及PBXT并不是简简单单的使用行锁机制，可序列化不能使用MVCC的原因是，它总是要锁定行，它们都使用了行锁结合一种提高并发的技术，被称为MV

多版本并发控制

Multiversion Concurrency Control

大部分的MySQL的存储引擎，比如InnoDB，Falcon，以及PBXT并不是简简单单的使用行锁机制。它们都使用了行锁结合一种提高并发的技术，被称为MVCC（多版本并发控制）。MVCC并不单单应用在MySQL中，其他的数据库如Oracle,PostgreSQL,以及其他数据库也使用这个技术。

MVCC避免了许多需要加锁的情形以及降低消耗。这取决于它实现的方式，它允许非阻塞读取，在写的操作的时候阻塞必要的记录。

MVCC保存了某一时刻数据的一个快照。意思就是无论事物运行了多久，它们都能看到一致的数据。也就是说在相同的时间下，不同的事物看相同表的数据是不同的。如果你从来没有这方面的经验，可能说这些有点令人困惑。但是在以后这个会很容易理解和熟悉的。

每个存储引擎实现MVCC方式都是不同的。有许多种包含了乐观（optimistic）和悲观（pessimistic）的并发控制。我们用简单的InnoDb的行为来举例说明MVCC工作方式。

InnoDB实现MVCC的方法是，它存储了每一行的两个额外的隐藏字段，这两个隐藏字段分别记录了行的创建的时间和删除的时间。在每个事件发生的时候，每行存储版本号，而不是存储事件实际发生的时间。每次事物的开始这个版本号都会增加。自记录时间开始，每个事物都会保存记录的系统版本号。依照事物的版本来检查每行的版本号。在事物隔离级别为可重复读的情况下，来看看怎样应用它。

SELECT

InnoDB检查每行，要确定它符合两个标准。

InnoDB必须知道行的版本号，这个行的版本号至少要和事物版本号一样的老。（也就是是说它的版本号可能少于或者和事物版本号相同）。这个既能确定事物开始之前行是存在的，也能确定事物创建或修改了这行。

行的删除操作的版本一定是未定义的或者大于事物的版本号。确定了事物开始之前，行没有被删除。

符合了以上两点。会返回查询结果。

INSERT

InnoDB记录了当前新增行的系统版本号。

DELETE

InnoDB记录的删除行的系统版本号作为行的删除ID。

UPDATE

InnoDB复制了一行。这个新行的版本号使用了系统版本号。它也把系统版本号作为了删除行的版本。

所有其他记录的结果保存是，从未获得锁的查询。这样它们查询的数据就会尽可能的快。要确定查询行要遵循这些标准。缺点是存储引擎要为每一行存储更多的数据，检查行的时候要做更多的处理以及其他内部的一些操作。

MVCC只能在可重复读和可提交读的隔离级别下生效。不可提交读不能使用它的原因是不能读取符合事物版本的行版本。它们总是读取最新的行版本。可序列化不能使用MVCC的原因是，它总是要锁定行。

下面的表说明了在MySQL中不同锁的模式以及并发级别。

锁的策略	并发性	开销	引擎
表	最低	最低	MyISAM,Merge,Memory
行	高	高	NDB Cluster
行和MVCC	最高	最高	InnoDB,Falcon,PBXT,solidDB