MVCC 让读者按可见性规则读取合适的行版本，从而减少普通读写之间的阻塞。它不是“完全无锁”，也不是把整张表复制一份快照。
Table of contents
三个组成部分
MVCC 是 Multi-Version Concurrency Control，多版本并发控制。InnoDB 会为聚簇索引记录维护事务相关隐藏信息，并把旧值保存在 Undo 记录形成的版本链中。Read View 是一次读取用来判断哪些事务版本可见的规则集合。
当前行版本 ──指向──> 较旧 Undo 版本 ──> 更旧版本
│
└─ Read View 判断当前事务应该看到哪一个它不是按时间戳简单比较。理解源码细节前，先牢牢记住：读视图、事务 ID 和版本链共同决定可见性。
快照读与当前读
普通 SELECT 通常是一致性快照读，可能沿 Undo 链找到旧版本；SELECT ... FOR UPDATE、UPDATE、DELETE 需要基于较新的可锁定记录工作，属于当前读。不要把同一事务中两类读的结果差异误判为缓存故障。
在 READ COMMITTED 下，普通查询通常每条语句建立新快照；在默认 REPEATABLE READ 下，同一事务的普通一致性读通常复用首次建立的快照。具体边界以官方版本文档与实验为准。
长事务为何危险
只要旧快照仍可能需要历史版本，Purge 就不能清掉相应 Undo。长事务会让历史链增长、读放大、表空间膨胀，并增加锁和复制风险。连接“空闲”不代表事务已经结束。
生产中应监控活动事务年龄、Undo 历史长度、长查询和未提交连接；批任务按可恢复批次提交；不要在事务内等待消息或人工操作。
参考 InnoDB 多版本机制。
下一步
继续阅读06-12 Redo、Undo、Binlog 与崩溃恢复，把可见性扩展到持久化和复制。