MySQL5。7MVCC原理分析与调试

　　简介：
　　大家好，我是xp，我又诈尸了
　　mvcc，想必大家都不陌生，每个Java程序员都或多或少的了解过，不过不知道大家都是怎么学习的，是不是简单的百度一下呢？下面，我来带大家装个13，调试mvcc。咳，不是源码哈，但有那味了。
　　开卷开卷。
　　首先介绍一下mvcc的字面意思，全称：MultiversionConcurrencyControl，翻译下来就是多版本并发控制技术。
　　脏读、不可重复读、幻读的概念就不多啰嗦了，mvcc具体的含义也不多啰嗦了，可以自行百度。mvcc解决了脏读、不可重复读、部分幻读，包含了3个重要成分：undolog3个隐式字段ReadView
　　undolog作用：回滚多个行版本控制
　　在数据修改的时候，不仅记录了redolog，还记录了undolog。但是不同于redolog，undolog是逻辑日志。简单理解成，delete的时候，undolog会出现一条insert，update的时候，undolog会出现一条旧数据，用来事务失败之后的回滚。
　　3个隐式字段：DBROWID：行idDBTRXID：事务idDBROLLPTR：回滚指针
　　ReadView：mcreatortrxid：事务idmlowlimitid：maxtrxid：全局变量，每次分配的事务id，就是这个id，用完1muplimitid：mids的第一个事务id，mids是升序列表mids：创建该ReadView时的活跃事务id列表
　　好了，理论讲完了，让我们嗨起来。
　　嗨之前，有一个情况单独说一下：
　　可以看到，此时的trxid非常大，这是因为此时是只读事务。对于只读事务，InnoDB并不会分配trxid，只有发生dml才会分配。这样有2个好处：减少活跃事务的数量减少trxid的申请次数
　　至于这2个好处具体的作用，这里就不细说了，想知道的可以百度或者留言。
　　当commit了之后，我们使用SHOWENGINEINNODBSTATUS查看：
　　可以看到，显示该事务并没有开始。
　　好，回到正轨，相信大家都知道，视图可见性判断（不知道的先百度mvcc）：trxidmcreatortrxid，可见trxidmuplimitid，可见trxidmlowlimitid，不可见muplimitidtrxidmlowlimitid，需要判断在不在mids里面
　　整体是这样的：
　　第一步我们以38488为开始值，把name更新成111，并且commit
　　第二步以38490把name更新成222，333，但是不commit
　　当38490第一次修改为222的时候，数据结构大致是这样的：
　　使用SHOWENGINEINNODBSTATUS侧面验证：
　　当38490第二次修改为333的时候，数据结构大致是这样的：
　　使用SHOWENGINEINNODBSTATUS侧面验证：
　　第三步以38491去查询，此时生成的mids应该是〔348490，38491〕
　　使用SHOWENGINEINNODBSTATUS侧面验证：
　　此时ReadView的几个属性值为：mcreatortrxid：38491mlowlimitid：38492muplimitid：348490mids：〔348490，38491〕
　　接下来我们来验证结论：
　　1：不用验证，当前事务修改的肯定自己可见
　　2：38491查询id1的记录，name为111
　　38488348490，所以111可见
　　3：不用验证，38492是下个事务的id，还没生成呢，当前事务，肯定看不见下个事务修改的值
　　4：我们先把38491commit，把id为20的name更新成111
　　然后再开一个事务38496：
　　此时查id为20，是可见的
　　mids：〔348490，38496〕，因为38491已经commit了，所以mids没有。此时的38491在mids之间，但是在mids里面找不到，所以可见。
　　好了，愉快的装13结束了，兄弟们，下次见。