MVCC
一种数据库并发控制机制，通过维护数据的多个版本使读操作不阻塞写、写操作不阻塞读，从而在保证事务隔离性的同时维持高并发性能。
时间轴 (近 90 天)
OLTP系统几乎都要求严格ACID，用行级锁或MVCC来管理并发。
在 HTAP 场景中，MVCC 的版本链和可见性判断机制使分析查询能够读取最新已提交的数据版本，而无需停止事务写入，从而消除读写冲突并避免 ETL 同步延迟。
多版本并发控制（MVCC）通过生成数据新版本并保留旧版本，使读操作可根据事务开始时间选择一致性快照而无需等待写操作完成。
InnoDB 的 MVCC 通过就地修改行、用 undo 链跟踪旧版本实现：每行隐藏事务 ID 和回滚指针，回滚指针串起 undo log 中的旧版本形成版本链；已提交读（RC）每次语句执行生成新快照，可重复读（RR）在事务开始时生成快照。
MySQL默认隔离级别为可重复读，通过MVCC实现快照读以避免不可重复读。
MVCC（多版本并发控制）通过每次写操作生成新版本、读操作读取一致性快照来避免读写互相阻塞
Linux的fork()系统调用、ZFS文件系统的快照功能以及许多现代数据库的MVCC机制都依赖写时复制原理
PostgreSQL 内部包含查询解析器、规划器/优化器、执行器、存储管理器（含 MVCC 多版本并发控制）、WAL 预写日志等多个高度耦合的子系统
PostgreSQL 的 MVCC 机制、ZFS/Btrfs 文件系统的快照，以及部分云数据库服务将写时复制或类似存储分层技术作为底层支撑
当子事务数量超过 64 后发生 subxid overflow，其他事务在进行 MVCC 可见性检查时必须频繁访问 pg_subtrans 这个 SLRU 缓存，导致锁竞争加剧、磁盘 I/O 增加和吞吐量下降
全部知识事实 (11)
PostgreSQL的MVCC机制下，每次UPDATE操作实际上是写入一条新的行版本，对大JSONB字段频繁增量更新会导致写放大问题
95%待验证OLTP系统几乎都要求严格ACID，用行级锁或MVCC来管理并发。
50%待验证多版本并发控制（MVCC）通过生成数据新版本并保留旧版本，使读操作可根据事务开始时间选择一致性快照而无需等待写操作完成。
50%待验证在 HTAP 场景中，MVCC 的版本链和可见性判断机制使分析查询能够读取最新已提交的数据版本，而无需停止事务写入，从而消除读写冲突并避免 ETL 同步延迟。
50%待验证InnoDB 的 MVCC 通过就地修改行、用 undo 链跟踪旧版本实现：每行隐藏事务 ID 和回滚指针，回滚指针串起 undo log 中的旧版本形成版本链；已提交读（RC）每次语句执行生成新快照，可重复读（RR）在事务开始时生成快照。
50%待验证MySQL默认隔离级别为可重复读，通过MVCC实现快照读以避免不可重复读。
50%待验证MVCC（多版本并发控制）通过每次写操作生成新版本、读操作读取一致性快照来避免读写互相阻塞
50%待验证Linux的fork()系统调用、ZFS文件系统的快照功能以及许多现代数据库的MVCC机制都依赖写时复制原理
50%待验证PostgreSQL 内部包含查询解析器、规划器/优化器、执行器、存储管理器（含 MVCC 多版本并发控制）、WAL 预写日志等多个高度耦合的子系统
50%待验证PostgreSQL 的 MVCC 机制、ZFS/Btrfs 文件系统的快照，以及部分云数据库服务将写时复制或类似存储分层技术作为底层支撑
50%待验证当子事务数量超过 64 后发生 subxid overflow，其他事务在进行 MVCC 可见性检查时必须频繁访问 pg_subtrans 这个 SLRU 缓存，导致锁竞争加剧、磁盘 I/O 增加和吞吐量下降
50%