MySQL：事务的ACID特性隔离级别脏读、不可重复读、幻读、Next-Key锁——场景复现

目录

1、什么是事务

2、 事务的ACID特性

2.1 事务的隔离性

3、为什么要使用事务？

4、查看支持事务的存储引擎

5、使用事务

5.1 控制事务

5.1.1 开启事务

5.1.2 关闭事务

5.2 开始一个事务，执行修改后回滚

5.3 开始一个事务，执行修改后提交

5.4 保存点

 5.5 自动/手动提交事务

6、隔离级别

6.1 隔离级别分类

6.1.1 查看隔离级别

6.1.2 设置隔离级别

6.2 READ UNCOMMITTED 【读未提交】

6.2.1 场景复现——“脏读”

6.3  READ COMMITTED 【读已提交】

6.3.1 场景复现——“不可重复读”

6.4  REPEATABLE READ 【可重复读(默认)】

6.4.1 场景复现——“幻读”

6.4.2 场景复现——间隙锁(next-key锁)

6.5 SERIALIZABLE【串行化】

1、什么是事务

事务一般是指要做的或所做的事情。

在计算机术语中，事务是指访问并可能更新‌数据库中各种数据项的一个程序执行单元。

事务结束有两种：

1. 事务中的步骤全部成功执行时，提交事务。
2. 如果其中一个失败，那么将会发生回滚。

在事务中，对于修改，只要提交(commit)，就可以成功保存；只要回滚(rollback)，就可以回到事务之初。

2、 事务的ACID特性

事务中含若干个SQL语句（可以是一组，也可以是一个），事务将这些SQL语句打包为一个整体，在执行的过程中，需满足：

1. 原子性（Atomicity）：是支持事务的数据库中最基本的一个特性。事务中的SQL，要么全部执行成功要么全部执行失败，不会出现只执行一半的情况。如果事务在执行时出现错误，事务就会回滚(Rollback)到事务开始的状态，就像事务没有执行过一样，不会出现只执行一半的情况。
2. 一致性（Consistency）：执行前后，结果“总和”不变。执行完成后，保证数据正确且符合预期。
3. 隔离性（Isolation）：执行时，多个事务之间不能相互干扰。
4. 持久性（Durability）：一旦执行完毕（提交或回滚）后，即刻落盘（永久保存，不会丢失）。

以上这四点在事务的整个执行过程中必须要得到保证，这也就是事务的 ACID 特性。

• 事务的一致性，是通过原子性、隔离性和持久性来实现的。

2.1 事务的隔离性

由于数据库是一个网络服务，可以同时支持多个客户端进行访问，那么不同的客户端在对同⼀张表中的同一条数据进行修改的时候就可能出现相互影响的情况。为了保证多个客户端之间不能相互干扰和影响，那么事务间就需要隔离起来，这种特性就称为隔离性。

本篇主要讲解事务的隔离性，下文会详细讲解隔离级别。为了帮助大家更好的理解隔离性，这里为大家举个例子。

假设张三的余额中存有1000元，此时，会话1和会话2同时对张三的余额进行扣除100元操作，
正确的余额应该是1000-100-100=800元，但是由于两个会话之间相互干扰(不具备隔离性)，导致余额错误：900。

​

此时，应该考虑在两个会话之间建立隔离性，使两个会话之间不能相互影响，正确结果应该让会话2在会话1的基础上再进行扣除100元的操作。

3、为什么要使用事务？

上文说到，对于数据库而言，两大要素是必须要保证的：

1. 安全
2. 效率

上文所讲的索引，是用来提升查询效率的。而事务，就是为了保证数据安全的。

事务的ACID特性，能够保证数据的安全。不论是在网络异常或者服务器宕机的情况下，都能够保证数据安全：修改成功——即刻落盘，永久保存。发生错误——即刻回滚，回到事务之初。

4、查看支持事务的存储引擎

查看MySQL中的存储引擎：show engines;

innoDB是MySQL中支持事务的存储引擎，也是MySQL默认的存储引擎。

5、使用事务

5.1 控制事务

5.1.1 开启事务

开启事务的语法有两种：

1. begin;
2. start transaction;

5.1.2 关闭事务

关闭事务分为提交(commit)和回滚(rollback)：

1. commit;//提交当前事务，使修改即刻落盘，永久保存
2. rollback;//发生错误，撤销修改，回滚(恢复)到事务之初

注意：无论是提交(COMMIT)还是回滚(ROLLBACK)，事务都会关闭。

5.2 开始一个事务，执行修改后回滚

事务开始前表中的数据：

开启事务，并在事务中进行插入操作，插入完成后执行回滚rollback操作(同时关闭事务)，发现数据回滚到事务之初： 

5.3 开始一个事务，执行修改后提交

 事务开始前表中的数据：

 开启事务，并在事务中进行插入操作，插入完成后执行提交commit操作(同时关闭事务)，发现插入的数据被保存： 

注意：

事务提交(commit)后不能再执行回滚(rollback)操作，因为数据提交后就已落盘。

5.4 保存点

在事务执行的过程中我们可以设置保存点，可以回滚到指定的保存点上，将数据恢复到该保存点的状态(不必将数据全部回滚到事务之初)。

 5.5 自动/手动提交事务

在MySQL中，事务是默认自动开启并提交或者回滚的，也就是说，我们写出的每一条SQL语句都是一个事务，且每一个事务中只包含了一条DML语句。

DML语句执行成功则自动提交，如果出现了错误则自动回滚。

查看当前事务是否自动提交，我们可以使用语句：show varibales like 'autocommit';

1. ON：代表事务开始自动提交/回滚
2. OFF：代表事务需手动提交/回滚

当然，我们也可以设置事务的提交方式：

# 设置事务⾃动提交
SET AUTOCOMMIT=1; # ⽅式⼀
SET AUTOCOMMIT=ON; # ⽅式⼆
# 设置事务⼿动提交
SET AUTOCOMMIT=0; # ⽅式⼀
SET AUTOCOMMIT=OFF; # ⽅式⼆

注意：

• 如果使用 start transaction / begin 开启事务，则必须使用commit / rollback 来关闭事务，与是否设置自动提交事务无关。 
• 手动提交模式下，不用显示开启事务，执行修改操作后，提交或回滚事务时直接使用 commit 或 rollback
• 已提交的事务不能回滚（数据已落盘）
• 因为MySQL默认的是自动提交事务，所以即使将autocommit设置为手动，下次启动时，也仍然会恢复为自动提交

6、隔离级别

6.1 隔离级别分类

上文讲到，事务具有隔离性。事务间可以有不同的隔离级别，在这些隔离级别中，有的注重并发性，有的注重安全性，有的并发和安全性适中。在MySQL的innoDB存储引擎中，隔离级别分为以下四种：

1. READ UNCOMMITTED ，读未提交
2. READ COMMITTED ，读已提交
3. REPEATABLE READ ，可重复读(默认)
4. SERIALIZABLE ，串行化

6.1.1 查看隔离级别

事务的隔离级别分为全局作用域和会话作用域，查看不同作用域事务的隔离级别，可以使用以下的 方式：

# 全局作用域
SELECT @@GLOBAL.transaction_isolation;
# 会话作⽤域
SELECT @@SESSION.transaction_isolation;

使用全局作用域查看的就是所有的会话下的隔离级别，而会话作用域查看的就是仅当前的会话中的隔离级别。

6.1.2 设置隔离级别

# 设置全局事务隔离级别为串⾏化，后续所有事务⽣效，不影响当前事务
SET GLOBAL TRANSACTION ISOLATION LEVEL SERIALIZABLE;# 设置会话事务隔离级别为串⾏化，当前会话后续的所有事务⽣效，不影响当前事务，可以在任何时候
执⾏
SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;# 如果不指定任何作⽤域，设置只针对下⼀个事务，随后的事务恢复之前的隔离级别
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

或者

# ⽅式⼀
SET GLOBAL transaction_isolation = 'SERIALIZABLE';
# 注意使⽤SET语法时有空格要⽤"-"代替
SET SESSION transaction_isolation = 'REPEATABLE-READ';

6.2 READ UNCOMMITTED 【读未提交】

在READ UNCOMMITTED的隔离级别下，读取数据时不做任何的限制，故此隔离级别具备很高的并发性能，但安全性极低，会出现大量的数据安全问题。

例如：事务A对某一数据进行了修改，此时事务A并没有提交，但是事务B却已经读取了这个还没有提交的数据，若事务A对这个数据进行了回滚操作，那么事务B读取的将是一条垃圾数据，毫无意义。

一个事务读取了另一个事务还没有提交的数据，这种情况就叫做“脏读”。 

6.2.1 场景复现——“脏读”

“脏读”现象——复现如下：

因为是全局域的设置，所以其他会话的隔离级别也被修改了：

这时，我们向事务A中插入数据（并不提交），但是事务B却可读取事务A中还未提交的数据：

这种现象就叫做——“脏读”。

6.3  READ COMMITTED 【读已提交】

该隔离级别解决了脏读的问题，只能读取到已提交的数据，但是也出现了不可重复读的问题。

例如：事务A查询了某一条记录后，事务B对这条记录进行了修改了并提交，事务A再次对这条记录进行了查询，发现第一次查询的内容和第二次查询的内容不一致。

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

6.3.1 场景复现——“不可重复读”

“不可重复读”现象——复现如下：

此时，事务B对事务A查询过的记录进行了修改并提交，事务A再次查询该记录得到的内容不一致：

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

6.4  REPEATABLE READ 【可重复读(默认)】

该隔离级别解决了不可重复读的问题，使得事务A在任何时候读取的数据都是相同的结果，相当于对这条记录上了一把锁，事务B无法对该记录进行修改操作。

但是，该隔离级别出现了“幻读”的问题。

例如：事务A在第一次查询得到了结果集后，事务B进行了记录的增/删操作(例如在记录间的区间间隙中插入新记录)，使得事务A再次查询时得到的结果集不同。

这种现象，就叫做“幻读”。

但是，innoDB存储引擎中，使用了next-key锁，锁住目标行和之前的间隙（中间有锁，后面没锁），使得其他事务使得无法在记录的间隙中插入新记录，解决了大部分的幻读问题。

注意：

• “不可重复读”，指的是某一条具体的记录发生了改变，两次查询出的这条记录的内容不同。(可以理解为，元素发生了改变)
• 而“幻读”，指的是结果集发生了改变，使得两次查询得到的结果集不同。(可以理解为，集合发生了改变)

6.4.1 场景复现——“幻读”

“幻读”现象——复现如下：

（由于innoDB对 可重复读 使用了“间隙锁”解决了幻读问题，所以本次仍在 读已提交 的隔离级别下进行演示）

由于事务A在记录的间隙中插入了新数据行，导致事务B在两次相同的查询中，得到的结果集不一致，这种现象就叫做——幻读。

6.4.2 场景复现——间隙锁(next-key锁)

将隔离级别恢复为 可重复读。

把隔离级别设置为REPEATABLE-READ(可重复读)后，在ID的间隙中插入新数据观察现象，如下图所示，在id=5和id=7的间隙中插入id=6的数据行：

innoDB存储引擎使用间隙锁，使得在记录的间隙中无法插入数据，解决了大部分“幻读问题”。

6.5 SERIALIZABLE【串行化】

该隔离级别解决了所有的数据安全问题，所有的事务都是一个挨着一个的执行，一个事务必须等上一个事务执行完之后才能执行。

END