前言

每次谈到数据库的事务隔离级别，大家一定会看到这张表。

其中，可重复读这个隔离级别，有效地防止了脏读和不可重复读，但仍然可能发生幻读，可能发生幻读就表示可重复读这个隔离级别防不住幻读吗g C @ P?

我不管从数据库方面的教科书@ x 9 . o M - D r还是一些网络教程上,经常看到RR级别是可以重复读的，但是无法解决幻读，只有可串行化(Serializabv V gle)才能解决幻读，这X Q ( U V个说法是否正确呢?

在这篇文章中,我将j ! r i N q T重4 } n $点围绕MySQL中可重复读（Repeatable read）能防住幻读吗?这一问题展开讨论，相信看完这篇文章后你一定会对事0 R ! f n r Y P务隔离级别有新的认识。

我们的数据库中有如下结构和数据的Users; P p =表，下文中我们将对这张表进行操作

长文预警，读完此篇文章，大概需要您二十至三十分钟。

什么是幻读?

在说幻读之前，我们要先来了解脏读和不可重复读。N % n O U G W s 8

脏读

当一个事务读取到另外一个事务修改但未提交的数据时，就可能发生脏读。

在我们的例子中，事务2修改了一行，但是没有提交，事务1读了这个没有提交的数据。

现在如果事务2回滚了刚才的修改或者做了另外的修改的话，事务1中查到的数据就是不正确的了，所以这条数据就是脏R s 2 D K读。

不可重复读

“不可重复读”现象发生在当执行SELECT 操作时没有获得读锁或者SELECT操作执行0 A z L !完后马上释放了读锁；另外一个事务对数据进行了A 9 y 0 @更新，读到了不同的结果。

在这个例子中，事务2提交成功，因此他对id为1的行的修改就对r # 3其他事务可见了。导致了事务1在此前读的age=1，第二次读的ageg K + q ( N=2，两次结果不一致,这就是不可重复读。

幻读

“幻读” e m P R ] J又叫\"幻象读\",是\'\'不可重复读\'e W D p E 2 U\'的一种特殊场景：当事务1两次执行\'\'SELECT ... WHE: = tRE\'\'检索一定范围内数据的操| S Q t v作中间，事务2在这个表中创建了(如 = $ p])了U X 0 &一行新数据，这条新数据正好满足事务1的“WHERE”子句。

如图事务1执行了两遍同= & 9 f样的查询语句，第二遍比第一遍多出了一条数据，这就是幻读。

三者到底什么区别

三者的场景介绍完,但是一定仍然有很多同学搞不清楚,它们到底有什么区别，我总结一下。

脏读：指读到了其他事务未提交的数据。

不可重复读：读到了其他事务已提交的数据(7 . 9 ! h G C p %update)。

不可重复读与幻读都是读到其他事务已提交的数据,但是它们针对点不同。

不可重复读：update。

幻读：delete，inse~ q 1 n ` ` V rrt。

MySQL中的四种事务隔离级别

未提交读

未提交读（READ UNC L Q I NySQL的InnoDB默g @ R v : X *认是使用的RR级别，所以我们先要将该session开启成RC级别，并且设置X O S xbinlog的模式

SET session&nbs@ 2 S $ / J w Rp;transaction isolation level ree ) $ h  X Z S fadW B r s Q $ r E k committeD v } = ? id;SET SESSION binlog_format =&nb+ * 1 = 1 O Q Y 0sp;\'ROW\';（或者是v q ?MIXED）

在已提交读（READ COMMITTED）级别中，读取数据的- I g p事务允许其他事务继续访问: Q t该行数据，但是未提交的写事务将会禁止其他事务V m f K 1访问该行，会对该d [ E 1 V _ P m 5写锁一直保持直到到事务提交。

同样，我们来分析脏读，事务2更新id=1的数据5 R a - $后，在提4 2 4 ! A交前，会对该对象写锁，所以事务1读取id=1的数据时，会一直等待事务2结束，处于阻塞状态，避免了产生脏读。

同样，来分析不可重复读，事务1读取id=1的数据后并没有锁住该数据，所以( 8 f J O 3事务2能对这条数据进行更新，事务2对更新并提交后，n l p x 2 T t C该数据立即生效，所以事务1再次执行同样的查询，查询到的结果便与第一次查到的不同，所以已提交读防不了不可重复读。

可重复读

在可重复读（REPEATABLE Rr W WEADS）是介于已提交读和可串行化之间的一种隔离级别(废话)，它是InnoDb的默认隔离级别，它是我这篇文章的重点讨论对象，所以在这里我先卖个关子,后面G , 6 b g d我会详细介绍。

可串行化

可串行化（Serializab{ 4 ` / U Rle ）是高的隔离级别，它求X ` { & n } f 7在选定对象上的读锁和写锁保持直到事务结束后才能释放，所以能防住上诉所有问题，但因为是串行化的，所以效率较低。

了解到了上诉的一些背景知识后，下面正式开始我们的} 9 8 [ ; r议题。

可重复读（Repeatable read）能防住幻读吗?

可重复读

在讲可重复读之前，我们先在my y 9 Ssql的InnoDB下做下面的实验。

可以看到，事务A既没有读到事务B更新的数据，也没有读到事务C添加的数据，所以在这个场景下，它既防住, b e S /了不可重复读，也防住了幻读。

到此为止，相信大家已经知道答案了，这是怎么做到的呢?

悲观锁与乐观锁d H / [

我们前面说的在对象上加锁，是一种悲观锁机制。

有很多文章说可N f / Z / x s ! LCLE、PostgreSQL等已经是非常成熟的数据库了，怎么会单纯地采用这种如此影响性能的方案呢?r } y N 4 A ; } ~

我- ` K T C D G 4来介绍一下悲观锁和乐观锁。

悲观锁

正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，~ p t = % P在整个数据处理过程中，将数据处于锁定R G r状态] r v f x n v。

读取数据时给加锁，其它事务无法修改这些数据。修改删除数据时也要加锁，其它事务无法读取这些数据。

乐观锁

相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保( u = M : =证操作最大程度的独占性。

但随之而来的就是数据库性能的大量开销，特别是对长事务! * D 9 j K G而言，这样的开销往往无法承受。

而乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基o r x X m 4于数据版本（ Version ）记录机制实现。

何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “vQ 6 @ & eersion” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。

此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，^ U , s否则认为是过期数据。

MySQL、ORACLE、PostgreSQL等都是使用了以乐观锁为理论基础的MVCC（多版本并发控制）来避免不可重复读和幻读,MVCC的实现没有固定的规范，- R d I ) N + p m每个数据库都会有不同的实现| D M s j q b方式，这里讨论的是InnoDB的MVCC。

MVCC(多版本并发控制)

在J & S } hInnoDB中，会在每行数据后添加两个额外的隐藏的值来实现MVCC，这两个值一个记录这行数据何时被创建，另外; + b一个记录这行数据何时过期（或者被删除）。

在实际操作中，存储的并不是时间，而是事务的版本号，每开启一个新事务，事务的版本号就会递增。在可重读Repeatable reads事务隔离级别下：

• SELECT时，读取创建版本号<=当前事务版本号，删除版本号为空或>当前事务版本号。
• I @ onbsp;table where ? for upda3 g t 0te;&nbsB W s % Kp;insert; update; delete;

  我们再利; O u . : N t用当! # { y q ^ 3 t前读来做试验。

  可以看到在读提交的隔离级别中，事务1修改了所有class_id=1的数据，当时当事务2 insert后，事务A莫名奇妙地多了一行class_id=1的数据，而且 O I `改，产生了读提交下的的幻读。

  
  

  而在可重复度的隔离级别下，情况就完全不同了。

  
  

  事务1在up 8 Y j E F | sdate后，对该数据加锁，事务B无法插入新的数据，这样事务A在upd g #ate前后数据保? $ X m 6 e Q持一致，避免了幻读，可以明确的是，update锁的肯定不只是已查询到的几条数据，因为这样无法阻止inse} D x srt，有# ] w { C . E同学会说，那就是锁住了整张表呗。

  
  

  还是那句话，Mysql已经是个成熟的数据库Y } t了，怎么会采用如此低效的方法呢？其实这里的锁，是通过next-key锁实现的。| N | x - @

  
  

  Next-Key锁

  在Users这张X m h 9 c M |表里面，class_id是个非聚簇索引，数据库会通过B+树维护一个非聚簇索引与主键的关系，简单来说，我们先通过class_id=1找到这个索引所对应所有节点，这f R r p y R J些节点存储着对应数据的主键信息，即id=1，X l ` | @ r我们再通过主键id=1找到我们要的数据，这个过程称为回表。

  前往学习:

  https://www.cnblogs.com/su1 c o d D , N x ojing/p/11110292.htmlj { J v K G L

  我本想用我们文章中的例子来画一个B+树，可是画得太丑了r 8 3 D 7，为了# p P x {避免拉低此偏文章B格。所以我想引用上面那边文章中作者画的B+树来解释Next-key。

  
  

  假设我们上面用到的User表需要对Name建立非聚簇索引，是怎么实现的呢？我们看下图：

  

  
  

  B+树的特点是所有数据都存储在叶子节点上，以非聚簇索引的秦寿生为例，在秦寿生的右叶子节点存储着所有秦寿生对应的Id，即图中的34。

  
  

  在我们对这条数据做了当前读后，就会对这条数据加行L m G Z o $ C k p锁，对于行锁很好理解，能够防止其他事务对其进行update或delete，但为什么要加GAP锁呢?

  
  

  还是那句话，| k _ Q |B+树的所有数据存储在叶子节点上，当有一个新的叫秦寿生的数据进来，一定是排在在这条I z ( k V niw r c N + ! 6d=34的数v W C I e据前( L c # J ; |面或者后面的，我们如果对前后这个范围进行y 1 c C R 2加锁了，那当然新的秦寿生就插不进来了。

  
  

  那如果有一个新的范统要插进行呢？因为范统的前后并没有被锁住，是能成功插入的，这样就极大地提高了数据库的并发能力。
  

  马失前蹄

  上! U / y d L A文中说了可重复读能 i S & | 6 [ n防不可重复读，还能防幻读，它能防住所有的幻读吗？当然不是，也有马失前蹄的时候。

  
  

  比如如下的例子:

  

  1. a事务先select，b事务i/ Y K T ! j : knsert确实会加一个gap锁，但是如果b事务commit，这个gap锁就会释放（释放后a事务可以随意操作）

  2. a事务再sel M ) ` t plect出来的结果在MVCC下还和第一次select一样

  3. 接着a事务不加条件地up{ ^ b % d I #date，这个update会作用在所有行上（包括b事务新加的）

  4. a事务再次select就会出现b事务中& a y 的新行，并且这个新行已经被update修改了。

  
  

  Mysql官方给出的幻读解释是：只要在一个事务中，第二次select多出了row就算幻读，所以这个场景下，算出现幻读了。

  那么文章最后留个问题，你R M N V Q J 9 `知道为什么上诉例子会出现幻读吗？欢迎留言讨论。

  Java知音@ q & s 2 + @ [，P ; R m Q专注于Java实用文章推送，不容错过！

  来源：cnblogs.com/CoderAyu/p/11525408.html