第三代分布式数据库（6）——没有价值的隔离级别
ANSI/ISO-SQL标准把隔离级别分为四个（读未提交、读已提交、可重复读、可串行化），这四个隔离级别只是被定义而没有被描述过其起因、定义时的初衷、以及定义分类的依据，如下我们从这三个角度来逐一分析：
1. 起因：可串行化隔离级别虽能很好保证数据正确性，但性能很差；---可是，大家验证过这个事情吗？比如，用多个场景测试一下MySQL V8.0，也许会有不一样的结论
2. 初衷：牺牲一定的数据正确性，换取较好的并发性能；---大家思考过这个事情吗？为什么在哪个级别牺牲某些数据正确性，就能换取好的性能？道理何在？
3. 定义方式：采取层进的方式从弱到强，定义不同的隔离级别，以逐级消除若干种数据异常。---可是，有谁曾告诉我们，隔离级别的层级是依据什么划分出来的？划分是否科学？
ANSI/ISO-SQL标准标准对隔离级别的定义方式，暗含了一层含义：即数据库引擎在实现隔离级别的时候，应“层进式”实现。所谓层进式的含义，是指较弱一级的隔离级别所消除数据异常的方法，应该被较强一级的隔离级别复用，然后较强一级的隔离级别再用新方法消除累增的本层隔离级别应该消除的数据异常。如果能够这样实现，则并发访问控制算法的实现就会非常简洁。那么，MySQL对隔离级别的工程实现，是“层进式”消除一些特定的数据异常吗？“层进式”消除数据异常的方法是科学的吗？
另外，从一致性八仙图上，我们可以看到，数据异常已经远不是ANSI/ISO-SQL标准所定义的四种，也不只是Jim Gray定义的八种，《数据库管理系统中数据异常体系化定义与分类》提出了33个种类（无数个异常）。那么，那些新数据异常应该被哪些隔离级别所隔离呢？
数据库的隔离级别，是一种鸡肋式的三无概念，无数据无理论无依据。没有数据表明其一定成立，本文后续以MySQL为例表明隔离级别的实现使得弱隔离级别并不会强于强隔离级别；没有科学的理论支撑其概念，数据异常未成体系则隔离级别不能成体系，本文后续会进行讨论；没有可信的依据支撑其理念，在既没有数据又没有理论支撑的情况下，退而求其次、如果有一点可信的依据也行，但遗憾的是：没有。
事实上，隔离级别的存在，使得并发算法在逻辑上变得混乱（陷于如上问题泥潭中不能自拔），在数据库实现引擎中使得代码实现变得混乱（数据异常复杂、情况众多，ANSI/ISO-SQL标准标准不具备可行性，代码层面不得不为各种数据异常复杂情况增加各类判断条件，混乱交织，更是难以理清头绪）。
客观地说，隔离级别几乎没有价值。CockroachDB，早期版本支持快照隔离和可串行化，后取消快照隔离只支持可串行化，是明智之举，分布式数据库未来应也将向其所行方向对齐。
既然隔离级别级别比较乱，那么，如何认知隔离级别呢？
《数据库管理系统中数据异常体系化定义与分类》一文提出隔离级别是可以灵活定义的，并根据所有的数据异常，给出了两种不同方式的隔离级别定义方法，一种是非常简化的可用于工程实践的隔离级别定义法，另外一种是比较详细的可用于教学的隔离级别定义方法。
该文表明：只有基于全部数据异常来定义隔离级别，隔离级别的定义才能更为科学，否则，将落入前述的“未被ANSI/ISO-SQL标准定义的、新的数据异常，应该被哪些隔离级别所隔离呢？”尴尬境地（ANSI/ISO-SQL标准标准即如此）。其实，数据异常是隔离级别和并发算法的基础与核心。
该文还表明：只有基于全部数据异常来设计并发算法，才能有效应对每一种情况，因具体情况设计具体的规则，最后形成最有效的并发算法。唯有此，才能有效指导数据库引擎的编码实现。
其实，采用精简的隔离级别定义方法，能更好地在数据库引擎中实施并发访问控制算法，使得并发算法的实现变得简单、简洁，增加引擎的健壮性；也使得数据库中最难理解、最繁杂的并发访问控制部分变得容易学习和理解。
更多内容，请参考《数据库管理系统中数据异常体系化定义与分类》。
如下，我们使用MySQL作为具体的示例，来看看MySQL数据库中，隔离级别的实现为MySQL引擎带来了什么优点和缺点？
MySQL同时使用封锁技术和MVCC技术，使得同一个数据异常在不同的隔离级别下，有着不同的处理方式。
MySQL的处理方式：
1. 没有遵从“强隔离级别包含弱隔离级别的能力”这一规则（传统的隔离级别定义是有层进关系的），例如，脏写异常被读已提交隔离级别避免，则读已提交隔离级别也一定会避免脏写异常。
2. 没有遵从“层进式”的实现方式。例如《第三代分布式数据库（5）——一无是处的MySQL》的表4和表5所示的Non-repeatable Read Committed即可表明这一点。
3. 另外，从一致性八仙图上也可以看出MySQL没有遵从“层进式”的实现方式。如果弱隔离级别消除了某个数据异常，则在强隔离级别下，当不应该有新的处理方式（如Read Skew Committed在可重复读级别下显示的是绿色的P，而在更高一级的可串行化级别下却是红色的D）。
MySQL如果采用“层进式”的实现方式，则会带来性能优化的效果。例如：既然Read Skew Committed在可重复读级别下已经被消除，则在可串行化级别下就不应该花费计算资源进行死锁检测，因此才能提高性能。但是MySQL偏偏在可串行化隔离级别下采用了不同于可重复读隔离级别的实现方式——死锁检测——来消除Read Skew Committed数据异常。
这样的例子其实很多，还包括：Write-read Skew Committed、Double-write Skew 1、Double-write Skew 1 Committed、Double-write Skew 2、Read Skew 2、Step RAT、Double-write Skew 2 Committed等。采用“层进式”的实现方式，则会在多个点上带来性能优化的效果。
可以说，隔离级别在MySQL中的实现，是混乱的。但是换种思维看，也许存在一种可能是——隔离级别的定义本身是混乱的，不能有效指导工程实现，所以MySQL中才会有混乱的实现。
正确答案是后者：第一节中，我们描述了原因。
而在历史上，Jim Gray、Adya都曾指出过ANSI/ISO-SQL标准对隔离级别定义的不科学性，他们并各自定义过新的隔离级别体系，只是他们的定义尚在有限的数据库异常范围内定义隔离级别，其思维方式依旧没有脱离ANSI/ISO-SQL标准的思维方式。因此其新定义尚不科学、不完备，没有掲示出隔离级别的本质。
《数据库管理系统中数据异常体系化定义与分类》的作者认为：
隔离级别只是数据异常的一种分类方式；ANSI/ISO-SQL标准是从数据库性能（外部视角）的角度对数据异常进行了分类，但是因基于有限的数据异常进行类别划分故不科学；只有基于全部数据异常、并根据每一类数据异常的特点设计适合的并发算法而划分出的隔离级别，才是科学的、完备的。
如下，我们再次使用MySQL作为具体的示例，来看看MySQL数据库中，隔离级别的实现为MySQL引擎的性能，带来了什么问题？
在《第三代分布式数据库（1）——踢球时代》一文的图4中，我们指出，MySQL“用户在应用中主动加锁导致数据库性能下降严重”。
其实从该图中，可以看出另外一个问题：MySQL在不同隔离级别下的性能相近（下图三个红色方框，比较了三种隔离级别的性能，几乎接近）。换句话说，ANSI/ISO-SQL标准的隔离级别机制，并未很好地达到定义隔离级别的初衷。
因此，ANSI/ISO-SQL标准定义的隔离级别是无效的，没有什么价值。
图1 用户在应用中主动加锁导致数据库性能下降严重，强隔离级别的性能并没有严重下降
前述我们以MySQL为例，讨论了MySQL实现的隔离级别存在的几个问题：
问题1：编程实现存在不符合标准的问题
问题2：实现方式有损性能的问题
问题3：现有的隔离级别实现效果并不符合弱隔离级别提升性能的初衷
问题4：隔离级别的实现较为混乱不简洁
在这些问题面前，MySQL的隔离级别实现方式真的可信吗？
对应MySQL隔离级别的四个问题，我们有机会可重新思考一下如下问题，相信您必然会有新的答案：
ANSI/ISO-SQL标准标准对于隔离级别的定义是否合理？（对应如上问题1）
ANSI/ISO-SQL标准标准定义的隔离级别，是否有助于并发性能的提升？（对应如上问题2和3）
ANSI/ISO-SQL标准标准定义的隔离级别，是否有助于简洁地编码？（对应如上问题4）
一个数据库的隔离级别的实现存在这样的问题，是MySQL自身的问题，还是所有数据库行业的问题？
虽然第一节中我们已经把道理讲明，但想必只以MySQL为例，部分读者还未必敢质疑几十年来被认定的国际标准ANSI/ISO-SQL。
接下来，让我们一起看看PostgreSQL的相关情况，再次用一个具体的实例，来确认如上问题是个别数据库的问题，还是行业普遍的问题。
4. 第三代分布式数据库（4）——为什么要100%保证数据的正确性？（下）
5. 第三代分布式数据库（4）——为什么要100%保证数据的正确性？（下）
更多事务处理和分布式相关知识，可参考如下2本图书。
扫码加关注，知数行云，专业有深度
声明：本文禁止用于开发“任何软件程序,包括但不限于训练机器学习或人工智能(AI)系统”。