全网最全的一篇数据库MVCC详解，不全我负责
什么是MVCC
全称Multi-Version Concurrency Control，即多版本并发操纵，主如果为了提高数据库的并发机能。以下文章都是环绕InnoDB引擎来讲，由于myIsam不支撑事务。
统一行数据平常发生读写恳求时，会上锁堵塞住。但mvcc用更好的方式去处置读—写恳求，做到在发生读—写恳求冲突时不消加锁。
这个读是指的快照读，而不是当前读，当前读是一种加锁操纵，是悲不雅锁。
那它到底是如何做到读—写不消加锁的，快照读和当前读又是啥鬼，跟着你们的知心老哥，连续往下看。
当前读、快照读都是啥鬼
什么是MySQL InnoDB下的当前读和快照读？
当前读
它读取的数据库记载，都是当前最新的版本，会对当前读取的数据停止加锁，防止其他事务修改数据。是悲不雅锁的一种操纵。
如下操纵都是当前读：
select lock in share mode (同享锁)
select for update (排他锁)
update (排他锁)
insert (排他锁)
delete (排他锁)
串行化事务隔离级别
快照读
快照读的实现是基于多版本并发操纵，即MVCC，既然是多版本，那么快照读读到的数据不必然是当前最新的数据，有大概是此前历史版本的数据。
如下操纵是快照读：
- 不加锁的select操纵（注：事务级别不是串行化）
快照读与mvcc的关系
MVCCC是“保持一个数据的多个版本，使读写操纵没有冲突”的一个抽象概念。
这个概念需要详细功效去实现，这个详细实现就是快照读。（详细实现下面讲）
听完知心老哥的讲解，是不是瞬时茅厕顿开。
数据库并发场景
读-读：不存在任何问题，也不需要并发操纵读-写：有线程平安问题，大概会造成事务隔离性问题，大概碰到脏读，幻读，不成反复读写-写：有线程平安问题，大概会存在更新丧失问题，比方第一类更新丧失，第二类更新丧失
MVCC解决并发哪些问题？
mvcc用来解决读—写冲突的无锁并发操纵，就是为事务分配单向增长的时间戳。为每个数据修改留存一个版本，版本与事务时间戳相关联。
读操纵只读取该事务开端前的数据库快照。
解决问题如下：
并发读-写时：可以做到读操纵不堵塞写操纵，同时写操纵也不会堵塞读操纵。解决
脏读、幻读、不成反复读等事务隔离问题，但不克不及解决上面的写-写 更新丧失问题。
因此有了下面提高并发机能的组合拳：
MVCC + 悲不雅锁：MVCC解决读写冲突，悲不雅锁解决写写冲突MVCC + 悲观锁：MVCC解决读写冲突，悲观锁解决写写冲突
MVCC的实现道理
它的实现道理主如果版本链，undo日志 ，Read View 来实现的
版本链
我们数据库中的每行数据，除了我们肉眼看见的数据，还有几个潜藏字段，得开天眼才能看到。离别是db_trx_id、db_roll_pointer、db_row_id。
db_trx_id
6byte，比来修改(修改/插入)
事务ID：记载创立这笔记录/最后一次修改该记载的事务ID。db_roll_pointer（版本链关键）
7byte，
回滚指针，指向这笔记录的上一个版本（储备于rollback segment里）db_row_id
6byte，隐含的
自增ID（潜藏主键），假如数据表没有主键，InnoDB会主动以db_row_id发生一个聚簇索引。实际还有一个
删除flag潜藏字段, 记载被更新或删除并不代表真的删除，而是删除flag变了
如上图，db_row_id是数据库默许为该行记载生成的独一隐式主键，db_trx_id是当前操纵该记载的事务ID，而db_roll_pointer是一个回滚指针，用于配合undo日志，指向上一个旧版本。
每次对数据库记载停止改动，都会记载一条undo日志，每条undo日志也都有一个roll_pointer属性（INSERT操纵对应的undo日志没有该属性，由于该记载并没有更早的版本），可以将这些undo日志都连起来，串成一个链表，所以此刻的状况就像下图一样：
对该记载每次更新后，都会将旧值放到一条undo日志中，就算是该记载的一个旧版本，随着更新次数的增多，所有的版本都会被roll_pointer属性连接成一个链表，我们把这个链表称之为版本链，版本链的头节点就是当前记载最新的值。别的，每个版本中还包括生成该版本时对应的事务id，这个信息很重要，在按照ReadView推断版本可见性的时候会用到。
undo日志
Undo log 主要用于记载数据被修改此前的日志，在表信息修改此前先会把数据拷贝到undo log里。
当事务停止回滚时可以通过undo log 里的日志停止数据复原。
Undo log 的用处
包管
事务停止rollback时的原子性和一致性，当事务停止回滚的时候可以用undo log的数据停止复原。用于MVCC
快照读的数据，在MVCC多版本操纵中，通过读取undo log的历史版本数据可以实现不一样事务版本号都具有本人独立的快照数据版本。
undo log主要分为两种：
insert undo log
代表事务在insert新记载时发生的undo log , 只在事务回滚时需要，并且在事务提交后可以被马上抛弃
update undo log（主要）
事务在停止update或delete时发生的undo log ; 不仅在事务回滚时需要，在快照读时也需要；
所以不克不及随意删除，只要在快速读或事务回滚不触及该日志时，对应的日志才会被purge线程统一清除
Read View(读视图)
事务停止快照读操纵的时候生产的读视图(Read View)，在该事务施行的快照读的那一刻，会生成数据库系统当前的一个快照。
记载并保护系统当前活泼事务的ID(没有commit，当每个事务开启时，都会被分配一个ID, 这个ID是递增的，所以越新的事务，ID值越大)，是系统中当前不该该被本领务看到的其他事务id列表。
Read View主如果用来做可见性推断的, 即当我们某个事务施行快照读的时候，对该记载创立一个Read View读视图，把它比作前提用来推断当前事务能够看到哪个版本的数据，既大概是当前最新的数据，也有大概是该行记载的undo log里面的某个版本的数据。
Read View几个属性
trx_ids: 当前系统活泼(未提交)事务版本号汇合。low_limit_id: 创立当前read view 时“当前系统最大事务版本号+1”。up_limit_id: 创立当前read view 时“系统正处于活泼事务最小版本号”creator_trx_id: 创立当前read view的事务版本号；
Read View可见性推断前提
db_trx_id<up_limit_id||db_trx_id==creator_trx_id（显示）假如数据事务ID小于read view中的
最小活泼事务ID，则可以必定该数据是在当前事务启此前就已经存在了的,所以可以显示。或者数据的
事务ID等于creator_trx_id，那么说明这个数据就是当前事务本人生成的，本人生成的数据本人当然能看见，所以这种状况下此数据也是可以显示的。db_trx_id>=low_limit_id（不显示）假如数据事务ID大于read view 中的当前系统的
最大事务ID，则说明该数据是在当前read view 创立之后才发生的，所以数据不显示。假如小于则进入下一个推断db_trx_id可否在活泼事务（trx_ids）中不存在：则说明read view发生的时候事务已经commit了，这种状况数据则可以显示。已存在：则代表我Read View生成时刻，你这个事务还在活泼，还没有Commit，你修改的数据，我当前事务也是看不见的。
MVCC和事务隔离级别
上面所讲的Read View用于支撑RC（Read Committed，读提交）和RR（Repeatable Read，可反复读）隔离级别的实现。
RR、RC生成时机
RC隔离级别下，是每个快照读都会生成并猎取最新的Read View；而在
RR隔离级别下，则是统一个事务中的第一个快照读才会创立Read View,之后的快照读猎取的都是统一个Read View，之后的查询就不会反复生成了，所以一个事务的查询结果每次都是一样的。
解决幻读问题
快照读：通过MVCC来停止操纵的，不消加锁。依照MVCC中规定的“语法”停止增删改查等操纵，以幸免幻读。当前读：通过next-key锁（行锁+gap锁）来解决问题的。
RC、RR级别下的InnoDB快照读不同
在RR级别下的某个事务的对某笔记录的第一次快照读会创立一个快照及Read View， 将当前系统活泼的其他事务记载起来，此后在调取快照读的时候，还是使用的是统一个Read View，所以只要当前事务在其他事务提交更新此前使用过快照读，那么之后的快照读使用的都是统一个Read View，所以对之后的修改不成见；
即RR级别下，快照读生成Read View时，Read View会记载此时所有其他活动事务的快照，这些事务的修改关于当前事务都是不成见的。而早于Read View创立的事务所做的修改均是可见
而在RC级别下的，事务中，每次快照读都会新生成一个快照和Read View, 这就是我们在RC级别下的事务中可以看到别的事务提交的更新的缘由
总结
从以上的描写中我们可以看出来，所谓的MVCC指的就是在使用READ COMMITTD、REPEATABLE READ这两种隔离级别的事务在施行一般的SEELCT操纵时拜访记载的版本链的历程，这模样可以使不一样事务的读-写、写-读操纵并发施行，从而晋升系统机能。
