SQL MVCC
MVCC
MVCC是Multi Version Concurrency Control的简称，代表多版本并发控制。
为什么需要MVCC，还要从数据库事务的ACID特性说起。
相信很多朋友都了解ACID，它们分别代表了Atomicity(原子性), Consistency(一致性), Isolation(隔离性), Durability(持久性)。
各种数据库厂商会对各个隔离级别进行实现。
和 Java 中的多线程问题相同，数据库通常使用锁来实现隔离性。
最原生的锁，锁住一个资源后会禁止其他任何线程访问同一个资源。
但是很多应用的一个特点都是读多写少的场景，很多数据的读取次数远大于修改的次数，而读取数据间互相排斥显得不是很必要。所以就使用了一种读写锁的方法，读锁和读锁之间不互斥，而写锁和写锁、读锁都互斥。这样就很大提升了系统的并发能力。
之后人们发现并发读还是不够，又提出了能不能让读写之间也不冲突的方法，就是读取数据时通过一种类似快照的方式将数据保存下来，这样读锁就和写锁不冲突了，不同的事务 session 会看到自己特定版本的数据。
当然快照是一种概念模型，不同的数据库可能用不同的方式来实现这种功能。
之后的讨论默认均以 REPEATABLE READ 作为隔离级别。
InnoDB与MVCC
MySQL中的InnoDB存储引擎的特性有，默认隔离级别REPEATABLE READ, 行级锁，实现了MVCC, Consistent nonlocking read(默认读不加锁，一致性非锁定读), Insert Buffer, Adaptive Hash Index, DoubleWrite, Cluster Index。
上面列举了这么多，表示InnoDB有很多特性、很快。
InnoDB中通过UndoLog实现了数据的多版本，而并发控制通过锁来实现。
Undo Log除了实现MVCC外，还用于事务的回滚。
Innodb 的一些概念
下面概念用于协助理解，粗略浏览即可。
MySQL Innodb中存在多种日志，除了错误日志、查询日志外，还有很多和数据持久性、一致性有关的日志。
bin log
binlog，是mysql服务层产生的日志，常用来进行数据恢复、数据库复制，常见的mysql主从架构，就是采用slave同步master的binlog实现的, 另外通过解析binlog能够实现mysql到其他数据源（如ElasticSearch)的数据复制。
redo log
redo log记录了数据操作在物理层面的修改，mysql中使用了大量缓存，缓存存在于内存中，修改操作时会直接修改内存，而不是立刻修改磁盘，当内存和磁盘的数据不一致时，称内存中的数据为脏页(dirty page)。为了保证数据的安全性，事务进行中时会不断的产生redo log，在事务提交时进行一次flush操作，保存到磁盘中, redo log是按照顺序写入的，磁盘的顺序读写的速度远大于随机读写。当数据库或主机失效重启时，会根据redo log进行数据的恢复，如果redo log中有事务提交，则进行事务提交修改数据。这样实现了事务的原子性、一致性和持久性。
Undo Log
除了记录redo log外，当进行数据修改时还会记录undo log，undo log用于数据的撤回操作，它记录了修改的反向操作，比如，插入对应删除，修改对应修改为原来的数据，通过undo log可以实现事务回滚，并且可以根据undo log回溯到某个特定的版本的数据，实现MVCC。
redo log 和binlog的一致性，为了防止写完binlog但是redo log的事务还没提交导致的不一致，innodb 使用了两阶段提交
大致执行序列为
InnoDB prepare （持有prepare_commit_mutex）；
write/sync Binlog；
InnoDB commit (写入COMMIT标记后释放prepare_commit_mutex)。Undo Log 删除
undo log 在没有活动事务依赖（用于consistent read或回滚)便可以清楚，innodb 中存在后台 purge 线程进行后台轮询删除 undo log。
rollback segment
回滚段这个概念来自Oracle的事物模型，在Innodb中，undo log被划分为多个段，具体某行的undo log就保存在某个段中，称为回滚段。可以认为undo log和回滚段是同一意思。
read view
read view 主要是用来做可见性判断的, 比较普遍的解释便是"本事务不可见的当前其他活跃事务", 但正是该解释, 可能会造成一节理解上的误区,
所以此处提供两个参考, 供给大家避开理解误区:
read view中的高水位low_limit_id可以参考
https://github.com/zhangyachen/zhangyachen.github.io/issues/68,
https://www.zhihu.com/question/66320138
其实上面第1点中加粗部分也是相关高水位的介绍( 注意进行了+1 )
可见性比较算法
这里每个比较算法后面的描述是建立在rr级别下，rc级别也是使用该比较算法,此处未做描述）
设要读取的行的最后提交事务id(即当前数据行的稳定事务id)为 trx_id_current
当前新开事务id为 new_id
当前新开事务创建的快照read view 中最早的事务id为up_limit_id, 最迟的事务id为low_limit_id(注意这个low_limit_id=未开启的事务id=当前最大事务id+1)
比较
1.trx_id_current = trx_id_last, 这种情况也比较好理解, 表示, 该行记录的稳定事务id是在本次新事务创建之后才开启的, 但是却在本次新事务执行第二个select前就commit了，所以该行记录的当前值不可见, 跳到步骤4。
3.trx_id_current innodb-locking-reads
select ... lock in share mode
select ... for update
insert
update
delete
在RR级别下，快照读是通过MVVC(多版本控制)和undo log来实现的，当前读是通过加record lock(记录锁)和gap lock(间隙锁)来实现的。
innodb在快照读的情况下并没有真正的避免幻读, 但是在当前读的情况下避免了不可重复读和幻读!!!
小结
MVCC特点：
每行数据都存在一个版本，每次数据更新时都更新该版本
修改时Copy出当前版本, 然后随意修改，各个事务之间无干扰
保存时比较版本号，如果成功(commit)，则覆盖原记录, 失败则放弃copy(rollback)
就是每行都有版本号，保存时根据版本号决定是否成功，听起来含有乐观锁的味道, 因为这看起来正是，在提交的时候才能知道到底能否提交成功
InnoDB实现MVCC的方式是:
事务以排他锁的形式修改原始数据
把修改前的数据存放于undo log，通过回滚指针与主数据关联
修改成功（commit）啥都不做，失败则恢复undo log中的数据（rollback）
二者最本质的区别是
当修改数据时是否要排他锁，如果锁定了还算不算是MVCC？
Innodb的实现真算不上MVCC, 因为并没有实现核心的多版本共存, undo log 中的内容只是串行化的结果, 记录了多个事务的过程, 不属于多版本共存。但理想的MVCC是难以实现的, 当事务仅修改一行记录使用理想的MVCC模式是没有问题的, 可以通过比较版本号进行回滚, 但当事务影响到多行数据时, 理想的MVCC就无能为力了。
比如, 如果事务A执行理想的MVCC, 修改Row1成功, 而修改Row2失败, 此时需要回滚Row1, 但因为Row1没有被锁定, 其数据可能又被事务B所修改, 如果此时回滚Row1的内容，则会破坏事务B的修改结果，导致事务B违反ACID。 这也正是所谓的 第一类更新丢失 的情况。
也正是因为InnoDB使用的MVCC中结合了排他锁, 不是纯的MVCC, 所以第一类更新丢失是不会出现了, 一般说更新丢失都是指第二类丢失更新。
应用场景
也不是说MVCC就无处可用，对一些一致性要求不高的场景和对单一数据的操作的场景还是可以发挥作用的，比如多个事务同时更改用户在线数，如果某个事务更新失败则重新计算后重试，直至成功。这样使用MVCC会极大地提高并发数，并消除线程锁。
参考资料
- mysql
https://dev.mysql.com/doc/refman/8.0/en/innodb-multi-versioning.html
- mvcc
http://ningg.top/inside-mysql-transaction-and-mvcc/
https://liuzhengyang.github.io/2017/04/18/innodb-mvcc/