共计 1242 个字符，预计需要花费 4 分钟才能阅读完成。
背景
笔者最近在回顾多版本并发管制（MVCC），上篇章从加锁的角度了解了几个异样场景（有趣味的敌人能够点击查看「技术探讨」事物零碎的几种异样场景），由此能够发现一个递进关系：在解决了上一个问题时，又发现了下一个新问题。因而才引出了，依据这几个异样场景来定义的不同的有递进关系的隔离级别的概念。
在对事物零碎的隔离级别剖析中，咱们同样能够发现：每个隔离级别，是用来解决绝对一个档次的问题。
事务零碎的隔离级别
1、Read-Uncommited 读未提交
该隔离级别解决第一个层面的异样场景：更新失落。该隔离级别，能够读到任意时刻的数据，然而对未提交的其余事务正在批改的数据，无奈同时写。咱们也能够了解，在这样一个隔离级别下，对资源的所有的操作，加了读锁。如图 1 所示：
2、Read-Commited 读已提交
该隔离级别，解决第二个层面的异样场景：脏读。该隔离级别，使得未提交的数据不能被读取。能够了解为，在该隔离级别下，对要批改的数据，读锁升级成了写锁，导致其余事务无奈对该数据进行读取，因此保障了不会呈现脏读的问题。如图 2 所示：
3、Repeatable-Read 可反复复读
该隔离级别，解决第三个层面的问题：不可反复读。该隔离级别下，一个事务对所波及到的数据，不论是读操作还是写操作，一律加写锁，因此保障了其余的事务，既不能读取，也不能批改这部分数据，因而确保了在事务执行过程中，这些被锁定的数据，不会被其余的事务批改，确保不会呈现不可反复读的问题。如图 3 所示：
4、Serializable 可串行化
该隔离级别下，解决第四个层面的问题：幻读。因为一个事务即使是对所有要读写的数据全副加写锁来实现彻底的排他，然而无奈预知哪些数据是会新产生的，因而要确保不产生幻读的状况，惟一的做法就是实现串行化事务，没有并发，实现根本性的事务隔离，前序事务未完结，后序事务不得开始。如图 4 所示：
上述对事务隔离级别的形容，能够总结为以下的图，就是一个逐层递进，逐层解决的过程。如图 5 所示：
总结与思考
从下面的图和剖析中，咱们思考问题的角度都是一般性的事务零碎，不波及到具体的实现，站在事务零碎的角度来说，要解决幻读的问题，须要实现串行化的隔离级别。
然而 MySQL 在 rr 的隔离级别，曾经实现了对幻读的防止。这是为什么呢？为何 MySQL 能够在不实现串行化的状况下，实现对幻读问题的解决？
这里的起因与 MySQL-innoDB 的数据组织模式密切相关：因为 innoDB 的数据时有序寄存的。
这里的有序寄存就带来了一个潜在的事实：雷同谓词所可能匹配到的数据，肯定时物理上寄存在相邻的地位上的。
基于这样的事实，MySQL 通过一种新的类型的锁“间隙锁”来保障无奈产生幻读，就是因为多锁了那一部分间隙，导致新增的数据，无奈写入被锁住的间隙，因而确保了不会呈现幻读。
KunlunDB 我的项目已开源
【GitHub：】
https://github.com/zettadb
【Gitee：】
https://gitee.com/zettadb
END
