MVCC面试怎么答

说到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