说到mvcc这个比较抽象的概念，很多人都有点束手无策。因为它实际上偏理论，实际应用中很难用到。但在面试中出现频率又很高，一问大部分都G。所以怎么精简回答并且能抓住重点就很关键了。往上详细解说MVCC的太多了，我这里没那么多废话，直击面试。
一般来说，面试官问到mysql事务特性时想再聊深一点就会问这个话题。会这么问
mysql 中的事务特性分别实现原理是啥？
redolog保障持久 undolog保障原子和一致 mvcc保证隔离。
mvcc 是什么？怎么实现的
MVCC是无锁多版本并发控制。主要实现为undo.log版本链，行隐式字段taxId,rollbackpoint,readView视图。通过readView比较算法来判断每个读事务的可见性。
主要流程体现为每个写事务操作时会以原始数据为尾结点，通过rollbackpoint指向形成一条版本链存储在undo.log中，当有读事务进入时开启readView视图。
通过readView视图比较算法确认当前事务可读数据。比较算法有四个属性 creator_trx_id,min_trx_id ,max_trx_id ,m_ids。
可见的原则是当前事务ID小于活跃事务ID的最小值。或者等于**creator_trx_id** 。或者不存在于**m_ids**.那就是可见的。
MVCC 中的快照读和当前读有什么区别？
快照读：读取的是数据的快照版本，不加锁，使用 MVCC 机制，如普通的 SELECT 语句。
当前读：读取的是数据的最新版本，会加锁，如 INSERT、UPDATE、DELETE 以及使用了 FOR UPDATE 等的 SELECT 语句。
readView是什么？
在 "读已提交" 和 "可重复读" 隔离级别下。ReadView 是一个事务在执行查询操作时生成的一个视图，它用于判断当前事务能够看到哪个版本的数据，主要通过比较事务 ID 来决定数据的可见性。
详细说说 MVCC 中readView的比较算法
四个核心属性
m_ids：当前活跃事务 ID 列表，即生成 ReadView 时还未提交的事务 ID 集合。
min_trx_id ：m_ids 列表中的最小事务 ID。
max_trx_id：生成 ReadView 时，系统应该分配给下一个事务的事务 ID（也就是当前最大事务 ID + 1）。
creator_trx_id：创建该 ReadView 的事务 ID。
四个比较步骤
步骤 1：判断 DB_TRX_ID 是否等于 creator_trx_id
如果 DB_TRX_ID 等于 creator_trx_id，说明这条记录是由当前事务自己创建或修改的，那么该记录版本对当前事务是可见的。
步骤 2：判断 DB_TRX_ID 是否小于 min_trx_id
如果 DB_TRX_ID 小于 min_trx_id，意味着创建该记录版本的事务在生成 ReadView 之前就已经提交了，所以该记录版本对当前事务是可见的。
步骤 3：判断 DB_TRX_ID 是否大于等于 max_trx_id
如果 DB_TRX_ID 大于等于 max_trx_id，表示创建该记录版本的事务是在生成 ReadView 之后才开启的，那么该记录版本对当前事务不可见，需要从回滚段中查找旧版本。
步骤 4：判断 DB_TRX_ID 是否在 m_ids 列表中
如果 DB_TRX_ID 在 m_ids 列表中，说明创建该记录版本的事务在生成 ReadView 时还未提交，该记录版本对当前事务不可见，同样需要从回滚段中查找旧版本。 如果 DB_TRX_ID 不在 m_ids 列表中，表明创建该记录版本的事务在生成 ReadView 之前就已经提交了，该记录版本对当前事务是可见的。
不同隔离级别下 ReadView 的生成时机
读已提交 （ Read Committed ）：每个 SQL 语句执行前都会重新生成一个 ReadView，所以每次查询都能看到最新已提交的数据。
可重复读 （ Repeatable Read ）：在事务开始时生成一个 ReadView，整个事务期间都使用这个 ReadView，保证事务内多次读取结果一致
mvcc 能否解决 幻读 问题
MVCC（多版本并发控制）在一定程度上可以解决幻读问题，不过具体情况要根据不同的事务隔离级别
对于快照读，MVCC 在可重复读隔离级别下可以解决幻读问题。
对于当前读，MVCC 不能解决幻读问题，需要借助额外的锁机制。
读已提交的隔离级别下，MVCC 不能解决幻读问题。
其它MVCC相关概念的详细参考:https://zhuanlan.zhihu.com/p/676793594