分布式数据库事务隔离的理论发展与实践演进¶

1. 引言¶

1.1 分布式数据库事务隔离的重要性¶

在当今数字化时代，随着数据量的爆炸式增长和业务复杂度的不断提升，分布式数据库已成为支撑大规模应用的核心基础设施。与传统集中式数据库相比，分布式数据库通过将数据分散存储在多个节点上，实现了高可用性、可扩展性和容错能力的显著提升。然而，这种分布式架构也带来了一个根本性挑战：如何在分布式环境中保证事务的隔离性，确保并发执行的事务之间不会相互干扰，从而维护数据的一致性和完整性。

事务隔离是数据库 ACID（原子性、一致性、隔离性、持久性）特性中的关键要素之一。在分布式系统中，由于网络延迟、节点故障、时钟不同步等因素的存在，实现事务隔离变得异常复杂。分布式数据库必须在保证数据一致性的同时，尽可能提高系统的并发性能，这就需要精心设计的事务隔离机制。正确的隔离级别选择不仅影响数据的正确性，还直接决定了系统的吞吐量、延迟和可扩展性。

1.2 理论发展的历史脉络¶

分布式数据库事务隔离的理论发展经历了从简单到复杂、从集中式到分布式的演进过程。早期的研究主要集中在单机数据库的隔离级别定义上，1992 年 ANSI SQL 标准定义了四种基本隔离级别，为整个行业提供了统一的规范。然而，随着分布式系统的兴起，传统的隔离级别定义暴露出诸多局限性。

1995 年，《A Critique of ANSI SQL Isolation Levels》论文的发表标志着隔离级别理论研究的重大转折。该论文系统地批判了 ANSI SQL 1992 标准的缺陷，指出其在定义事务异常时的模糊性和不完整性。1999 年，Atul Adya 的博士论文《Weak Consistency: A Generalized Theory》进一步推动了理论发展，提出了基于序列化图的形式化隔离级别定义方法，为后续的研究奠定了坚实的理论基础。

进入 21 世纪后，随着云计算、大数据、区块链等新技术的兴起，分布式数据库事务隔离面临着新的挑战和机遇。研究重点逐渐从理论定义转向实际系统的实现优化，特别是在高并发、低延迟、跨数据中心等场景下的性能提升。同时，机器学习、硬件加速等新兴技术也开始被应用于事务隔离的优化中，为分布式数据库的发展开辟了新的道路。

1.3 研究范围与目标¶

本报告旨在全面梳理分布式数据库事务隔离的理论发展历程，深入分析当前主流技术的实现原理和性能特点，并探讨未来的发展趋势。研究范围涵盖从 ANSI SQL 1992 标准到最新的学术研究成果，重点关注以下几个方面：

首先，我们将系统回顾事务隔离理论的发展历程，包括经典的隔离级别定义、异常分类体系以及形式化验证方法。其次，深入分析主流分布式数据库系统的隔离机制实现，包括 TiDB、CockroachDB、Google Spanner 等代表性系统。第三，重点关注 2020 年以来的最新研究进展，特别是在性能优化、新型隔离级别、形式化验证等方面的突破。最后，探讨未来的发展趋势，包括新兴技术的应用、性能优化策略以及标准演进方向。

通过对这些内容的深入研究，本报告期望为数据库研究者和实践者提供全面的理论基础和技术指导，推动分布式数据库事务隔离技术的进一步发展。

2. 事务隔离理论的发展历程¶

2.1 ANSI SQL 1992 标准的四种隔离级别¶

1992 年发布的 ANSI SQL 标准（ISO/IEC 9075:1992）定义了四种事务隔离级别，这一标准成为了数据库行业的基础规范。这四种隔离级别从低到高依次为：读未提交（READ UNCOMMITTED）、读已提交（READ COMMITTED）、可重复读（REPEATABLE READ）和可串行化（SERIALIZABLE）。每种隔离级别通过控制并发事务间的可见性来解决三类读异常：脏读（Dirty Read）、不可重复读（Non-Repeatable Read）和幻读（Phantom Read）。

** 读未提交（READ UNCOMMITTED）** 是最低的隔离级别，它允许事务读取其他事务尚未提交的数据修改。这种隔离级别虽然提供了最高的并发性能，但存在严重的数据一致性问题，因为读取到的数据可能在后续被回滚。在实际应用中，这种隔离级别很少被使用，仅在对数据一致性要求极低的场景下才会考虑。

** 读已提交（READ COMMITTED）** 是大多数数据库系统的默认隔离级别。在这种级别下，事务只能读取其他事务已经提交的数据修改，从而避免了脏读问题。然而，同一事务内多次读取同一数据时，可能会得到不同的结果，这就是不可重复读现象。这种隔离级别在保证数据一致性和系统性能之间取得了较好的平衡。

** 可重复读（REPEATABLE READ）** 提供了更高的隔离保证。在这种级别下，同一事务内多次读取同一数据时，结果始终保持一致，从而避免了不可重复读问题。但是，这种隔离级别并不能完全防止幻读现象，即事务可能在多次查询中看到不同的结果集，特别是当其他事务插入或删除符合查询条件的记录时。

** 可串行化（SERIALIZABLE）** 是最高的隔离级别，它保证了并发执行的事务与串行执行的结果完全一致。在这种级别下，数据库系统会通过各种机制（如锁、时间戳排序等）来确保事务的执行顺序是可串行化的，从而完全避免了所有的并发异常。然而，这种最高级别的隔离通常会带来显著的性能开销。

2.2 1995 年的批判与理论突破¶

1995 年发表的《A Critique of ANSI SQL Isolation Levels》论文（作者：Hal Berenson、Phil Bernstein、Jim Gray、Jim Melton、Elizabeth O’Neil、Patrick O’Neil）对 ANSI SQL 1992 标准进行了系统性的批判，指出了其在定义和实现上的根本性缺陷。这篇论文的发表标志着事务隔离理论研究进入了一个新的阶段。

论文的核心批判主要集中在以下几个方面：

首先，ANSI SQL 1992 标准完全忽略了写异常。标准只定义了三类读异常（P1 脏读、P2 不可重复读、P3 幻读），却完全没有考虑写异常，特别是最危险的 P0 脏写（Dirty Write）。脏写是指事务 T1 写入数据后，事务 T2 覆盖了 T1 的写入，随后 T1 提交或回滚，导致数据一致性被破坏。这种异常的危害比读异常更加严重，因为它会违反对象间的约束条件。

其次，标准的自然语言定义导致了严重的歧义问题。ANSI SQL 1992 使用自然语言而非形式化方法来描述隔离级别和异常现象，这导致不同的实现可能有不同的理解。例如，”可重复读” 这一术语名不副实，因为标准定义的 REPEATABLE READ 仅保证单行数据读取一致，无法保证多表 / 多字段的逻辑一致性。

第三，标准的异常覆盖范围严重不足。ANSI 定义的三类异常仅覆盖了简单的单行操作，无法描述复杂的多对象、多约束业务场景中的一致性问题。例如，写偏差（Write Skew）异常就不在标准的覆盖范围内。写偏差是指两个并发事务基于相同条件读取数据，分别修改不同行，提交后共同违反全局约束的情况。

基于这些批判，论文提出了一个更加完整的异常分类体系，将事务异常分为两大类（宽泛版 P 和严格版 A），共定义了 8 种关键异常。这一分类体系不仅包含了原有的读异常，还引入了写异常的概念，为后续的理论研究奠定了基础。

2.3 1999 年的形式化理论框架¶

1999 年，Atul Adya 在其博士论文《Weak Consistency: A Generalized Theory and Optimistic Implementations for Distributed Transactions》中提出了一个突破性的理论框架，首次实现了独立于具体实现的形式化隔离级别定义。这一理论框架的提出标志着事务隔离研究从经验总结走向了严格的数学证明阶段。

Adya 的理论框架基于 ** 直接序列化图（Direct Serialization Graph, DSG）** 的概念。DSG 通过数学方法严格定义了事务间的冲突关系，将事务间的冲突分为三种类型：

1. 写 – 写冲突（WW）：事务 T1 写入对象 x 后，事务 T2 也写入 x，对应 P0 脏写异常

2. 写 – 读冲突（WR）：事务 T1 写入对象 x 后，事务 T2 读取 x，对应 P1 脏读异常

3. 读 – 写冲突（RW）：事务 T1 读取对象 x 后，事务 T2 写入 x，对应 P2 不可重复读和 P3 幻读异常

通过分析 DSG 图中的环结构，Adya 定义了不同类型的环与异常现象的对应关系。例如：

• G0（单节点环）：事务自身形成环，理论上不可能出现

• G1a（单 WW 边环）：T1→T2（WW）→T1，对应 P0 脏写

• G1b（单 WR 边环）：T1→T2（WR）→T1，对应 P1 脏读

• G1c（单 RW 边环）：T1→T2（RW）→T1，对应 P2 不可重复读

基于这种形式化定义，Adya 重新定义了各种隔离级别：

• 读未提交：禁止 G0 和 G1a（仅禁止脏写）

• 读已提交：禁止 G0、G1a 和 G1b（禁止脏写和脏读）

• 可重复读：禁止 G0、G1a、G1b 和 G1c（禁止所有单条边环）

• 快照隔离（Snapshot Isolation）：与可重复读相同，禁止所有单条边环

• 可序列化：禁止所有环类型

这一理论框架的重要贡献在于，它不再依赖于具体的实现机制（如锁、MVCC 等），而是通过数学关系来定义隔离级别。这使得不同的数据库系统可以采用不同的实现方式，只要满足相应的数学关系即可。同时，这一框架还为后续的形式化验证提供了基础，使得事务隔离的正确性可以通过数学证明来保证。

2.4 21 世纪的演进与创新¶

进入 21 世纪后，分布式数据库事务隔离的研究呈现出多元化和实用化的趋势。随着云计算、大数据、区块链等新技术的兴起，传统的隔离级别理论面临着新的挑战和机遇。研究重点逐渐从理论定义转向实际系统的实现优化，特别是在高并发、低延迟、跨数据中心等场景下的性能提升。

快照隔离（Snapshot Isolation）的广泛应用是这一时期的重要特征。快照隔离作为一种介于可重复读和可序列化之间的隔离级别，在保证较高一致性的同时提供了优异的并发性能。主流数据库系统如 Oracle、PostgreSQL、SQL Server 等都实现了快照隔离机制。与传统的锁机制不同，快照隔离通过多版本并发控制（MVCC）技术，让事务在开始时获取数据快照，后续所有读取都基于这个快照，从而避免了读锁的使用。

分布式共识算法的引入为分布式事务隔离带来了新的解决方案。以 Raft、Paxos 为代表的共识算法不仅用于数据复制，还被广泛应用于分布式事务的协调和隔离。例如，Google Spanner 通过 TrueTime API 实现了全球范围内的强一致性，而 CockroachDB 则基于 Raft 实现了可序列化快照隔离（SSI）。这些系统通过共识算法保证了分布式环境下的数据一致性，同时提供了良好的性能和可扩展性。

新兴隔离级别和一致性模型的探索成为研究热点。除了传统的四种隔离级别，研究者们提出了各种新的一致性模型，如因果一致性（Causal Consistency）、会话一致性（Session Consistency）、单调读一致性（Monotonic Read Consistency）等。这些模型在保证数据一致性的同时，提供了更大的灵活性，特别适合于特定的应用场景。

形式化验证技术的成熟为事务隔离的正确性提供了强有力的保证。通过使用定理证明器（如 Coq、Isabelle）和模型检验器，研究者们能够对复杂的并发控制协议进行严格的正确性验证。2025 年发表的《Weak Isolation Levels in Separation Logic》论文就是这一领域的最新成果，它首次使用分离逻辑对弱隔离级别进行了形式化规范和验证。

机器学习在事务优化中的应用代表了未来的发展方向。通过分析历史数据和实时监控信息，机器学习算法可以动态调整事务的隔离级别、优化锁策略、预测死锁等。这种智能化的优化方法能够在保证数据一致性的前提下，显著提升系统的整体性能。

3. 主流分布式数据库的隔离机制实现¶

3.1 TiDB 的快照隔离实现¶

TiDB 作为中国自主研发的分布式关系型数据库，在事务隔离方面采用了独特的实现方式。TiDB 支持两种隔离级别：读已提交（Read Committed, RC）和快照隔离（Snapshot Isolation, SI）。其中，SI 级别基本等价于 ANSI 标准中的可重复读（RR）隔离级别，但在实现上具有显著的优势。

TiDB 的快照隔离实现基于 ** 多版本并发控制（MVCC）** 技术，同时结合了 Raft 共识算法来保证分布式环境下的数据一致性。在 TiDB 中，每个事务在开始时会获取一个全局的时间戳（TSO），这个时间戳不仅用于版本控制，还用于实现快照隔离。

TiDB 的快照隔离具有以下关键特性：

1. 避免幻读：与 ANSI 标准的 RR 级别不同，TiDB 的 SI 级别能够完全避免幻读现象。这是因为 TiDB 在读取数据时会记录所有相关的索引信息，当再次读取时会检查是否有新的记录插入，从而防止了幻读的发生。

2. 写偏差问题：虽然 TiDB 的 SI 级别能够避免幻读，但它无法避免写偏差（Write Skew）异常。写偏差是指两个并发事务读取不同但相关的记录，然后各自更新自己读取的数据并最终提交，如果这些相关记录之间存在约束，最终结果可能违反该约束。TiDB 建议使用SELECT FOR UPDATE语法来避免写偏差问题。

3. 乐观事务模型：TiDB 默认使用乐观事务模型，在事务执行过程中不会获取锁，只有在提交时才会检查数据的版本。这种方式大大提高了并发性能，但也可能导致较高的重试率。从 TiDB v8.0.0 开始，自动重试功能被移除，因为它可能破坏事务隔离级别。

4. 悲观事务模型：TiDB 还支持悲观事务模型，在这种模式下，DML 操作基于最新提交的数据执行，行为与 MySQL 相似。悲观事务通过在读取数据时获取锁来保证数据的一致性，适合于写冲突较多的场景。

TiDB 的事务执行流程如下：

• 事务开始时，获取全局时间戳 TSO

• 执行读操作时，基于 TSO 读取相应版本的数据

• 执行写操作时，记录修改操作但不立即写入磁盘

• 提交时，检查所有修改的数据是否被其他事务修改

• 如果检查通过，写入数据并提交；否则，回滚事务

3.2 CockroachDB 的可序列化快照隔离¶

CockroachDB 作为一个分布式 SQL 数据库，其设计目标是提供强一致性和高可用性。与大多数数据库不同，CockroachDB默认使用可序列化（Serializable）隔离级别，这是 SQL 标准中最强的隔离级别，比后来发展的快照隔离级别更强。

CockroachDB 实现了三种隔离级别：

• 读已提交（Read Committed）

• 快照（Snapshot）

• 可序列化（Serializable）

此外，系统还暴露了可重复读（Repeatable Read）和读未提交（Read Uncommitted），它们分别映射到快照和读已提交级别。

CockroachDB 的默认隔离级别称为可序列化快照（Serializable Snapshot），这是一个乐观的、多版本的、时间戳排序的并发控制系统。其核心特性包括：

1. 可序列化保证：最终的数据库状态等同于事务组件的串行执行结果。

2. 可恢复性：已中止或放弃的事务对数据库状态没有影响。

3. 无锁：操作执行时无需对资源加锁，通过中止违反可序列化或严格调度的事务来保证正确性。

4. 分布式：系统中没有中央协调器或服务。

CockroachDB 的可序列化快照隔离基于以下关键技术：

多版本时间戳排序：CockroachDB 使用多版本时间戳排序来保证完整的事务提交历史是可序列化的。每个事务在开始时被分配一个时间戳，该事务的所有操作都在这个时间戳下执行。通过确保时间戳的有序性和冲突检测，系统能够保证事务执行的可序列化性。

读时间戳缓存：在任何读操作中，该读操作的时间戳会被记录在节点本地的时间戳缓存中。所有写操作都会查询这个缓存，如果发现有比当前操作时间戳更大的读时间戳，就说明存在读 – 写冲突，需要中止当前事务并重试。

严格调度：CockroachDB 使用严格调度来处理未提交事务之间的冲突。严格调度要求操作只能读取或覆盖已提交的值，绝不允许对未提交的值进行操作。当遇到未提交的意图（intent）时，系统会通过优先级机制决定哪个事务应该被中止。

CockroachDB 还实现了 ** 可序列化快照隔离（SSI）** 技术，这是一种基于锁的无锁多版本时间戳排序方案。SSI 能够在快照隔离的基础上，通过检测写偏序来防止写偏差异常，从而真正实现可序列化的隔离保证。

3.3 Google Spanner 的外部一致性¶

Google Spanner 是全球第一个实现了真正意义上的全球分布式、强一致性数据库。Spanner 支持两种 ANSI/ISO SQL 标准定义的隔离级别：可序列化（Serializable）和可重复读（Repeatable Read）。其中，可序列化是 Spanner 的默认隔离级别。

Spanner 的隔离机制的核心是其独特的TrueTime API。TrueTime API 不是提供一个具体的时间值，而是返回一个时间区间 [earliest, latest]，这个区间保证包含了真实时间。Spanner 利用 TrueTime API 实现了外部一致性（External Consistency），这是一种比可序列化更强的一致性模型。

Spanner 的可序列化隔离具有以下特点：

1. 外部一致性：Spanner 保证所有事务都按照顺序执行，就像在单台服务器数据库上执行一样。即使事务在多个服务器（甚至多个数据中心）上执行，Spanner 也能保证这种外部一致性。

2. 全局时间戳分配：Spanner 使用 TrueTime API 为所有事务分配全局提交时间戳。这个时间戳不仅用于版本控制，还用于实现线性一致性（Linearizability）。通过全局时间戳，Spanner 能够在分布式环境中实现真正的强一致性。

3. 时间戳排序：Spanner 的并发控制基于时间戳排序。所有事务按照它们的提交时间戳顺序执行，从而保证了可序列化性。读操作会返回具有小于当前事务时间戳的最新版本的数据。

4. 锁机制：虽然 Spanner 主要依靠时间戳排序，但在某些情况下也会使用锁。例如，在处理写 – 写冲突时，Spanner 会使用锁来确保同一数据的多个写操作按照时间戳顺序执行。

Spanner 的可重复读隔离使用快照隔离技术实现。在这种隔离级别下：

• 事务内的所有读操作都基于事务开始时的一致性快照

• 只有在没有写冲突时，对同一数据的并发写操作才能成功

• 读操作无需获取锁，不会阻塞并发写操作

这种实现方式在高并发读的场景下表现优异，能够显著减少事务的中止率。

3.4 其他代表性系统的隔离机制¶

除了上述三个代表性系统外，还有许多其他优秀的分布式数据库在事务隔离方面有着独特的实现。

Apache Cassandra采用了一种轻量级的事务处理方式。Cassandra 支持轻量级事务（Lightweight Transactions）和批处理（Batch）操作。轻量级事务基于 Paxos 算法实现，可以保证单行数据的原子性，但不支持多行事务。批处理操作可以将多个操作组合在一起执行，但只能保证最终一致性，不提供强隔离保证。

Amazon Aurora是 AWS 推出的云原生关系型数据库。Aurora 使用了一种创新的存储架构，将数据库存储层与计算层分离。在事务隔离方面，Aurora 支持标准的四种隔离级别，并通过优化的锁机制和 MVCC 技术来提高并发性能。Aurora 的乐观并发控制最小化了跨区域延迟，但要求应用程序处理重试。

YugabyteDB是一个兼容 PostgreSQL 的分布式数据库。YugabyteDB 支持可序列化、快照隔离和读已提交等隔离级别。它使用 Raft 协议来保证分布式一致性，同时通过 MVCC 和时间戳排序来实现高性能的并发控制。

**Citus（PostgreSQL 扩展）** 将 PostgreSQL 转换为分布式数据库。Citus 支持与 PostgreSQL 相同的隔离级别，但在分布式事务处理上有一些限制。由于 Citus 使用 PostgreSQL 的原生事务机制，它能够提供与单机 PostgreSQL 相同的隔离保证，但在处理跨分片事务时需要额外的协调。

Redis Cluster虽然主要作为内存数据库使用，但也提供了事务支持。Redis 的事务是通过 MULTI/EXEC 命令实现的，支持简单的命令队列和原子性执行。但 Redis 的事务不支持回滚，也不提供严格的隔离保证，主要用于简单的批量操作。

这些系统在事务隔离方面的不同实现方式，反映了不同的设计理念和应用场景需求。从强一致性到最终一致性，从严格隔离到宽松隔离，每种选择都有其特定的优势和适用场景。

4. 2020 年后的最新研究进展¶

4.1 性能优化的突破性研究¶

2020 年以来，分布式数据库事务隔离的研究重点逐渐从理论完善转向性能优化。传统的事务隔离机制往往在保证数据一致性和系统性能之间存在难以调和的矛盾，而最新的研究正在努力打破这种僵局。

2024 年发表的《NOC-NOC: Towards Performance-optimal Distributed Transactions》代表了这一领域的最新突破。该研究提出了一个全新的设计目标 ——NOC-NOC，旨在同时优化读写操作的延迟和吞吐量。NOC-NOC 的核心思想包括：

• Non-blocking Concurrency Control（无阻塞并发控制）：读写操作都不需要等待锁释放

• One round-trip（单次往返）：事务提交只需一次网络往返

• Constant-size metadata（常量大小的元数据）：元数据不随事务大小或分区数量增长

该研究的重要贡献在于证明了不可能结果：支持并行快照隔离（PSI）或更强隔离级别的事务系统无法满足所有 NOC-NOC 标准。这一发现为后续的研究指明了方向，即需要探索更弱的隔离级别或创新的实现方式。

基于这些理论发现，研究者提出了两种新的事务算法：

1. RA-NOC2：提供读原子性（Read Atomicity）隔离保证

2. Eiger-NOC2：提供事务因果一致性（Transactional Causal Consistency with convergence, TCCv）隔离保证

实验结果显示，Eiger-NOC2 相比现有系统实现了显著的性能提升：

• 吞吐量提升高达 7%（在相同写延迟下）

• 写延迟降低高达 48%（在相同吞吐量下）

• 99% 分位延迟始终低于或等于对比系统

另一项重要研究是《Pushing the Limit: Verified Performance-Optimal Causally-Consistent Database Transactions》。该研究提出了 **Eiger-PORT+** 并发控制协议，首次实现了事务因果一致性（TCCv）的性能最优读事务。更重要的是，该研究通过演绎验证证明了 Eiger-PORT + 满足 TCCv 隔离级别，这是复杂并发控制协议的首次演绎验证。

4.2 新型隔离级别与算法¶

2020 年后，研究者们提出了多种新型隔离级别和并发控制算法，这些创新为分布式数据库提供了更多的选择。

** 广义快照隔离（Generalized Snapshot Isolation）** 是对传统快照隔离的重要扩展。与要求事务观察数据库 “最新” 快照的传统快照隔离不同，广义快照隔离允许使用 “更旧” 的快照，这大大简化了复制数据库的实现。研究表明，在特定的工作负载假设下，广义快照隔离的执行是可序列化的。

确定性并发控制（Deterministic Concurrency Control）代表了另一个重要方向。传统的确定性数据库只能支持可序列化一种隔离级别，而新的研究提出了DCC 系列算法，包括：

• DCC-RC：用于读已提交隔离级别

• DCC-RR：用于可重复读隔离级别

• DCC-SI：用于快照隔离级别

• DCC-SE：用于可序列化隔离级别

DCC 的创新之处在于允许混合使用这些隔离级别，应用程序可以为每个事务指定特定的隔离级别。这种灵活性在区块链等新兴应用中特别有价值，因为许多区块链应用并不需要最高级别的隔离保证。

** 前缀一致快照隔离（Prefix-Consistent Snapshot Isolation）** 是广义快照隔离的一个有趣实例。在这种隔离级别下，快照至少包含本地提交事务的所有写操作。其优势在于：

• 只读事务永远不会阻塞

• 连续提交的事务能够观察到前序事务的更新

• 提供了良好的性能和数据新鲜度平衡

基于向量时钟的隔离机制也取得了重要进展。向量时钟技术被广泛用于捕获事务的独立性，特别是在账户型区块链系统中。通过使用部分有序而非全序的方式，向量时钟能够显著减少不必要的串行化，提高系统吞吐量。

4.3 形式化验证的最新进展¶

形式化验证技术在 2020 年后取得了重大突破，为分布式数据库事务隔离的正确性提供了强有力的保证。

2025 年发表的《Weak Isolation Levels in Separation Logic》是这一领域的里程碑式成果。该研究首次使用 ** 分离逻辑（Separation Logic）** 对弱隔离级别进行了形式化规范，包括：

• 读未提交（Read Uncommitted）

• 读已提交（Read Committed）

• 快照隔离（Snapshot Isolation）

研究的主要贡献包括：

1. 为弱隔离级别提供了第一个模块化的分离逻辑规范

2. 形式化证明了快照隔离蕴含读已提交，读已提交蕴含读未提交

3. 实现并验证了基于原始快照隔离论文中 MVCC 算法的内存键值数据库

所有结果都在 Rocq 证明器（原 Coq）中使用 Iris 分离逻辑框架进行了机械化验证，证明代码超过 5000 行。

Plume 系统代表了另一个重要进展。Plume 是第一个高效、完整的弱隔离级别黑盒检查器，它基于模块化、细粒度的事务异常模式，为代表性的弱隔离级别建立了健全和完整的特征描述。Plume 利用向量和树时钟的新颖组合来加速隔离检查，能够：

• 重现大量异常数据库执行历史中的所有已知违规

• 在三个生产数据库中检测新的隔离错误并提供详细的反例

• 比最先进的检查器发现更多的弱隔离异常

4.4 跨异构数据存储的事务支持¶

随着数据存储技术的多样化发展，支持跨异构数据存储的事务成为了新的研究热点。2023 年发表的《Epoxy: ACID Transactions Across Diverse Data Stores》提出了一个创新的解决方案。

Epoxy 的核心创新包括：

1. 跨数据存储的 MVCC：将多版本并发控制适配到跨数据存储场景，在记录元数据中存储版本信息

2. 全局事务快照：使用元数据谓词过滤读取操作，确保它们只看到全局事务快照中的记录版本

3. 原子提交协议：设计了一种不需要数据存储实现两阶段提交参与者协议的原子提交协议，只需要持久化写能力

Epoxy 已经在五种不同的数据存储上实现：

• PostgreSQL

• Elasticsearch

• MongoDB

• Google Cloud Storage

• MySQL

性能评估显示，Epoxy 在 TPC-C 基准测试上的性能与分布式事务协议 XA 相当，但提供了更强的隔离保证。在只读微服务工作负载上，Epoxy 相比非事务基线的开销小于 10%；在写密集型工作负载上，开销为 72%。

4.5 区块链与数据库融合的新方向¶

区块链技术与传统数据库的融合代表了分布式事务处理的新方向。2019 年发表的《Blockchain Meets Database: Design and Implementation of a Blockchain Relational Database》提出了区块链关系数据库的概念。

该研究的核心贡献包括：

1. 设计了两种方法：

• 方法一：在执行事务前就事务提交顺序达成共识

• 方法二：在不知道提交顺序的情况下执行事务，同时并行确定顺序

1. 利用 ** 可序列化快照隔离（SSI）** 保证跨节点副本的一致性

2. 设计了基于块高度的 SSI 变体，专门用于区块链场景

研究团队在 PostgreSQL 上实现了该系统，并进行了详细的性能实验。结果表明，这种融合架构能够充分利用关系数据库的成熟功能和区块链的分布式特性。

另一项重要研究是《Lockless Transaction Isolation in Hyperledger Fabric》。Hyperledger Fabric 是 Linux 基金会托管的许可区块链分布式操作系统，它引入了执行 – 排序 – 验证架构，允许事务执行和验证的并行化。该研究提出了一种无锁方法来提供事务隔离，利用数据库中现有的键值对版本控制来创建基于版本的快照事务隔离。实验结果显示，新方法的性能比当前实现高 8.1 倍，与不应用隔离机制的最优解决方案相当。

4.6 地理复制环境下的创新¶

地理分布式数据库的事务处理一直是一个极具挑战性的问题。2025 年发表的《Mako: Speculative Distributed Transactions with Geo-Replication》提出了一种创新的解决方案。

Mako 的核心创新是将事务执行与复制解耦，实现了推测性执行：

1. 首先在分片领导者之间执行和认证事务

2. 在后台执行跨数据中心的并行状态机地理复制

3. 同时继续推测性执行新事务

Mako 的关键技术包括：

• 推测性两阶段提交（2PC）：允许分布式事务在等待复制完成前继续执行

• 分布式向量时钟：作为粗粒度依赖跟踪方法，结合矢量化水印技术选择性回滚受影响的事务

• 无界级联中止防护：防止分片在复制完成前失败导致的级联中止

实验结果显示，Mako 在 Azure 上处理 10 个分片（每个分片 24 个线程）时，每秒可处理 366 万 TPC-C 事务，比最先进的地理复制优化系统高 8.6 倍吞吐量。

另一项重要研究是《GeoGauss: Strongly Consistent and Light-Coordinated OLTP for Geo-Replicated SQL Database》。GeoGauss 提出了一种全副本多主架构，通过以下创新实现了强一致性和轻量级协调：

• 多主 OCC（乐观并发控制）统一了数据复制和并发事务处理

• 基于 epoch 的增量状态合并规则

• 乐观异步执行

实验结果显示，在 TPC-C 基准测试上，GeoGauss 比最先进的地理分布式数据库 CockroachDB 实现了 7.06 倍更高的吞吐量和 17.41 倍更低的延迟。

5. 性能优化策略与基准测试¶

5.1 不同隔离级别下的性能对比¶

在分布式数据库系统中，不同的隔离级别对性能有着显著的影响。通过对主流系统的性能基准测试，我们可以更清楚地了解各种隔离级别的性能特征。

CockroachDB 的性能基准测试提供了令人印象深刻的数据。CockroachDB 成功通过了 100,000 仓库的 TPC-C 基准测试，最大吞吐量达到 120 万 tpmC，比 Amazon Aurora 的最后发布基准高 100 倍。更重要的是，CockroachDB 能够在保持可序列化隔离级别的同时实现如此高的性能，这与其他系统通过降级隔离级别来提升性能形成了鲜明对比。

具体性能对比数据如下：

系统	最大吞吐量 (tpmC)	效率	新订单事务 p95 延迟 (ms)	最大仓库数	最大行数 (十亿)	未复制数据 (TB)
Amazon Aurora	12,582	97.84%	未报告	1,000	0.499	0.08
CockroachDB 18.2	631,851	98.27%	1140.90	50,000	24.9	4
CockroachDB 19.2	1,245,462	98.81%	486.50	100,000	49.8	8

从数据可以看出，CockroachDB 不仅在吞吐量上远超 Aurora，在延迟控制上也表现优异。特别是在 100,000 仓库规模下，CockroachDB 19.2 的 p95 延迟仅为 486.50ms，这在分布式数据库中是非常出色的表现。

TiDB 的性能特征显示了快照隔离的优势。TiDB 的快照隔离（SI）级别相比读已提交（RC）级别，在某些场景下能够提供更好的性能。这是因为 SI 级别通过避免幻读检查，可以减少一些额外的开销。但在写密集型工作负载下，SI 级别的乐观事务模型可能导致更高的重试率，从而影响整体性能。

隔离级别对并发性能的影响呈现出明显的规律性：

• 读未提交：提供最高的并发性能，因为几乎不使用任何锁机制

• 读已提交：在大多数 OLTP 应用中是性能和一致性的最佳平衡点

• 可重复读 / 快照隔离：在写冲突较少的场景下表现良好，但在高并发写场景下可能出现较多重试

• 可序列化：提供最强的一致性保证，但通常伴随着显著的性能开销

5.2 优化策略的技术分析¶

基于最新的研究成果和实践经验，分布式数据库在事务隔离性能优化方面形成了多种有效的策略。

混合隔离级别策略是近年来的重要创新。传统的数据库系统通常要求整个事务使用单一的隔离级别，而新的研究表明，根据事务的不同操作动态调整隔离级别可以显著提升性能。例如：

• 只读操作使用快照隔离以避免锁竞争

• 更新操作使用可重复读级别保证一致性

• 关键的写操作使用可序列化级别确保正确性

智能锁优化技术包括多种策略：

1. 锁后限定（LAQ）优化：在读取数据时不立即获取锁，而是在评估查询谓词后再决定是否需要加锁。这种方法需要读已提交快照隔离（RCSI）的支持。

2. 锁粒度优化：根据数据访问模式动态调整锁的粒度。例如，在范围查询时使用更细粒度的键范围锁，而不是全表锁。

3. 锁超时机制：为锁设置合理的超时时间，避免长时间等待导致的性能下降。

基于机器学习的自适应优化代表了未来的发展方向：

• 分析历史事务模式，预测未来的锁冲突

• 动态调整事务优先级，减少死锁概率

• 根据工作负载特征自动选择最优的隔离级别

• 预测热点数据，提前进行锁优化

硬件加速技术的应用也带来了性能提升：

• 使用 RDMA 技术减少网络延迟，特别是在跨数据中心的场景下

• 利用多核 CPU 并行处理事务，通过无锁数据结构减少线程竞争

• 使用 SSD 等高速存储设备减少 I/O 延迟，提升事务处理速度

批处理优化策略包括：

• 批量提交：将多个小事务合并为一个大事务，减少提交开销

• 批量读取：使用预取技术，一次性读取多个相关数据

• 批量写入：将多个写操作合并，减少锁竞争和日志写入次数

5.3 实际应用场景的性能表现¶

不同的应用场景对事务隔离的需求和性能要求各不相同，了解实际应用中的性能表现对于选择合适的隔离级别至关重要。

电商订单处理场景是典型的 OLTP 应用，其特点包括：

• 大量的读操作（查询商品信息、库存等）

• 相对较少的写操作（创建订单、更新库存等）

• 对一致性要求高（订单不能重复、库存不能超卖）

在这种场景下，读已提交隔离级别通常是最佳选择。TiDB 的性能数据显示，在电商场景下使用读已提交级别，系统能够达到很高的并发处理能力，同时保证数据的一致性。

金融交易场景对隔离级别要求最高，通常需要可序列化隔离：

• 严格的一致性要求（账户余额不能为负、交易必须可追溯）

• 相对较低的并发度（与电商相比）

• 对延迟敏感（用户期望快速响应）

在这种场景下，CockroachDB 的可序列化隔离表现出色，能够在保证强一致性的同时提供可接受的性能。其 p95 延迟在 486.50ms，这在金融交易中是可以接受的。

社交媒体数据处理具有独特的特征：

• 极高的并发度（ millions of users）

• 对一致性要求相对宽松（最终一致性通常可接受）

• 读多写少的模式

在这种场景下，使用快照隔离或更低的隔离级别能够获得更好的性能。基于向量时钟的隔离机制在这种场景下特别有效，能够在保证最终一致性的同时提供极高的吞吐量。

地理分布式应用面临特殊的挑战：

• 跨数据中心的网络延迟

• 分区容忍性要求

• 数据就近访问需求

Mako 和 GeoGauss 等系统在地理分布式场景下的表现显示，通过创新的架构设计和算法优化，能够在保持强一致性的同时获得良好的性能。例如，GeoGauss 比 CockroachDB 实现了 7.06 倍更高的吞吐量和 17.41 倍更低的延迟。

5.4 与传统集中式数据库的对比¶

分布式数据库与传统集中式数据库在事务隔离性能上的对比，反映了不同架构设计的优劣。

性能对比数据显示了显著差异：

• 集中式数据库通常在单节点性能上占优，特别是在小数据集的情况下

• 分布式数据库在大数据集和高并发场景下表现更好

• 分布式数据库的性能可扩展性远超集中式数据库

以 TPC-C 基准测试为例，现代分布式数据库如 CockroachDB 已经能够达到 120 万 tpmC 的吞吐量，这远超大多数集中式数据库的性能。更重要的是，分布式数据库能够通过增加节点来线性扩展性能，而集中式数据库受限于单机性能。

隔离机制的差异主要体现在：

1. 锁机制复杂度：集中式数据库的锁管理相对简单，而分布式数据库需要处理跨节点的锁协调

2. 时间同步需求：分布式数据库需要全局时间同步（如 Spanner 的 TrueTime），而集中式数据库不需要

3. 故障恢复复杂度：分布式数据库的故障恢复涉及多个节点的协调，而集中式数据库相对简单

4. 一致性保证：分布式数据库在保证强一致性方面面临更大挑战，需要更复杂的协议

成本效益分析显示：

• 集中式数据库的硬件成本通常较低，但扩展性有限

• 分布式数据库的硬件成本较高，但能够处理更大规模的数据和更高的并发

• 在大规模应用中，分布式数据库的总体拥有成本（TCO）通常更低

6. 未来发展趋势与挑战¶

6.1 云原生环境下的新需求¶

随着云原生技术的快速发展，分布式数据库事务隔离面临着前所未有的挑战和机遇。根据 Gartner 的预测，到 2025 年，75% 的数据库将迁移到云系统，超过 50% 将采用多模型或混合解决方案。这种大规模的迁移趋势正在重塑数据库的设计理念和技术架构。

容器化部署带来的新挑战包括：

• 动态资源分配：容器的生命周期短、迁移频繁，要求数据库能够快速适应资源变化

• 服务网格集成：需要与 Istio 等服务网格技术无缝集成，实现分布式事务的跨服务协调

• 微服务架构适配：支持细粒度的服务间事务，同时保证性能和一致性

Serverless 架构的影响：

Serverless 计算模式要求数据库能够自动扩缩容，按需分配资源。这种模式对事务隔离提出了新的要求：

• 无状态事务处理：事务状态不能依赖于特定的计算节点

• 快速启动：事务处理必须能够在毫秒级内启动

• 成本优化：通过智能调度减少资源浪费

多云和跨云需求：

企业越来越多地采用多云策略，这要求数据库能够：

• 支持跨云的数据同步和事务处理

• 在不同云平台间保持一致的隔离语义

• 处理不同云服务商的网络延迟差异

6.2 新兴技术的融合应用¶

多项新兴技术正在与分布式数据库事务隔离技术深度融合，带来革命性的变化。

机器学习的全面应用：

机器学习技术在事务隔离优化中展现出巨大潜力：

1. 智能隔离级别选择：根据实时工作负载特征，自动选择最优的隔离级别

2. 死锁预测与避免：通过分析历史数据和实时监控，预测死锁发生的概率并提前干预

3. 查询优化：学习查询模式，优化执行计划，减少锁竞争

4. 自适应参数调优：动态调整缓冲池大小、锁超时时间等关键参数

硬件加速技术的突破：

• RDMA（远程直接内存访问）：显著减少网络延迟，特别是在跨数据中心的场景下

• NVM（非易失性内存）：提供接近内存的访问速度和持久化存储的可靠性

• GPU 加速：利用 GPU 的并行处理能力加速复杂的事务处理

• FPGA 定制化：通过硬件编程实现特定的事务处理逻辑

量子计算的潜在影响：

虽然量子计算仍处于早期阶段，但其对数据库技术的潜在影响不容忽视：

• 量子密码学：提供更安全的事务认证和数据加密

• 量子算法：可能革新复杂查询的执行方式

• 量子随机数生成：为分布式系统提供更好的随机源

边缘计算的协同：

边缘计算与分布式数据库的结合带来新的机遇：

• 就近数据处理：减少数据传输延迟，提高事务处理速度

• 分布式智能：在边缘节点进行智能决策，减轻中心数据库压力

• 离线事务支持：在网络不稳定时保证事务的正常执行

6.3 标准化演进方向¶

数据库标准的演进反映了技术发展的趋势和业界的共识。未来的标准化工作将重点关注以下方向：

扩展隔离级别定义：

现有的 ANSI SQL 标准已经不能满足现代应用的需求，未来的标准需要：

• 明确定义快照隔离（SI）和可序列化快照隔离（SSI）

• 引入新的隔离级别，如因果一致性、会话一致性等

• 为每种隔离级别提供清晰的异常保证和性能特征

跨数据存储的事务标准：

随着数据存储技术的多样化，需要制定跨异构数据存储的事务标准：

• 定义统一的事务接口，支持不同类型的数据存储

• 制定跨存储的原子性、一致性保证规范

• 建立统一的错误处理和回滚机制

分布式事务的形式化规范：

• 为分布式事务提供数学化的正确性定义

• 建立统一的验证方法和工具标准

• 制定性能基准测试的标准方法

6.4 面临的技术挑战¶

尽管分布式数据库事务隔离技术取得了巨大进步，但仍面临诸多挑战。

一致性与可用性的权衡：

CAP 理论告诉我们，在分布式系统中无法同时保证一致性、可用性和分区容忍性。未来的研究需要在这三者之间找到更好的平衡点，特别是在广域网环境下。

性能与隔离级别的矛盾：

强隔离级别往往伴随着性能损失，如何在保证强一致性的同时获得接近弱隔离级别的性能，是一个持续的挑战。

异构系统的集成：

企业通常使用多种不同的数据库系统，如何在这些异构系统间实现统一的事务隔离保证，是一个复杂的技术难题。

安全与隐私保护：

随着数据隐私法规的日益严格，数据库需要在保证事务隔离的同时，提供更强的数据保护机制。这包括加密数据上的事务处理、隐私计算等技术。

故障恢复的复杂性：

分布式系统的故障恢复涉及多个节点的协调，如何在保证数据一致性的同时实现快速恢复，仍然是一个挑战。

6.5 产业生态的发展机遇¶

分布式数据库事务隔离技术的发展也为产业生态带来了新的机遇。

数据库即服务（DBaaS）的兴起：

云服务商正在将数据库服务化，这为事务隔离技术的标准化和产品化提供了机会。通过提供统一的事务接口和管理工具，降低了企业使用分布式数据库的门槛。

开源生态的繁荣：

开源数据库项目的成功（如 TiDB、CockroachDB）证明了开源模式在分布式数据库领域的可行性。开源不仅促进了技术创新，也加速了最佳实践的传播。

专业化工具链的完善：

围绕分布式数据库的工具链正在快速完善，包括：

• 性能监控和调优工具

• 数据迁移和同步工具

• 事务跟踪和分析工具

• 自动化运维工具

人才培养的需求：

分布式数据库技术的复杂性对人才提出了更高要求。这催生了新的培训和认证体系，为相关专业人士提供了新的职业发展机会。

7. 总结¶

分布式数据库事务隔离技术的发展历程是一个从简单到复杂、从理论到实践、从单一到多元的演进过程。从 1992 年 ANSI SQL 标准定义的四种隔离级别，到 1995 年的批判性反思，再到 1999 年的形式化理论突破，每一步都推动着整个行业的进步。

21 世纪以来，特别是 2020 年以后，分布式数据库事务隔离技术呈现出以下重要特征：

1. 理论体系的完善：从最初的经验性定义发展为严格的数学理论，形式化验证技术的成熟为系统正确性提供了强有力的保证。

2. 实现方式的多样化：从传统的锁机制到 MVCC、从悲观并发控制到乐观并发控制、从单一隔离级别到混合隔离策略，技术选择更加丰富。

3. 性能的显著提升：通过创新的架构设计和算法优化，现代分布式数据库能够在保证强一致性的同时提供优异的性能。例如，CockroachDB 达到 120 万 tpmC 的吞吐量，Mako 实现了比传统系统高 8.6 倍的性能。

4. 应用场景的扩展：从传统的 OLTP 应用扩展到金融、电商、社交媒体、地理分布式等多样化场景，每种场景都有相应的优化方案。

5. 新兴技术的融合：机器学习、硬件加速、区块链、云原生等技术与事务隔离技术的深度融合，为未来发展开辟了广阔空间。

展望未来，分布式数据库事务隔离技术将在以下方向继续发展：

• 智能化：通过机器学习实现自适应的隔离级别选择和性能优化

• 云原生化：更好地适应容器化、微服务、Serverless 等云原生架构

• 标准化：制定更完善的标准以适应新技术和新需求

• 性能突破：通过软硬件协同优化，在保证强一致性的同时实现更高性能

• 生态繁荣：开源社区的持续创新和产业生态的不断完善

分布式数据库事务隔离技术的发展不仅推动了数据库技术本身的进步，也为整个信息技术产业的发展奠定了坚实基础。随着技术的不断成熟和应用场景的持续扩展，我们有理由相信，分布式数据库将在未来的数字经济中发挥更加重要的作用。

对于数据库研究者和实践者而言，深入理解事务隔离的理论基础、掌握主流系统的实现原理、关注最新的技术发展趋势，是在这个快速变化的时代保持竞争力的关键。同时，我们也期待更多的创新和突破，推动分布式数据库技术走向新的高度。

参考资料

[1] NOC-NOC: Towards Performance-optimal Distributed Transactions https://www.research-collection.ethz.ch/bitstream/20.500.11850/665216/1/main.pdf

[2] Generalized Snapshot Isolation and a Prefix-Consistent Implementation https://core.ac.uk/download/147902755.pdf

[3] Pushing the Limit: Verified Performance-Optimal Causally-Consistent Database Transactions https://arxiv.org/pdf/2411.07049

[4] Reasoning about Weak Isolation Levels in Separation Logic https://arxiv.org/pdf/2501.14421

[5] SoK: TEE-assisted Confidential Smart Contract https://arxiv.org/pdf/2203.08548

[6] Epoxy: ACID Transactions Across Diverse Data Stores https://dl.acm.org/doi/abs/10.14778/3611479.3611484

[7] Lockless Blockchain Sharding with Multiversion Control https://arxiv.org/pdf/2303.17105

[8] SYSTEM AND METHOD OF PERFORMING SNAPSHOT ISOLATION IN DISTRIBUTED DATABASES https://www.researchgate.net/publication/302817710_System_and_method_of_performing_snapshot_isolation_in_distributed_databases/fulltext/57b4b34e08ae19a365faf1bc/System-and-method-of-performing-snapshot-isolation-in-distributed-databases.pdf

[9] Efficient Deterministic Concurrency Control Under Practical Isolation Levels https://www.semanticscholar.org/paper/Efficient-Deterministic-Concurrency-Control-Under-Lai/7a13450e1601f8559a690d00bb5e7309e0fcb2f6

[10] Blockchain Meets Database: Design and Implementation of a Blockchain Relational Database https://arxiv.org/pdf/1903.01919

[11] TiDB 事务隔离级别-CSDN博客 https://blog.csdn.net/justlpf/article/details/127533422

[12] TiDB Pessimistic Transaction Mode https://docs.pingcap.com/tidbcloud/pessimistic-transaction/

[13] Transaction Restraints https://docs.pingcap.com/tidb/v7.1/dev-guide-transaction-restraints/

[14] COMMIT https://docs.pingcap.com/tidb/dev/sql-statement-commit/

[15] Transaction overview https://docs.pingcap.com/tidb/stable/dev-guide-transaction-overview/

[16] TiDB Optimistic Transaction Model https://docs.pingcap.com/tidb/stable/optimistic-transaction/

[17] Serializable Transactions https://www.cockroachlabs.com/docs/v25.1/demo-serializable

[18] Transactions https://www.cockroachlabs.com/docs/v21.1/transactions

[19] Serializable, lockless, distributed: Isolation in CockroachDB https://www.cockroachlabs.com/blog/serializable-lockless-distributed-isolation-cockroachdb/

[20] CockroachDB SQL开发基础 ——事务隔离级别和并发控制介绍 (1)_cockroachdb 事务隔离-CSDN博客 https://blog.csdn.net/u011782423/article/details/83213137

[21] Dynamic Timestamp Allocation for Reducing Transaction Aborts https://sites.cs.ucsb.edu/\~vaibhavarora/dynamicTimestampOrdering-IEEECloud-2018.pdf

[22] Serializable Isolation https://www.cockroachlabs.com/glossary/distributed-db/serializable-isolation/

[23] 分離レベルの概要 https://cloud.google.com/spanner/docs/isolation-levels?authuser=9\&hl=ja

[24] Class TransactionOptions https://googleapis.dev/dotnet/Google.Apis.Spanner.v1/latest/api/Google.Apis.Spanner.v1.Data.TransactionOptions.html

[25] Isolation levels overview https://cloud.google.com/spanner/docs/isolation-levels

[26] What is an ACID transaction in distributed databases? https://milvus.io/ai-quick-reference/what-is-an-acid-transaction-in-distributed-databases

[27] Distributed Systems Week 9: Sp http://krzyzanowski.org/417/notes/pdf/09c-spanner-slides-annotated.pdf

[28] Google Spanner vs. Calvin: Is There a Clear Winner in the Battle for Global Consistency at Scale? https://www.yugabyte.com/blog/google-spanner-vs-calvin-global-consistency-at-scale/

[29] Spanner: Google’s Globally-Distributed Database https://mwhittaker.github.io/prelim_notes/html/spanner-googles-globally-distributed-database.html

[30] Mako: Speculative Distributed Transactions with Geo-Replication https://www.usenix.org/system/files/osdi25-shen-weihai.pdf

[31] NOC-NOC: Towards Performance-optimal Distributed Transactions https://www.research-collection.ethz.ch/bitstream/20.500.11850/665216/1/main.pdf

[32] Blockchain Meets Database: Design and Implementation of a Blockchain Relational Database https://arxiv.org/pdf/1903.01919

[33] GeoGauss: Strongly Consistent and Light-Coordinated OLTP for Geo-Replicated SQL Database https://arxiv.org/pdf/2304.09692

[34] Lockless Transaction Isolation in Hyperledger Fabric https://arxiv.org/pdf/1911.12711

[35] Pushing the Limit: Verified Performance-Optimal Causally-Consistent Database Transactions https://arxiv.org/pdf/2411.07049

[36] The Binary Vector Clock https://arxiv.org/pdf/2004.07087

[37] CockroachDB: The Resilient Geo-Distributed SQL Database https://www.researchgate.net/profile/Irfan-Sharif-2/publication/341744190_CockroachDB_The_Resilient_Geo-Distributed_SQL_Database/links/630f9b7facd814437feff7a4/CockroachDB-The-Resilient-Geo-Distributed-SQL-Database.pdf

[38] Efficient Deterministic Concurrency Control Under Practical Isolation Levels https://www.semanticscholar.org/paper/Efficient-Deterministic-Concurrency-Control-Under-Lai/7a13450e1601f8559a690d00bb5e7309e0fcb2f6

[39] When Scalability Meets Consistency: Genuine Multiversion Update-Serializable Partial Data Replication https://www.dpss.inesc-id.pt/\~romanop/files/papers/icdcs12.pdf

[40] Epoxy: ACID Transactions Across Diverse Data Stores https://www.vldb.org/pvldb/vol16/p2742-kraft.pdf

[41] Plume: Efficient and Complete Black-Box Checking of Weak Isolation Levels https://dl.acm.org/doi/pdf/10.1145/3689742

[42] Scalable OLTP in the Cloud: What’s the BIG DEAL? The Database AND the Application Have a BIG DEAL: Their Isolation Semantics https://www.cidrdb.org/cidr2024/papers/p63-helland.pdf

[43] CockroachDB vs. Aurora: Who passes TPC-C at 100k warehouses? https://www.cockroachlabs.com/blog/tpcc-100k/

[44] TPC-C Update 2024 https://www.dolthub.com/blog/2024-03-06-tpcc-update-2/

[45] Open Telekom Cloud MySQL RDS: a leading DBaaS https://www.open-telekom-cloud.com/en/support/downloads/benchmark-mysql-rds

[46] How we stress test and benchmark CockroachDB for global scale https://www.cockroachlabs.com/blog/how-we-stress-test-and-benchmark-cockroachdb-for-global-scale/

[47] 金仓数据库MVCC机制在高并发读写隔离中的实践与优化-腾讯云开发者社区-腾讯云 https://cloud.tencent.cn/developer/article/2591853?policyId=1004

[48] How does intelligent database operation and maintenance optimize database transaction isolation levels? – Tencent Cloud https://www.tencentcloud.com/techpedia/128600

[49] Efficient Transaction Management in MS SQL – Tips and Techniques for Optimizing Database Performance https://moldstud.com/articles/p-efficient-transaction-management-in-ms-sql-tips-and-techniques-for-optimizing-database-performance

[50] Concurrency Control Techniques in Distributed DBMSs: A Comparative Study https://www.researchgate.net/profile/Manoj-Gupta-12/publication/333843970_Concurrency_Control_Techniques_in_Distributed_DBMSs_A_Comparative_Study/links/5d08a63b92851cfcc61f7c09/Concurrency-Control-Techniques-in-Distributed-DBMSs-A-Comparative-Study.pdf

[51] Aurora DSQL: How the Latest Distributed SQL Database Compares to YugabyteDB https://www.yugabyte.com/blog/aurora-dsql-compared-to-yugabytedb

[52] On Using an Abstract Model of Distributed Database Concurrency Control Methods. https://www.researchgate.net/profile/Martin-Rennhackkamp/publication/220459294_On_Using_an_Abstract_Model_of_Distributed_Database_Concurrency_Control_Methods/links/5805741808aef179365e70b3/On-Using-an-Abstract-Model-of-Distributed-Database-Concurrency-Control-Methods.pdf

[53] 分布式数据库系统:规则、挑战与未来趋势 – CSDN文库 https://wenku.csdn.net/column/ftfi65a98j

[54] The Future of Databases – Key Questions Every Back End Developer Should Consider https://moldstud.com/articles/p-the-future-of-databases-key-questions-every-back-end-developer-should-consider

[55] Data Decentralization: How to Break Silos and Drive Insights https://www.acceldata.io/blog/data-decentralization-how-to-break-silos-and-drive-insights

[56] Why distributed SQL is better for businesses in 2025 https://www.cockroachlabs.com/blog/why-distributed-sql-better-business/

[57] Database Trends and Innovations: A Comprehensive Outlook for 2025 https://www.rapydo.io/blog/database-trends-and-innovations-a-comprehensive-outlook-for-2025

[58] ACID vs BASE Database Expert Use Cases And Future Trends 2025 https://www.spotsaas.com/blog/acid-vs-base-database/

[59] 天翼云数据库分布式事务处理:剖析 ACID 特性在云原生环境下的实现，保障数据一致性-天翼云开发者社区 – 天翼云 https://www.ctyun.cn/developer/article/697689687818309

[60] TiDB Introduction https://docs.pingcap.com/tidb/stable/overview

[61] Transaction Isolation in App Engine https://cloud.google.com/datastore/docs/articles/transaction_isolation

[62] No Dirty Reads: Everything you always wanted to know about SQL isolation levels (but were too afraid to ask) https://www.cockroachlabs.com/blog/sql-isolation-levels-explained/

[63] Transaction serializability and isolation https://firebase.google.com/docs/firestore/transaction-data-contention?authuser=1

[64] Fundamentals of Distributed Transactions https://docs.yugabyte.com/preview/architecture/transactions/transactions-overview/

[65] googleapis documentation https://googleapis.dev/nodejs/googleapis/latest/spanner/interfaces/Schema\$TransactionOptions.html

[66] How does intelligent database operation and maintenance optimize database transaction isolation levels? – Tencent Cloud https://www.tencentcloud.com/techpedia/128600

[67] 智能索引革命:机器学习驱动的数据库性能优化新范式-天翼云开发者社区 – 天翼云 https://www.ctyun.cn/developer/article/733784549769285

[68] How does intelligent database operation and maintenance achieve automated database parameter optimization? – Tencent Cloud https://www.tencentcloud.com/techpedia/128597

[69] Mastering DynamoDB Transactions – A Guide for Machine Learning Applications https://moldstud.com/articles/p-mastering-dynamodb-transactions-a-guide-for-machine-learning-applications

[70] Machine Learning and Big Data – The Perfect Partnership for Database Administrators https://moldstud.com/articles/p-machine-learning-and-big-data-the-perfect-partnership-for-database-administrators

[71] Adaptive and Scalable Database Management with Machine Learning Integration: A PostgreSQL Case Study https://tijer.org/tijer/viewpaperforall.php?paper=TIJER2506219