MVCC通过隐藏字段（DB_TRX_ID、DB_ROLL_PTR）、undo log和Read View协同实现多版本并发控制：DB_TRX_ID标识修改事务，DB_ROLL_PTR链接旧版本，undo log存储历史版本，Read View在事务快照时刻决定数据可见性。

MySQL 的 MVCC（多版本并发控制）不是简单的“快照读”概念，而是 InnoDB 存储引擎围绕事务隔离、数据可见性与性能平衡构建的一套底层机制。它不依赖锁来解决所有并发问题，而是通过隐藏列、undo log 和 Read View 协同工作，让不同事务看到“各自时间点”的数据版本。

MVCC 的核心组件怎么配合工作的？

MVCC 的运行依赖三个关键部分：隐藏字段、undo log 和 Read View。它们不是独立存在，而是在事务执行 SELECT 时实时联动：

• DB_TRX_ID：每行记录隐含的“最后修改事务 ID”，标识谁改了这行；
• DB_ROLL_PTR：指向该行旧版本在 undo log 中的位置，构成版本链；
• undo log 不仅用于回滚，更是版本历史的存储载体——每次 UPDATE/DELETE 都会把旧值写入 undo log，并用 DB_ROLL_PTR 连成链；
• Read View 是事务“拍照”那一刻生成的可见性规则，包含当时活跃事务 ID 列表（m_ids）、最小未提交事务 ID（min_trx_id）、最大已提交事务 ID（max_trx_id）等信息。

可重复读（RR）下为什么不会出现幻读？

严格来说，RR 级别下普通 SELECT（快照读）确实不发生幻读，但这是靠 MVCC + Next-Key Lock 共同实现的，并非 MVCC 单独完成：

• 快照读（如 SELECT * FROM t WHERE id = 5）基于当前事务的 Read View 判断可见性，只看到“拍照时已提交”的版本，自然看不到其他事务之后插入并提交的新行；
• 当前读（如 SELECT ... FOR UPDATE、UPDATE、DELETE）会加锁，InnoDB 在 RR 下使用 Next-Key Lock（记录锁 + 间隙锁），直接阻止其他事务在相同范围插入新记录；
• 所以“RR 防幻读”是快照读的可见性控制 + 当前读的锁机制共同作用的结果，面试中若只答 MVCC 就不够完整。

Read View 的可见性判断逻辑到底是怎样的？

判断某条记录对当前事务是否可见，本质是比对记录的 DB_TRX_ID 和 Read View 中的关键值。规则如下（按顺序判断）：

• 如果记录的 DB_TRX_ID 等于当前事务 ID → 自己修改的，可见；
• 如果 DB_TRX_ID 小于 min_trx_id → 修改发生在当前事务“拍照”之前，且该事务已提交，可见；
• 如果 DB_TRX_ID 大于等于 max_trx_id → 修改发生在当前事务“拍照”之后，不可见；
• 如果 DB_TRX_ID 落在 [min_trx_id, max_trx_id) 区间 → 查 m_ids 列表：存在则说明该事务当时还活跃，不可见；不存在则说明已提交，可见。

这个判断过程在每次访问行记录时都会触发，不是一次性生成快照后就固化结果。

为什么长事务会导致 undo log 膨胀和性能问题？

因为 InnoDB 不能清理那些“可能被还在运行的事务用到”的旧版本：

• undo log 的清理时机取决于最老的活跃 Read View —— 只要有一个长事务没结束，它的 Read View 就一直有效，所有早于它的版本都必须保留；
• 大量 UPDATE/DELETE 会持续追加 undo 日志，导致 ibdata1 或独立 undo 表空间不断增长；
• 查询时需要遍历更长的版本链才能找到可见版本，增加 CPU 和内存开销；
• 极端情况下，可能触发 purge 线程延迟，甚至因磁盘满导致写入失败。

所以生产中要监控 information_schema.INNODB_TRX，避免事务执行时间过长或未正确提交。