精华内容
下载资源
问答
  • mysql到底是怎么解决幻读的?mvcc是什么,怎么实现的?先理解几个概念非锁定的一致性读图中左边为非一致性读部分【非一致性读】在sql查询的时候,如果发现记录已经被加了X锁,会转而查询当前记录回滚段中最近的快照...

    mysql到底是怎么解决幻读的?
    mvcc是什么,怎么实现的?
    先理解几个概念非锁定的一致性读

    1c925cf27287d3898e84abd529e62e5a.png


    图中左边为非一致性读部分
    【非一致性读】
    在sql查询的时候,如果发现记录已经被加了X锁,会转而查询当前记录回滚段中最近的快照,读快照不加锁,非常快;
    【mvcc】
    多版本控制
    这里的多版本就是指的回滚段的快照,用来解决幻读的情况,即ABA的问题;
    【锁算法】
    record:记录锁,单行记录加锁
    gap:间隙锁,锁住一个范围
    next-key:等于record+gap两者结合
    【场景解释】
    背景:表:tab,主键=id,索引=user_id
    当发生update tab set age = 10 where user_id>10;时候,加锁如下:
    1.主键索引id会给id=10的记录加上record行锁
    2.索引user_id上会加上gap锁,锁住user_id (10,+无穷大)这个范围
    所以,在插入 user_id =100的记录时候会命中第二个索引上加的锁会报出事务异常;
    所以在事务中即使查询多次user_id>10的返回结果都是一样的,因为期间内的数据都没有变化,这样就解决了幻读的问题;
    转载于https://blog.csdn.net/philip502/article/details/90722780

    展开全文
  • MySQL是怎么解决幻读问题的?

    万次阅读 2020-09-18 10:05:18
    首先幻读是什么? 根据MySQL文档上面的定义 The so-called phantom problem occurs within a transaction when the same query produces different sets of rows at different times. For example, if a SELECT is...

    问题分析

    首先幻读是什么?

    根据MySQL文档上面的定义

    The so-called phantom problem occurs within a transaction when the same query produces different sets of rows at different times. For example, if a SELECT is executed twice, but returns a row the second time that was not returned the first time, the row is a “phantom” row.

    幻读指的是在一个事务内,同一SELECT语句在不同时间执行,得到不同的结果集时,就会发生所谓的幻读问题。

    可以看看下面的例子:

    这是网上找的一张图(事务的务字写错了,不过不影响我们理解)

    假设这个例子中的MySQL的隔离级别是提交读,也就是一个事务内可以读到其他事务提交后的结果。

    那么事务1第一次查询dept表中所有部门时,结果是没有"研发部",但是由于隔离级别是提交读,在事务2插入“研发部”这一行数据后,并且提交后,事务1是可以读取到的,所以第二次查询时,结果集中会有“研发部”。这就是幻读。

    SELECT语句分类

    首先我们的SELECT查询分为快照读和实时读,快照读通过MVCC(并发多版本控制)来解决幻读问题,实时读通过行锁来解决幻读问题。

    快照读

    1.1 快照读是什么?

    因为MySQL默认的隔离级别是可重复读,这种隔离级别下,我们普通的SELECT语句都是快照读,也就是在一个事务内,多次执行SELECT语句,查询到的数据都是事务开始时那个状态的数据(这样就不会受其他事务修改数据的影响),这样就解决了幻读的问题。

    1.2 那么innodb是怎么解决快照读的幻读问题的?

    快照读就是每一行数据中额外保存两个隐藏的列,插入这个数据行时的版本号,删除这个数据行时的版本号(可能为空),滚动指针(指向undo log中用于事务回滚的日志记录)。

    事务在对数据修改后,进行保存时,如果数据行的当前版本号与事务开始取得数据的版本号一致就保存成功,否则保存失败。

    当我们不显式使用BEGIN来开启事务时,我们执行的每一条语句就是一个事务,每次开始事务时,会对系统版本号+1作为当前事务的ID。

    1.2.1插入操作

    插入一行数据时,将事务的ID作为数据行的创建版本号。

    1.2.2删除操作

    执行删除操作时,会将原数据行的删除版本号设置为当前事务的ID,然后根据原数据行生成一条INSERT语句,写入undo log,用于事务执行失败时回滚。delete操作实际上不会直接删除,而是将delete对象打上delete flag,标记为删除,最终的删除操作是purge线程完成的。但是会将数据行的删除版本号设置为当前的事务的ID,这样后面的事务B即便查到这行数据由于事务B的ID>删除版本号,也会忽略这条数据。

    1.2.3更新操作

    更新时可以简单的认为是先将旧数据删除,然后插入一条新数据。

    所以执行更新操作时,其实是会将原数据行的删除版本号设置为当前事务的ID,生成一条INSERT语句,写入undo log,用于事务执行失败时回滚。插入一条新的数据,将事务的ID作为数据行的的创建版本号。

    1.2.4查询操作

    数据行要被查询出来必须满足两个条件,

    数据行删除版本号为空或者>当前事务版本号的数据(否则数据已经被标记删除了)

    创建版本号<=当前事务版本号的数据(否则数据是后面的事务创建出来的)

    简单来说,就是查询时,

    如果该行数据没有被加行锁中的X锁(也就是没有其他事务对这行数据进行修改),那么直接读取数据(前提是数据的版本号<=当前事务版本号的数据,不然不会放到查询结果集里面)。

    该行数据被加了行锁X锁(也就是现在有其他事务对这行数据进行修改),那么读数据的事务不会进行等待,而是回去undo log端里面读之前版本的数据(这里存储的数据本身是用于回滚的),在可重复读的隔离级别下,从undo log中读取的数据总是事务开始时的快照数据(也就是版本号小于当前事务ID的数据),在提交读的隔离级别下,从undo log中读取的总是最新的快照数据。

    1.3 补充资料:undo log段是什么?

    undo_log是一种逻辑日志,是旧数据的备份。有两个作用,用于事务回滚和为MVCC提供老版本的数据。

    可以认为当delete一条记录时,undo log中会记录一条对应的insert记录,反之亦然,当update一条记录时,它记录一条对应相反的update记录。

    1.3.1.用于事务回滚

    当事务执行失败,回退时,会读取这行数据的滚动指针(指向undo log中用于事务回滚的日志记录),就可以在undo log中找到相应的逻辑记录,读取到相应的回滚语句,执行进行回滚。

    1.3.2.为MVCC提供老版本的数据

    当读取的某一行被其他事务锁定时(也就是有其他事务正在改这行数据),它可以从undo log中分析出该行记录以前的数据是什么,从而提供该行版本信息,让用户进行快照读。在可重复读的隔离级别下,从undo log中读取的数据总是事务开始时的快照数据(也就是版本号小于当前事务ID的数据),在提交读的隔离级别下,从undo log中读取的总是最新的快照数据(也就是比正在修改这行数据的事务ID修改前的数据。)。

    实时读

    2.1实时读是什么?

    如果说快照读总是读取事务开始时那个状态的数据,实时读就是查询时总是执行这个查询时数据库中的数据。

    一般使用以下这两种查询语句进行查询时就是实时读。

    SELECT *** FOR UPDATE 在查询时会先申请X锁

    SELECT *** IN SHARE MODE 在查询时会先申请S锁

    首先看一个实时读产生幻读的案例:

    这是《MySQL技术内幕++InnoDB存储引擎++第2版》里面的一张图,就是先将隔离级别设置为提交读,这样第一次执行SELECT...FOR UPDATE查询出来的数据是a:4,事务B插入了一条新的数据,再次执行SELECT...FOR UPDATE语句时,查询出来就是a:4,a:5两条数据,这就是幻读的问题。

    2.1那么innodb是怎么解决实时读的幻读问题的?

    如果我们不在一开始将将隔离级别设置为提交读,其实是不会产生幻读问题的,因为MySQL的默认隔离级别是可重复读,在这种情况下,我们执行第一次SELECT...FOR UPDATE查询语句是,其实是会先申请行锁,因为一开始数据库就只有a:4一行数据,那么加锁区间其实是

    (负无穷,4]

    (4,正无穷)

    我们查询条件是a>2,上面两个加锁区间都会可能有数据满足条件,所以会申请行锁中的next-key lock,是会对上面这两个区间都加锁,这样其他事务不能往这两个区间插入数据,事务B会执行插入时会一直等待获取锁,直到事务A提交,释放行锁,事务B才有可能申请到锁,然后进行插入。这样就解决了幻读问题。

    如果大家对行锁了解得比较少,下一期会对innodb中的锁进行介绍。

    最后

    大家有什么想法,可以一起讨论!

    参考链接:

    https://dev.mysql.com/doc/refman/8.0/en/innodb-next-key-locking.html

    https://www.cnblogs.com/f-ck-need-u/archive/2018/05/08/9010872.html

    展开全文
  • 作者:LastSunhttps://...二、为什么要解决幻读在高并发数据库系统中,需要保证事务与事务之间的隔离性,还有事务本身的一致性。三、MySQL 是如何解决幻读的如果你看到了这篇文章,那么我会默认你了解了脏...

    627b9d2f9cb152d312eab1ac85ec5e8e.png

    作者:LastSun

    https://www.cnblogs.com/wdy1184/p/10655180.html

    一、什么是幻读

    在一次事务里面,多次查询之后,结果集的个数不一致的情况叫做幻读。而多出来或者少的哪一行被叫做幻行。

    二、为什么要解决幻读

    在高并发数据库系统中,需要保证事务与事务之间的隔离性,还有事务本身的一致性。

    三、MySQL 是如何解决幻读的

    如果你看到了这篇文章,那么我会默认你了解了脏读 、不可重复读与可重复读。

    1. 多版本并发控制(MVCC)(快照读/一致性读)

    多数数据库都实现了多版本并发控制,并且都是靠保存数据快照来实现的。以 InnoDB 为例,每一行中都冗余了两个字断。

    一个是行的创建版本,一个是行的删除(过期)版本。具体的版本号(trx_id)存在 information_schema.INNODB_TRX 表中。版本号(trx_id)随着每次事务的开启自增。

    事务每次取数据的时候都会取创建版本小于当前事务版本的数据,以及过期版本大于当前版本的数据。

    普通的 select 就是快照读。

    select * from T where number = 1;

    原理:将历史数据存一份快照,所以其他事务增加与删除数据,对于当前事务来说是不可见的。

    2. next-key 锁 (当前读)

    next-key 锁包含两部分:

    记录锁(行锁)

    间隙锁

    记录锁是加在索引上的锁,间隙锁是加在索引之间的。(思考:如果列上没有索引会发生什么?)

    select * from T where number = 1 for update;

    select * from T where number = 1 lock in share mode;

    insert

    update

    delete

    原理:将当前数据行与上一条数据和下一条数据之间的间隙锁定,保证此范围内读取的数据是一致的。

    其他:MySQL InnoDB 引擎 RR 隔离级别是否解决了幻读

    引用一个 github 上面的评论 地址:

    Mysql官方给出的幻读解释是:只要在一个事务中,第二次select多出了row就算幻读。

    a事务先select,b事务insert确实会加一个gap锁,但是如果b事务commit,这个gap锁就会释放(释放后a事务可以随意dml操作),a事务再select出来的结果在MVCC下还和第一次select一样,接着a事务不加条件地update,这个update会作用在所有行上(包括b事务新加的),a事务再次select就会出现b事务中的新行,并且这个新行已经被update修改了,实测在RR级别下确实如此。

    如果这样理解的话,Mysql的RR级别确实防不住幻读

    有道友回复 地址:

    在快照读读情况下,mysql通过mvcc来避免幻读。

    在当前读读情况下,mysql通过next-key来避免幻读。

    select * from t where a=1;属于快照读

    select * from t where a=1 lock in share mode;属于当前读

    不能把快照读和当前读得到的结果不一样这种情况认为是幻读,这是两种不同的使用。所以我认为mysql的rr级别是解决了幻读的。

    先说结论,MySQL 存储引擎 InnoDB 隔离级别 RR 解决了幻读问题。面试问烂的 MySQL 四种隔离级别,这篇文章建议大家看下。

    如引用一问题所说,T1 select 之后 update,会将 T2 中 insert 的数据一起更新,那么认为多出来一行,所以防不住幻读。看着说法无懈可击,但是其实是错误的,InnoDB 中设置了快照读和当前读两种模式,如果只有快照读,那么自然没有幻读问题,但是如果将语句提升到当前读,那么 T1 在 select 的时候需要用如下语法: select * from t for update (lock in share mode) 进入当前读,那么自然没有 T2 可以插入数据这一回事儿了。

    注意

    next-key 固然很好的解决了幻读问题,但是还是遵循一般的定律,隔离级别越高,并发越低。

    关注Java技术栈微信公众号,在后台回复关键字:mysql,可以获取更多栈长整理的MySQL技术干货。

    最近干货分享

    93d2b55e987e4fa6fb0cfed82d545dd5.png

    点击「阅读原文」一起搞技术,爽~

    展开全文
  • 本文阐述了自己对于幻读的看法,对于什么是幻读,本文给出了自己的解释。除此之外,本文解释了为什么在可重复读的隔离条件下还会产生幻读,并分析了MySQL中是怎么通过引入间隙锁来解决幻读

    什么是幻读

    先来看看事务的隔离级别
    在这里插入图片描述
    然后,谈幻读之前,我先说说我对幻读的理解:
    所谓幻读,重点在于“幻”这个词,很梦幻,很玄乎,真假不定,就像蒙上了一层雾一样,你不能真真切切的看到对方,给人以幻的感觉,这便是“幻”。而所谓的幻读,也就是你通过SELECT查询出来的数据集并不是真实存在的数据集,你通过SELECT语句查询出某条记录是不存在的,但是它有可能在真实的表中是存在的。
    我是这么理解幻读与不可重复读的:

    • 幻读说的是存不存在的问题:原来不存在的,现在存在了,则是幻读
    • 不可重复读说的是变没变化的问题:原来是A,现在却变为了B,则为不可重复读

    幻读,目前我了解的有两种说法:

    说法一:事务 A 根据条件查询得到了 N 条数据,但此时事务 B 删除或者增加了 M 条符合事务 A 查询条件的数据,这样当事务 A 再次进行查询的时候真实的数据集已经发生了变化,但是A却查询不出来这种变化,因此产生了幻读。

    这一种说法强调幻读在于某一个范围内的数据行变多或者是变少了,侧重说明的是数据集不一样导致了产生了幻读。

    说法二:幻读并不是说两次读取获取的结果集不同,幻读侧重的方面是某一次的 select 操作得到的结果所表征的数据状态无法支撑后续的业务操作。更为具体一些:A事务select 某记录是否存在,结果为不存在,准备插入此记录,但执行 insert 时发现此记录已存在,无法插入,此时就发生了幻读。产生这样的原因是因为有另一个事务往表中插入了数据。


    我个人更赞成第一种说法。

    说法二这种情况也属于幻读,说法二归根到底还是数据集发生了改变,查询得到的数据集与真实的数据集不匹配。

    对于说法二:当进行INSERT的时候,也需要隐式的读取,比如插入数据时需要读取有没有主键冲突,然后再决定是否能执行插入。如果这时发现已经有这个记录了,就没法插入。所以,SELECT 显示不存在,但是INSERT的时候发现已存在,说明符合条件的数据行发生了变化,也就是幻读的情况,而不可重复读指的是同一条记录的内容被修改了。

    举例来说明:说法二说的是如下的情况:
    有两个事务A和B,A事务先开启,然后A开始查询数据集中有没有id = 30的数据,查询的结果显示数据中没有id = 30的数据。紧接着又有一个事务B开启了,B事务往表中插入了一条id = 30的数据,然后提交了事务。然后A再开始往表中插入id = 30的数据,由于B事务已经插入了id = 30的数据,自然是不能插入,紧接着A又查询了一次,结果发现表中没有id = 30的数据呀,A事务就很纳闷了,怎么会插入不了数据呢。当A事务提交以后,再次查询,发现表中的确存在id = 30的数据。但是A事务还没提交的时候,却查不出来?
    其实,这便是可重复读的作用。
    过程如下图所示:
    在这里插入图片描述
    上图中操作的t表的创建语句如下:

    CREATE TABLE `t` (
      `id` int(11) NOT NULL,
      `c` int(11) DEFAULT NULL,
      `d` int(11) DEFAULT NULL,
      PRIMARY KEY (`id`),
      KEY `c` (`c`) -- 创建索引
    ) ENGINE=InnoDB;
    
    INSERT INTO t VALUES(0,0,0),(5,5,5),
    (10,10,10),(15,15,15),(20,20,20),(25,25,25);
    

    MySQL使用的InnoDB引擎默认的隔离级别是可重复读,也就是说在同一个事务中,两次执行同样的查询,得到的效果应该是一样的。因此,尽管B事务在A事务还未结束的时候,增加了表中的数据,但是为了维护可重复读,A事务中不管怎么查询,是查询不了新增的数据的。但是对于真实的表而言,表中的数据是的的确确增加了。

    A查询不到这个数据,不代表这个数据不存在查询得到了某条数据,不代表它真的存在。这样是是而非的查询,就像是幻觉一样,似真似假,故为幻读
    产生幻读的原因归根到底是由于查询得到的结果与真实的结果不匹配。

    幻读 VS 不可重复读

    • 幻读重点在于数据是否存在。原本不存在的数据却真实的存在了,这便是幻读。在同一个事务中,第一次读取到结果集和第二次读取到的结果集不同。(对比上面的例子,当B事务INSERT以后,A事务中再进行插入,此次插入相当于一次隐式查询)。引起幻读的原因在于另一个事务进行了INSERT操作。
    • 不可重复读重点在于数据是否被改变了。在一个事务中对同一条记录进行查询,第一次读取到的数据和第二次读取到的数据不一致,这便是可重复读。引起不可重复读的原因在于另一个事务进行了UPDATE或者是DELETE操作。

    简单来说:幻读是说数据的条数发生了变化,原本不存在的数据存在了。不可重复读是说数据的内容发生了变化,原本存在的数据的内容发生了改变

    可重复读隔离下为什么会产生幻读?

    在可重复读隔离级别下,普通的查询是快照读,是不会看到别的事务插入的数据的。因此,幻读在 当前读 下才会出现。

    什么是快照读,什么是当前读?

    快照读读取的是快照数据。不加锁的简单的 SELECT都属于快照读,比如这样:

    SELECT * FROM player WHERE ...
    

    当前读就是读取最新数据,而不是历史版本的数据。加锁SELECT,或者对数据进行增删改都会进行当前读。这有点像是 Java 中的 volatile 关键字,被 volatile 修饰的变量,进行修改时,JVM 会强制将其写回内存,而不是放在 CPU 缓存中,进行读取时,JVM 会强制从内存读取,而不是放在 CPU 缓存中。这样就能保证其可见行,保证每次读取到的都是最新的值。如果没有用 volatile 关键字修饰,变量的值可能会被放在 CPU 缓存中,这就导致读取到的值可能是某次修改的值,不能保证是最新的值。

    说多了,我们继续来看,如下的操作都会进行 当前读

    SELECT * FROM player LOCK IN SHARE MODE;
    SELECT * FROM player FOR UPDATE;
    INSERT INTO player values ...
    DELETE FROM player WHERE ...
    UPDATE player SET ...
    

    说白了,快照读就是普通的读操作,而当前读包括了 加锁的读取DML(DML只是对表内部的数据操作,不涉及表的定义,结构的修改。主要包括insert、update、deletet) 操作。

    比如在可重复读的隔离条件下,我开启了两个事务,在另一个事务中进行了插入操作,当前事务如果使用当前读 是可以读到最新的数据的。
    在这里插入图片描述

    MySQL中如何实现可重复读

    当隔离级别为可重复读的时候,事务只在第一次 SELECT 的时候会获取一次 Read View,而后面所有的 SELECT 都会复用这个 Read View。也就是说:对于A事务而言,不管其他事务怎么修改数据,对于A事务而言,它能看到的数据永远都是第一次SELECT时看到的数据。这显然不合理,如果其它事务插入了数据,A事务却只能看到过去的数据,读取不了当前的数据。

    既然都说到 Read View 了,就不得不说 MVCC (多版本并发控制) 机制了。MVCC 其实字面意思还比较好理解,为了防止数据产生冲突,我们可以使用时间戳之类的来进行标识,不同的时间戳对应着不同的版本。比如你现在有1000元,你借给了张三 500 元, 之后李四给了你 500 元,虽然你的钱的总额都是 1000元,但是其实已经和最开始的 1000元不一样了,为了判断中途是否有修改,我们就可以采用版本号来区分你的钱的变动。

    如下,在数据库的数据表中,idnametype 这三个字段是我自己建立的,但是除了这些字段,其实还有些隐藏字段是 MySQL 偷偷为我们添加的,我们通常是看不到这样的隐藏字段的。
    在这里插入图片描述

    我们重点关注这两个隐藏的字段:

    • db_trx_id:操作这行数据的事务 ID,也就是最后一个对该数据进行插入或更新的事务 ID。我们每开启一个事务,都会从数据库中获得一个事务 ID(也就是事务版本号),这个事务 ID 是自增长的,通过 ID 大小,我们就可以判断事务的时间顺序。

    • db_roll_ptr:回滚指针,指向这个记录的 Undo Log 信息。什么是 Undo Log 呢?可以这么理解,当我们需要修改某条记录时,MySQL 担心以后可能会撤销该修改,回退到之前的状态,所以在修改之前,先把当前的数据存个档,然后再进行修改,Undo Log 就可以理解为是这个存档文件。这就像是我们打游戏一样,打到某个关卡先存个档,然后继续往下一关挑战,如果下一关挑战失败,就回到之前的存档点,不至于从头开始。

    在 MVCC(多版本并发控制) 机制中,多个事务对同一个行记录进行更新会产生多个历史快照,这些历史快照保存在 Undo Log 里。如下图所示,当前行记录的 回滚指针 指向的是它的上一个状态,它的上一个状态的 回滚指针 又指向了上一个状态的上一个状态。这样,理论上我们通过遍历 回滚指针,就能找到该行数据的任意一个状态。

    Undo Log 示意图
    在这里插入图片描述
    我们没有想到,我们看到的或许只是一条数据,但是MySQL却在背后为该条数据存储多个版本,为这条数据存了非常多的档。那问题来了,当我们开启事务时,我们在事务中想要查询某条数据,但是每一条数据,都对应了非常多的版本,这时,我们需要读取哪个版本的行记录呢?

    这时就需要用到 Read View 机制了,它帮我们解决了行的可见性问题。Read View 保存了当前事务开启时所有活跃(还没有提交)的事务列表。

    在 Read VIew 中有几个重要的属性:

    • trx_ids,系统当前正在活跃的事务 ID 集合
    • low_limit_id,活跃的事务中最大的事务 ID
    • up_limit_id,活跃的事务中最小的事务 ID
    • creator_trx_id,创建这个 Read View 的事务 ID

    在前面我们说过了,在每一行记录中有一个隐藏字段 db_trx_id,表示操作这行数据的事务 ID ,而且 事务 ID 是自增长的,通过 ID 大小,我们就可以判断事务的时间顺序

    当我们开启事务以后,准备查询某条记录,发现该条记录的 db_trx_id < up_limit_id,这说明什么呢?说明该条记录一定是在本次事务开启之前就已经提交的,对于当前事务而言,这属于历史数据,可见,因此,我们通过 select 一定能查出这一条记录。

    但是如果发现,要查询的这条记录的 db_trx_id > up_limit_id。这说明什么呢,说明我在开启事务的时候,这条记录肯定是还没有的,是在之后这条记录才被创建的,不应该被当前事务看见,这时候我们就可以通过 回滚指针 + Undo Log 去找一下该记录的历史版本,返回给当前事务。在本文 什么是幻读 ? 这一章节中举的一个例子。A 事务开启时,数据库中还没有(30, 30, 30)这条记录。A事务开启以后,B事务往数据库中插入了(30, 30, 30)这条记录,这时候,A事务使用 不加锁select 进行 快照读 时是查询不出这条新插入的记录的,这符合我们的预期。对于 A事务而言,(30, 30, 30)这条记录的 db_trx_id 一定大于 A事务开启时的 up_limit_id,所以这条记录不应该被A事务看见。

    如果需要查询的这条记录的 trx_id 满足 up_limit_id < trx_id < low_limit_id 这个条件,说明该行记录所在的事务 trx_id 在目前 creator_trx_id 这个事务创建的时候,可能还处于活跃的状态,因此我们需要在 trx_ids 集合中进行遍历,如果 trx_id 存在于 trx_ids 集合中,证明这个事务 trx_id 还处于活跃状态,不可见,如果该记录有 Undo Log,我们可以通过回滚指针进行遍历,查询该记录的历史版本数据。如果 trx_id 不存在于 trx_ids 集合中,证明事务 trx_id 已经提交了,该行记录可见。

    从图中你能看到回滚指针将数据行的所有快照记录都通过链表的结构串联了起来,每个快照的记录都保存了当时的 db_trx_id,也是那个时间点操作这个数据的事务 ID。这样如果我们想要找历史快照,就可以通过遍历回滚指针的方式进行查找。

    最后,再来强调一遍:事务只在第一次 SELECT 的时候会获取一次 Read View

    因此,如下图所示,在 可重复读 的隔离条件下,在该事务中不管进行多少次 以WHERE heigh > 2.08为条件 的查询,最终结果得到都是一样的,尽管可能会有其它事务对这个结果集进行了更改。
    在这里插入图片描述

    如何解决幻读

    即便是给每行数据都加上行锁,也无法解决幻读,行锁只能阻止修改,无法阻止数据的删除。而且新插入的数据,自然是数据库中不存在的数据,原本不存在的数据自然无法对其加锁,因此仅仅使用行锁是无法阻止别的事务插入数据的。

    为了解决幻读问题,InnoDB 只好引入新的锁,也就是间隙锁(Gap Lock)。顾名思义,间隙锁,锁的就是两个值之间的空隙。比如文章开头的表 t,初始化插入了 6 个记录,这就产生了 7 个间隙。

    表 t 主键索引上的行锁和间隙锁
    在这里插入图片描述
    也就是说这时候,在一行行扫描的过程中,不仅将给行加上了行锁,还给行两边的空隙,也加上了间隙锁。现在你知道了,数据行是可以加上锁的实体,数据行之间的间隙,也是可以加上锁的实体。但是间隙锁跟我们之前碰到过的锁都不太一样。

    • 间隙锁和行锁合称 next-key lock,每个 next-key lock 是前开后闭区间。也就是说,我们的表 t 初始化以后,如果用 SELECT * FEOM t FOR UPDATE要把整个表所有记录锁起来,就形成了 7 个 next-key lock,分别是 (负无穷,0]、(0,5]、(5,10]、(10,15]、(15,20]、(20, 25]、(25, 正无穷]。
    • 间隙锁是在可重复读隔离级别下才会生效的

    怎么加间隙锁呢?使用写锁(又叫排它锁,X锁)时自动生效,也就是说我们执行 SELECT * FEOM t FOR UPDATE时便会自动触发间隙锁。会给主键加上上图所示的锁。

    如下图所示,如果在事务A中执行了SELECT * FROM t WHERE d = 5 FOR UPDATE以后,事务B则无法插入数据了,因此就避免了产生幻读。

    数据表的创建语句如下

    CREATE TABLE `t` (
      `id` int(11) NOT NULL,
      `c` int(11) DEFAULT NULL,
      `d` int(11) DEFAULT NULL,
      PRIMARY KEY (`id`),
      KEY `c` (`c`) -- 创建索引
    ) ENGINE=InnoDB;
    
    INSERT INTO t VALUES(0,0,0),(5,5,5),
    (10,10,10),(15,15,15),(20,20,20),(25,25,25);
    

    需要注意的是,由于创建数据表的时候仅仅只在c字段上创建了索引,因此使用条件WHERE id = 5查找时是会扫描全表的。因此,SELECT * FROM t WHERE d = 5 FOR UPDATE实际上锁住了整个表,如上图所示,产生了七个间隙,这七个间隙都不允许数据的插入。

    因此当B想插入一条数据(1, 1, 1)时就会被阻塞住,因为它的主键位于位于(0, 5]这个区间,被禁止插入。

    在这里插入图片描述

    还需要注意的一点是,间隙锁和间隙锁是不会产生冲突的
    读锁(又称共享锁,S锁)和写锁会冲突,写锁和写锁也会产生冲突。但是间隙锁和间隙锁是不会产生冲突的

    如下:
    A事务对id = 5的数据加了读锁,B事务再对id = 5的数据加写锁则会失败,若B事务加读锁则会成功。读锁和读锁可以兼容,读锁和写锁则不能兼容。

    A事务对id = 5的数据加了写锁,B事务再对id = 5的数据加写锁则会失败,若B事务加读锁同样也会失败。
    在这里插入图片描述
    在加了间隙锁以后,当A事务开启以后,并对(5, 10]这个区间加了间隙锁,那么B事务则无法插入数据了。

    在这里插入图片描述
    但是当A事务对(5, 10]加了间隙锁以后,B事务也可以对这个区间加间隙锁。

    间隙锁的目的是阻止往这个区间插入数据,因此A事务加了以后B事务继续加间隙锁,这并不矛盾。但是对于写锁和读锁就不一样了。
    写锁是不允许其它事务读,也不允许写,而读锁则是允许写,语义上就存在冲突。自然无法同时加这两个锁。
    而写锁和写锁也是,写锁不允许读,也不允许写,想想,A事务对数据加了写锁,就是完全不想让其它事务操作该数据,那其它数据若能为这个数据加写锁,就相当于是对该数据实施了操作,违背了写锁的涵义,自然不被允许。

    参考
    SQL必知必会 陈旸
    MySQL实战45讲 林晓斌

    展开全文
  • 二、为什么要解决幻读在高并发数据库系统中,需要保证事务与事务之间的隔离性,还有事务本身的一致性。三、MySQL 是如何解决幻读的如果你看到了这篇文章,那么我会默认你了解了脏读 、不可重复读与可重复读。1. 多...
  • mysql到底是怎么解决幻读的?

    千次阅读 2019-05-31 20:55:09
    mysql到底是怎么解决幻读的? mvcc是什么,怎么实现的? 先理解几个概念 非锁定的一致性读 图中左边为非一致性读部分 【非一致性读】 在sql查询的时候,如果发现记录已经被加了X锁,会转而查询当前记录回滚...
  • InnoDB怎么解决幻读的?

    万次阅读 多人点赞 2019-04-03 20:39:52
    首先说结论,在RR的隔离级别下,Innodb使用MVVC和next-key locks解决幻读,MVVC解决的是普通读(快照读)的幻读,next-key locks解决的是当前读情况下的幻读。 2.幻读是什么 事务A,先执行: update table set ...
  • MySql系列:MySQL 到底是怎么解决幻读的? 前言 今天博主将为大家分享MySql系列:MySQL 到底是怎么解决幻读的?不喜勿喷,如有异议欢迎讨论! 什么是幻读?在一次事务里面,多次查询之后,结果集的个数不一致的...
  • 首先幻读是什么?根据MySQL文档上面的定义The so-called phantom problem occurs within a transaction when the same query produces different sets of rows at different times. For example, if a SELECT is ...
  • 作者:LastSunhttps://...二、为什么要解决幻读在高并发数据库系统中,需要保证事务与事务之间的隔离性,还有事务本身的一致性。三、MySQL 是如何解决幻读的如果你看到了这篇文章,那么我会默认你...
  • InnoDB怎么解决幻读

    2020-10-20 10:08:44
    首先说结论,在RR的隔离级别下,Innodb使用MVCC和next-key locks解决幻读,MVCC解决的是普通读(快照读)的幻读,next-key locks解决的是当前读情况下的幻读。 幻读是什么 事务A,先执行: update table set name=...
  • 二、为什么要解决幻读在高并发数据库系统中,需要保证事务与事务之间的隔离性,还有事务本身的一致性。三、MySQL 是如何解决幻读的如果你看到了这篇文章,那么我会默认你了解了脏读 、不可重复读与可重复读。1. 多...
  • mysql的默认隔离级别是RR(可重复读),网上随便一查都知道RR会导致幻读(同一个事务里面多次查询的结果不一致),可是我自己测试过后发现在RR下并不存在幻读的问题,哪mysql是怎么解决幻读的呢?有两种手段。1,...
  • 二、为什么要解决幻读 在高并发数据库系统中,需要保证事务与事务之间的隔离性,还有事务本身的一致性。 三、MySQL 是如何解决幻读的 如果你看到了这篇文章,那么我会默认你了解了 脏读 、不可重复读与可重复读。...
  • 首先说结论,在RR的隔离级别下,Innodb使用MVCC和next-key locks解决幻读,MVCC解决的是普通读(快照读)的幻读,next-key locks解决的是当前读情况下的幻读。 2. 幻读是什么 事务A,先执行: ...
  • 作者:LastSunhttps://...二、为什么要解决幻读在高并发数据库系统中,需要保证事务与事务之间的隔离性,还有事务本身的一致性。三、MySQL 是如何解决幻读的如果你看到了这篇文章,那么我会默认你了解了脏读...
  • 在RR级别下,快照读是通过MVVC(多版本...在mysql中通过MVCC快照读和next-key(当前读)两种模式解决幻读问题。 关于MVVC MySQL InnoDB存储引擎,实现的是基于多版本的并发控制协议——MVCC (Multi-Version Concurrency...
  • 1. 结论首先说结论,在RR的隔离级别下,Innodb使用MVCC和next-key locks解决幻读,MVCC解决的是普通读(快照读)的幻读,next-key locks解决的是当前读情况下的幻读。2. 幻读是什么事务A,先执行:update table set ...
  • 首先幻读是什么?根据MySQL文档上面的定义The so-called phantom problem occurs within a transaction when the same query produces different sets of rows at different times. For example, if a SELECT is ...
  • MySQL 到底是怎么解决幻读的?

    千次阅读 2019-06-03 17:33:04
    作者:LastSun ... 一、什么是幻读 在一次事务里面,多次查询...二、为什么要解决幻读 在高并发数据库系统中,需要保证事务与事务之间的隔离性,还有事务本身的一致性。 三、MySQL 是如何解决幻读的 如果你看到...

空空如也

空空如也

1 2 3 4 5 ... 10
收藏数 185
精华内容 74
关键字:

怎么解决幻读