MySQL的正确性为何如此拉垮？

JEPSEN 与 Hermitage 指出：MySQL 的事务 ACID 存在显著缺陷，且与文档承诺不符。这会导致正确性问题，在关键场景使用 MySQL 时请谨慎。

太长不看

正确性为什么很重要？

Hermitage 的结果怎么说？

JEPSEN 又有什么新发现？

隔离性问题：不可重复读

原子性问题：非单调视图

串行化问题：鸡肋且糟糕

正确性与性能的利弊权衡

参考阅读

太长；不看

MySQL 曾经是世界上最流行的开源关系型数据库，然而流行并不意味着先进，流行的东西也会出大问题。JEPSEN[1] 对 MySQL 的评测捅穿了这层窗户纸 —— 在正确性这个体面数据库产品必须的基本属性上，MySQL的表现一塌糊涂。

MySQL 文档声称实现了 可重复读/RR 隔离等级，但实际提供的正确性保证却弱得多。JEPSEN 在 Hermitage 的研究基础上进一步指出，MySQL 的 可重复读/RR 隔离等级实际上并不可重复读，甚至既不原子也不单调，连 单调原子视图/MAV 的基本水平都不满足。

此外，能“避免”这些异常的 MySQL 可串行化/SR 隔离等级难以生产实用，也非官方文档与社区认可的最佳实践；而且在AWS RDS默认配置下，MySQL SR 也没有真正达到“串行化”的要求；而李海翔教授的对 MySQL 一致性的分析进一步指出了 SR 的设计缺陷与问题。

综上， MySQL 的 ACID 存在缺陷，且与文档承诺不符 —— 这可能会导致严重的正确性问题。尽管可以通过显式加锁等方式规避此类问题，但用户确实应当充分意识到这里的利弊权衡与风险：在对正确性/一致性有要求的场景中选用 MySQL 时，请务必保持谨慎。

正确性为什么很重要？

可靠的系统需要应对各种错误，在数据系统的残酷现实中，更是很多事情都可能出错。要保证数据不丢不错，实现可靠的数据处理是一件工作量巨大且极易错漏的事情。而事务的出现解决了这个问题。事务是数据处理领域最伟大的抽象之一，也是关系型数据库引以为傲的金字招牌和尊严所在。

事务这个抽象让所有可能的结果被归结为两种情况：要么成功完事 COMMIT，要么失败了事 ROLLBACK，有了后悔药，程序员不用再担心处理数据时半路翻车，留下数据一致性被破坏的惨不忍睹的车祸现场。应用程序的错误处理变得简单多了，因为它不用再担心部分失败的情况了。而它提供的保证，用四个单词的缩写，被概括为 ACID。

事务的原子性/A让你在提交前能随时中止事务并丢弃所有写入，相应地，事务的持久性/D则承诺一旦事务成功提交，即使发生硬件故障或数据库崩溃，写入的任何数据也不会丢失。事务的隔离性/I确保每个事务可以假装它是唯一在整个数据库上运行的事务 —— 数据库会确保当多个事务被提交时，结果与它们一个接一个地串行运行是一样的，尽管实际上它们可能是并发运行的。而原子性与隔离性则服务于 一致性/Consistency —— 也就是应用的正确性/Correctness —— ACID 中的C是应用的属性而非事务本身的属性，属于用来凑缩写的。

然而在工程实践中，完整的隔离性/I是很少见的 —— 用户很少会使用所谓的 “可串行化/SR” 隔离等级，因为它有可观的性能损失。一些流行的数据库如 Oracle 甚至没有实现它 —— 在 Oracle 中有一个名为 “可串行化” 的隔离级别，但实际上它实现了一种叫做 快照隔离（snapshot isolation） 的功能，这是一种比可串行化更弱的保证。

RDBMS 允许使用不同的隔离级别，供用户在性能与正确性之间进行权衡。ANSI SQL92 用三种并发异常（Anomaly），划分出四种不同的隔离级别，将这种利弊权衡进行了（糟糕的）标准化。：更弱的隔离级别“理论上”可以提供更好的性能，但也会出现更多种类的并发异常（Anomaly），这会影响应用的正确性。

为了确保正确性，用户可以使用额外的并发控制机制，例如显式加锁或  SELECT FOR UPDATE ，但这会引入额外的复杂度并影响系统的简单性。对于金融场景而言，正确性是极其重要的 —— 记账错漏，对账不平很可能会在现实世界中产生严重后果；然而对于糙猛快的互联网场景而言，错漏几条数据并非不可接受 —— 正确性的优先级通常会让位于性能。

这也为伴随互联网东风而流行的 MySQL 的正确性问题埋下了祸根。

Hermitage 的结果怎么说？

在介绍 JEPSEN 的研究之前，我们先来回顾一下 Hermitage[2] 项目。这是互联网名著 《DDIA》 作者 Martin Kelppmann 在 2014 年发起的项目，旨在评测各种主流关系数据库的正确性。项目设计了一系列并发运行的事务场景，用于评定数据库标称隔离等级的实际水平。

从 Hermitage 的评测结果表格中不难看出，在主流数据库的隔离级别实现里有两处缺陷，用红圈标出：Oracle 的 可串行化/SR 因无法避免 G2 异常，而被认为实际上是 “快照隔离/SI”。

MySQL 的问题更为显著：因为默认使用的 可重复读/RR 隔离等级无法避免 PMP G-Single 异常，Hermitage 将其实际等级定为 单调原子视图/MAV。

需要指出 ANSI SQL 92 隔离等级是一个糟糕简陋且广为诟病的标准，它只定义了三种异常现象并用它们区分出四个隔离等级 —— 但实际上的异常种类/隔离等级要多得多。著名的《A Critique of ANSI SQL Isolation Levels》论文对此提出了修正，并介绍了几种重要的新隔离等级，并给出了它们之间的强弱关系偏序图（图左）。

在新的模型下，许多数据库的 “读已提交/RC” 与 “可重复读/RR” 实际上是更为实用的 “单调原子视图/MAV” 和 “快照隔离/SI” 。但 MySQL 确实别具一格：在 Hermitage 的评测中，MySQL的 可重复读/RR 与 快照隔离/SI 相距甚远，也不满足 ANSI 92 可重复读/RR 的标准，实际水平为 单调原子视图/MAV。而 JEPSEN 的研究进一步指出，MySQL 可重复读/RR 实际上连 单调原子视图/MAV 都不满足，仅仅略强于 读已提交/RC 。

JEPSEN 又有什么新发现？

JEPSEN 是分布式系统领域最为权威的测试框架，他们最近发布了针对 MySQL 最新的 8.0.34 版本的研究与测评。建议读者直接阅读原文，以下是论文摘要：

MySQL 是流行的关系型数据库。我们重新审视了 Kleppmann （DDIA作者）在2014年发起的 Hermitage[3] 项目结果，并确认了在当下 MySQL 的 可重复读/RR 隔离等级依然会出现 G2-item、G-single 和丢失更新异常。

我们用事务一致性检查组件 —— Elle，发现了 MySQL 可重复读隔离等级也违反了内部一致性。更有甚者 —— 它违反了单调原子视图（MAV）：即一个事务可以先观察到另一个事务的结果，再次尝试观察后却又无法复现同样的结果。

作为彩蛋，我们还发现 AWS RDS 的 MySQL集群经常出现违反串行要求的异常。这项研究是独立进行的，没有报酬，并遵循 Jepsen研究伦理[4]。

MySQL 8.0.34 的 RU，RC，SR 隔离等级符合 ANSI 标准的描述。且默认配置（RR，且innodb_flush_log_at_trx_commit = on
[5]）下的 持久性/D 并没有问题。问题出在MySQL 默认的 可重复读/RR 隔离等级上：

1.不满足 ANSI SQL92 可重复读（G2，WriteSkew）2.不满足快照隔离（G-single, ReadSkew, LostUpdate）3.不满足游标稳定性（LostUpdate）4.违反内部一致性（Hermitage 披露）5.违反读单调性（JEPSEN新披露）

 MySQL RR 下的事务观察到了违反内部一致性、单调性、原子性的现象。这使得其评级被进一步调整至一个仅略高于 RC 的未定隔离等级水平上。

在 JEPSEN 的测试中共披露了六项异常，其中在2014年已知的问题我们先跳过，这里重点关注 JEPSEN 的新发现的异常，下面是几个具体的例子。

隔离性问题：不可重复读

在这个测试用例（JEPSEN 2.3）中使用了一张表 people
 ，id
 作为主键，预填充一行数据。

CREATE TABLE people (
id int PRIMARY KEY,
name text not null,
gender text not null
);
INSERT INTO people (id, name, gender)
VALUES (0, "moss", "enby");