Skip to content

Commit 7143240

Browse files
committed
Update transaction-isolation-level.md
1 parent 9f626e3 commit 7143240

File tree

1 file changed

+23
-57
lines changed

1 file changed

+23
-57
lines changed

docs/database/mysql/transaction-isolation-level.md

Lines changed: 23 additions & 57 deletions
Original file line numberDiff line numberDiff line change
@@ -7,48 +7,16 @@ tag:
77

88
> 本文由 [SnailClimb](https://github.com/Snailclimb)[guang19](https://github.com/guang19) 共同完成。
99
10-
## 事务隔离级别(图文详解)
10+
关于事务基本概览的介绍,请看这篇文章的介绍:[MySQL 常见知识点&面试题总结](./MySQL-questions-01.md#MySQL-事务)
1111

12-
### 什么是事务?
12+
## 事务隔离级别总结
1313

14-
事务是逻辑上的一组操作,要么都执行,要么都不执行。
14+
SQL 标准定义了四个隔离级别:
1515

16-
事务最经典也经常被拿出来说例子就是转账了。假如小明要给小红转账 1000 元,这个转账会涉及到两个关键操作就是:将小明的余额减少 1000 元,将小红的余额增加 1000 元。万一在这两个操作之间突然出现错误比如银行系统崩溃,导致小明余额减少而小红的余额没有增加,这样就不对了。事务就是保证这两个关键操作要么都成功,要么都要失败。
17-
18-
### 事务的特性(ACID)
19-
20-
![事务的特性](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-6/事务特性.png)
21-
22-
1. **原子性:** 事务是最小的执行单位,不允许分割。事务的原子性确保动作要么全部完成,要么完全不起作用;
23-
2. **一致性:** 执行事务前后,数据保持一致,例如转账业务中,无论事务是否成功,转账者和收款人的总额应该是不变的;
24-
3. **隔离性:** 并发访问数据库时,一个用户的事务不被其他事务所干扰,各并发事务之间数据库是独立的;
25-
4. **持久性:** 一个事务被提交之后。它对数据库中数据的改变是持久的,即使数据库发生故障也不应该对其有任何影响。
26-
27-
### 并发事务带来的问题
28-
29-
在典型的应用程序中,多个事务并发运行,经常会操作相同的数据来完成各自的任务(多个用户对统一数据进行操作)。并发虽然是必须的,但可能会导致以下的问题。
30-
31-
- **脏读(Dirty read):** 当一个事务正在访问数据并且对数据进行了修改,而这种修改还没有提交到数据库中,这时另外一个事务也访问了这个数据,然后使用了这个数据。因为这个数据是还没有提交的数据,那么另外一个事务读到的这个数据是“脏数据”,依据“脏数据”所做的操作可能是不正确的。
32-
- **丢失修改(Lost to modify):** 指在一个事务读取一个数据时,另外一个事务也访问了该数据,那么在第一个事务中修改了这个数据后,第二个事务也修改了这个数据。这样第一个事务内的修改结果就被丢失,因此称为丢失修改。 例如:事务 1 读取某表中的数据 A=20,事务 2 也读取 A=20,事务 1 修改 A=A-1,事务 2 也修改 A=A-1,最终结果 A=19,事务 1 的修改被丢失。
33-
- **不可重复读(Unrepeatableread):** 指在一个事务内多次读同一数据。在这个事务还没有结束时,另一个事务也访问该数据。那么,在第一个事务中的两次读数据之间,由于第二个事务的修改导致第一个事务两次读取的数据可能不太一样。这就发生了在一个事务内两次读到的数据是不一样的情况,因此称为不可重复读。
34-
- **幻读(Phantom read):** 幻读与不可重复读类似。它发生在一个事务(T1)读取了几行数据,接着另一个并发事务(T2)插入了一些数据时。在随后的查询中,第一个事务(T1)就会发现多了一些原本不存在的记录,就好像发生了幻觉一样,所以称为幻读。
35-
36-
**不可重复度和幻读区别:**
37-
38-
不可重复读的重点是修改,幻读的重点在于新增或者删除。
39-
40-
例 1(同样的条件, 你读取过的数据, 再次读取出来发现值不一样了 ):事务 1 中的 A 先生读取自己的工资为 1000 的操作还没完成,事务 2 中的 B 先生就修改了 A 的工资为 2000,导 致 A 再读自己的工资时工资变为 2000;这就是不可重复读。
41-
42-
例 2(同样的条件, 第 1 次和第 2 次读出来的记录数不一样 ):假某工资单表中工资大于 3000 的有 4 人,事务 1 读取了所有工资大于 3000 的人,共查到 4 条记录,这时事务 2 又插入了一条工资大于 3000 的记录,事务 1 再次读取时查到的记录就变为了 5 条,这样就导致了幻读。
43-
44-
### 事务隔离级别
45-
46-
**SQL 标准定义了四个隔离级别:**
47-
48-
- **READ-UNCOMMITTED(读取未提交):** 最低的隔离级别,允许读取尚未提交的数据变更,**可能会导致脏读、幻读或不可重复读**
49-
- **READ-COMMITTED(读取已提交):** 允许读取并发事务已经提交的数据,**可以阻止脏读,但是幻读或不可重复读仍有可能发生**
50-
- **REPEATABLE-READ(可重复读):** 对同一字段的多次读取结果都是一致的,除非数据是被本身事务自己所修改,**可以阻止脏读和不可重复读,但幻读仍有可能发生**
51-
- **SERIALIZABLE(可串行化):** 最高的隔离级别,完全服从 ACID 的隔离级别。所有的事务依次逐个执行,这样事务之间就完全不可能产生干扰,也就是说,**该级别可以防止脏读、不可重复读以及幻读**
16+
- **READ-UNCOMMITTED(读取未提交)** : 最低的隔离级别,允许读取尚未提交的数据变更,可能会导致脏读、幻读或不可重复读。
17+
- **READ-COMMITTED(读取已提交)** : 允许读取并发事务已经提交的数据,可以阻止脏读,但是幻读或不可重复读仍有可能发生。
18+
- **REPEATABLE-READ(可重复读)** : 对同一字段的多次读取结果都是一致的,除非数据是被本身事务自己所修改,可以阻止脏读和不可重复读,但幻读仍有可能发生。
19+
- **SERIALIZABLE(可串行化)** : 最高的隔离级别,完全服从 ACID 的隔离级别。所有的事务依次逐个执行,这样事务之间就完全不可能产生干扰,也就是说,该级别可以防止脏读、不可重复读以及幻读。
5220

5321
---
5422

@@ -62,7 +30,7 @@ tag:
6230
MySQL InnoDB 存储引擎的默认支持的隔离级别是 **REPEATABLE-READ(可重读)**。我们可以通过`SELECT @@tx_isolation;`命令来查看,MySQL 8.0 该命令改为`SELECT @@transaction_isolation;`
6331

6432
```sql
65-
mysql> SELECT @@tx_isolation;
33+
MySQL> SELECT @@tx_isolation;
6634
+-----------------+
6735
| @@tx_isolation |
6836
+-----------------+
@@ -85,9 +53,9 @@ InnoDB 存储引擎在分布式事务的情况下一般会用到 SERIALIZABLE
8553

8654
> InnoDB 存储引擎提供了对 XA 事务的支持,并通过 XA 事务来支持分布式事务的实现。分布式事务指的是允许多个独立的事务资源(transactional resources)参与到一个全局的事务中。事务资源通常是关系型数据库系统,但也可以是其他类型的资源。全局事务要求在其中的所有参与的事务要么都提交,要么都回滚,这对于事务原有的 ACID 要求又有了提高。另外,在使用分布式事务时,InnoDB 存储引擎的事务隔离级别必须设置为 SERIALIZABLE。
8755
88-
### 实际情况演示
56+
## 实际情况演示
8957

90-
在下面我会使用 2 个命令行 mysql ,模拟多线程(多事务)对同一份数据的脏读问题。
58+
在下面我会使用 2 个命令行 MySQL ,模拟多线程(多事务)对同一份数据的脏读问题。
9159

9260
MySQL 命令行的默认配置中事务都是自动提交的,即执行 SQL 语句后就会马上执行 COMMIT 操作。如果要显式地开启一个事务需要使用命令:`START TRANSACTION`
9361

@@ -103,47 +71,45 @@ SET [SESSION|GLOBAL] TRANSACTION ISOLATION LEVEL [READ UNCOMMITTED|READ COMMITTE
10371
- `COMMIT`:提交事务,使得对数据库做的所有修改成为永久性。
10472
- `ROLLBACK`:回滚会结束用户的事务,并撤销正在进行的所有未提交的修改。
10573

106-
#### 脏读(读未提交)
74+
### 脏读(读未提交)
10775

108-
![](<https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-31-1脏读(读未提交)实例.jpg>)
76+
![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-31-1脏读(读未提交)实例.jpg)
10977

110-
#### 避免脏读(读已提交)
78+
### 避免脏读(读已提交)
11179

11280
![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-31-2读已提交实例.jpg)
11381

114-
#### 不可重复读
82+
### 不可重复读
11583

11684
还是刚才上面的读已提交的图,虽然避免了读未提交,但是却出现了,一个事务还没有结束,就发生了 不可重复读问题。
11785

11886
![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-32-1不可重复读实例.jpg)
11987

120-
#### 可重复读
88+
### 可重复读
12189

12290
![](https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-33-2可重复读.jpg)
12391

124-
#### 幻读
92+
### 幻读
12593

126-
##### 演示幻读出现的情况
94+
#### 演示幻读出现的情况
12795

12896
![](https://guide-blog-images.oss-cn-shenzhen.aliyuncs.com/github/javaguide/database/phantom_read.png)
12997

130-
sql 脚本 1 在第一次查询工资为 500 的记录时只有一条,sql 脚本 2 插入了一条工资为 500 的记录,提交之后;sql 脚本 1 在同一个事务中再次使用当前读查询发现出现了两条工资为 500 的记录这种就是幻读。
131-
132-
幻读和不可重复读有些相似之处 ,但是不可重复读的重点是修改,幻读的重点在于新增或者删除。
98+
SQL 脚本 1 在第一次查询工资为 500 的记录时只有一条,SQL 脚本 2 插入了一条工资为 500 的记录,提交之后;SQL 脚本 1 在同一个事务中再次使用当前读查询发现出现了两条工资为 500 的记录这种就是幻读。
13399

134-
##### 解决幻读的方法
100+
#### 解决幻读的方法
135101

136102
解决幻读的方式有很多,但是它们的核心思想就是一个事务在操作某张表数据的时候,另外一个事务不允许新增或者删除这张表中的数据了。解决幻读的方式主要有以下几种:
137103

138104
1. 将事务隔离级别调整为 `SERIALIZABLE`
139105
2. 在可重复读的事务级别下,给事务操作的这张表添加表锁
140-
3. 在可重复读的事务级别下,给事务操作的这张表添加 `Next-Key Locks`
106+
3. 在可重复读的事务级别下,给事务操作的这张表添加 `Next-key Lock`
141107

142-
> 说明:`Next-Key Locks` 相当于 行锁 + 间隙锁
108+
> 说明:`Next-key Lock` 相当于行锁 + 间隙锁
143109
144110
### 参考
145111

146112
- 《MySQL 技术内幕:InnoDB 存储引擎》
147-
- <https://dev.mysql.com/doc/refman/5.7/en/>
148-
- [Mysql 锁:灵魂七拷问](https://tech.youzan.com/seven-questions-about-the-lock-of-mysql/)
113+
- <https://dev.MySQL.com/doc/refman/5.7/en/>
114+
- [Mysql 锁:灵魂七拷问](https://tech.youzan.com/seven-questions-about-the-lock-of-MySQL/)
149115
- [Innodb 中的事务隔离级别和锁的关系](https://tech.meituan.com/2014/08/20/innodb-lock.html)

0 commit comments

Comments
 (0)