作者：京东批发 李泽阳
最近在浏览《认知沉睡》这本书，外面有句话十分感动我：通过本人的语言，用最简略的话把一件事件讲清楚，最好让外行人也能听懂。
兴许这就是大道至简，只是咱们习惯了繁缛和简单。
心愿借助明天这篇文章，能用大白话说分明这个绝对比拟底层和简单的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。