MySQL 事务的默认隔离级别是什么可以解决幻读问题么

我们设想一个场景，这个场景中我们需要插入多条相关联的数据到数据库，不幸的是，这个过程可能会遇到下面这些问题：

上面的任何一个问题都可能会导致数据的不一致性。为了保证数据的一致性，系统必须能够处理这些问题。事务就是我们抽象出来简化这些问题的首选机制。事务的概念起源于数据库，目前，已经成为一个比较广泛的概念。

何为事务？ 一言蔽之， 事务是逻辑上的一组 *** 作，要么都执行，要么都不执行。

事务最经典也经常被拿出来说例子就是转账了。假如小明要给小红转账 1000 元，这个转账会涉及到两个关键 *** 作，这两个 *** 作必须都成功或者都失败。

事务会把这两个 *** 作就可以看成逻辑上的一个整体，这个整体包含的 *** 作要么都成功，要么都要失败。这样就不会出现小明余额减少而小红的余额却并没有增加的情况。

大多数情况下，我们在谈论事务的时候，如果没有特指 分布式事务 ，往往指的就是 数据库事务 。

数据库事务在我们日常开发中接触的最多了。如果你的项目属于单体架构的话，你接触到的往往就是数据库事务了。

那数据库事务有什么作用呢？

简单来说，数据库事务可以保证多个对数据库的 *** 作（也就是 SQL 语句）构成一个逻辑上的整体。构成这个逻辑上的整体的这些数据库 *** 作遵循： 要么全部执行成功,要么全部不执行 。

另外，关系型数据库（例如： MySQL 、 SQL Server 、 Oracle 等）事务都有 ACID 特性：

ACID

这里要额外补充一点： 只有保证了事务的持久性、原子性、隔离性之后，一致性才能得到保障。也就是说 A、I、D 是手段，C 是目的！

在典型的应用程序中，多个事务并发运行，经常会 *** 作相同的数据来完成各自的任务（多个用户对同一数据进行 *** 作）。并发虽然是必须的，但可能会导致以下的问题。

不可重复读和幻读区别 ：不可重复读的重点是修改比如多次读取一条记录发现其中某些列的值被修改，幻读的重点在于新增或者删除比如多次查询同一条查询语句（DQL）时，记录发现记录增多或减少了。

SQL 标准定义了四个隔离级别：

隔离级别脏读不可重复读幻读 READ-UNCOMMITTED READ-COMMITTED REPEATABLE-READ SERIALIZABLE

MySQL 的隔离级别基于锁和 MVCC 机制共同实现的。

SERIALIZABLE 隔离级别，是通过锁来实现的。除了 SERIALIZABLE 隔离级别，其他的隔离级别都是基于 MVCC 实现。

不过， SERIALIZABLE 之外的其他隔离级别可能也需要用到锁机制，就比如 REPEATABLE-READ 在当前读情况下需要使用加锁读来保证不会出现幻读。

MySQL InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ（可重读） 。我们可以通过 SELECT @@tx_isolation; 命令来查看，MySQL 80 该命令改为 SELECT @@transaction_isolation;

从上面对 SQL 标准定义了四个隔离级别的介绍可以看出，标准的 SQL 隔离级别定义里，REPEATABLE-READ(可重复读)是不可以防止幻读的。

但是！InnoDB 实现的 REPEATABLE-READ 隔离级别其实是可以解决幻读问题发生的，主要有下面两种情况：

因为隔离级别越低，事务请求的锁越少，所以大部分数据库系统的隔离级别都是 READ-COMMITTED ，但是你要知道的是 InnoDB 存储引擎默认使用 REPEATABLE-READ 并不会有任何性能损失。

InnoDB 存储引擎在分布式事务的情况下一般会用到 SERIALIZABLE 隔离级别。

1查看当前会话隔离级别

select @@tx_isolation;

2查看系统当前隔离级别

select @@globaltx_isolation;

3设置当前会话隔离级别

set session transaction isolatin level repeatable read;

4设置系统当前隔离级别

set global transaction isolation level repeatable read;

5命令行，开始事务时

set autocommit=off 或者 start transaction

关于隔离级别的理解

1read uncommitted

可以看到未提交的数据（脏读），举个例子：别人说的话你都相信了，但是可能他只是说说，并不实际做。

2read committed

读取提交的数据。但是，可能多次读取的数据结果不一致（不可重复读，幻读）。用读写的观点就是：读取的行数据，可以写。

3repeatable read(MySQL默认隔离级别)

可以重复读取，但有幻读。读写观点：读取的数据行不可写，但是可以往表中新增数据。在MySQL中，其他事务新增的数据，看不到，不会产生幻读。采用多版本并发控制（MVCC）机制解决幻读问题。

4serializable

可读，不可写。像java中的锁，写数据必须等待另一个事务结束。

那么不知道你 对于Spring支持的常用数据库事务传播属性和隔离级别 了解得怎么样呢？要不要一起复习复习了:grin:

很喜欢一句话：“八小时内谋生活，八小时外谋发展”

共勉 :woman: :computer:

描述 ：进来先看看风景啦，要相信会有光的哦

对于数据库事务ACID（原子性、一致性、隔离性、持久性）性质我想大家都是知道的，这里就不写了:grin:

我们都知道用事务是为了保证数据库的完整性，保证成批的 SQL 语句要么全部执行，要么全部不执行。

但是如果一个方法嵌套关联着其他方法了，这该怎么算呢？当前方法及关联方法都有事务呢，或者只是其中某几个有事务，该用谁的呢？

事务的传播行为：一个方法运行在一个开启了事务的方法上时，当前方法是使用原来的事务还是开启一个新的事务。

通过 @Transaction 注解中 propagation 来设置事务传播行为。其中

事务传播行为总共有以下七种：

下面写了一个小demo来让理解更加快捷一些哈。

注意：account表中 balance 字段是设置为无符号的（即不能为负数）。

项目就是普通Spring项目

模拟的是买书的一个过程，账户余额不足，但是一次买多本的情况，一起付款。

在其中再测试事务传播行为的不同，来看数据的变化。

初始代码：

mapper层代码

测试一：默认事务传播行为

我们在 void checkout(int userId, List isbns) 和 void purchase(int userId, int isbn) 上都加了 @Transactional

目前账户为 100元，两本书的价格分别为 60和50 ，因为我们的付款过程是 使用循环 购买的，你说我们会买到一本还是一本都买不到呢？

答案当然是一本都买不到，因为 @Transactional 注解 ，默认事务的传播属性是：REQUIRED，即业务方法需要在一个事务中运行。如果方法运行时，已经处在一个事务中，那么加入到该事务，否则为自己创建一个新的事务。所以实际上 void purchase(int userId, int isbn) 其实和调用它的方法用的同一个事务。简单画个图：

测试二：测试 -->REQUIRES_NEW属性

其他代码未改变，仅在 purchase 上的注解上加了点东西 @Transactional(propagation = PropagationREQUIRES_NEW)

REQUIRES_NEW: 不管是否存在事务，业务方法总会为自己发起一个新的事务。如果方法已经运行在一个事务中，则原有事务会被挂起，新的事务会被创建，直到方法执行结束，新事务才算结束，原先的事务才会恢复执行。

你说说答案和上面是一样的么？:grinning:

答案是不一样的， 测试一 我们实际上用的就是checkout上的事务，并没有用到 purchase 的事务，从图上也能看出来。

测试二它的事务传播属性 用 图来讲是这样的啦：

所以是可以买到一本书的。

还有很多，意思都解释过了，没有一一测完了。

假设现在有A和B 两个事务 并发执行。

1）脏读：一个事务读取到另一事务未提交的更新新据

2）不可重复读: 同一事务中，多次读取同一数据返回的结果有所不同(针对的update *** 作)

3）幻读:一个事务读取到另一事务已提交的insert数据(针对的insert *** 作)

数据库事务的隔离性: 数据库系统必须具有隔离并发运行各个事务的能力, 使它们不会相互影响, 避免各种并发问题

一个事务与其他事务隔离的程度称为隔离级别 数据库规定了多种事务隔离级别, 不同隔离级别对应不同的干扰程度, 隔离级别越高, 数据一致性就越好, 但并发性越弱

在代码中，我们可以通过

数据库提供了4种隔离级别：

注 : 模拟并发情况。

1） 测试一下 mysql 的默认隔离级别：

测试代码特别简单，但因为我是手动模拟，得打断点、debug启动，

当执行完第一个 double bookPrice = bookShopMappergetBookPriceByIsbn(isbn) 语句时，应该去mysql 修改一下书的价格，这样看一下结果。

这个时候再接着执行。看输出什么。

最后的结果仍然是50、50。因为mysql的默认事务隔级别是可重复读，意思在这同一个事务中，可以重复读。

注 ：因为这是直接修改数据库，其 *** 作行为并不可取，此处只是为了模拟。其结果有时也非一定准确。

1查看当前会话隔离级别

select

@@tx_isolation;

2查看系统当前隔离级别

select

@@globaltx_isolation;

3设置当前会话隔离级别

set

session

transaction

isolatin

level

repeatable

read;

4设置系统当前隔离级别

set

global

transaction

isolation

level

repeatable

read;

5命令行，开始事务时

set

autocommit=off

或者

start

transaction

关于隔离级别的理解

MVCC(Mutil-Version Concurrency Control)，就是多版本并发控制。这种并发控制的方法，主要应用在RC和RR隔离级别的事务当中，利用执行select *** 作时，访问记录版本链，使得不同事物的读写，写读可以并发执行，提高系统性能。

Innodb 有两个隐藏字段 trx_id(事务id)和roll_pointer(回滚指针)。

transaction id ：

innoDB里面每个事务有一个唯一的事务ID，叫作transaction id，它是在事务开始的时候向InnoDB的事务系统申请的，是按申请顺序严格递增的。

roll_pointer ：

指向上一事务版本的指针。

版本链 ：

是一个单链表结构，对于同一行数据，每一个事务对其进行更新的时候都会产生一个新的版本，就会存储在这个链表当中。

一个存储事务id的列表。

readview的几个参数：

m_ids:表示活跃事务id列表

min_trx_id:活跃事务中的最小事务id

max_trx_id:已创建的最大事务id

creator_trx_id:当前的事务id。

readview的生成时机：

RC隔离级别：每次读取数据前，都生成一个readview；

RR隔离级别：在第一次读取数据前，生成一个readview；

使用场景：

[ 创建事务节点 ] 当我创建一个新的事务需要读取一行数据, 我会查询活跃的事务列表; 假设我当前的事务id是200, 当前活跃的事务id没有我的200, 因此需要去拷贝一个最新的不活跃事务并在版本链最后插入一个新节点200; mysql会去对比版本链和readView, 假设版本链数据为[1,50,100,150], 活跃列表为[100,150], 说明100和150都是未提交的活跃事务, 再向前一个节点50不在活跃事务列表说明事务50已经提交, 所以事务200拷贝事务50并插入版本链最后, 且将200追加到readView活跃列表的最后一个元素

[ 使用事务节点 ] 当我再次进行200号事务的查询或修改, 我需要读版本链的数据, 因为上一次 *** 作已经在版本链做了200号节点, 因此我读的数据都是200号节点的数据, 这样就隔离了其他未提交的事务; 我的全部增删查改都在200号版本链上进行

[ readView实现事务隔离级别 ]以上两点都是基于隔离级别"读已提交"来进行说明的; 当mysql设置为"可重复读"时, 不同事务仍然是保存在版本链的不同节点上, 只不过新的事务创建的时候拷贝了当下的readView列表, 只要新事物不提交就一直使用这个拷贝的活跃列表; 假设此时100号数据提交了, 我在新事务执行了select 会去查活跃列表发现100号事务还是未提交状态, 因此读取到的还是50号事务提交的记录。

原子性，一致性，隔离性，持久性。

未提交读（read uncommitted）、提交读（read committed）、可重复读（repeatable read）、序列化读（serializable）

术式之后皆为逻辑，一切皆为需求和实现。希望此文能从需求、现状和解决方式的角度帮大家理解隔离级别。

隔离级别的产生

在串型执行的条件下，数据修改的顺序是固定的、可预期的结果，但是并发执行的情况下，数据的修改是不可预期的，也不固定，为了实现数据修改在并发执行的情况下得到一个固定、可预期的结果，由此产生了隔离级别。

所以隔离级别的作用是用来平衡数据库并发访问与数据一致性的方法。

事务的4种隔离级别

READ UNCOMMITTED       未提交读，可以读取未提交的数据。READ COMMITTED         已提交读，对于锁定读(select with for update 或者 for share)、update 和 delete 语句，                       InnoDB 仅锁定索引记录，而不锁定它们之间的间隙，因此允许在锁定的记录旁边自由插入新记录。                       Gap locking 仅用于外键约束检查和重复键检查。REPEATABLE READ        可重复读，事务中的一致性读取读取的是事务第一次读取所建立的快照。SERIALIZABLE           序列化

在了解了 4 种隔离级别的需求后，在采用锁控制隔离级别的基础上，我们需要了解加锁的对象(数据本身&间隙)，以及了解整个数据范围的全集组成。

数据范围全集组成

SQL 语句根据条件判断不需要扫描的数据范围（不加锁）；

SQL 语句根据条件扫描到的可能需要加锁的数据范围；

以单个数据范围为例，数据范围全集包含：（数据范围不一定是连续的值，也可能是间隔的值组成）

1 数据已经填充了整个数据范围：（被完全填充的数据范围，不存在数据间隙）

整形，对值具有唯一约束条件的数据范围 1～5 ，

已有数据1、2、3、4、5，此时数据范围已被完全填充；

整形，对值具有唯一约束条件的数据范围 1 和 5 ，

已有数据1、5，此时数据范围已被完全填充；

2 数据填充了部分数据范围：（未被完全填充的数据范围，是存在数据间隙）

整形的数据范围 1～5 ，

已有数据 1、2、3、4、5，但是因为没有唯一约束，

所以数据范围可以继续被 1～5 的数据重复填充；

整形，具有唯一约束条件的数据范围 1～5 ，

已有数据 2，5，此时数据范围未被完全填充，还可以填充 1、3、4 ；

3 数据范围内没有任何数据（存在间隙）

如下：

整形的数据范围 1～5 ，数据范围内当前没有任何数据。

在了解了数据全集的组成后，我们再来看看事务并发时，会带来的问题。

无控制的并发所带来的问题

并发事务如果不加以控制的话会带来一些问题，主要包括以下几种情况。

1 范围内已有数据更改导致的：

更新丢失：当多个事务选择了同一行，然后基于最初选定的值更新该行时，

由于每个事物不知道其他事务的存在，最后的更新就会覆盖其他事务所做的更新；

脏读： 一个事务正在对一条记录做修改，这个事务完成并提交前，这条记录就处于不一致状态。

这时，另外一个事务也来读取同一条记录，如果不加控制，

第二个事务读取了这些“脏”数据，并据此做了进一步的处理，就会产生提交的数据依赖关系。

这种现象就叫“脏读”。

2 范围内数据量发生了变化导致：

不可重复读：一个事务在读取某些数据后的某个时间，再次读取以前读过的数据，

却发现其读出的数据已经发生了改变，或者某些记录已经被删除了。

这种现象就叫“不可重复读”。

幻读：一个事务按相同的查询条件重新读取以前检索过的数据，

却发现其他事务插入了满足其查询条件的新数据，这种现象称为“幻读”。

可以简单的认为满足条件的数据量变化了。

因为无控制的并发会带来一系列的问题，这些问题会导致无法满足我们所需要的结果。因此我们需要控制并发，以实现我们所期望的结果(隔离级别)。

MySQL 隔离级别的实现

InnoDB 通过加锁的策略来支持这些隔离级别。

行锁包含：

Record Locks

索引记录锁，索引记录锁始终锁定索引记录，即使表中未定义索引，

这种情况下，InnoDB 创建一个隐藏的聚簇索引，并使用该索引进行记录锁定。

Gap Locks

间隙锁是索引记录之间的间隙上的锁，或者对第一条记录之前或者最后一条记录之后的锁。

间隙锁是性能和并发之间权衡的一部分。

对于无间隙的数据范围不需要间隙锁，因为没有间隙。

Next-Key Locks

索引记录上的记录锁和索引记录之前的 gap lock 的组合。

假设索引包含 10、11、13 和 20。

可能的next-key locks包括以下间隔，其中圆括号表示不包含间隔端点，方括号表示包含端点：

(负无穷大, 10]    (10, 11]    (11, 13]    (13, 20]    (20, 正无穷大)        对于最后一个间隔，next-key将会锁定索引中最大值的上方，

左右滑动进行查看

"上确界"伪记录的值高于索引中任何实际值。

上确界不是一个真正的索引记录，因此，实际上，这个 next-key 只锁定最大索引值之后的间隙。

基于此，当获取的数据范围中，数据已填充了所有的数据范围，那么此时是不存在间隙的，也就不需要 gap lock。

对于数据范围内存在间隙的，需要根据隔离级别确认是否对间隙加锁。

默认的 REPEATABLE READ 隔离级别，为了保证可重复读，除了对数据本身加锁以外，还需要对数据间隙加锁。

READ COMMITTED 已提交读，不匹配行的记录锁在 MySQL 评估了 where 条件后释放。

对于 update 语句，InnoDB 执行 "semi-consistent" 读取，这样它会将最新提交的版本返回到 MySQL，

以便 MySQL 可以确定该行是否与 update 的 where 条件相匹配。

总结&延展：

唯一索引存在唯一约束，所以变更后的数据若违反了唯一约束的原则，则会失败。

当 where 条件使用二级索引筛选数据时，会对二级索引命中的条目和对应的聚簇索引都加锁；所以其他事务变更命中加锁的聚簇索引时，都会等待锁。

行锁的增加是一行一行增加的，所以可能导致并发情况下死锁的发生。

例如，

在 session A 对符合条件的某聚簇索引加锁时，可能 session B 已持有该聚簇索引的 Record Locks，而 session B 正在等待 session A 已持有的某聚簇索引的 Record Locks。

session A 和 session B 是通过两个不相干的二级索引定位到的聚簇索引。

session A 通过索引 idA，session B通过索引 idB 。

当 where 条件获取的数据无间隙时，无论隔离级别为 rc 或 rr，都不会存在间隙锁。

比如通过唯一索引获取到了已完全填充的数据范围，此时不需要间隙锁。

间隙锁的目的在于阻止数据插入间隙，所以无论是通过 insert 或 update 变更导致的间隙内数据的存在，都会被阻止。

rc 隔离级别模式下，查询和索引扫描将禁用 gap locking，此时 gap locking 仅用于外键约束检查和重复键检查（主要是唯一性检查）。

rr 模式下，为了防止幻读，会加上 Gap Locks。

事务中，SQL 开始则加锁，事务结束才释放锁。

就锁类型而言，应该有优化锁，锁升级等，例如rr模式未使用索引查询的情况下，是否可以直接升级为表锁。

就锁的应用场景而言，在回放场景中，如果确定事务可并发，则可以考虑不加锁，加快回放速度。

锁只是并发控制的一种粒度，只是一个很小的部分：

从不同场景下是否需要控制并发，(已知无交集且有序的数据的变更，MySQL 的 MTS 相同前置事务的多事务并发回放)

并发控制的粒度，(锁是一种逻辑粒度，可能还存在物理层和其他逻辑粒度或方式)

相同粒度下的优化，(锁本身存在优化，如IX、IS类型的优化锁)

粒度加载的安全&性能(如获取行锁前，先获取页锁，页锁在执行获取行锁 *** 作后即释放，无论是否获取成功)等多个层次去思考并发这玩意。

以上就是关于MySQL 事务的默认隔离级别是什么可以解决幻读问题么全部的内容，包括:MySQL 事务的默认隔离级别是什么可以解决幻读问题么、什么是oracle数据库隔离级别、Spring支持的常用数据库事务传播属性和隔离级别等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！