多版本并发控制（MVCC）是现代数据库的核心机制，允许读写操作并发进行，避免了传统加锁的性能瓶颈。PostgreSQL 通过在堆表中存储版本链和快照隔离来管理事务可见性。虽然快照隔离能防止脏读和不可重复读，但存在 write skew 问题。为了解决这一问题，PostgreSQL 引入了可序列化快照隔离（SSI），增加了读写依赖追踪。MVCC 的代价包括版本膨胀和 VACUUM 开销，因此需要合理选择隔离级别以平衡性能与正确性。

本文讨论了FoundationDB的严格可串行化和外部一致性，强调了5秒事务限制的设计目的，以确保系统恢复的有界性。通过结合OCC与MVCC，FoundationDB实现了可串行化快照隔离（SSI）语义。在高冲突情况下，重试机制可能导致吞吐量下降，需通过优化数据模型和减少读集来缓解。

本文讨论了对象存储中目录式分区表的缺陷，如并发写入导致的部分提交、查询规划成本高和缺乏快照隔离。为解决这些问题，开放表格式（如Iceberg、Delta、Hudi）提供了原子提交、快照隔离、文件级统计裁剪和schema演进等功能，确保数据一致性和高效查询。

Iceberg通过四层不可变元数据树解决了对象存储中的目录管理问题。这四层分别存储表的状态、快照信息、manifest列表和数据文件，确保原子提交和快照隔离。查询时，Iceberg利用元数据快速定位数据文件，避免了传统方法中的高成本LIST操作，并支持高效的分区裁剪和文件裁剪，提升查询性能。

本文横向对比主流数据库的 MVCC 实现：PostgreSQL 采用堆表追加式、由旧到新的版本链，InnoDB 采用 undo 增量、由新到旧的版本链，TiKV 将版本编码进键。三者可见性规则等价，但快照隔离会放过写偏斜；PostgreSQL 用 SSI 在线检测危险结构实现可串行化，代价是误杀。长事务会拖住回收水位，导致版本膨胀。

Percolator是Google在Bigtable上构建的分布式事务系统，用于解决搜索引擎增量索引更新问题。它通过data、lock、write三列结构编码事务状态，采用两阶段提交（Prewrite/Commit），以主键提交作为原子提交点，消除专用协调者依赖。系统提供快照隔离，支持冲突检测与锁清理。TiDB等产品在此基础上进行了工程优化，如悲观锁、Async Commit等。

AWS Aurora DSQL 通过快照隔离和乐观并发控制（OCC）提升性能，减少事务提交时的数据库交互，优化跨区域场景。然而，取消缓存可能增加延迟，使用复杂度上升，适合对延迟不敏感且具备开发能力的用户。

Epoxy是一个新的协议，简化了跨异构数据存储的ACID事务。它使用多版本并发控制来适应不同的数据存储设置，并通过插入读写操作来实现快照隔离。Epoxy保证事务的原子性和持久性，并通过验证操作和持久化更改来提交事务。然而，Epoxy对辅助存储的假设和介入带来了一些开销，且必须以独占模式访问辅助存储表。