MVCC是InnoDB在READ COMMITTED和REPEATABLE READ级别下自动启用的一致性快照读机制，依赖DB_TRX_ID、DB_ROLL_PTR及ReadView判断版本可见性，仅对普通SELECT生效；当前读（如FOR UPDATE、UPDATE等）绕过MVCC，直接读最新版本并加锁。
MySQL 的 MVCC 不是靠“开关”启用的，而是 InnoDB 引擎在 READ COMMITTED 和 REPEATABLE READ 隔离级别下自动生效的底层机制——只要用的是 InnoDB、事务没设成 READ UNCOMMITTED 或 SERIALIZABLE，它就在工作。
为什么普通 SELECT 不加锁却能读到一致数据？
因为这类查询默认是「快照读」（Consistent Nonlocking Read），它不直接访问最新行，而是根据事务启动时生成的 Read View，结合行记录的隐藏字段和 undo log 中的版本链，筛选出对该事务可见的历史版本。
-
Read View里保存了当前活跃事务 ID 列表（m_ids）、最小未提交事务 ID（min_trx_id）、最大已分配事务 ID（max_trx_id）等关键信息 - 判断某行版本是否可见，核心逻辑是：该版本的
DB_TRX_ID必须小于min_trx_id（说明它在本事务开始前已提交），或等于当前事务 ID（自己改的），或在m_ids中不存在（说明修改它的事务已结束） - 不同隔离级别下
Read View的创建时机不同：REPEATABLE READ在事务第一次快照读时创建并复用；READ COMMITTED每次快照读都新建
哪些操作会绕过 MVCC 直接读最新版本？
所有「当前读」（Locking Read）都不走快照，而是读取最新行并加锁，因此不享受 MVCC 的无锁优势。这些操作明确要求看到最新状态，或需要为后续修改做并发保护：
SELECT ... FOR UPDATESELECT ... LOCK IN SHARE MODE-
UPDATE、DELETE、INSERT
注意：UPDATE 和 DELETE 执行前，其实先做了当前读来定位目标行——所以即使你在 REPEATABLE READ 下执行 UPDATE，也可能因读到“幻行”而触发 Next-Key Lock，这和快照读的语义完全分离。
隐藏字段和 undo log 怎么串联起多个版本？
每一行数据背后有三个关键隐藏字段，它们不是可选配置，而是 InnoDB 强制维护的物理结构：
-
DB_TRX_ID：6 字节，记录最后一次修改该行的事务 ID -
DB_ROLL_PTR：7 字节，回滚指针，指向undo log中该行的上一个历史版本 -
DB_ROW_ID：6 字节，行 ID（无主键时用于生成聚簇索引）
当事务更新某行时，InnoDB 会把旧值连同当时 DB_TRX_ID 和 DB_ROLL_PTR 一起写入 undo log，再更新当前行，并让新行的 DB_ROLL_PTR 指向这个旧版本。这样就形成一条从最新行往 undo log 深处延伸的「版本链」。MVCC 读取时，就是沿着这条链回溯，直到找到第一个满足 Read View 可见性规则的版本。
真正容易被忽略的是：MVCC 的效果高度依赖事务持续时间与 undo log 的保留策略。长事务会拖住 min_trx_id，导致 undo log 无法及时 purge，可能引发磁盘膨胀甚至 Undo Log 空间耗尽。这不是理论风险，而是线上常见故障点。
