关于java:四个案例看懂-MySQL-事务隔离级别

@[toc]
很多小伙伴对 MySQL 的隔离级别始终心存疑惑，其实这个问题一点都不难，要害看怎么讲！单纯的看实践，相对让你昏头昏脑，然而，如果咱们通过几个理论的 SQL 来演示一些，大家就会发现这玩意原来这么简略！

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

1. 实践

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

• 序列化（SERIALIZABLE）
• 可反复读（REPEATABLE READ）
• 提交读（READ COMMITTED）
• 未提交读（READ UNCOMMITTED）

四种不同的隔离级别含意别离如下：

1. SERIALIZABLE

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

2. REPEATABLE READ

在可反复读在这一隔离级别上，事务不会被看成是一个序列。不过，以后正在执行事务的变动依然不能被内部看到，也就是说，如果用户在另外一个事务中执行同条 SELECT 语句数次，后果总是雷同的。（因为正在执行的事务所产生的数据变动不能被内部看到）。

3. READ COMMITTED

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

4. 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 脏读

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

1. 首先关上两个 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;

2. 在 B 窗口执行如下 SQL，批改默认的事务隔离级别为 READ UNCOMMITTED，如下：

SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

3. 接下来在 B 窗口中输出如下 SQL，输出实现后，首先执行第一行开启事务（留神只须要执行一行即可）：

START TRANSACTION;
SELECT * from account;
COMMIT;

4. 接下来执行 A 窗口中的前两条 SQL，即开启事务，给 javaboy 这个账户增加 100 元。
5. 进入到 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 执行后果如下：

3. 在 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;

咱们执行步骤如下：

1. 首先执行 B 窗口的前两行，开启一个事务，同时查询数据库中的数据，此时查问到的数据只有 javaboy 和 itboyhub。
2. 执行 A 窗口的前两行，向数据库中增加一个名为 zhangsan 的用户，留神不必提交事务。
3. 执行 B 窗口的第二行，因为脏读问题，此时能够查问到 zhangsan 这个用户。
4. 执行 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;

测试形式如下：

1. 首先执行 B 窗口的前两行 SQL，开启事务并查问数据，此时查到的只有 javaboy 和 itboyhub 两个用户。
2. 执行 A 窗口的前两行 SQL，插入一条记录，然而并不提交事务。
3. 执行 B 窗口的第二行 SQL，因为当初曾经没有了脏读问题，所以此时查不到 A 窗口中增加的数据。
4. 执行 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. 总结

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

性能关系如图：

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