Mysql案例刨析事务隔离级别

目录
  • 1. 理论
    • SERIALIZABLE
    • REPEATABLE READ
    • READ COMMITTED
    • READ UNCOMMITTED
  • 2. SQL 实践
    • 2.1 查看隔离级别
    • 2.2 READ UNCOMMITTED
      • 2.2.1 准备测试数据
      • 2.2.2 脏读
      • 2.2.3 不可重复读
      • 2.2.4 幻象读
    • 2.3 READ COMMITTED
    • 2.4 REPEATABLE READ
    • 2.5 SERIALIZABLE
  • 3. 总结

很多小伙伴对 MySQL 的隔离级别一直心存疑惑,其实这个问题一点都不难,关键看怎么讲!单纯的看理论,绝对让你晕头转向,但是,如果我们通过几个实际的 SQL 来演示一些,大家就会发现这玩意原来这么简单!

今天松哥想通过几个简单的案例,来和大家演示一下 MySQL 中的事务隔离级别问题。

1. 理论

MySQL 中事务的隔离级别一共分为四种,分别如下:

  • 序列化(SERIALIZABLE)
  • 可重复读(REPEATABLE READ)
  • 提交读(READ COMMITTED)
  • 未提交读(READ UNCOMMITTED)

四种不同的隔离级别含义分别如下:

SERIALIZABLE

如果隔离级别为序列化,则用户之间通过一个接一个顺序地执行当前的事务,这种隔离级别提供了事务之间最大限度的隔离。

REPEATABLE READ

在可重复读在这一隔离级别上,事务不会被看成是一个序列。不过,当前正在执行事务的变化仍然不能被外部看到,也就是说,如果用户在另外一个事务中执行同条 SELECT 语句数次,结果总是相同的。(因为正在执行的事务所产生的数据变化不能被外部看到)。

READ COMMITTED

READ COMMITTED 隔离级别的安全性比 REPEATABLE READ 隔离级别的安全性要差。处于 READ COMMITTED 级别的事务可以看到其他事务对数据的修改。也就是说,在事务处理期间,如果其他事务修改了相应的表,那么同一个事务的多个 SELECT 语句可能返回不同的结果。

READ UNCOMMITTED

READ UNCOMMITTED 提供了事务之间最小限度的隔离。除了容易产生虚幻的读操作和不能重复的读操作外,处于这个隔离级的事务可以读到其他事务还没有提交的数据,如果这个事务使用其他事务不提交的变化作为计算的基础,然后那些未提交的变化被它们的父事务撤销,这就导致了大量的数据变化。

在 MySQL 数据库种,默认的事务隔离级别是 REPEATABLE READ

2. SQL 实践

接下来通过几条简单的 SQL 向读者验证上面的理论。

2.1 查看隔离级别

通过如下 SQL 可以查看数据库实例默认的全局隔离级别和当前 session 的隔离级别:

MySQL8 之前使用如下命令查看 MySQL 隔离级别:

SELECT @@GLOBAL.tx_isolation, @@tx_isolation;

查询结果如图:

可以看到,默认的隔离级别为 REPEATABLE-READ,全局隔离级别和当前会话隔离级别皆是如此。

MySQL8 开始,通过如下命令查看 MySQL 默认隔离级别:

SELECT @@GLOBAL.transaction_isolation, @@transaction_isolation;

就是关键字变了,其他都一样。

通过如下命令可以修改隔离级别(建议开发者在修改时修改当前 session 隔离级别即可,不用修改全局的隔离级别):

SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

上面这条 SQL 表示将当前 session 的数据库隔离级别设置为 READ UNCOMMITTED,设置成功后,再次查询隔离级别,发现当前 session 的隔离级别已经变了,如图1-2:

注意,如果只是修改了当前 session 的隔离级别,则换一个 session 之后,隔离级别又会恢复到默认的隔离级别,所以我们测试时,修改当前 session 的隔离级别即可。

2.2 READ UNCOMMITTED

2.2.1 准备测试数据

READ UNCOMMITTED 是最低隔离级别,这种隔离级别中存在脏读、不可重复读以及幻象读问题,所以这里我们先来看这个隔离级别,借此大家可以搞懂这三个问题到底是怎么回事。

下面分别予以介绍。

首先创建一个简单的表,预设两条数据,如下:

表的数据很简单,有 javaboy 和 itboyhub 两个用户,两个人的账户各有 1000 人民币。现在模拟这两个用户之间的一个转账操作。

注意,如果读者使用的是 Navicat 的话,不同的查询窗口就对应了不同的 session,如果读者使用了 SQLyog 的话,不同查询窗口对应同一个 session,因此如果使用 SQLyog,需要读者再开启一个新的连接,在新的连接中进行查询操作。

2.2.2 脏读

一个事务读到另外一个事务还没有提交的数据,称之为脏读。具体操作如下:

首先打开两个SQL操作窗口,假设分别为 A 和 B,在 A 窗口中输入如下几条 SQL (输入完成后不用执行):

START TRANSACTION;
UPDATE account set balance=balance+100 where name='javaboy';
UPDATE account set balance=balance-100 where name='itboyhub';
COMMIT;

在 B 窗口执行如下 SQL,修改默认的事务隔离级别为 READ UNCOMMITTED,如下:

SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

接下来在 B 窗口中输入如下 SQL,输入完成后,首先执行第一行开启事务(注意只需要执行一行即可):

START TRANSACTION;
SELECT * from account;
COMMIT;

接下来执行 A 窗口中的前两条 SQL,即开启事务,给 javaboy 这个账户添加 100 元。

进入到 B 窗口,执行 B 窗口的第二条查询 SQL(SELECT * from user;),结果如下:

可以看到,A 窗口中的事务,虽然还未提交,但是 B 窗口中已经可以查询到数据的相关变化了。

这就是脏读问题。

2.2.3 不可重复读

不可重复读是指一个事务先后读取同一条记录,但两次读取的数据不同,称之为不可重复读。具体操作步骤如下(操作之前先将两个账户的钱都恢复为1000):

  1. 首先打开两个查询窗口 A 和 B ,并且将 B 的数据库事务隔离级别设置为 READ UNCOMMITTED。具体 SQL 参考上文,这里不赘述。
  2. 在 B 窗口中输入如下 SQL,然后只执行前两条 SQL 开启事务并查询 javaboy 的账户:
START TRANSACTION;
SELECT * from account where name='javaboy';
COMMIT;

前两条 SQL 执行结果如下:

在 A 窗口中执行如下 SQL,给 javaboy 这个账户添加 100 块钱,如下:

START TRANSACTION;
UPDATE account set balance=balance+100 where name='javaboy';
COMMIT;

4.再次回到 B 窗口,执行 B 窗口的第二条 SQL 查看 javaboy 的账户,结果如下:

javaboy 的账户已经发生了变化,即前后两次查看 javaboy 账户,结果不一致,这就是不可重复读。

和脏读的区别在于,脏读是看到了其他事务未提交的数据,而不可重复读是看到了其他事务已经提交的数据(由于当前 SQL 也是在事务中,因此有可能并不想看到其他事务已经提交的数据)。

2.2.4 幻象读

幻象读和不可重复读非常像,看名字就是产生幻觉了。

我举一个简单例子。

在 A 窗口中输入如下 SQL:

START TRANSACTION;
insert into account(name,balance) values('zhangsan',1000);
COMMIT;

然后在 B 窗口输入如下 SQL:

START TRANSACTION;
SELECT * from account;
delete from account where name='zhangsan';
COMMIT;

我们执行步骤如下:

  • 首先执行 B 窗口的前两行,开启一个事务,同时查询数据库中的数据,此时查询到的数据只有 javaboy 和 itboyhub。
  • 执行 A 窗口的前两行,向数据库中添加一个名为 zhangsan 的用户,注意不用提交事务。
  • 执行 B 窗口的第二行,由于脏读问题,此时可以查询到 zhangsan 这个用户。
  • 执行 B 窗口的第三行,去删除 name 为 zhangsan 的记录,这个时候删除就会出问题,虽然在 B 窗口中可以查询到 zhangsan,但是这条记录还没有提交,是因为脏读的原因才看到了,所以是没法删除的。此时就产生了幻觉,明明有个 zhangsan,却无法删除。

这就是幻读。

看了上面的案例,大家应该明白了脏读、不可重复读以及幻读各自是什么含义了。

2.3 READ COMMITTED

和 READ UNCOMMITTED 相比,READ COMMITTED 主要解决了脏读的问题,对于不可重复读和幻象读则未解决。

将事务的隔离级别改为 READ COMMITTED 之后,重复上面关于脏读案例的测试,发现已经不存在脏读问题了;重复上面关于不可重复读案例的测试,发现不可重复读问题依然存在。

上面那个案例不适用于幻读的测试,我们换一个幻读的测试案例。

还是两个窗口 A 和 B,将 B 窗口的隔离级别改为 READ COMMITTED

然后在 A 窗口输入如下测试 SQL:

START TRANSACTION;
insert into account(name,balance) values('zhangsan',1000);
COMMIT;

在 B 窗口输入如下测试 SQL:

START TRANSACTION;
SELECT * from account;
insert into account(name,balance) values('zhangsan',1000);
COMMIT;

测试方式如下:

  • 首先执行 B 窗口的前两行 SQL,开启事务并查询数据,此时查到的只有 javaboy 和 itboyhub 两个用户。
  • 执行 A 窗口的前两行 SQL,插入一条记录,但是并不提交事务。
  • 执行 B 窗口的第二行 SQL,由于现在已经没有了脏读问题,所以此时查不到 A 窗口中添加的数据。
  • 执行 B 窗口的第三行 SQL,由于 name 字段唯一,因此这里会无法插入。此时就产生幻觉了,明明没有 zhangsan 这个用户,却无法插入 zhangsan。

2.4 REPEATABLE READ

和 READ COMMITTED 相比,REPEATABLE READ 进一步解决了不可重复读的问题,但是幻象读则未解决。

REPEATABLE READ 中关于幻读的测试和上一小节基本一致,不同的是第二步中执行完插入 SQL 后记得提交事务。

由于 REPEATABLE READ 已经解决了不可重复读,因此第二步即使提交了事务,第三步也查不到已经提交的数据,第四步继续插入就会出错。

注意,REPEATABLE READ 也是 InnoDB 引擎的默认数据库事务隔离级别

2.5 SERIALIZABLE

SERIALIZABLE 提供了事务之间最大限度的隔离,在这种隔离级别中,事务一个接一个顺序的执行,不会发生脏读、不可重复读以及幻象读问题,最安全。

如果设置当前事务隔离级别为 SERIALIZABLE,那么此时开启其他事务时,就会阻塞,必须等当前事务提交了,其他事务才能开启成功,因此前面的脏读、不可重复读以及幻象读问题这里都不会发生。

3. 总结

总的来说,隔离级别和脏读、不可重复读以及幻象读的对应关系如下:

隔离级别 脏读 不可重复读 幻象读
READ UNCOMMITTED 允许 允许 允许
READ COMMITED 不允许 允许 允许
REPEATABLE READ 不允许 不允许 允许
SERIALIZABLE 不允许 不允许 不允许

性能关系如图:

好了,这篇文章就和小伙伴们先说这么多,大家不妨写几行 SQL 试一试。

到此这篇关于Mysql案例刨析事务隔离级别的文章就介绍到这了,更多相关Mysql 事务隔离级别内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • mysql、oracle默认事务隔离级别的说明

    1.事务的特性(ACID) (1)原子性(Atomicity).事务中所涉及的程序对数据库的修改操作要么全部成功,要么全部失败. (2)一致性(Consistency).事务执行前和执行后来源和去向保持平衡. (3)隔离性(Isolation).并发时每个事务是隔离的,相互不影响. (4)持久性(Durubility).一旦事务成功提交,应该保证数据的完整存在. 2.事务隔离级别 (1)read uncommitted 未提交读 所有事务都可以看到没有提交事务的数据. (2)read commi

  • MySql学习笔记之事务隔离级别详解

    背景 说的事务,大家应该都不陌生,开发用到 MySql 数据库的时候,通常会用到事务.其中比较经典的例子就是转账,比如你要给小明转 50 块钱,而此时你的银行卡也就只有 50 块钱. 对于转账过程在代码程序里会有一系列的操作,比如查询账户余额.余额加减.更新余额等,这些操作必须保证是一起处理的,不然等程序查完之后,如果账号 50 块钱还在,然后再给另外一个朋友转账,如果银行也处理的话,没有保证整个流程数据一致性的话,这不就乱套了吗?这时就要用到"事务"了. 事务介绍 简单来说,事务就是

  • 简述MySql四种事务隔离级别

    隔离级别: 隔离性其实比想象的要复杂. 在SQL标准中定义了四种隔离级别, 每一个事务中所做的修改,哪些在事务内和事务间是可见的,哪些是不可见的.较低级别的隔离通常可以执行更高的并发,系统的开销也更低. 下面简单地介绍一下四种隔离级别. 1.READ UNCOMMITTED(未提交读) 在 READ UNCOMMITTED级别, 事务中的修改, 即使没有提交, 对其他事务也都是可见的. 事务可以读取未提交的数据, 这也被称为脏读 (Dirty Read). 这个级别会导致很多问题,从性能上来说,

  • 详解MySQL中事务隔离级别的实现原理

    前言 说到数据库事务,大家脑子里一定很容易蹦出一堆事务的相关知识,如事务的ACID特性,隔离级别,解决的问题(脏读,不可重复读,幻读)等等,但是可能很少有人真正的清楚事务的这些特性又是怎么实现的,为什么要有四个隔离级别. 今天我们就先来聊聊MySQL中事务的隔离性的实现原理,后续还会继续出文章分析其他特性的实现原理. 当然MySQL博大精深,文章疏漏之处在所难免,欢迎批评指正. 说明 MySQL的事务实现逻辑是位于引擎层的,并且不是所有的引擎都支持事务的,下面的说明都是以InnoDB引擎为基准.

  • mysql在项目中怎么选事务隔离级别

    引言 开始我们的内容,相信大家一定遇到过下面的一个面试场景 面试官:"讲讲mysql有几个事务隔离级别?" 你:"读未提交,读已提交,可重复读,串行化四个!默认是可重复读" 面试官:"为什么mysql选可重复读作为默认的隔离级别?" (你面露苦色,不知如何回答!) 面试官:"你们项目中选了哪个隔离级别?为什么?" 你:"当然是默认的可重复读,至于原因..呃..." (然后你就可以回去等通知了!) 为了避免上

  • Mysql案例刨析事务隔离级别

    目录 1. 理论 SERIALIZABLE REPEATABLE READ READ COMMITTED READ UNCOMMITTED 2. SQL 实践 2.1 查看隔离级别 2.2 READ UNCOMMITTED 2.2.1 准备测试数据 2.2.2 脏读 2.2.3 不可重复读 2.2.4 幻象读 2.3 READ COMMITTED 2.4 REPEATABLE READ 2.5 SERIALIZABLE 3. 总结 很多小伙伴对 MySQL 的隔离级别一直心存疑惑,其实这个问题一

  • MySQL中Innodb的事务隔离级别和锁的关系的讲解教程

    前言: 我们都知道事务的几种性质,数据库为了维护这些性质,尤其是一致性和隔离性,一般使用加锁这种方式.同时数据库又是个高并发的应用,同一时间会有大量的并发访问,如果加锁过度,会极大的降低并发处理能力.所以对于加锁的处理,可以说就是数据库对于事务处理的精髓所在.这里通过分析MySQL中InnoDB引擎的加锁机制,来抛砖引玉,让读者更好的理解,在事务处理中数据库到底做了什么. 一次封锁or两段锁? 因为有大量的并发访问,为了预防死锁,一般应用中推荐使用一次封锁法,就是在方法的开始阶段,已经预先知道会

  • 一文了解MySQL事务隔离级别

    目录 前言 1.四种事务隔离级别 1.1 READ UNCOMMITTED 1.2 READ COMMITTED 1.3 REPEATABLE READ 1.4 SERIALIZABLE 1.5 小结 2.并发事务中的问题 2.1 脏读 2.2 不可重复读 2.3 幻读 3.隔离级别实战 3.1 查询事务隔离级别 3.2 设置事务隔离级别 3.3 脏读问题 3.4 不可重复读问题 3.5 幻读问题 总结 前言 MySQL 事务隔离级别是为了解决并发事务互相干扰的问题的,MySQL 事务隔离级别总

  • 深入理解Mysql事务隔离级别与锁机制问题

    概述 数据库一般都会并发执行多个事务,多个事务可能会并发的对相同的一批数据进行增删改查操作,可能导致脏读.脏写.不可重复度和幻读.这些问题的本质都是数据库的多事务并发问题,为了解决事务并发问题,数据库设计了事务隔离机制.锁机制.MVCC多版本并发控制隔离机制,用一整套机制来解决多事务并发问题. 事务及其ACID属性 原子性:操作的不可分割: 一致性:数据的一致性: 隔离性:事务之间互不干扰: 持久性:数据的修改时永久的: 并发事务处理带来的问题 脏写:丢失更新,最后的更新覆盖了由其他事务所做的更

  • MySQL数据库事务隔离级别介绍(Transaction Isolation Level)

    数据库隔离级别有四种,应用<高性能mysql>一书中的说明: 然后说说修改事务隔离级别的方法: 1.全局修改,修改mysql.ini配置文件,在最后加上 复制代码 代码如下: #可选参数有:READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, SERIALIZABLE. [mysqld] transaction-isolation = REPEATABLE-READ 这里全局默认是REPEATABLE-READ,其实MySQL本来默认也是这个级别

  • MySQL数据库事务隔离级别详解

    数据库事务隔离级别 数据库事务的隔离级别有4个,由低到高依次为 Read uncommitted:允许脏读. Read committed: 防止脏读,最常用的隔离级别,并且是大多数数据库的默认隔离级别. Repeatable read:可以防止脏读和不可重复读. Serializable:可以防止脏读,不可重复读取和幻读,(事务串行化)会降低数据库的效率. 这四个级别可以逐个解决脏读 .不可重复读 .幻读 这几类问题. √: 可能出现 ×: 不会出现 事务级别 脏读 不可重复读 幻读 Read

  • 通过实例分析MySQL中的四种事务隔离级别

    前言 在数据库操作中,为了有效保证并发读取数据的正确性,提出的事务隔离级别.数据库事务的隔离级别有4个,下面话不多说了,来一起看看详细的介绍吧. 数据库事务有四种隔离级别: 未提交读(Read Uncommitted):允许脏读,也就是可能读取到其他会话中未提交事务修改的数据. 提交读(Read Committed):只能读取到已经提交的数据,Oracle等多数数据库默认都是该级别. 可重复读(Repeated Read):可重复读.在同一个事务内的查询都是事务开始时刻一致的,InnoDB默认级

  • MySQL四种事务隔离级别详解

    本文实验的测试环境:Windows 10+cmd+MySQL5.6.36+InnoDB 一.事务的基本要素(ACID) 1.原子性(Atomicity):事务开始后所有操作,要么全部做完,要么全部不做,不可能停滞在中间环节.事务执行过程中出错,会回滚到事务开始前的状态,所有的操作就像没有发生一样.也就是说事务是一个不可分割的整体,就像化学中学过的原子,是物质构成的基本单位. 2.一致性(Consistency):事务开始前和结束后,数据库的完整性约束没有被破坏 .比如A向B转账,不可能A扣了钱,

随机推荐