3 - 事务隔离 - 为什么要避免长事务？

关键字

事务、隔离性

0.什么是事务

• 事务是一个非常重要的概念，在很多应用场景中，我们都要使用事务。抛去各种因素，简单来说，事务就是要保证在数据库中的一组操作，要么全部成功，要么全部失败。
• 事务有四大特性：原子性、一致性、隔离性、持久性。今天我们说一说其中的隔离性。
• 事务在引擎层实现，InnoDB引擎 就很好的支持了事务性。

1.隔离级别

SQL的标准事务隔离级别有四种;

1. 读未提交：一个事务还没提交时，它的变更就可以被其它事务看到。
2. 读提交：一个事务提交之后，它做的变更才可以被其它事务看到。
3. 可重复读：一个事务在执行的过程中，它看到的数据是一直不变的；同样，它所做的改变，在未提交之前，也不会被其它事务看到。
4. 串行化：对操作进行加锁操作，锁分为 “读锁” 和 “写锁” 。通过锁，将事务使用的资源串行化执行。

上面的四种隔离级别，隔离程度为递增趋势。

下面举个例子，首先我们使用如下语句插入数据：

mysql> create table T(c int) engine=InnoDB;
insert into T(c) values(1);

随后我们使用两个事务进行查询： 3-两个事务.png

我们看一看在不同隔离级别之下，事务A 会有怎样的返回结果，即 V1,V2,V3 分别为多少：

• 若隔离级别是“读未提交”， 则 V1 的值就是 2。这时候事务 B 虽然还没有提交，但是结果已经被 A 看到了。因此，V2、V3 也都是 2。
• 若隔离级别是“读提交”，则 V1 是 1，V2 的值是 2。事务 B 的更新在提交后才能被 A 看到。所以， V3 的值也是 2。
• 若隔离级别是“可重复读”，则 V1、V2 是 1，V3 是 2。之所以 V2 还是 1，遵循的就是这个要求：事务在执行期间看到的数据前后必须是一致的。
• 若隔离级别是“串行化”，则在事务 B 执行“将 1 改成 2”的时候，会被锁住。直到事务 A 提交后，事务 B 才可以继续执行。所以从 A 的角度看， V1、V2 值是 1，V3 的值是 2。

在实现上，数据库使用创建视图的方式为一个事务提供数据：
在实现上，数据库里面会创建一个视图，访问的时候以视图的逻辑结果为准。在“可重复读”隔离级别下，这个视图是在事务启动时创建的，整个事务存在期间都用这个视图。在“读提交”隔离级别下，这个视图是在每个 SQL 语句开始执行的时候创建的。这里需要注意的是，“读未提交”隔离级别下直接返回记录上的最新值，没有视图概念；而“串行化”隔离级别下直接用加锁的方式来避免并行访问。

• MySQL的默认隔离级别是 “REPEATABLE-READ” ，Oracle的默认级别是 “READ_COMMITTED”。
• 我们在启动时设置参数 transaction-isolation 的值，可以控制事务的隔离级别。

2.事务隔离的实现

之前我们说过了，事务隔离主要是使用视图实现。在这里，我们看看在读取事务和被读取事务之间发生了什么。
这里，我们以可重复读的实现。

在 MySQL 中，每条记录在更新的时候都会记录一条回滚操作，记录上的值，通过回滚，都可以得到前一个状态的值。

例如，下图将一个值从 1 依次改为 2、3、4，在回滚日志中会有如下记录： 3-回滚.png

这里解释一下：

• 绿色字代表从下一个状态回滚到这个状态需要做什么。也就是“回滚日志”。
• 四个状态为 1，2，3，4。
• 在 1 状态 下，事务A 请求了这个数据，基于可重复读的要求，这个状态将会被保持，也就是说，MySQL 需要保持从当前状态（值为 4）回滚到值为 1 的状态的能力。这就要求我们需要记录这个回滚日志。
• B 和 C 的视图请求同理。

你会疑问：这个日志什么时候删除呢？

• 当系统中没有比这个回滚日志状态更早的读视图请求的时候。也就是说，在它之前的所有事务请求都提交完成，这个日志就再不会被用到，故可以删掉这个日志。
• 你可以思考一下，如果一个请求事务很长会发生什么。
• 为了保持这个长事务，MySQL 会一直记录这条日志，从而导致大量的内存占用。
• 所以，请不要使用长事务。

3.事务的启动方式

• 默认情况下，参数 autocommit = 1 ，这个参数会自动将一条语句设置为一个事务提交。在这种情况下，你可以显示启动事务：使用 begin 或 strat transaction 启动事务，使用 commit 提交 或 rollback 回滚。
• 如果你 set autocommit = 0 ，线程会关掉自动提交，这时你不论做什么，都需要手动提交。（甚至是一个单纯的 select 语句）。
• 建议使用第一种方法。但是第一种方法在启动事务的时候都要使用 begin ，这比较麻烦，尤其是在两个事务中间还要添加 begin。
  对这种情况，你可以使用 commit work and chain 语法，这个语法可以提交当前事务，并自动启动下一个事务。
• 你可以使用 information_schema 库中的 innodb_trx 表查询长事务，例如下面的语句，查找了超过 60s 是事务：

select * from information_schema.innodb_trx where TIME_TO_SEC(timediff(now(),trx_started))>60

• 使用 SET MAX_EXECUTION_TIME 控制每个语句的最长执行时间。

小结

我们知道了事务的特性，并着重讨论了事务中的“隔离性”。事务有四种隔离级别，这种隔离是使用 回滚日志 + 视图 的方式实现的。
记住，少使用长事务。

思考题：
你现在知道了系统里面应该避免长事务，如果你是业务开发负责人同时也是数据库负责人，你会有什么方案来避免出现或者处理这种情况呢？

解答：
这个问题，我们可以从应用开发端和数据库端来看。

• 首先，从应用开发端来看：确认是否使用了 set autocommit=0。这个确认工作可以在测试环境中开展，把 MySQL 的 general_log 开起来，然后随便跑一个业务逻辑，通过 general_log 的日志来确认。一般框架如果会设置这个值，也就会提供参数来控制行为，你的目标就是把它改成 1。
• 确认是否有不必要的只读事务。有些框架会习惯不管什么语句先用 begin/commit 框起来。我见过有些是业务并没有这个需要，但是也把好几个 select 语句放到了事务中。这种只读事务可以去掉。
• 业务连接数据库的时候，根据业务本身的预估，通过 SET MAX_EXECUTION_TIME 命令，来控制每个语句执行的最长时间，避免单个语句意外执行太长时间。（为什么会意外？在后续的文章中会提到这类案例）

其次，从数据库端来看：

• 监控 information_schema.Innodb_trx 表，设置长事务阈值，超过就报警 / 或者 kill；
• Percona 的 pt-kill 这个工具不错，推荐使用；在业务功能测试阶段要求输出所有的 general_log，分析日志行为提前发现问题；
• 如果使用的是 MySQL 5.6 或者更新版本，把 innodb_undo_tablespaces 设置成 2（或更大的值）。如果真的出现大事务导致回滚段过大，这样设置后清理起来更方便。

---

以上就是关于事务隔离的全部内容，希望对你有所帮助。

注：本文章的主要内容来自我对极客时间app的《MySQL实战45讲》专栏的总结，我使用了大量的原文、代码和截图，如果想要了解具体内容，可以前往极客时间