MVCC(Multiversion Concurrency Control)多版本并发控制

MVCC是MySQL中的一种隔离技术，提高并发能力，也可以说是一种行级锁的变种，在MySQL的学习使用中是需要关注的地方。这篇文章出自《高性能MySQL（第3版）》。

一、MVCC概述

MySQL的大多数事务型存储引擎实现的都不是简单的行级锁。基于提升并发性能的考虑，它们一般都同时实现了多版本并发控制MVCC（Multiversion Concurrency Control）。不仅是MySQL，包括Oracle、PostgreSQL等其他数据库系统也都实现了MVCC，但各自的实现机制不尽相同，因为MVCC没有一个统一的实现标准。
　　可以认为MVCC是行级锁的一个变种，但是它在很多情况下避免了加锁操作，因此开销更低。虽然实现机制有所不同，但大都实现了非阻塞的读操作，写操作也只锁定必要的行。

二、MVCC的实现

MVCC的实现，是通过保存数据在某个时间点的快照来实现的。也就是说，不管需要执行多长时间，每个事务看到的数据都是一致的。根据事务开始的时间不同，每个事务对同一张表，同一时刻看到的数据可能是不一样的。如果之前没有这方面的概念，这句话听起来就有点迷惑。熟悉了以后会发现，这句话其实还是很容易理解的。
　　前面说到不同存储引擎的MVCC实现是不同的，典型的有乐观（optimistic）并发控制和悲观（pessimistic）并发控制。

三、MVCC如何工作

下面我们通过InnoDB的简化版行为来说明MVCC是如何工作的。
　　InnoDB的MVCC，是通过在每行记录后面保存两个隐藏的列来实现的。这两个列，一个保存了行的创建时间，一个保存行的过期时间（或删除时间）。当然存储的并不是实际的时间值，而是系统版本号（system version number）。每开始一个新的事务，系统版本号都会自动递增。事务开始时刻的系统版本号会作为事务的版本号，用来和查询到的每行记录的版本号进行比较。

四、MVCC具体是如何操作

下面看一下在REPEATABLE READ隔离级别下，MVCC具体是如何操作的：
4.1 SELECT
InnoDB会根据以下两个条件检查每行记录：
　　（1）InnoDB只查找版本早于当前事务版本的数据行（也就是，行的系统版本号小于或等于事务的系统版本号），这样可以确保事务读取的行，要么是在事务开始前已经存在的，要么是事务自身插入或者修改过的。
　　（2）行的删除版本要么未定义，要么大于当前事务版本号。这可以确保事务读取到的行，在事务开始之前未被删除。
4.2 INSERT
　　InnoDB为新插入的每一行保存当前系统版本号作为行版本号。
4.3 DELECT
　　InnoDB为删除的每一行保存当前系统版本号作为行删除标识。
4.4 UPDATE
　　InnoDB为插入一行新纪录，保存当前系统版本号作为行版本号，同时保存当前系统版本号到原来的行作为行删除标识。

五、MVCC的优劣

保存这两个额外系统版本号，使大多数读操作都可以不用锁。这样设计使得读数据操作很简单，性能很好，并且也能保证只会读取到符合标准的行。不足之处是每行记录都需要额外的存储空间，需要做更多的行检查工作，以及一些额外的维护工作。
　　MVCC只在REPEATABLE READ和READ COMMITTED两个隔离级别下工作。其他两个隔离级别都和MVCC不兼容（MVCC并没有正式的规范，所以各个存储引擎和数据库系统的实现都是各异的，没有人能说其他的实现方式是错误。），因为READ UNCOMMITTED总是读取最新的数据行，而不是符合当前事务版本的数据行。而SERIALIZABLE则会对所以读取的行都加锁。

六、快照读和当前读

1、快照读(snapshot read)
　　快照读也称为普通读，读取的是快照版本，也就是历史版本。执行方式是生成 ReadView，直接利用 MVCC 机制来进行读取，并不会对记录进行加锁。
　　每次读取操作读到的实际是基于当前可见性生成的快照，快照的实现基于多版本并发控制（MVCC），我们日常使用的不加锁的select就是一种快照读（当事务隔离级别退化为串行时，默认select就是当前读）。
　　快照读是为了解决事务ACID特性中的Isolation隔离性而诞生的，有了快照的存在，会让每个事务只看到自己应该看到，仿佛数据库系统只有当前一个事务在执行一样，正是隔离性的体现。
　　对于SERIALIZABLE隔离级别来说，如果autocommit系统变量被设置为OFF，那普通读的语句会转变为锁定读，和在普通的 SELECT 语句后边加 LOCK IN SHARE MODE 达成的效果一样。

实现原理：
undo log + MVCC
在实际的MySQL的InnoDB存储引擎中，每个行数据会有三个隐藏列（可理解为MVCC的原理）：
（1）DB_TRX_ID
　　该行记录的最近修改过的事务id，就像是文件系统里的最近修改时间一样，是生成ReadView时可见性判断的重要依据
（2）DB_ROLL_PTR
　　回滚指针，如果这个记录被修改过，那么会指向上一个版本，形成了一个历史版本的链表
（3）DB_ROW_ID
　　隐藏主键，当我们的表没有指定主键的时候，这个字段就会作为聚簇索引。

2、当前读(current read)
　　每次都读取记录的最新版本，并且会对记录进行加锁，典型的当前读操作：
（1）select lock in share mode(共享锁)
（2）select for update(排他锁)
（3）update(排他锁)
（4）insert(排他锁)
（5）delete(排他锁)

https://www.jianshu.com/p/35c168eeaa45

3、锁介绍
（1）Record Locks（记录锁）：在索引记录上加锁。
（2）Gap Locks（间隙锁）：在索引记录之间加锁，或者在第一个索引记录之前加锁，或者在最后一个索引记录之后加锁。
（3）Next-Key Locks：在索引记录上加锁，并且在索引记录之前的间隙加锁。它相当于是Record Locks与Gap Locks的一个结合。

假设一个索引包含以下几个值：10,11,13,20。那么这个索引的next-key锁将会覆盖以下区间：
(negative infinity, 10]
(10, 11]
(11, 13]
(13, 20]
(20, positive infinity)

4、总结
　　在RR级别下，快照读是通过MVVC(多版本控制)和undo log来实现的，当前读是通过加record lock(记录锁)和gap lock(间隙锁)来实现的。
　　如果需要实时显示数据，还是需要通过加锁来实现。这个时候会使用next-key技术来实现。
　　
在mysql中，提供了两种事务隔离技术：
　　第一个是mvcc，
　　第二个是next-key技术。
这个在使用不同的语句的时候可以动态选择。
（1）不加lock inshare mode之类的就使用mvcc，否则使用next-key。
（2）mvcc的优势是不加锁，并发性高；缺点是不是实时数据。
（3）next-key的优势是获取实时数据，但是需要加锁。

同时需要注意几点：
　　（1）事务的快照时间点是以第一个select来确认的。所以即便事务先开始。但是select在后面的事务的update之类的语句后进行，那么它是可以获取后面的事务的对应的数据。
　　（2）mysql中数据的存放还是会通过版本记录一系列的历史数据，这样，可以根据版本查找数据。