从 《业务的基本概念》 一文中咱们了解了什么是业务以及并发业务带来的问题，数据库经过不同的业务阻隔等级来处理这些问题，本文首要具体解说 MySQL 的业务阻隔等级。
MySQL 业务阻隔等级
SQL:1992 规范界说了四种业务阻隔等级，分别是读未提交（Read Uncommitted）、读已提交（Read Committed）、可重复读（Repeatable Read）和串行化（Serializable）。不同的阻隔等级下会产生脏读、幻读、不行重复读等相关问题，因此在挑选阻隔等级的时候要根据运用场景来决定，运用适宜的阻隔等级。
MySQL 中的 InnoDB 存储引擎供给了 SQL 规范所描绘的四种业务阻隔等级，默许业务阻隔等级是可重复读（Repeatable Read）。
各种阻隔等级和数据库业务并发时存在的问题对应情况如下：
| 阻隔等级 | 脏读 | 不行重复读 | 幻读 |
|---|---|---|---|
| Read Uncommitted | √ | √ | √ |
| Read Committed | √ | √ | |
| Repeatable Read | √ | ||
| Serializable |
- 读未提交（Read Uncommitted）答应脏读，便是在该阻隔等级下，或许读到其他会话未提交业务修改的数据，存在脏读、不行重读读、幻读的问题。
- 读已提交（Read Committed）只能查询到已提交的数据。这是 Oracle 数据库默许的业务阻隔等级。存在不行重读读、幻读的问题。
- 可重复读（Repeatable Read）便是在一个业务里相同条件下，无论何时查到的数据都和第一次查到的数据共同。这是 MySQL 数据库 InnoDB 引擎默许的业务阻隔等级。在范围查询时存在幻读的问题。
- 串行化（Serializable）是最高的业务阻隔等级，它严厉服从 ACID 特性的阻隔等级。一切的业务顺次逐一履行，业务之间互不干扰，该等级能够避免脏读、不行重复读以及幻读。但每个业务读数据时都需要获取表级的共享锁，导致读和写都会堵塞，功能极低。
由于阻隔等级越低，业务请求的锁越少，所以大部分数据库系统的阻隔等级都是读已提交（Read Committed），但是 MySQL 中 InnoDB 存储引擎默许运用**可重复读（Repeatable Read）**并不会有任何功能丢失。
怎么设置 MySQL 业务阻隔等级
1、能够在 MySQL 的配置文件 my.cnf、my.ini 中设置：
transaction-isolation=READ-UNCOMMITTED # 读未提交
或
transaction-isolation=READ-COMMITTED # 读已提交
或
transaction-isolation=REPEATABLE-READ # 可重复读
或
transaction-isolation=SERIALIZABLE # 串行化
2、能够在衔接 MySQL 服务端指令行用 –transaction-isolation；
3、能够运用 SET TRANSACTION 指令改动单个或许一切新衔接的业务阻隔等级：
SET [SESSION | GLOBAL] TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE}
# 如
set session transaction isolation level read committed;
- 不带 GLOBAL 或 SESSION 关键字表明设置下一个业务的阻隔等级；
- 运用 GLOBAL 关键字表明对全局设置业务阻隔等级，设置后的业务阻隔等级对一切新的数据库衔接收效；
- 运用 SESSION 关键字表明对当时的数据库衔接设置业务阻隔等级，只对当时衔接收效；
- 任何客户端都能够自由改动当时会话的业务阻隔等级，能够在业务中间改动，也能够改动下一个业务的阻隔等级。
怎么检查 MySQL 业务阻隔等级
# MySQL 8.0 之前
SELECT @@global.tx_isolation;
SELECT @@session.tx_isolation;
SELECT @@tx_isolation;
# MySQL8.0
SELECT @@global.transaction_isolation;
SELECT @@session.transaction_isolation;
SELECT @@transaction_isolation;
在 MySQL 8.0 之前的版别中
tx_isolation是作为transaction_isolation的别名被运用的，新版别现已弃用了，需要把tx_isolation换成transaction_isolation，不然会呈现1193 - Unknown system variable 'xx_isolation'错误。
MySQL 业务阻隔等级实践
在 MySQL 中创建一个 test 数据库，在 test 数据库中创建一个 account 账户数据表作为测试运用：
CREATE TABLE `account` (
`id` int NOT NULL AUTO_INCREMENT COMMENT '账户id',
`name` varchar(32) COLLATE utf8_bin DEFAULT NULL COMMENT '名字',
`balance` int DEFAULT '0' COMMENT '余额',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
在 account 表中刺进测试数据：
INSERT INTO test.account (name, balance)
VALUES
('熊大',300),
('熊二',400),
('光头强',500)
此刻熊大、熊二、光头强的账户余额分别为 300 元、400 元、500元。
读未提交（read uncommitted）
敞开两个终端分别为 A 和 B，登录 MySQL，并将当时终端的业务阻隔等级设置为读未提交 read uncommitted：
mysql> set session transaction isolation level read uncommitted;
Query OK, 0 rows affected (0.01 sec)
mysql> select @@session.transaction_isolation;
+---------------------------------+
| @@session.transaction_isolation |
+---------------------------------+
| READ-UNCOMMITTED |
+---------------------------------+
1 row in set (0.00 sec)
在终端 A 敞开业务并查询熊二的账户余额：
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from account where id = 2;
+----+--------+---------+
| id | name | balance |
+----+--------+---------+
| 2 | 熊二 | 400 |
+----+--------+---------+
1 row in set (0.00 sec)
此刻熊二的账户余额为 400 元。
在终端 B 敞开业务并向熊二的账户余额增加 50 元：
mysql> begin;
Query OK, 0 rows affected (0.01 sec)
mysql> update account set balance = balance + 50 where id = 2;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
此刻在终端 A 查询熊二的账户余额：
mysql> select * from account where id = 2;
+----+--------+---------+
| id | name | balance |
+----+--------+---------+
| 2 | 熊二 | 450 |
+----+--------+---------+
1 row in set (0.00 sec)
能够发现，终端 A 业务读取到了终端 B 业务还未提交的数据，这个问题便是脏读。终端 A 业务两次读取的数据不共同，这个问题便是不行重复读。
假如此刻终端 B 业务回滚，而终端 A 业务对熊二账户余额进行减 50 元，成果会是什么样？
终端 B 业务回滚并查询到余额为 400 元：
mysql> rollback;
Query OK, 0 rows affected (0.01 sec)
mysql> select * from account where id = 2;
+----+--------+---------+
| id | name | balance |
+----+--------+---------+
| 2 | 熊二 | 400 |
+----+--------+---------+
1 row in set (0.00 sec)
终端 A 业务修改并提交，查询到余额为 350 元：
mysql> update account set balance = balance - 50 where id = 2;
Query OK, 1 row affected (0.01 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> commit;
Query OK, 0 rows affected (0.02 sec)
mysql> select * from account where id = 2;
+----+--------+---------+
| id | name | balance |
+----+--------+---------+
| 2 | 熊二 | 350 |
+----+--------+---------+
1 row in set (0.00 sec)
以下是整个事情的时间线：
| 时间线 | 终端 A 业务 | 终端 B 业务 |
|---|---|---|
| ① | begin; | |
| ② | select * from account where id = 2; 读到熊二的账户余额为 400 元 |
|
| ③ | begin; | |
| ④ | update account set balance = balance + 50 where id = 2; | |
| ⑤ | select * from account where id = 2; 读到熊二的账户余额为 450 元 （脏读+不行重复读） |
|
| ⑥ | rollback; | |
| ⑦ | select * from account where id = 2; 读到熊二的账户余额为 400 元 |
|
| ⑧ | update account set balance = balance – 50 where id = 2; | |
| ⑨ | commit; | |
| ⑩ | select * from account where id = 2; 读到熊二的账户余额为 350 元 (不受影响) |
那么脏读有什么影响呢？
在运用程序中，假如一个业务读到脏数据，并作为其他业务逻辑的依据或许进行其他处理，但其并不知道其他会话回滚了业务，那么后续的整个逻辑处理都或许存在问题。
读已提交（read committed）
敞开两个终端分别为 A 和 B，登录 MySQL，并将当时终端的业务阻隔等级设置为读已提交 read committed：
mysql> set session transaction isolation level read committed;
Query OK, 0 rows affected (0.00 sec)
mysql> select @@session.transaction_isolation;
+---------------------------------+
| @@session.transaction_isolation |
+---------------------------------+
| READ-COMMITTED |
+---------------------------------+
1 row in set (0.00 sec)
在终端 A 敞开业务并查询光头强的账户余额：
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from account where id = 3;
+----+-----------+---------+
| id | name | balance |
+----+-----------+---------+
| 3 | 光头强 | 500 |
+----+-----------+---------+
1 row in set (0.00 sec)
此刻光头强的账户余额为 500 元。
在终端 B 敞开业务，为光头强的账户余额增加 100 元：
mysql> begin;
Query OK, 0 rows affected (0.01 sec)
mysql> update account set balance = balance + 100 where id = 3;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
此刻终端 A 业务再次查询光头强的账户余额，查询到余额仍为 500 元，阐明不存在脏读问题：
mysql> select * from account where id = 3;
+----+-----------+---------+
| id | name | balance |
+----+-----------+---------+
| 3 | 光头强 | 500 |
+----+-----------+---------+
1 row in set (0.00 sec)
在终端 B 提交业务：
mysql> commit;
Query OK, 0 rows affected (0.01 sec)
此刻终端 A 业务再次查询光头强的账户余额，查询到余额为 600 元：
mysql> select * from account where id = 3;
+----+-----------+---------+
| id | name | balance |
+----+-----------+---------+
| 3 | 光头强 | 600 |
+----+-----------+---------+
1 row in set (0.00 sec)
能够发现终端 A 业务相同条件下两次查询的成果不共同，这个问题便是不行重读读。
以下是整个事情的时间线：
| 时间线 | 终端 A 业务 | 终端 B 业务 |
|---|---|---|
| ① | begin; | |
| ② | select * from account where id = 3; 读到光头强的账户余额为 500 元 |
|
| ③ | begin; | |
| ④ | update account set balance = balance + 100 where id = 3; | |
| ⑤ | select * from account where id = 3; 读到光头强的账户余额为 500 元 （不存在脏读） |
|
| ⑥ | commit; | |
| ⑦ | select * from account where id = 3; 读到光头强的账户余额为 600 元 （不行重复读） |
|
| ⑧ | commit; |
可重复读（repeatable read）
敞开两个终端分别为 A 和 B，登录 MySQL，并将当时终端的业务阻隔等级设置为可重复读 repeatable read：
mysql> set session transaction isolation level repeatable read;
Query OK, 0 rows affected (0.00 sec)
mysql> select @@session.transaction_isolation;
+---------------------------------+
| @@session.transaction_isolation |
+---------------------------------+
| REPEATABLE-READ |
+---------------------------------+
1 row in set (0.00 sec)
mysql> select * from account;
+----+-----------+---------+
| id | name | balance |
+----+-----------+---------+
| 1 | 熊大 | 300 |
| 2 | 熊二 | 350 |
| 3 | 光头强 | 600 |
+----+-----------+---------+
3 rows in set (0.00 sec)
此刻查询熊大、熊二、光头强的账户余额分别为 300 元、350 元、600 元。
在终端 A 敞开业务并查询光头强的账户余额：
mysql> begin;
Query OK, 0 rows affected (0.01 sec)
mysql> select * from account where id = 3;
+----+-----------+---------+
| id | name | balance |
+----+-----------+---------+
| 3 | 光头强 | 600 |
+----+-----------+---------+
1 row in set (0.00 sec)
此刻光头强的账户余额为 600 元。
在终端 B 敞开业务，为光头强的账户余额增加 100 元：
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> update account set balance = balance + 100 where id = 3;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
此刻终端 A 业务再次查询光头强的账户余额，查询到余额仍为 600 元，阐明不存在脏读问题：
mysql> select * from account where id = 3;
+----+-----------+---------+
| id | name | balance |
+----+-----------+---------+
| 3 | 光头强 | 600 |
+----+-----------+---------+
1 row in set (0.00 sec)
在终端 B 提交业务：
mysql> commit;
Query OK, 0 rows affected (0.01 sec)
此刻终端 A 业务再次查询光头强的账户余额，查询到余额仍为 600 元，阐明不存在不行重复读问题：：
mysql> select * from account where id = 3;
+----+-----------+---------+
| id | name | balance |
+----+-----------+---------+
| 3 | 光头强 | 600 |
+----+-----------+---------+
1 row in set (0.00 sec)
以下是整个事情的时间线：
| 时间线 | 终端 A 业务 | 终端 B 业务 |
|---|---|---|
| ① | begin; | |
| ② | select * from account where id = 3; 读到光头强的账户余额为 600 元 |
|
| ③ | begin; | |
| ④ | update account set balance = balance + 100 where id = 3; | |
| ⑤ | select * from account where id = 3; 读到光头强的账户余额为 600 元 （不存在脏读） |
|
| ⑥ | commit; | |
| ⑦ | select * from account where id = 3; 读到光头强的账户余额为 600 元 （不存在不行重复读） |
|
| ⑧ | commit; |
**但在可重复读的业务阻隔等级下，仍然存在幻读问题。**下面咱们来复现一下。
在终端 A 敞开业务并查询 id 大于 2 的账户信息：
mysql> begin;
Query OK, 0 rows affected (0.01 sec)
mysql> select * from account where id > 2;
+----+-----------+---------+
| id | name | balance |
+----+-----------+---------+
| 3 | 光头强 | 700 |
+----+-----------+---------+
1 row in set (0.00 sec)
能够看到查询得到的成果是 1 条数据。
在终端 B 敞开业务，刺进一条数据并提交：
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> insert into account (name,balance) values('吉吉国王',400);
Query OK, 1 row affected (0.00 sec)
mysql> commit;
Query OK, 0 rows affected (0.01 sec)
此刻终端 A 再次查询 id 大于 2 的账户信息：
mysql> select * from account where id > 2;
+----+-----------+---------+
| id | name | balance |
+----+-----------+---------+
| 3 | 光头强 | 700 |
+----+-----------+---------+
1 row in set (0.00 sec)
得到的成果仍然是相同的 1 条数据。为什么？说好的幻读呢？其实这是 MySQL 为了提高功能，运用了基于达观锁的 MVCC（多版别并发控制）机制来避免了幻读问题，但幻读问题仍然存在。
假如终端 A 业务履行把 id 大于 2 的账户余额都修改为 800：
mysql> update account set balance = 800 where id > 2;
Query OK, 1 row affected (0.00 sec)
Rows matched: 2 Changed: 1 Warnings: 0
mysql> select * from account where id > 2;
+----+--------------+---------+
| id | name | balance |
+----+--------------+---------+
| 3 | 光头强 | 800 |
| 4 | 吉吉国王 | 800 |
+----+--------------+---------+
2 rows in set (0.00 sec)
此刻能够看到查询得到的成果是 2 条数据。
以下是整个事情的时间线：
| 时间线 | 终端 A 业务 | 终端 B 业务 |
|---|---|---|
| ① | begin; | |
| ② | select * from account where id > 2; 读到账户信息数据是 1 条 |
|
| ③ | begin; | |
| ④ | insert into account (name,balance) values(‘吉吉国王’,400); | |
| ⑤ | commit; | |
| ⑥ | select * from account where id > 2; 读到账户信息数据是 1 条 |
|
| ⑦ | update account set balance = 800 where id > 2; | |
| ⑧ | select * from account where id > 2; 读到账户信息数据是 2 条 （存在幻读） |
|
| ⑨ | commit; |
幻读无法经过行级锁来处理，需要运用串行化的业务阻隔等级，但这种业务阻隔等级会极大的降低数据库的并发能力。
串行化（serializable）
敞开两个终端分别为 A 和 B，登录 MySQL，并将当时终端的业务阻隔等级设置为串行化 serializable：
mysql> set session transaction isolation level serializable;
Query OK, 0 rows affected (0.01 sec)
mysql> select @@session.transaction_isolation;
+---------------------------------+
| @@session.transaction_isolation |
+---------------------------------+
| SERIALIZABLE |
+---------------------------------+
1 row in set (0.00 sec)
在终端 A 敞开业务并查询 id 大于 2 的账户信息：
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from account where id > 2;
+----+--------------+---------+
| id | name | balance |
+----+--------------+---------+
| 3 | 光头强 | 800 |
| 4 | 吉吉国王 | 800 |
+----+--------------+---------+
2 rows in set (0.00 sec)
能够看到查询得到的成果是 2 条数据。
在终端 B 敞开业务，刺进一条数据：
mysql> begin;
Query OK, 0 rows affected (0.01 sec)
mysql> insert into account (name,balance) values('蹦蹦',600);
1205 - Lock wait timeout exceeded; try restarting transaction
能够看到，在终端 B 业务履行新增操作时，会产生堵塞，锁超时后会抛出 1205 - Lock wait timeout exceeded; try restarting transaction 错误，避免了幻读。能够经过 select * from performance_schema.data_locks; 检查业务的锁信息，从 supremum pseudo-record 获知，经过增加空隙锁处理幻读问题。此处本文不具体展开，后续独自解说。
supremum pseudo-record
相当于比索引中一切值都大，但却不存在索引中，相当于最终一行之后的空隙锁。
总结
本节首要介绍了 MySQL 的业务阻隔等级，经过实战演示解说了不同阻隔等级处理的问题以及存在的问题，从中咱们能够开始了解 MySQL 业务的阻隔机制是经过锁机制和 MVCC (多版别并发控制) 实现的。
下一篇文章咱们首要介绍 MySQL 的锁机制，经过实践学习不同业务阻隔等级下的加锁情况。
参阅
业务阻隔等级：dev.mysql.com/doc/refman/…
