MVCC即 多版本并发控制
其解决了：高并发下，只有等写 操作完毕后 才能读的性能问题，让读写不再冲突
这里的读是快照读，for update这种是当前读
MVCC是在 读已提交和可重复读 的隔离级别下生效的
如下图所示，事务101虽然先开启事务，但是是在104后才开始执行的
当事务102和103执行了修改操作后，无论是否提交，undolog版本链都会把事务102和103修改的版本以节点的形式和从新到旧的顺序存放，节点之间用回滚指针来连接
每一次读取操作，都会产生一次readview （可重复读隔离级别不会，后续讲），其他事务在修改数据的时候，都不会影响到这个既定的快照视图，ReadView的四个属性如图
max_trx_id：创建readView视图的事务id+1
m_ids：正在执行但没有提交的事务id
creator_trx_id：创建readView视图的事务id
如下图，只有undolog版本链中 符合访问条件的快照，才可以被访问
这三种条件的规律总结就是： 要么是自己的，要么就要提交过
举个栗子：比如当前指向事务103修改后的版本，那么trx_id=103
creator_tex_id=104 select语句所在事务的id
min_trx_id=101 活跃中(未提交)的最小事务id
max_trx_id=105 select语句所在的事务id+1
m_ids=[101,104] 活跃的事务id集合
则：min_trx_id(101) <= trx_id(103) <=max_trx_id(105)且不在m_ids[104]中
满足可访问条件，由此可得出查询的结果是axing3（如果此版本不满足条件，则顺着版本链向下继续找，直到满足条件为止）
图中可以发现事务104有两个查询，那么此时就需要考虑事务的隔离级别了
当隔离级别为 读已提交 的时候，每次select都会创建一次readView（结果为axing1）
当隔离级别为 可重复读 的时候，一个事务内多次select都会使用第一次的readview
可重复读如下图：虽然undolog回滚日志记录了事务101的修改，但是readview是用的第一次的，所以回滚日志101不符合readview条件集里的条件，依次向下，103满足
可能笔记写的不好，但是视频真的豁然开朗，墙裂推荐！！
