MVCC通过多版本实现高并发隔离，核心是版本存储（隐藏字段）、快照生成（事务启动时固定视图）和异步清理（VACUUM/Purge），三者协同保障一致性与性能。

MVCC（Multi-Version Concurrency Control）是主流SQL数据库（如PostgreSQL、MySQL InnoDB）实现高并发读写隔离的核心机制，它不依赖锁来避免读写冲突，而是通过为数据行保存多个历史版本，让不同事务看到“各自时间点的一致性快照”。其本质不是消除并发问题，而是把“读-写阻塞”转化为“空间换时间”的版本管理。

版本如何存储：行级隐藏字段是关键

每行数据实际包含若干系统级隐藏字段，不同数据库实现略有差异，但核心信息一致：

• 事务ID（xmin / trx_id）：记录插入该版本的事务ID。对PostgreSQL是xmin，InnoDB中是DB_TRX_ID。该值标识“谁创建了这个版本”。
• 删除事务ID（xmax / roll_ptr）：PostgreSQL用xmax标记删除该版本的事务ID（0表示未删除）；InnoDB则用DB_ROLL_PTR指向undo日志中的前一版本，通过回滚段链式组织历史版本。
• 可见性判断依赖当前事务ID与这些字段的比较：例如在PostgreSQL中，一个版本对当前事务可见，当且仅当：xmin ≤ 当前事务ID 且 (xmax = 0 或 xmax > 当前事务ID)，同时该版本未被已提交的事务删除（还需检查clog中事务状态）。

快照怎么生成：事务启动时的“一致性视图”

事务开始（执行第一条SELECT或BEGIN后第一个操作）时，数据库为其分配一个唯一的事务ID，并捕获当前活跃事务ID集合（即正在运行、尚未提交/回滚的事务列表）。

• 这个快照决定了事务整个生命周期内能“看到哪些版本”——只认得启动时刻已提交的版本，以及自己修改的版本；之后新提交的事务变更对其不可见（可重复读级别）。
• InnoDB中，快照基于Read View结构，包含m_up_limit_id（最小活跃事务ID）、m_low_limit_id（下一个将分配的事务ID）和m_ids（启动时活跃事务ID数组）。查询时逐行比对版本的trx_id是否落在可见范围内。
• 注意：快照在事务启动时固定，非执行语句时才生成。所以长事务会持有一个“老旧快照”，导致大量旧版本无法被清理（vacuum或purge延迟），可能引发bloat或undo表空间膨胀。

版本清理与空间回收：不清理就撑爆磁盘

旧版本不会自动消失。MVCC必须配合后台清理机制，否则数据文件和undo日志将持续增长。

• PostgreSQL依赖VACUUM进程扫描表，识别出所有事务均已结束（committed or aborted）且不再被任何活跃快照需要的行版本，将其标记为可复用空间；autovacuum默认开启，但配置不当会导致膨胀。
• InnoDB由Purge Thread异步执行清理：先从history list（按提交顺序排列的已提交事务链表）中取出最老的可清理事务，再遍历其修改的undo日志，物理删除对应的历史版本。若存在长事务或未提交的查询，purge会被阻塞。
• 关键指标：PostgreSQL中查看pg_stat_all_tables.n_dead_tup；InnoDB中监控INFORMATION_SCHEMA.INNODB_METRICS里的purge_trx_count和purge_undo_log_bytes。

隔离级别如何落地：快照粒度决定行为差异

MVCC本身不直接定义隔离级别，而是提供底层能力，上层通过控制快照获取时机和范围来实现不同语义：

• 读已提交（RC）：每次SELECT都生成新快照，只能看到语句开始前已提交的数据。同一事务内两次查询可能结果不同（不可重复读）。
• 可重复读（RR）：事务第一次读时建立快照，后续读复用该快照。保证事务内多次读一致，但InnoDB在此级别仍可能有幻读（通过间隙锁+MVCC组合缓解，非纯MVCC解决）。
• 串行化（Serializable）：多数数据库（如PostgreSQL）在RR基础上增加谓词锁或SIREAD检测，冲突时回滚；InnoDB则升级为真实锁机制，已脱离纯MVCC路径。

理解MVCC不能只看“多版本”，更要抓住三个联动环节：版本如何随事务写入而产生、快照如何约束可见性边界、清理如何保障系统可持续运行。三者缺一不可，任一环节失配都会引发性能抖动或数据异常。