Mysql事务隔离级别_数据库默认的事务隔离级别

大家好，又见面了，我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。

Jetbrains全系列IDE稳定放心使用

前言

提到事务，你肯定不会陌生，最经典的例子就是转账，甲转账给乙100块，当乙的账户中到账100块的时候，甲的账户就应该减去100块，事务可以有效的做到这一点。

在MySQL中，事务支持实在引擎层实现的，MySQL是一个支持多引擎的系统，但并不是所有引擎都支持事务。比如MySQL原生的 MyISAM 引擎就不支持事务，这也是 MyISAM 被取代的原因之一。

隔离性

事务的四大特性ACID（Atomicity原子性、Consistency一致性、Isolation隔离性、Durability持久性），今天就来讲讲其中的隔离性。当数据库上有多个事务同时执行的时候，就可能出现脏读（dirty read）、不可重复读（non-repeatable read）、幻读（phantom read）的问题，为了解决这些问题，就有了事务隔离级别这个概念。

首先你要知道，隔离得越结实，效率就会越低。因此需要我们考虑到这两点，不能只顾一边。SQL的标准事务隔离级别包括：

• 读未提交（read uncommitted）：一个事务还没有提交时，它做的变更就能被别的事务看到。
• 读提交（read committed）：一个事物提交之后，它做的变更才会被其他事务看到。
• 可重复读（repeatable read）：一个事物执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的。未提交变更对其他事务也是不可见的。
• 串行化（serializable）：对于同一行记录，写会加“写锁”，读会加“读锁”，当出现锁冲突时，后访问的事务需要等前一个事务执行完成，才能继续执行。

其中，“读提交”和“可重复读”比较难理解，这里用一个例子说明一下。

假设数据表中 T 中只有一列，其中一行的值为 1，下面是按照时间顺序执行两个事务的行为。

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

在不同的隔离级别下，事务A查到的结果是不一样的：

• 若隔离级别是“读未提交”，则 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语句开始执行的时候创建的。这里需要注意的是，“读未提交”隔离界别下直接返回记录上的最新值，没有视图概念；而“串行化”隔离级别下直接用加锁的方式来避免并行访问。

我们可以看到在不同的隔离级别下，数据库行为是有所不同的。Oracle 数据库的默认隔离级别其实是“读提交”，因此对于一些从 Oracle 迁移到 MySQL 的应用，为保证数据库隔离级别的一致，你一定要记得将 MySQL 的隔离级别设置为“读提交”。配置的方式是：将启动参数 transaction-isolation 的值设置成 READ-COMMITTED，你可以用 show variables 来查看当前的值。

每个事务隔离级别都有存在的意义，都有自己的场景，下面来一个“可重复读”的场景：

假设你在管理一个个人银行账户表，一个表存了每个月月底的余额，一个表存了账单明细，这时候你要做数据校对，也就是判断上个月的余额和当前余额的差额，是否与本月的账单明细一致。你一定希望在校对过程中，即使有用户发生了一笔新的交易，也不影响你的校对结果。这时候使用“可重复读”隔离级别就很方便，事务启动时的视图可以认为是静态的，不受其他事务更新的影响。

事务隔离的实现

理解了事务隔离级别，我们再来看看事务隔离具体是怎么实现的，这里我们展开说明“可重复读”。在MySQL中，实际上每条记录在更新的时候都会同时记录一条回滚操作，记录上的最新值，通过回滚操作，都可以得到前一个状态的值。

假设一个值从 1 被按顺序改成了 2、3、4，在回滚日志里面就会有类似下面的记录。

当前值是 4，但是在查询这条记录的时候，不同时刻启动的事务会有不同的 read-view。如图中看到的，在试图 A、B、C里面，这一个记录的值分别是 1、2、4，同一条记录在系统中可以存在多个版本，就是数据库的多版本并发控制（MVCC）。对于 read-view A，要得到1，就必须将当前值依次执行图中所有的回滚操作得到。

同时你会发现，即使现在有另外一个事务正在将 4 改成 5，这个事务跟 read-view A、B、C对应的事务是不会冲突的。那么回滚日志什么时候删除呢？答案是，再不需要的时候才删除，也就是说，系统会判断，当没有事务在需要用到这些回滚日志时，回滚日志才会被删除。什么时候才是不需要了呢？就是当系统里没有比这个回滚日志更早的 read-view 的时候。

基于上面的说明，我们来讨论一下为什么建议你尽量不要使用长事务。

长事务意味着系统里面会存在很老的事务视图，由于这些事务随时可能访问数据库里面的任何数据，所以这个事务提交之前，数据库里面它可能用到的回滚记录都必须保留，这就会导致大量占用存储空间。

在MySQL 5.5 及以前的版本，回滚日志是跟数据字典一起放在 ibdata 文件里的，即使长事务最终提交，回滚段被清理，文件也不会变小，作者见过数据只有20GB，而回滚段有200GB 的库，最终只好为了清理回滚段，重新建个库。

除了对回滚段的影响，长事务还占用锁资源，也可能拖垮整个库，这个我们会在后面讲锁的时候展开。

事务的启动方式

如前面所述，长事务有这些潜在风险，我当然建议读者尽量避免。其实很多业务开发的同学并不是有意使用长事务，通常是由于误用所致。MySQL 的事务启动方式有以下几种：

1. 显式启动事务语句，begin 或者 start transaction。配套的提交语句是 commit，回滚语句是 rollback。
2. set autocommit = 0，这个命令会将这个线程的自动提交关掉。意味着如果你只执行一个 select 语句，这个事务就启动了，而且并不会自动提交。这个事务持续存在直到你主动 commit 或者 rollback 语句，或者断开连接。

有些客户端连接框架会默认连接成功后先执行一个 set autocommit = 0 的命令。这就导致接下来的查询都在事务中，如果是长连接，就导致了意外的长事务，因此，建议读者总是使用 set autocommit = 1，通过显式语句的方式来启动事务。

但是有的开发同学会纠结“多一次交互”的问题。对于一个需要频繁使用事务的业务。第二种方式每个事务在开始时都不需要主动执行一次“begin”，减少了语句的交互次数。如果读者也有这个顾虑，建议使用 commit work and chain 语法。

在 autocommit 为 1 的情况下，用 begin 显式启动的事务，如果执行 commit 则提交事务。如果执行 commit work and chain，则是提交事务并自动启动下一个事务，这样也省去了再次执行 begin 语句的开销。同时带来的好处是从程序开发的角度明确地知道每个语句是否处于事务中。

你可以在 information_schema 库的 innodb_trx 这个表中查询长事务，比如下面这个语句，用于查找持续时间超过 60s 的事务。

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

小结

这篇文章主要介绍了MySQL的事务隔离几倍的现象和实现，根据实现原理分析了长事务存在的风险，以及如何用正确的方式避免长事务。

篇尾继续留个问题：现在知道了系统里面如何避免长事务，如果你是业务开发负责人同时也是数据库负责人，你会有什么方案来避免出现或者处理这种情况呢？问题答案下篇揭晓。

上一篇问题答案

上一篇的问题是：

前面说到定期全量备份的周期，“取决于系统重要性，有的是一天一备，有的是一周一备”，那么在什么场景下，一天一备会比一周一备更有优势呢？或者说，它影响了这个数据库系统的哪个指标？

优势是“最长恢复时间”更短。

在一天一备的模式里，最坏的情况下需要应用一天的 binlog。比如，每天 0 点做一次全量备份，而要恢复出一个到昨天晚上 23 点的备份。在一周一备的模式里，最坏的情况就是需要应用一周的 binlog 了。

数据库系统中对应的指标就是恢复目标时间（RTO）。当然，一天一备的成本要远高于一周一备，毕竟是全量备份。所以全量备份的周期还是需要根据业务重要性来评估。