MySQL的MVCC

基本概念

Multi-Version Concurrency Control 多版本并发控制，MVCC 是一种并发控制的方法，一般在数据库管理系统中，实现对数据库的并发访问；在编程语言中实现事务内存。（与MVCC相对的，是基于锁的并发控制，Lock-Based Concurrency Control）

目前支持 MVCC 的数据库，包括 DB2、Oracle、Sybase、SQL Server、MySQL、PG 等所有主流数据库，以及 HBase、Couchbase、Berkeley DB 等 NoSQL 数据库。

大多数的MySQL事务型存储引擎，如InnoDB，Falcon以及PBXT都在使用一种简单的行锁机制。事实上，他们都和另外一种用来增加并发性的被称为"多版本并发控制（MVCC）"的机制来一起使用。MVCC不只使用在MySQL中，Oracle、PostgreSQL，以及其他一些数据库系统也同样使用它。

不再单纯的使用行锁来进行数据库的并发控制，取而代之的是把数据库的行锁与行的多个版本结合起来，只需要很小的开销，就可以实现非锁定读，从而大大提高数据库系统的并发性能。

你可将MVCC看成行级别锁的一种妥协，它在许多情况下避免了使用锁，同时可以提供更小的开销。根据实现的不同，它可以允许非阻塞式读，在写操作进行时只锁定必要的记录。

原理

MVCC会保存某个时间点上的数据快照。这意味着事务可以看到一个一致的数据视图，不管他们需要跑多久。这同时也意味着不同的事务在同一个时间点看到的同一个表的数据可能是不同的。

通过使用MVCC（Multi-Version Concurrency Control）算法自动提供并发控制。MVCC维持一个数据的多个版本使读写操作没有冲突。

如果有人从数据库中读数据的同时，有另外的人写入数据，有可能读数据的人会看到『半写』或者不一致的数据。有很多种方法来解决这个问题，叫做并发控制方法。最简单的方法，通过加锁，让所有的读者等待写者工作完成，但是这样效率会很差。MVCC 使用了一种不同的手段，每个连接到数据库的读者，在某个瞬间看到的是数据库的一个快照，写者写操作造成的变化在写操作完成之前（或者数据库事务提交之前）对于其他的读者来说是不可见的。

当一个 MVCC数据库需要更一个一条数据记录的时候，它不会直接用新数据覆盖旧数据，而是将旧数据标记为过时（obsolete）并在别处增加新版本的数据。这样就会有存储多个版本的数据，但是只有一个是最新的。这种方式允许读者读取在他读之前已经存在的数据，即使这些在读的过程中半路被别人修改、删除了，也对先前正在读的用户没有影响。这种多版本的方式避免了填充删除操作在内存和磁盘存储结构造成的空洞的开销，但是需要系统周期性整理（sweep through）以真实删除老的、过时的数据。对于面向文档的数据库（Document-oriented database，也即半结构化数据库）来说，这种方式允许系统将整个文档写到磁盘的一块连续区域上，当需要更新的时候，直接重写一个版本，而不是对文档的某些比特位、分片切除，或者维护一个链式的、非连续的数据库结构。

MVCC 提供了时点（point in time）一致性视图。MVCC 并发控制下的读事务一般使用时间戳或者事务 ID去标记当前读的数据库的状态（版本），读取这个版本的数据。读、写事务相互隔离，不需要加锁。读写并存的时候，写操作会根据目前数据库的状态，创建一个新版本，并发的读则依旧访问旧版本的数据。

一句话讲，MVCC就是用 同一份数据临时保留多版本的方式 的方式，实现并发控制。
这里留意到 MVCC 关键的两个点：

• 在读写并发的过程中如何实现多版本；
• 在读写并发之后，如何实现旧版本的删除（毕竟很多时候只需要一份最新版的数据就够了）；

InnoDB中MVCC的使用

各个存储引擎对于MVCC的实现各不相同。这些不同中的一些包括乐观和悲观并发控制。我们将通过一个简化的InnoDB版本的行为来展示MVCC工作的一个侧面。

InnoDB：通过为每一行记录添加两个额外的隐藏的值来实现MVCC，这两个值一个记录这行数据何时被创建，另外一个记录这行数据何时过期（或者被删除）。但是InnoDB并不存储这些事件发生时的实际时间，相反它只存储这些事件发生时的系统版本号。这是一个随着事务的创建而不断增长的数字。每个事务在事务开始时会记录它自己的系统版本号。每个查询必须去检查每行数据的版本号与事务的版本号是否相同。让我们来看看当隔离级别是REPEATABLE READ时这种策略是如何应用到特定的操作的：

SELECT InnoDB必须每行数据来保证它符合两个条件：

1. InnoDB必须找到一个行的版本，它至少要和事务的版本一样老(也即它的版本号不大于事务的版本号)。这保证了不管是事务开始之前，或者事务创建时，或者修改了这行数据的时候，这行数据是存在的。
2. 这行数据的删除版本必须是未定义的或者比事务版本要大。这可以保证在事务开始之前这行数据没有被删除。这里的不是真正的删除数据，而是标志出来的删除。真正意义的删除是在commit的时候。

符合这两个条件的行可能会被当作查询结果而返回。

• INSERT：InnoDB为这个新行记录当前的系统版本号。
• DELETE：InnoDB将当前的系统版本号设置为这一行的删除ID。
• UPDATE：InnoDB会写一个这行数据的新拷贝，这个拷贝的版本为当前的系统版本号。它同时也会将这个版本号写到旧行的删除版本里。

说明

• insert操作时"创建时间"=DB_ROW_ID，这时，"删除时间"是未定义的；
• update时，复制新增行的"创建时间"=DB_ROW_ID，删除时间未定义，旧数据行"创建时间"不变，删除时间=该事务的DB_ROW_ID；
• delete操作，相应数据行的"创建时间"不变，删除时间=该事务的DB_ROW_ID；
• select操作对两者都不修改，只读相应的数据

这种额外的记录所带来的结果就是对于大多数查询来说根本就不需要获得一个锁。他们只是简单地以最快的速度来读取数据，确保只选择符合条件的行。这个方案的缺点在于存储引擎必须为每一行存储更多的数据，做更多的检查工作，处理更多的善后操作。

MVCC只工作在REPEATABLE READ和READ COMMITED隔离级别下。READ UNCOMMITED不是MVCC兼容的，因为查询不能找到适合他们事务版本的行版本；它们每次都只能读到最新的版本。SERIABLABLE也不与MVCC兼容，因为读操作会锁定他们返回的每一行数据  。

实现

MVCC 使用时间戳（TS）、递增的事务 ID（T）实现事务一致性。

MVCC 通过维护多版本数据，保证一个读事务永远不会被阻塞。对象 P 维护有多个版本，每个版本会有一个读时间戳（Read TimeStamp, RTS）和 写时间戳（Write TimeStamp, WTS），事务 Ti 读对象 P 的最新版本，该版本早于事务 Ti 的读时间戳 RTS(Ti)。

事务 Ti 要对 P 执行写操作，如果有其他事务 Tk 同时对 P 操作，则 RTS(Ti）必须要早于 RTS(Tk)，即有 RTS(Ti) < RTS(Tk)，这样对 Ti 对 P 的写操作才能完成。一般地，如果其他事务拥有 P 的一个更早的读时间戳的情况下，写操作是不能完成的。打个比方就是在存储前面有一道线，只有等你前面的人的完成了他们的事务，你的修改事务才可以提交完成。

重复说一下：每个对象 P 有一个时间戳 TS，如果事务 Ti 想要对 P 执行写操作，（写要先读）事务的读时间戳是 RTS(Ti)，如果有其他事务拥有一个比较早的时间戳，有 TS(P) < RTS(Ti)，这时事务 Ti 会退出并重新开始。否则，事务 Ti 创建一个 P 的新版本，并设置新版本 P 的时间戳，似的 TS = TS(Ti)。

MVCC 系统明显的缺点是会存储多个版本数据的冗余开销。但同时，读操作永不会被阻塞，这对那些以读操作为主的数据库来说非常重要。MVCC 实现了真的快照隔离（snapshot isolation），然后其他的并发控制方法要么是不完整的快照隔离方式，要么需要较高的性能损耗。

Wikipedia 中的内容有点繁琐，简单地，上面的描述，阐明了在同一数据版本下写操作的限制，已经通过多版本实现快照隔离的优越性。

示例
Time    Object1    Object2
0    "Foo" by T0    "Bar" by T0
1    "Hello" by T1   
Time=1的时候数据库的状态如上：

T0 写 Object1 为 "Foo"，写 Object2 为 "Bar"；之后 T1 写 Object1 为 "Hello"，保留 Object2 为原始值。 Object1 的新值将取代 Time=0 时刻的旧值，并提供给 T1提交之后的发生的所有事务。Object1的版本号为0的旧数据会被 GC 掉。

如果有一个长事务 T2，在 T1之后对 Object1和 Object2 进行读操作，同时并行地，有事务 T3 做更新：删除 Object2、增加 Object3="Foo-Bar"，在 Time=2 数据的状态如下所示：

Time    Object1    Object2    Object3
0    "Foo" by T0    "Bar" by T0   
1    "Hello" by T1       
2        (delete)by T3    "Foo-Bar" by T3
在 Time=2 Object2有一个新版本：标记删除，同时增加了新对象 Object3 。T2 和 T3 并发执行，T2 看到的是数据在 Time=2 且 T3提交前的版本，这样 T2读到了 Object2="Bar""且Object1="Hello"。

以上就是 MVCC 在不加锁的情况下实现的快照隔离的读的原理。

历史

最早于1978年，论文『Naming and Synchronization in a Decentralized Computer System』清晰地介绍了 MVCC，这是公认关于 MVCC 最早的工作。

在1981年，论文『Concurrency Control in Distributed Database System』介绍MVCC的一些细节。

扩展

事务的四个特点：ACID

事务的隔离级别：REPEATABLE READ，READ COMMITED，READ UNCOMMITED，SERIABLABLE

数据库的锁：表锁，行锁，乐观锁，悲观锁，GAP锁

多版本并发控制的实现：用java写一个小例子出来

数据库的隐藏列：mysql的版本列，oracle的row_id

真实的MVCC是什么样的，现在是锁和MVCC结合使用，那么能不能不要锁，只是用MVCC呢？

undo log和redo log？以及数据库中CRUD的执行过程

参考

1. https://www.cnblogs.com/YFYkuner/p/5178684.html
2. https://baike.baidu.com/item/MVCC/6298019
3. https://www.cnblogs.com/chenpingzhao/p/5065316.html