作者：京东批发 李泽阳
最近在浏览《认知沉睡》这本书，外面有句话十分感动我：通过本人的语言，用最简略的话把一件事件讲清楚，最好让外行人也能听懂。
兴许这就是大道至简，只是咱们习惯了繁缛和简单。
心愿借助明天这篇文章，能用大白话说分明这个绝对比拟底层和简单的 MVCC 机制。
在开始之前，先抛出一个问题：咱们都晓得，目前（MySQL 5.6 以上）数据库已广泛应用 InnoDB 存储引擎，InnoDB 绝对于 MyISAM 存储引擎其中一个益处就是在数据库级别锁和表级别锁的根底上反对了行锁，还有就是反对事务，保障一组数据库操作要么胜利，要么失败。基于此，问题来了，在 InnoDB 默认隔离级别（可反复读）下，一个事务想要更新一行数据，如果刚好有另外一个事务领有这个行锁，那么这个事务就会进入期待状态。既然进入期待状态，那么等到这个事务获取到行锁要更新数据的时候，它读取到的值是什么呢？
具体的问题见下图，咱们设定有一张表 user，初始化语句如下，试想在这样的场景下，事务 A 三次查问的值别离是什么？
create table `user` (
`id` bigint not null,
`name` varchar(50) default null,
PROMARY KEY (`id`)
) ENGINE = InnoDB;
insert into user(id,name) values (1,'A');
想要把这件事件答复正确，咱们先来铺垫一下基础知识。
提到事务，首先会想到的就是 ACID（Atomic 原子性、Consist 一致性、Isolate 隔离性、Durable 持久性），明天咱们次要关注隔离性，当有多个事务同时执行产生并发时，数据库可能会呈现脏读、不可反复读和幻读等问题，为了解决这些问题，“隔离级别”这位大哥上场，蕴含：读未提交、读已提交、可反复读和串行。
但咱们都晓得，隔离级别越高，执行效率越低。毕竟大哥就是大哥，级别越高，越审慎，常在河边走哪能不湿鞋。
咱们通过一个例子简略说一下这四种隔离级别：
• 读未提交：一个事务还未提交，它的变更就能被其余事务看到。V1 为 B，V2 为 B，V3 为 B。
• 读已提交：一个事务提交之后，变更后果对其余事务可见。V1 为 A，V2 和 V3 为 B。
• 可反复读：一个事务执行过程中看到的数据与事务启动时统一。V1 为 A，V2 为 A，V3 为 B。
• 串行：不论读和写，加锁就完了，就是干！V1 和 V2 均为 A，V3 为 B。
事务是怎么实现的呢？实际上，事务执行时，数据库会创立一个视图，读未提交间接返回最新值，没有视图概念；串行是间接加锁防止并发拜访；读已提交是在每个 SQL 语句开始执行时创立的视图。可反复读的视图是在事务启动的时候创立的，整个事务都会应用这个视图。这样的话，下面四种不同隔离级别下的 V1、V2、V3 值便对号入座，有了后果。
**MySQL 是怎么实现的呢？** 咱们以 MySQL 默认的可反复读隔离级别为例，实际上每条行记录在更新时都会记录一条回滚日志，也就是大家常说的 undo log。通过回滚操作，都能够失去前一个状态的值。假如 name 值从初始值 A 被顺次更新为 B、C、D，咱们看一下回滚日志：
以后值是 D，然而在查问这条记录的时候，不同时刻启动的事务会有不同的视图，看到的值也就不一样。在视图 1、2、3、4 外面，记录的 name 值别离是 A、B、C、D。同一条行记录在数据库中能够存在多个版本，这就是多版本并发管制（MVCC）。对于视图 1，如果想要将 name 值回到 A，那么就要顺次执行图中所有回滚操作。
到这里，你曾经接触到了 MVCC 的概念，兴许你曾经对文章最开始的问题有了一点点想法，别着急，咱们先来简略总结下 MVCC 的特点：
MVCC 的呈现使得一条行记录在不同隔离级别下不同的事务操作会造成一条不同版本的链路，从而实现在不加锁的前提下使不同事务的读写操作可能并发平安执行，这个版本链就是通过回滚日志 undo log 实现的。用大白话说，你这个事务想要查问一条行记录，MVCC 会通过你这个事务所在视图确认版本链中哪个版本的行数据对你可见。方才咱们提到，四种隔离级别下，只有 读已提交 和可反复读 会用到视图。对于读已提交，MVCC 会在每次查问前都会生成一个视图，可反复读隔离级别只会在第一次查问时生成一个视图，之后在这个事务中的所有查问操作都会重复使用这个视图。行业上，将创立视图的那一刻称为快照，晃你一下子，让你激灵激灵，别产生脏读，变脏喽～
想要解决文章最开始的那个问题，咱们还得开展说说版本链是如何造成的和快照的原理，稍有干燥，先忍一下，急躁看上来，乖～
对于 InnoDB 存储引擎来说，主键索引（也称为聚簇索引）记录中除了失常的字段数据外，还蕴含两个暗藏列：
（1）trx\_id：每次一个事务想要对主键索引进行更新、删除和新增时，都会把这个事务的事务 id 赋值给 trx\_id 字段。留神事务 id 严格递增，且查问操作不会调配事务 id，即 trx_id = 0;
（2）roll\_point：每次一个事务对主键索引进行更新时，都会把旧的版本写入到 undo 日志中，roll\_point 相当于一个指针，通过它能够找到这条记录批改前的信息。
咱们以可反复读隔离级别为例，为了尚未提交的更新后果对其余事务不可见，InnoDB 在创立视图时，有以下四局部组成：
• m_ids：示意生成视图时，以后零碎中“沉闷”的读写事务的事务 id 列表，这里的沉闷大白话就是事务尚未提交；
• min\_trx\_id：示意在生成视图时，以后零碎中沉闷的读写事务中最小的事务 id，即 m_ids 中的最小值；
• max\_trx\_id：示意生成视图时零碎应该调配给下一个事务的 id 值；
• creator\_trx\_id：示意生成该视图的事务 id。
概念比拟多，举个例子，当初有事务 id 别离是 1、2、3 三个事务，1 和 2 事务尚未提交，3 事务已提交，这个时候如果来了一个新事务，那么它创立的视图对应这几个参数别离为：m\_ids 蕴含 1、2，min\_trx\_id 为 1，max\_trx_id 为 4。
要害的知识点来了，如何依据某个事务生成的视图，判断版本链上的某个版本对这个事务可见呢？
遵循上面步骤：
1、版本链上的不同版本 trx\_id 值如果与这个视图的 creator\_trx_id 值雷同，阐明以后事务在拜访它本人批改过的记录，所以被拜访的版本对以后事务可见。一家人还是意识一家人的～
2、版本链上的不同版本 trx\_id 值小于这个视图的 min\_trx_id 值，阐明这个版本的事务在以后事务生成视图之前就曾经提交了，所以被拜访的版本对以后事务可见。
3、版本链上的不同版本的 trx\_id 值大于或等于这个视图的 max\_trx_id 值，阐明这个版本的事务在以后事务之后才开启，所以被拜访版本对以后事务不可见。
4、版本链上的不同版本的 trx\_id 值在这个视图的 min\_trx\_id 和 max\_trx\_id 之间，须要进一步判断被拜访版本 trx\_id 值是不是在 m_ids 中，如果在，阐明以后事务是沉闷的，被拜访版本对以后事务不可见。如果不在，阐明被拜访版本的事务曾经提交了，被拜访版本对以后事务可见。
比拟绕是不是，千万别晕，兄弟呀～，大白话解释一下，设定某个事务生成的视图霎时（也就是快照），这个事务的 id 为 creator\_trx\_id，那么有上面三种可能：
1、如果 creator\_trx\_id 落在绿色局部，示意被拜访的版本是已提交的事务或者就是以后事务本人生成的，这个数据是可见的；
2、如果 creator\_trx\_id 落在红色局部，示意被拜访的版本还未开启，数据不可见；
3、如果 creator\_trx\_id 落在黄色局部，包含两种状况：
若 creator\_trx\_id 在 m_ids 汇合中，示意被拜访的版本尚未提交，数据不可见；
若 creator\_trx\_id 不在 m_ids 汇合中，示意被拜访的版本曾经曾经提交了，数据可见。
晓得了这个之后，咱们就能够答复文章最开始那个问题了，在隔离级别为可反复读的状况下（这里的隐含条件就是 可反复读隔离级别只会在第一次查问时生成一个视图，之后在这个事务中的所有查问操作都会重复使用这个视图）剖析一波：
以文章结尾的例子，设定事务 B 的事务 id=100，事务 C 的事务 id=200，当事务 B 尚未提交时，id= 1 这条记录的版本链是这样的：
这个时候咱们看一下事务 A 第一个 select 语句，留神查问操作的事务 trx\_id=0，在执行 select 语句时会创立一个视图，这个视图的 m\_ids={100}，min\_trx\_id=100，max\_trx\_id=101，creator\_trx\_id=0。
而后在版本链中筛选可见的数据记录，从图中能够看到最新版本的 name 值是 B，最新版本的 trx\_id 值为 100，在 m\_ids 汇合中，这个版本数据不可见，依据 roll_point 跳到下一个版本；
下一个版本的 name 值是 A，这个版本的 trx\_id=99，小于 min\_trx_id，这个版本数据是可见的，所以返回 name 为 A 的记录，即 V1 为 A。
咱们持续，事务 B 这时进行了 commit 提交，此时事务 C 曾经开启，那么事务 A 第二个 select 语句不会创立一个新的视图，而是从新利用第一次创立的视图。最新版本的 trx\_id 为 100，在 m\_ids 中，数据不可见，即 V2=A；
接下来，事务 C 进行了更新操作，此时版本链产生的扭转如下：
事务 C 接着进行了 commit 提交，此时事务 A 第三次 select 语句也不会创立一个新的视图，最新版本的 trx\_id 为 200，大于 max\_trx_id，数据不可见，即 V3=A。
到这里，MVCC 就完结啦，留一个小问题，如果是读已提交隔离级别，那么文章结尾的例子中 V1、V2、V3 的值又别离是什么呢？答案在最初哦。
最初，咱们再来总结一下 MVCC 的作用，应用可反复读隔离级别的事务在查问时，仅会应用第一次 select 时生成的视图，相比于读已提交隔离级别每次查问都会生成一个新的视图，可反复读在查问时应用的视图版本不会那么新，因而有些曾经提交的事务对行记录进行批改时对查问事务就不可见，进而防止了不可反复读景象的产生，同时也防止了脏读。
小问题答案：
读已提交隔离级别下，每次 select 查问都会生成一个新的视图，基于此，剖析如下：
事务 A 第一个 select 语句，留神查问操作的事务 trx\_id=0，在执行 select 语句时会创立一个视图，这个视图的 m\_ids={100}，min\_trx\_id=100，max\_trx\_id=101，creator\_trx\_id=0。
而后在版本链中筛选可见的数据记录，从图中能够看到最新版本的 name 值时 B，最新版本的 trx\_id 值为 100，在 m\_ids 汇合中，这个版本数据不可见，依据 roll_point 跳到下一个版本；
下一个版本的 name 值是 A，这个版本的 trx\_id=99，小于 min\_trx_id，这个版本数据是可见的，所以返回 name 为 A 的记录，即 V1 为 A。
事务 B 这时进行了 commit 提交，此时事务 C 曾经开启，那么事务 A 第二个 select 语句会创立一个新的视图，这个视图的 m\_ids={200}，min\_trx\_id=200,max\_trx\_id=201,creator\_trx\_id=0。版本链没有发生变化，最新版本 trx\_id 值为 100，小于 min\_trx\_id，数据可见，即 V2=B；
事务 C 接着进行了 commit 提交，此时事务 A 第三次 select 语句会创立一个新的视图，这个视图的 m\_ids={},min\_trx\_id 不存在，max\_trx\_id=201,creator\_trx\_id=0。在版本链中筛选可见的数据记录，从图中能够看到最新版本的 name 值为 C，最新版本的 trx\_id 值为 200，小于 max\_trx\_id 且不在 m_ids 中，则数据可见，即 V3=C。