分布式事务开局第一篇，从数据库事务隔离级别说起

春节临近，松哥也有点无心撸码。不过很多时候，很多事情，我们不能由着自己的性子，还是要控制一下自己，这不，松哥最近又打算开一个坑，和大家聊一聊分布式事务，因为我们做微服务，分布式事务肯定是跳不过去的坎。这个坑有点大，年前先更几篇。

说到分布式事务，很多小伙伴可能会想到 TCC ，但是实际上，分布式事务本身是一个比较大的话题，一步一步从头开始讲，会涉及到数据库事务、Jdbc 事务、Spring 事务、消息驱动模式处理事务、事件溯源模式等等很多种。

松哥想写一个类似于 SpringBoot 那样成体系的教程，来和大家仔细的捋一捋分布式事务，今天我们就先从数据库事务开始。（另外，大家在公众号后台分别回复 spring、springmvc、mybatis、springboot、maven 可以下载松哥手撸的干货教程。）

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 向读者验证上面的理论。

2.1 查看隔离级别

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

SELECT @@GLOBAL.tx_isolation, @@tx_isolation;

查询结果如图：

可以看到，默认的隔离级别为 REPEATABLE-READ，通过如下命令可以修改隔离级别（建议开发者在修改时修改当前 session 隔离级别即可）：

SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

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

注意，如果只是修改了当前 session 的隔离级别，则换一个 session 之后，隔离级别又会恢复到默认的隔离级别

2.2 READ UNCOMMITTED

READ UNCOMMITTED 是最低隔离级别，这种隔离级别中存在脏读、不可重复读以及幻象读问题，下面分别予以介绍。

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

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

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

2.2.1 脏读

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

1.首先打开两个SQL操作窗口，假设分别为 A 和 B，在 A 窗口中输入如下几条 SQL （输入完成后不用执行）：

START TRANSACTION;
UPDATE user set account=account+100 where username='zhangsan';
UPDATE user set account=account-100 where username='lisi';
COMMIT;

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

SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

3.接下来在 B 窗口中输入如下 SQL，输入完成后，首先执行第一行开启事务（注意只需要执行一行即可）：

START TRANSACTION;
SELECT * from user;
COMMIT;

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

5.进入到 B 窗口，执行 B 窗口的第二条查询 SQL（SELECT * from user;），结果如下：

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

这就是脏读问题。

2.2.2 不可重复读

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

1.首先打开两个查询窗口 A 和 B ，并且将 B 的数据库事务隔离级别设置为 READ UNCOMMITTED。具体 SQL 参考上文，这里不赘述。

2.在 B 窗口中输入如下 SQL，然后只执行前两条 SQL 开启事务并查询 zhangsan 的账户：

START TRANSACTION;
SELECT * from user where username='zhangsan';
COMMIT;

前两条 SQL 执行结果如下：

3.在 A 窗口中执行如下 SQL，给 zhangsan 这个账户添加 100 块钱，如下：

START TRANSACTION;
UPDATE user set account=account+100 where username='zhangsan';
COMMIT;

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

zhangsan 的账户已经发生了变化，即前后两次查看 zhangsan 账户，结果不一致。不可重复读强调的是其他事务对数据进行了修改或者删除，这一点注意和幻象读进行区分。

2.2.3 幻象读

幻象读和不可重复读比较像，强调了不同方面。幻象读是指当一个事务根据条件查询数据时，另外一个事务插入一条新记录，这条新数据恰好可以满足第一个事务的查询条件，然后此时再次执行第一个事务，就会看到第二个事务插入的新记录，这个新记录就称为“幻象”。

例如，执行如下SQL查询当前表的用户数量：

START TRANSACTION;
SELECT COUNT(*) FROM user;
COMMIT;

获取到的结果为 2，表示有两个用户。

此时在一个新的事务中，向表中添加新记录，然后再次执行这里第二行统计 SQL，就会查到三个用户，这个比较简单，本文就不演示了。

2.3 READ COMMITTED

和 READ UNCOMMITTED 相比，READ COMMITTED 主要解决了脏读的问题，对于不可重复读和幻象读则未解决。操作案例与上文一致，这里不再赘述。

2.4 REPEATABLE READ

和 READ COMMITTED 相比，REPEATABLE READ 进一步解决了不可重复读的问题，但是幻象读则未解决。操作案例与上文一致，这里不再赘述。

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

2.5 SERIALIZABLE

SERIALIZABLE 提供了事务之间最大限度的隔离，在这种隔离级别中，事务一个接一个顺序的执行，不会发生脏读、可不重复读以及幻象读问题。最安全。相关操作案例与上文一致，这里不再赘述。

3. 总结

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

性能关系如图：

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

松哥明天也要回家啦，祝小伙伴们新年快乐哦～