正文

快照读会加锁吗（快照读 rr rc）

发布时间：2023-04-19 09:26:24 稿源：创意岭阅读： 101

大家好！今天让创意岭的小编来大家介绍下关于快照读会加锁吗的问题，以下是小编对此问题的归纳整理，让我们一起来看看吧。

开始之前先推荐一个非常厉害的Ai人工智能工具，一键生成原创文章、方案、文案、工作计划、工作报告、论文、代码、作文、做题和对话答疑等等

只需要输入关键词，就能返回你想要的内容，越精准，写出的就越详细，有微信小程序端、在线网页版、PC客户端

官网：https://ai.de1919.com。

创意岭作为行业内优秀的企业，服务客户遍布全球各地，如需了解SEO相关业务请拨打电话175-8598-2043，或添加微信：1454722008

本文目录:

1、Innodb事务--隔离级别
2、mysql 解决可提交读、可重复读、幻读
3、事务的隔离级别全部都是共享锁吗
4、正确理解MYSQL的幻读

快照读会加锁吗（快照读 rr rc）

一、Innodb事务--隔离级别

innodb 事务有四个隔离级别，分别为：未提交读、提交读、重复读与序列化

由于隔离级别的不同，会导致如下问题：脏读、不可重复读、幻读。

脏读：指当前事务能看到其他事务还没Commit的内容。

不可重复读 ：同一个事务中，分别两次查询相同的一行数据，看到的结果不一致。

幻读：幻读指的是一个事务在前后两次查询同一个范围的时候，后一次查询看到了前一次查询没有看到的行。

不可重复读和幻读最大区别 ：不可重复读重点在于update和delete，而幻读的重点在于insert，也有说法是幻读侧重行发生了变化；不可重复读侧重某行数据的修改。不可重复读是修改了存在的数据，导致两次查看不一致，幻读是新增了之前不存在的数据。

下面一一解释各个隔离级别会产生的问题与如何解决脏读、不可重复读、幻读

事务中的修改，即使没有提交，其他事务也可以看得到，会 导致“脏读”、“幻读”和“不可重复读取” 。

一个事务不会读到另一个并行事务已修改但未提交的数据，避免了“脏读取”，但不能避免“幻读”和“不可重复读取”。

为什么无不能避免幻读和不可重复读？

因为每次读取都会重新生成一个快照，所以每次快照都是最新的，也因此事务中每次SELECT也可以看到其它已commit事务所作的更改；

这是MySQL中InnoDB默认的隔离级别。从读的角度看， 快照会在事务中第一次SELECT语句执行时生成，只有在本事务中对数据进行更改才会更新快照 ；

RR级别的事务隔离可以解决脏读和不可重复读，他通过MVVC解决了 快照读情况下的幻读问题 ，当前读下的幻读是以来Innodb的锁机制实现的。所以总结起来就是：

1.在快照读情况下，Mysql通过MVVC来避免幻读。

2.在当前读的情况下，Mysql通过锁机制来避免幻读。

可以通过下面SQL进行测试

上述例子，事务2插入语句并且提交了，事务1通过update语句能更新到，那是因为update语句是当前都，他能读到现在最新的数据并加锁。下面语句要达到可重复度的级别，需要这样修改：

所以，网上很多说可重复读通过MVVC机制解决了幻读问题，其实是不正确的，锁机制才是解决可重复读下幻读问题的重大功臣

这里补充说明下当前读与快照读是什么！

快照读 ：读取专门的快照 (对于RC，快照（ReadView）会在每个语句中创建。对于RR，快照是在事务启动时创建的)。简单的select操作即可。

当前读 ：读取最新版本的记录, 没有快照。在InnoDB中，当前读取根本不会创建任何快照。语句包括：select ... lock in share mode、select ... for update、inset、update、delete。当前读是通过手动加record lock(记录锁)和gap lock(间隙锁)来实现的。

待续-后续讲下事务的原理

二、mysql 解决可提交读、可重复读、幻读

这张图本人觉得总结得挺好的，在一般的互联网项目中，基本上用的都是Innodb引擎，一般只涉及到的都是行级锁，但是如果sql语句中不带索引进行操作，可能会导致锁表，这是不推荐的，性能非常低，可能会导致全表扫描等，行锁的具体实现算法有以下几种mysql特有的锁：

Record Lock(记录锁):单个行记录的锁,一般是唯一索引或者主键上的加锁

Gap Lock(间隙锁):锁定一个区间，但是不包括自身，开区间的锁，RR级别才会有间隙锁，间隙锁的唯一目的是防止区间数据的插入，所以间隙锁与间隙锁之间是不会相互阻塞的

Next-key Lock(临键锁):与间隙锁的区别是包括自身，是左开右闭区间，RR级别才会有

加锁规则里面，包含了两个“原则”、两个“优化”和一个“bug”。

原则 1：加锁的基本单位是 next-key lock，希望你还记得，next-key lock 是前开后闭区间。

原则 2：查找过程中访问到的对象才会加锁。

优化 1：索引上的等值查询，给唯一索引加锁的时候，next-key lock 退化为行锁。

优化 2：索引上的等值查询，向右遍历时且最后一个值不满足等值条件的时候，next-key lock 退化为间隙锁。

一个 bug：唯一索引上的范围查询会访问到不满足条件的第一个值为止。

举例来说明上述的原则：

建表

插入数据：

INSERT INTO t ( id , c , d ) VALUES (0, 0, 0);

INSERT INTO t ( id , c , d ) VALUES (5, 5, 10);

INSERT INTO t ( id , c , d ) VALUES (10, 10, 10);

INSERT INTO t ( id , c , d ) VALUES (15, 15, 15);

INSERT INTO t ( id , c , d ) VALUES (20, 20, 20);

INSERT INTO t ( id , c , d ) VALUES (25, 25, 25);

例子1：锁表

因为d字段上没有建索引，所以涉及该字段的查询加锁会锁住整个表

因为d字段上面没有建立索引，所以事务1执行后会导致整个表被锁，后面所有的操作都会在等待整个表锁被释放

例子2：主键/唯一索引记录锁

id字段为主键，而且事务1查询命中了唯一的记录，默认是加Next-key Lock，区间是（0，5]，但是根据优化1，唯一索引/主键上的等值查询，会退化为行锁，所以只会锁5这个记录。

例子3：主键/唯一索引上的间隙锁

由于表 t 中没有 id=7 的记录，所以用我们上面提到的加锁规则判断一下的话：根据原则 1，加锁单位是 next-key lock，事务1加锁范围就是 (5,10]；同时根据优化 2，这是一个等值查询 (id=7)，而 id=10 不满足查询条件，next-key lock 退化成间隙锁，因此最终加锁的范围是 (5,10)，所以事务2会阻塞，事务3执行成功。

例子4：普通索引上的间隙锁

c字段是普通索引，事务1执行时默认是对区间（0,5]加间隙锁，根据优化2，非唯一索引/主键会继续向右遍历，找到10，所以最终的加锁为（0，5]的Next-Key锁+(5，10)的间隙锁，所以事务2阻塞，事务3成功。

例子5：间隙锁与行锁

事务1默认的Next-Key锁区间是(0，5],根据优化2会向右遍历，找到不满足查询条件的10，退化成间隙锁，所以事务1的锁是（0，5]的Next-Key锁+(5，10)的间隙锁，这两个锁与行锁是冲突的，而事务2申请的Next-Key锁是和事务1一样，但是c=5的行锁与事务1冲突，所以产生了阻塞，如果改为update t set d=1000 where c=6;因为此时产生的间隙锁为（5，10），而间隙锁与间隙锁是不冲突的，不会产生阻塞

例子6：lock in share mode锁覆盖索引

事务1存在覆盖索引的情况，不会去回表，lock in share mode这种情况下只会锁c字段索引，而事务2是对主键加行锁，所以两者不存在冲突。

例子7：主键/唯一索引上的范围查询

开始执行的时候，要找到第一个 id=10 的行，因此本该是 Next-Key Lock(5,10]，根据优化 1，主键 id 上的等值条件，退化成行锁，只加了 id=10 这一行的行锁。范围查找就往后继续找，找到 id=15 这一行停下来，因此需要加 Next-Key Lock(10,15]，所以事务3是冲突的。

例子8：普通索引上的范围查询

开始执行时，找到第一个满足条件的行10，加锁Next-Key Lock(5,10]，因为不是唯一索引，所以不会退化，继续向后面找，找到15这一行停下来，因此需要加 Next-Key Lock(10,15]，因为是范围查询，所以锁不会退化。

快照读：通过MVCC实现，该技术不仅可以保证innodb的可重复读，而且可以防止幻读，但是他读取的数据虽然是一致的，但是数据是历史数据。

简单的select操作(不包括 select … lock in share mode, select … for update)

当前读：要做到保证数据是一致的，同时读取的数据是最新的数据,innodb提供了next-key lock，即gap锁与行锁结合来实现。

select … lock in share mode

select … for update

insert

update

delete

自己理解：

简单的select是快照读，快照读实现可提交读，可重复读和幻读是通过MVCC+ReadView实现的,而当前读实现这几种是通过锁来实现的,为了说明具体原理,下面介绍下MVCC和ReadView概念，所以简单的select是通过乐观锁实现的，当前读是通过悲观锁实现的。

参考文章：

https://www.sohu.com/a/302045871_411876

https://www.jianshu.com/p/d1aba64b5c03

https://www.jianshu.com/p/32904ee07e56

三、事务的隔离级别全部都是共享锁吗

前言: 我们都知道事务的几种性质，数据库为了维护这些性质，尤其是一致性和隔离性，一般使用加锁这种方式。同时数据库又是个高并发的应用，同一时间会有大量的并发访问，如果加锁过度，会极大的降低并发处理能力。所以对于加锁的处理，可以说就是数据库对于事务处理的精髓所在。这里通过分析MySQL中InnoDB引擎的加锁机制，来抛砖引玉，让读者更好的理解，在事务处理中数据库到底做了什么。一次封锁or两段锁？因为有大量的并发访问，为了预防死锁，一般应用中推荐使用一次封锁法，就是在方法的开始阶段，已经预先知道会用到哪些数据，然后全部锁住，在方法运行之后，再全部解锁。这种方式可以有效的避免循环死锁，但在数据库中却不适用，因为在事务开始阶段，数据库并不知道会用到哪些数据。数据库遵循的是两段锁协议，将事务分成两个阶段，加锁阶段和解锁阶段（所以叫两段锁）加锁阶段：在该阶段可以进行加锁操作。在对任何数据进行读操作之前要申请并获得S锁（共享锁，其它事务可以继续加共享锁，但不能加排它锁），在进行写操作之前要申请并获得X锁（排它锁，其它事务不能再获得任何锁）。加锁不成功，则事务进入等待状态，直到加锁成功才继续执行。解锁阶段：当事务释放了一个封锁以后，事务进入解锁阶段，在该阶段只能进行解锁操作不能再进行加锁操作。事务加锁/解锁处理 begin； insert into test ..... 加insert对应的锁 update test set... 加update对应的锁 delete from test .... 加delete对应的锁 commit; 事务提交时，同时释放insert、update、delete对应的锁这种方式虽然无法避免死锁，但是两段锁协议可以保证事务的并发调度是串行化（串行化很重要，尤其是在数据恢复和备份的时候）的。事务中的加锁方式事务的四种隔离级别在数据库操作中，为了有效保证并发读取数据的正确性，提出的事务隔离级别。我们的数据库锁，也是为了构建这些隔离级别存在的。隔离级别脏读（Dirty Read）不可重复读（NonRepeatable Read）幻读（Phantom Read）未提交读（Read uncommitted）可能可能可能已提交读（Read committed）不可能可能可能可重复读（Repeatable read）不可能不可能可能可串行化（Serializable ）不可能不可能不可能未提交读(Read Uncommitted)：允许脏读，也就是可能读取到其他会话中未提交事务修改的数据提交读(Read Committed)：只能读取到已经提交的数据。Oracle等多数数据库默认都是该级别 (不重复读) 可重复读(Repeated Read)：可重复读。在同一个事务内的查询都是事务开始时刻一致的，InnoDB默认级别。在SQL标准中，该隔离级别消除了不可重复读，但是还存在幻象读串行读(Serializable)：完全串行化的读，每次读都需要获得表级共享锁，读写相互都会阻塞 Read Uncommitted这种级别，数据库一般都不会用，而且任何操作都不会加锁，这里就不讨论了。 MySQL中锁的种类 MySQL中锁的种类很多，有常见的表锁和行锁，也有新加入的Metadata Lock等等,表锁是对一整张表加锁，虽然可分为读锁和写锁，但毕竟是锁住整张表，会导致并发能力下降，一般是做ddl处理时使用。行锁则是锁住数据行，这种加锁方法比较复杂，但是由于只锁住有限的数据，对于其它数据不加限制，所以并发能力强，MySQL一般都是用行锁来处理并发事务。这里主要讨论的也就是行锁。 Read Committed（读取提交内容）在RC级别中，数据的读取都是不加锁的，但是数据的写入、修改和删除是需要加锁的。效果如下 MySQL> show create table class_teacher \G\ Table: class_teacher Create Table: CREATE TABLE `class_teacher` ( `id` int(11) NOT NULL AUTO_INCREMENT, `class_name` varchar(100) COLLATE utf8mb4_unicode_ci NOT NULL, `teacher_id` int(11) NOT NULL, PRIMARY KEY (`id`), KEY `idx_teacher_id` (`teacher_id`) ) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci 1 row in set (0.02 sec) MySQL> select * from class_teacher; +----+--------------+------------+ id class_name teacher_id +----+--------------+------------+ 1 初三一班 1 3 初二一班 2 4 初二二班 2 +----+--------------+------------+ 由于MySQL的InnoDB默认是使用的RR级别，所以我们先要将该session开启成RC级别，并且设置binlog的模式 SET session transaction isolation level read committed; SET SESSION binlog_format = 'ROW'; （或者是MIXED）事务A 事务B begin; begin; update class_teacher set class_name='初三二班' where teacher_id=1; update class_teacher set class_name='初三三班' where teacher_id=1; ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction commit; 为了防止并发过程中的修改冲突，事务A中MySQL给teacher_id=1的数据行加锁，并一直不commit（释放锁），那么事务B也就一直拿不到该行锁，wait直到超时。这时我们要注意到，teacher_id是有索引的，如果是没有索引的class_name呢？update class_teacher set teacher_id=3 where class_name = '初三一班'; 那么MySQL会给整张表的所有数据行的加行锁。这里听起来有点不可思议，但是当sql运行的过程中，MySQL并不知道哪些数据行是 class_name = '初三一班'的（没有索引嘛），如果一个条件无法通过索引快速过滤，存储引擎层面就会将所有记录加锁后返回，再由MySQL Server层进行过滤。但在实际使用过程当中，MySQL做了一些改进，在MySQL Server过滤条件，发现不满足后，会调用unlock_row方法，把不满足条件的记录释放锁 (违背了二段锁协议的约束)。这样做，保证了最后只会持有满足条件记录上的锁，但是每条记录的加锁操作还是不能省略的。可见即使是MySQL，为了效率也是会违反规范的。（参见《高性能MySQL》中文第三版p181）这种情况同样适用于MySQL的默认隔离级别RR。所以对一个数据量很大的表做批量修改的时候，如果无法使用相应的索引，MySQL Server过滤数据的的时候特别慢，就会出现虽然没有修改某些行的数据，但是它们还是被锁住了的现象。 Repeatable Read（可重读）这是MySQL中InnoDB默认的隔离级别。我们姑且分“读”和“写”两个模块来讲解。读读就是可重读，可重读这个概念是一事务的多个实例在并发读取数据时，会看到同样的数据行，有点抽象，我们来看一下效果。 RC（不可重读）模式下的展现事务A 事务B begin; begin; select id,class_name,teacher_id from class_teacher where teacher_id=1; id class_name teacher_id 1 初三二班 1 2 初三一班 1 update class_teacher set class_name='初三三班' where id=1; commit; select id,class_name,teacher_id from class_teacher where teacher_id=1; id class_name teacher_id 1 初三三班 1 2 初三一班 1 读到了事务B修改的数据，和第一次查询的结果不一样，是不可重读的。 commit; 事务B修改id=1的数据提交之后，事务A同样的查询，后一次和前一次的结果不一样，这就是不可重读（重新读取产生的结果不一样）。这就很可能带来一些问题，那么我们来看看在RR级别中MySQL的表现：事务A 事务B 事务C begin; begin; begin; select id,class_name,teacher_id from class_teacher where teacher_id=1; id class_name teacher_id 1 初三二班 1 2 初三一班 1 update class_teacher set class_name='初三三班' where id=1; commit; insert into class_teacher values (null,'初三三班',1); commit; select id,class_name,teacher_id from class_teacher where teacher_id=1; id class_name teacher_id 1 初三二班 1 2 初三一班 1 没有读到事务B修改的数据，和第一次sql读取的一样，是可重复读的。没有读到事务C新添加的数据。 commit; 我们注意到，当teacher_id=1时，事务A先做了一次读取，事务B中间修改了id=1的数据，并commit之后，事务A第二次读到的数据和第一次完全相同。所以说它是可重读的。那么MySQL是怎么做到的呢？这里姑且卖个关子，我们往下看。不可重复读和幻读的区别很多人容易搞混不可重复读和幻读，确实这两者有些相似。但不可重复读重点在于update和delete，而幻读的重点在于insert。如果使用锁机制来实现这两种隔离级别，在可重复读中，该sql第一次读取到数据后，就将这些数据加锁，其它事务无法修改这些数据，就可以实现可重复读了。但这种方法却无法锁住insert的数据，所以当事务A先前读取了数据，或者修改了全部数据，事务B还是可以insert数据提交，这时事务A就会发现莫名其妙多了一条之前没有的数据，这就是幻读，不能通过行锁来避免。需要Serializable隔离级别，读用读锁，写用写锁，读锁和写锁互斥，这么做可以有效的避免幻读、不可重复读、脏读等问题，但会极大的降低数据库的并发能力。所以说不可重复读和幻读最大的区别，就在于如何通过锁机制来解决他们产生的问题。上文说的，是使用悲观锁机制来处理这两种问题，但是MySQL、ORACLE、PostgreSQL等成熟的数据库，出于性能考虑，都是使用了以乐观锁为理论基础的MVCC（多版本并发控制）来避免这两种问题。悲观锁和乐观锁悲观锁正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。在悲观锁的情况下，为了保证事务的隔离性，就需要一致性锁定读。读取数据时给加锁，其它事务无法修改这些数据。修改删除数据时也要加锁，其它事务无法读取这些数据。乐观锁相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。而乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本（ Version ）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。要说明的是，MVCC的实现没有固定的规范，每个数据库都会有不同的实现方式，这里讨论的是InnoDB的MVCC。 MVCC在MySQL的InnoDB中的实现在InnoDB中，会在每行数据后添加两个额外的隐藏的值来实现MVCC，这两个值一个记录这行数据何时被创建，另外一个记录这行数据何时过期（或者被删除）。在实际操作中，存储的并不是时间，而是事务的版本号，每开启一个新事务，事务的版本号就会递增。在可重读Repeatable reads事务隔离级别下： SELECT时，读取创建版本号<=当前事务版本号，删除版本号为空或>当前事务版本号。 INSERT时，保存当前事务版本号为行的创建版本号 DELETE时，保存当前事务版本号为行的删除版本号 UPDATE时，插入一条新纪录，保存当前事务版本号为行创建版本号，同时保存当前事务版本号到原来删除的行通过MVCC，虽然每行记录都需要额外的存储空间，更多的行检查工作以及一些额外的维护工作，但可以减少锁的使用，大多数读操作都不用加锁，读数据操作很简单，性能很好，并且也能保证只会读取到符合标准的行，也只锁住必要行。我们不管从数据库方面的教课书中学到，还是从网络上看到，大都是上文中事务的四种隔离级别这一模块列出的意思，RR级别是可重复读的，但无法解决幻读，而只有在Serializable级别才能解决幻读。于是我就加了一个事务C来展示效果。在事务C中添加了一条teacher_id=1的数据commit，RR级别中应该会有幻读现象，事务A在查询teacher_id=1的数据时会读到事务C新加的数据。但是测试后发现，在MySQL中是不存在这种情况的，在事务C提交后，事务A还是不会读到这条数据。可见在MySQL的RR级别中，是解决了幻读的读问题的。参见下图读问题解决了，根据MVCC的定义，并发提交数据时会出现冲突，那么冲突时如何解决呢？我们再来看看InnoDB中RR级别对于写数据的处理。 “读”与“读”的区别可能有读者会疑惑，事务的隔离级别其实都是对于读数据的定义，但到了这里，就被拆成了读和写两个模块来讲解。这主要是因为MySQL中的读，和事务隔离级别中的读，是不一样的。我们且看，在RR级别中，通过MVCC机制，虽然让数据变得可重复读，但我们读到的数据可能是历史数据，是不及时的数据，不是数据库当前的数据！这在一些对于数据的时效特别敏感的业务中，就很可能出问题。对于这种读取历史数据的方式，我们叫它快照读 (snapshot read)，而读取数据库当前版本数据的方式，叫当前读 (current read)。很显然，在MVCC中：快照读：就是select select * from table ....; 当前读：特殊的读操作，插入/更新/删除操作，属于当前读，处理的都是当前的数据，需要加锁。 select * from table where ? lock in share mode; select * from table where ? for update; insert; update ; delete; 事务的隔离级别实际上都是定义了当前读的级别，MySQL为了减少锁处理（包括等待其它锁）的时间，提升并发能力，引入了快照读的概念，使得select不用加锁。而update、insert这些“当前读”，就需要另外的模块来解决了。写（"当前读"）事务的隔离级别中虽然只定义了读数据的要求，实际上这也可以说是写数据的要求。上文的“读”，实际是讲的快照读；而这里说的“写”就是当前读了。为了解决当前读中的幻读问题，MySQL事务使用了Next-Key锁。 Next-Key锁 Next-Key锁是行锁和GAP（间隙锁）的合并，行锁上文已经介绍了，接下来说下GAP间隙锁。行锁可以防止不同事务版本的数据修改提交时造成数据冲突的情况。但如何避免别的事务插入数据就成了问题。我们可以看看RR级别和RC级别的对比 RC级别：事务A 事务B begin; begin; select id,class_name,teacher_id from class_teacher where teacher_id=30; id class_name teacher_id 2 初三二班 30 update class_teacher set class_name='初三四班' where teacher_id=30; insert into class_teacher values (null,'初三二班',30); commit; select id,class_name,teacher_id from class_teacher where teacher_id=30; id class_name teacher_id 2 初三四班 30 10 初三二班 30 RR级别：事务A 事务B begin; begin; select id,class_name,teacher_id from class_teacher where teacher_id=30; id class_name teacher_id 2 初三二班 30 update class_teacher set class_name='初三四班' where teacher_id=30; insert into class_teacher values (null,'初三二班',30); waiting.... select id,class_name,teacher_id from class_teacher where teacher_id=30; id class_name teacher_id 2 初三四班 30 commit; 事务Acommit后，事务B的insert执行。通过对比我们可以发现，在RC级别中，事务A修改了所有teacher_id=30的数据，但是当事务Binsert进新数据后，事务A发现莫名其妙多了一行teacher_id=30的数据，而且没有被之前的update语句所修改，这就是“当前读”的幻读。 RR级别中，事务A在update后加锁，事务B无法插入新数据，这样事务A在update前后读的数据保持一致，避免了幻读。这个锁，就是Gap锁。 MySQL是这么实现的：在class_teacher这张表中，teacher_id是个索引，那么它就会维护一套B+树的数据关系，为了简化，我们用链表结构来表达（实际上是个树形结构，但原理相同）如图所示，InnoDB使用的是聚集索引，teacher_id身为二级索引，就要维护一个索引字段和主键id的树状结构（这里用链表形式表现），并保持顺序排列。 Innodb将这段数据分成几个个区间 (negative infinity, 5], (5,30], (30,positive infinity)； update class_teacher set class_name='初三四班' where teacher_id=30; 不仅用行锁，锁住了相应的数据行；同时也在两边的区间，（5,30]和（30，positive infinity），都加入了gap锁。这样事务B就无法在这个两个区间insert进新数据。受限于这种实现方式，Innodb很多时候会锁住不需要锁的区间。如下所示：事务A 事务B 事务C begin; begin; begin; select id,class_name,teacher_id from class_teacher; id class_name teacher_id 1 初三一班 5 2 初三二班 30 update class_teacher set class_name='初一一班' where teacher_id=20; insert into class_teacher values (null,'初三五班',10); waiting ..... insert into class_teacher values (null,'初三五班',40); commit; 事务A commit之后，这条语句才插入成功 commit; commit; update的teacher_id=20是在(5，30]区间，即使没有修改任何数据，Innodb也会在这个区间加gap锁，而其它区间不会影响，事务C正常插入。如果使用的是没有索引的字段，比如update class_teacher set teacher_id=7 where class_name='初三八班（即使没有匹配到任何数据）',那么会给全表加入gap锁。同时，它不能像上文中行锁一样经过MySQL Server过滤自动解除不满足条件的锁，因为没有索引，则这些字段也就没有排序，也就没有区间。除非该事务提交，否则其它事务无法插入任何数据。行锁防止别的事务修改或删除，GAP锁防止别的事务新增，行锁和GAP锁结合形成的的Next-Key锁共同解决了RR级别在写数据时的幻读问题。 Serializable 这个级别很简单，读加共享锁，写加排他锁，读写互斥。使用的悲观锁的理论，实现简单，数据更加安全，但是并发能力非常差。如果你的业务并发的特别少或者没有并发，同时又要求数据及时可靠的话，可以使用这种模式。这里要吐槽一句，不要看到select就说不会加锁了，在Serializable这个级别，还是会加锁的！

四、正确理解MYSQL的幻读

一、定义

1、幻读MYSQL官方叫法是Phantom Rows，意为鬼影行或者幻影行，请看官方定义：

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语句执行了两次，第二次执行的时候比第一次执行时多出一行，则该行就是所谓的幻影行。

2、幻读与不可重复读的区别

从官方的定义来看，幻读的定义侧重于多条记录，就是记录条数的变化，而不可重复读侧重于单条记录数据的变化，这样区分原因在于解决幻读需要范围锁，解决不可重复读只需要单条记录加锁

二、InnoDB的REPEATABLE READ级别

InnoDB支持由SQL1992标准描述的所有四个事务隔离级别，默认隔离级别是 REPEATABLE READ。

1、快照读：

在RR模式下，第一次读取会建立快照，后续查询会读取快照。

这意味着，如果在同一事务中发出多个普通[ SELECT ]（非锁定）语句，则这些 [ SELECT ]语句的结果也是一致的。

2、[locking reads](锁定读取，又叫当前读）

[ SELECT ]语句中使用 FOR UPDATE 或 FOR SHARE