事务隔离级别中可重复读与幻读

前言

中秋刚过,大家是不是还没充中秋的假日里缓过来?三天假期里,我深入窥探了Innodb中可重复读与幻读,非常有意思,分享给大家,作为大家工作前的开胃小菜,希望有所帮助.

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

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

我不管从数据库方面的教科书还是一些网络教程上,经常看到RR级别是可以重复读的,但是无法解决幻读,只有可串行化(Serializable)才能解决幻读,这个说法是否正确呢?

在这篇文章中,我将重点围绕MySQL中
可重复读（Repeatable read）能防住幻读吗?
这一问题展开讨论,相信看完这篇文章后,你一定会对事务隔离级别有新的认识.

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

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

什么是幻读?

在说幻读之前,我们要先来了解脏读和不可重复读.

脏读

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

在我们的例子中，事务2修改了一行，但是没有提交，事务1读了这个没有提交的数据。现在如果事务2回滚了刚才的修改或者做了另外的修改的话，事务1中查到的数据就是不正确的了,所以这条数据就是脏读。

不可重复读

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

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

幻读

“幻读”又叫"幻象读",是‘‘不可重复读‘‘的一种特殊场景：当事务1两次执行‘‘SELECT ... WHERE‘‘检索一定范围内数据的操作中间，事务2在这个表中创建了(如[[INSERT]])了一行新数据，这条新数据正好满足事务1的“WHERE”子句。

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

三者到底什么区别

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

脏读:指读到了其他事务未提交的数据.
不可重复读: 读到了其他事务已提交的数据(update).

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

MySQL中的四种事务隔离级别

未提交读

未提交读（READ UNCOMMITTED）是最低的隔离级别,在这种隔离级别下,如果一个事务已经开始写数据，则另外一个事务则不允许同时进行写操作，但允许其他事务读此行数据.

把脏读的图拿来分析分析,因为事务2更新id=1的数据后,仍然允许事务1读取该条数据,所以事务1第二次执行查询,读到了事务2更新的结果,产生了脏读.

已提交读

由于MySQL的InnoDB默认是使用的RR级别，所以我们先要将该session开启成RC级别，并且设置binlog的模式

SET session transaction isolation level read committed;
SET SESSION binlog_format = ‘ROW‘;（或者是MIXED）

在已提交读（READ COMMITTED）级别中，读取数据的事务允许其他事务继续访问该行数据，但是未提交的写事务将会禁止其他事务访问该行,会对该写锁一直保持直到到事务提交.

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

同样,来分析不可重复读,事务1读取id=1的数据后并没有锁住该数据,所以事务2能对这条数据进行更新,事务2对更新并提交后,该数据立即生效,所以事务1再次执行同样的查询,查询到的结果便与第一次查到的不同,所以已提交读防不了不可重复读.

可重复度

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

可串行化

可串行化（Serializable ）是高的隔离级别,它求在选定对象上的读锁和写锁保持直到事务结束后才能释放,所以能防住上诉所有问题,但因为是串行化的,所以效率较低.

了解到了上诉的一些背景知识后,下面正式开始我们的议题.

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

可重复读

在讲可重复读之前,我们先在mysql的InnoDB下做下面的实验.


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

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

悲观锁与乐观锁

我们前面说的在对象上加锁,是一种悲观锁机制,有很多文章说可重复读的隔离级别防不了幻读, 是认为可重复读会对读的行加锁,导致他事务修改不了这条数据,直到事务结束,但是这种方案只能锁住数据行,如果有新的数据进来,是阻止不了的,所以会产生幻读.

可是MySQL、ORACLE、PostgreSQL等已经是非常成熟的数据库了,怎么会单纯地采用这种如此影响性能的方案呢?

我来介绍一下悲观锁和乐观锁.

悲观锁

正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。读取数据时给加锁，其它事务无法修改这些数据。修改删除数据时也要加锁，其它事务无法读取这些数据。

乐观锁

相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。

而乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本（ Version ）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。

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

MVCC(多版本并发控制)

在InnoDB中，会在每行数据后添加两个额外的隐藏的值来实现MVCC，这两个值一个记录这行数据何时被创建，另外一个记录这行数据何时过期（或者被删除）。 在实际操作中，存储的并不是时间，而是事务的版本号，每开启一个新事务，事务的版本号就会递增。 在可重读Repeatable reads事务隔离级别下：

  • SELECT时，读取创建版本号<=当前事务版本号，删除版本号为空或>当前事务版本号。
  • INSERT时，保存当前事务版本号为行的创建版本号
  • DELETE时，保存当前事务版本号为行的删除版本号
  • UPDATE时，插入一条新纪录，保存当前事务版本号为行创建版本号，同时保存当前事务版本号到原来删除的行

通过MVCC,虽然每行记录都要额外的存储空间来记录version,需要更多的行检查工作以及一些额外的维护工作,但可以减少锁的使用,大多读操作都不用加锁,读取数据操作简单,性能好.

细心的同学应该也看到了,通过MVCC读取出来的数据其实是历史数据,而不是最新数据,这在一些对于数据时效特别敏感的业务中,很可能出问题,这也是MVCC的短板之处,有办法解决吗? 当然有.

MCVV这种读取历史数据的方式称为快照读(snapshot read),而读取数据库当前版本数据的方式,叫当前读(current read).

快照读

我们平时只用使用select就是快照读,这样可以减少加锁所带来的开销.

select * from table ....

当前读

对于会对数据修改的操作(update、insert、delete)都是采用当前读的模式。在执行这几个操作时会读取最新的记录，即使是别的事务提交的数据也可以查询到。假设要update一条记录，但是在另一个事务中已经delete掉这条数据并且commit了，如果update就会产生冲突，所以在update的时候需要知道最新的数据。读取的是最新的数据，需要加锁。以下第一个语句需要加共享锁，其它都需要加排它锁。

select * from table where ? lock in share mode;
select * from table where ? for update;
insert;
update;
delete;

我们再利用当前读来做试验.

可以看到在读提交的隔离级别中,事务1修改了所有class_id=1的数据,当时当事务2 insert后,事务A莫名奇妙地多了一行class_id=1的数据,而且没有被之前的update所修改,产生了读提交下的的幻读.

而在可重复度的隔离级别下,情况就完全不同了.事务1在update后,对该数据加锁,事务B无法插入新的数据,这样事务A在update前后数据保持一致,避免了幻读,可以明确的是,update锁的肯定不只是已查询到的几条数据,因为这样无法阻止insert,有同学会说,那就是锁住了整张表呗.

还是那句话, Mysql已经是个成熟的数据库了,怎么会采用如此低效的方法呢? 其实这里的锁,是通过next-key锁实现的.

Next-Key锁

在Users这张表里面,class_id是个非聚簇索引,数据库会通过B+树维护一个非聚簇索引与主键的关系,简单来说,我们先通过class_id=1找到这个索引所对应所有节点,这些节点存储着对应数据的主键信息,即id=1,我们再通过主键id=1找到我们要的数据,这个过程称为回表.

不懂数据库索引的底层原理？那是因为你心里没点b树
前往学习: https://www.cnblogs.com/sujing/p/11110292.html

我本想用我们文章中的例子来画一个B+树,可是画得太丑了,为了避免拉低此偏文章B格.所以我想引用上面那边文章中作者画的B+树来解释Next-key.

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

B+树的特点是所有数据都存储在叶子节点上,以非聚簇索引的秦寿生为例,在秦寿生的右叶子节点存储着所有秦寿生对应的Id,即图中的34,在我们对这条数据做了当前读后,就会对这条数据加行锁,对于行锁很好理解,能够防止其他事务对其进行update或delete,但为什么要加GAP锁呢?

还是那句话,B+树的所有数据存储在叶子节点上,当有一个新的叫秦寿生的数据进来,一定是排在在这条id=34的数据前面或者后面的,我们如果对前后这个范围进行加锁了,那当然新的秦寿生就插不进来了.

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

马失前蹄

上文中说了可重复读能防不可重复读,还能防幻读,它能防住所有的幻读吗?当然不是,也有马失前蹄的时候.

比如如下的例子:

1.a事务先select，b事务insert确实会加一个gap锁，但是如果b事务commit，这个gap锁就会释放（释放后a事务可以随意操作），
2.a事务再select出来的结果在MVCC下还和第一次select一样，
3.接着a事务不加条件地update，这个update会作用在所有行上（包括b事务新加的），
4.a事务再次select就会出现b事务中的新行，并且这个新行已经被update修改了.

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

原文地址：https://www.cnblogs.com/liliuguang/p/11525452.html

时间： 2024-10-08 10:30:15

事务隔离级别中可重复读与幻读的相关文章

事务隔离级别中可重复读与幻读的恩恩怨怨

前言 中秋刚过,大家是不是还没充中秋的假日里缓过来?三天假期里,我深入窥探了Innodb中可重复读与幻读,非常有意思,分享给大家,作为大家工作前的开胃小菜,希望有所帮助. 每次谈到数据库的事务隔离级别,大家一定会看到这张表. 其中,可重复读这个隔离级别,有效地防止了脏读和不可重复读,但仍然可能发生幻读,可能发生幻读就表示可重复读这个隔离级别防不住幻读吗? 我不管从数据库方面的教科书还是一些网络教程上,经常看到RR级别是可以重复读的,但是无法解决幻读,只有可串行化(Serializable)才能解

mysql事务隔离级别/脏读/不可重复读/幻读详解

一.四种事务隔离级别 1.1 read uncommitted 读未提交 即:事务A可以读取到事务B已修改但未提交的数据. 除非是文章阅读量,每次+1这种无关痛痒的场景,一般业务系统没有人会使用该事务隔离级别,标准实在太宽松了. 1.2 read committed 读已提交(简称RC) 即:事务A只能读取到事务B修改并已提交的数据. 这个级别相对要严格一些,至少是要等其它事务把变更提交到db,才能读取到,听上去蛮靠谱的.但是有些业务场景,比如会员系统中,如果要在一个事务中,多次读取用户身份,判

事务隔离级别、脏读、不可重复读、幻读

事务隔离级别.脏读.不可重复读.幻读 网络上关于这方面的博文有些偏理论,有些通篇代码,都不能深入浅出.本文用图文并茂的方式,配上行云流水般的代码,非要摆清楚这个问题.相关代码已提交至码云(点击这里下载). 事务是现代关系型数据库的核心之一.在多个事务并发操作数据库(多线程.网络并发等)的时候,如果没有有效的避免机制,就会出现以下几种问题: 第一类丢失更新(Lost Update) 在完全未隔离事务的情况下,两个事务更新同一条数据资源,某一事务完成,另一事务异常终止,回滚造成第一个完成的更新也同时

数据库 - 脏读、不可重复读、幻读。

脏读 读取未提交数据.脏读即事务A读取到事务B未提交的数据,如果此时事务B数据回滚,事务A仍然是使用旧的数据即是脏的数据. 顺序 事务A 事务B 1 开始事务 2 开始事务 3 查询余额2000元 4 取出1000元剩余1000元 5 查询余额剩余1000元(脏读) 6 产生异常事务发生回滚,余额剩余2000元 7 转入2000元,余额为3000元 8 提交事务 - 数据发生异常(凭空少了1000元) 不可重复读 前后多次读取,数据内容不一致.事务A多次读取某个数据而这些数据不能保证每次查询都一

SQL Server 中的事务与事务隔离级别以及如何理解脏读, 未提交读,不可重复读和幻读产生的过程和原因

原本打算写有关 SSIS Package 中的事务控制过程的,但是发现很多基本的概念还是需要有 SQL Server 事务和事务的隔离级别做基础铺垫.所以花了点时间,把 SQL Server 数据库中的事务概念,ACID 原则,事务中常见的问题,问题造成的原因和事务隔离级别等这些方面的知识好好的整理了一下. 其实有关 SQL Server 中的事务,说实话因为内容太多, 话题太广,稍微力度控制不好就超过了我目前知识能力范围,就不是三言两语能够讲清楚的.所以希望大家能够指出其中总结的不足之处,对我

Hibernate中的事务隔离问题（脏读、不可重复读、幻读）

Hibernate中的事务隔离问题(脏读.不可重复读.幻读) 1.事务的特性 事务的四个特性: 1)原子性:事务是进行数据库操作的最小单位,所以组成事务的各种操作是不可分割的 2)一致性:组成事务的各种操作,要么全部成功,要么全部失败.其中有一个失败,事务无法完成 3)隔离性:在并发中,每个事务都是独立的 4)持久性:这是结果,表示在事务提交之后,数据将持久的保存到数据库 2.事务的隔离问题 事务的三个隔离问题: 1)脏读:一个事务读到了另一个事务还没提交的数据 如:A事务正在读一个数据a,但是

[MySQL]对于事务并发处理带来的问题，脏读、不可重复读、幻读的理解与数据库事务隔离级别 - 分析脏读 &amp; 不可重复读 &amp; 幻读

刚开始写博客.. 写的太low. 1.数据库的两种读,每种读读的数据版本不一样,所以也称为MVCC,即多版本并发控制 a) 快照读 select * from where xxx  这种形式的都是快照读. b) 当前读 update , insert ,delete ,select xx from xx for update ,  in share mode 都是当前读 当前读会等待,不会返回数据的历史版本 2.mvcc 的实现原理 mvcc是基于read view.活跃事务列表 做的,以后的文

数据库事务隔离级别、脏读、重复读、不可重复读、幻读

数据库事务四种隔离级别 1.Read Uncommitted(读未提交) :事务中的修改,即使没有提交,其他事务也可以看得到,会导致“脏读”.“幻读”和“不可重复读取”. 2.READ COMMITTED (读提交):大多数主流数据库的默认事务等级,保证了一个事务不会读到另一个并行事务已修改但未提交的数据,避免了“脏读取”,但不能避免“幻读”和“不可重复读取”.该级别适用于大多数系统. 3.REPEATABLE READ(可重复读) :保证了一个事务不会修改已经由另一个事务读取但未提交(回滚)的

总是忘记的场景：MySQL InnoDB四个事务级别 与 脏读、不重复读、幻读

MySQL InnoDB事务隔离级别脏读.可重复读.幻读 MySQL InnoDB事务的隔离级别有四级,默认是“可重复读”(REPEATABLE READ). ·        未提交读(READUNCOMMITTED).另一个事务修改了数据,但尚未提交,而本事务中的SELECT会读到这些未被提交的数据(脏读). ·        提交读(READCOMMITTED).本事务读取到的是最新的数据(其他事务提交后的).问题是,在同一个事务里,前后两次相同的SELECT会读到不同的结果(不重复读).