📝个人主页：五敷有你
🔥系列专栏：面经
⛺️ 稳中求进，晒太阳
MVCC（Multi-Version Concurrency Control）即多版本并发控制。
mvcc解决的就是读写时的线程安全问题，线程不用去争抢读写锁。
先看事务的隔离级别
在MySQL InnoDB存储引擎下，RC(读已提交)，RR(可重复读）实现基于MVCC进行并发事务控制
MVCC是基于"数据版本"对并发事务进行访问。
如下四个事务ABCD。是事务开始执行的时候分配的事务编号。
第四个事务没有数据调整，但进行的两次读取操作，但事务的读取时机很微妙。
- 第一次是事务A的提交后B事务的提交前查询。
- 第二次是在事务C提交前查询到。
如果是在RR级别下，RR级别天然就是可以处理不可重复读。所以前后执行都读到了张三的结果
RC级别下，不能保证不可重复读的，所以导致第一次读到张三，第二次读到张小三
在用MVCC多版本的控制下，有一个前提就是基于UNDO_LOG的版本链
在mysql的Innodb存储引擎的undologl里面本质就是采用链的方式存储一个一个的版本变化。
那版本链是如何组织的？
- 最上面一行是当前表的数据，在innodb中会附加两个字段：TRX_ID(代表最后一次更新的事务的编号)和DB_ROLL_PTR(指针信息，指向上次版本变化的数据)
- 无论是否提交都会加入版本链。
这时候就有人想UNDO_LOG不是会被删除嘛，万一中间数据被删除了版本链不久断了吗？
- UNDO_LOG版本链不是立即删除，MySQL确保版本数据不在被其他并行事务引用后在进行删除。
那版本链究竟起到什么作用呢？引出了ReadView
- ReadView就是"快照读"SQL执行时MVCC提取数据的依据。
- 快照读就是最普通的Select查询语句。
- 当前读指的是执行下列语句时进行数据读取的方式：Insert Update Delete ...
ReadView是一个数据结构，包含四个字段：
- m_ids：当前活跃的事务编号集合。
- min_trx_id：最小活跃事务编号
- max_trx_id:预分配事务编号，当前最大事务编号+1
- creator_trx_id：ReadView创建者的事务编号。
场景：
读已提交（RC）：在每一个执行快照读时生成ReadView
如下：
将版本放入右边的规则，成功则访问，不成功就一直往前找
可重复读：仅在第一次执行快照时生成ReadView，后续快照读复用。
RR级别下使用MVCC能避免幻读吗？
能，但不完全能。
能是在多次查询的本事务中没有增删改的操作下，ReadView会复用，不会有幻读的问题。
特例：当两次快照读之间同一事务存在当前读(使用了增删改)，ReadView会重新生成，导致幻读
