MVCC是InnoDB在READ COMMITTED和REPEATABLE READ下自动启用的快照读机制，通过DB_TRX_ID、DB_ROLL_PTR和ReadView实现非阻塞读；快照读基于事务或语句启动时的已提交版本，当前读则强制读最新并加锁；隔离级别差异在于ReadView生成时机，RC每次新建，RR复用首次；Undo Log存于ibd中，大事务易致其膨胀影响性能。
MVCC 不是锁，而是一套“让读不用等写”的快照机制。它不是 MySQL 的某个开关或配置项，而是 InnoDB 在 READ COMMITTED 和 REPEATABLE READ 隔离级别下自动启用的底层行为——你执行普通 SELECT 时，它就在工作。
快照读 vs 当前读：为什么同一张表里“看到的数据不一样”？
这是 MVCC 最直观的体现。你没改 SQL，但结果可能不同，原因在于读的方式不同：
-
SELECT（无锁）→ 快照读：读的是事务启动时刻（REPEATABLE READ）或语句执行时刻（READ COMMITTED）的已提交版本，不加锁，不阻塞别人 -
SELECT ... FOR UPDATE、UPDATE、DELETE→ 当前读：强制读最新行，并加行锁（X锁）或间隙锁（Next-Key Lock），会阻塞其他当前读 - 同一个事务中，第一次
SELECT和第二次SELECT ... FOR UPDATE可能返回不同值——前者是快照，后者是实时，这不矛盾，是设计使然
三个隐藏字段 + Undo Log + ReadView：MVCC 怎么“记住历史”？
InnoDB 每行数据背后有三样东西在默默协作：
-
DB_TRX_ID：记录最后一次修改该行的事务 ID；用来比对“这个版本我能不能看见” -
DB_ROLL_PTR：指向 Undo Log 中上一个版本的指针；靠它串起一条“版本链”，像时间轴一样回溯 -
ReadView：事务开启时生成的“可见性快照”，含m_ids（当时活跃事务列表）、min_trx_id、max_trx_id、creator_trx_id；每次快照读都用它判断某行版本是否可见 - Undo Log 不是日志文件，而是存放在 ibd 表空间里的“历史副本仓库”；长期未提交的事务会让 Undo Log 膨胀，拖慢 purge 线程，最终影响性能甚至撑爆磁盘
隔离级别怎么影响 MVCC 行为？
差别就落在 ReadView 的生成时机和复用逻辑上：
-
READ COMMITTED：每个SELECT都新建一个ReadView→ 同一事务内多次查询可能看到不同结果（非可重复读） -
REPEATABLE READ：只在事务第一个SELECT时创建ReadView，后续全复用 → 实现了可重复读，但幻读靠 Next-Key Lock 补足，不是 MVCC 单独完成的 -
READ UNCOMMITTED和SERIALIZABLE不走 MVCC：前者直接读最新行（脏读），后者所有读都升级为当前读（全表加锁）
真正容易被忽略的点是：MVCC 的“版本可见性”判断发生在引擎层，不经过 SQL 层优化器；所以即使你加了索引，如果 WHERE 条件涉及的列没被索引覆盖，InnoDB 仍需遍历版本链逐条比对 DB_TRX_ID 和 ReadView —— 这就是为什么大事务+高频更新+复杂查询下，性能会断崖下跌。别只盯着锁等待，也得查 INFORMATION_SCHEMA.INNODB_TRX 和 undo log size。
