MySQL的事务隔离级别介绍

共计 4177 个字符，预计需要花费 11 分钟才能阅读完成。

本篇内容介绍了“MySQL 的事务隔离级别介绍”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让丸趣 TV 小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

什么是事务？

数据库事务（简称：事务）是数据库管理系统执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成。—— 维基百科

事务的概念看上去不难，但是需要注意以下几个点：

1、首先，事务就是要保证一组数据库操作，要么全部成功，要么全部失败；

2、在 MySQL 中，事务支持是在引擎层实现的；

3、并不是所有引擎都支持事务，如 MyISAM 就不支持，InnoDB 就支持；

今天，我们的主角是隔离性，隔离性是指当多个用户并发操作数据库时，数据库为每一个用户开启不同的事务，这些事务之间相互不干扰，相互隔离。

为什么需要隔离性？

如果事务之间不是互相隔离的，可能将会出现以下问题。

1、脏读

脏读（dirty read），简单来说，就是一个事务在处理过程中读取了另外一个事务未提交的数据。

这种未提交的数据我们称之为脏数据。依据脏数据所做的操作肯能是不正确的。

还记得上节中我们提到的 dirty page 吗？这种临时处理的未提交的，都是「脏」的。

举例

但是，若该事务未提交成功，最终所有操作都会回滚，丸趣 TV 小编看到的一分钱也只是镜花水月。比如，你给丸趣 TV 小编赞赏 1 分钱，整个事务需要两个步骤：

①给丸趣 TV 小编账号加一分钱，这时丸趣 TV 小编看到了，觉得很欣慰；
②你的账号减一分钱；

2、不可重复读

不可重复读（non-repeatable read），是指一个事务范围内，多次查询某个数据，却得到不同的结果。

在第一个事务中的两次读取数据之间，由于第二个事务的修改，第一个事务两次读到的数据可能就是不一样的。

举例

接着上一个例子，假设你真给丸趣 TV 小编打赏了一分钱，丸趣 TV 小编乐得屁颠屁颠地去准备提现，一查，发现真多了一分钱。

在这同时，在我还没有提现成功之前，丸趣 TV 小编的老婆已经提前将这一分钱支走了，丸趣 TV 小编此时再次查账，发现一分钱也没了。

脏读和不可重复读有点懵逼？

二者的区别是，脏读是某一事务读取了另外一个事务未提交的数据，不可重复读是读取了其他事务提交的数据。

其实，有些情况下，不可重复读不是问题，比如，丸趣 TV 小编提现期间，一分钱被老婆支走了，这不是问题！

而脏读，是可以通过设置隔离级别避免的。

3、幻读

幻读（phantom read），是事务非独立执行时发生的一种现象。

例如事务 T1 对一个表中所有的行的某个数据项做了从“1”修改为“2”的操作，这时事务 T2 又对这个表中插入了一行数据项为“1”的数据，并且提交给数据库。

而操作事务 T1 的用户如果再查看刚刚修改的数据，会发现数据怎么还是 1？其实这行是从事务 T2 中添加的，就好像产生幻觉一样，这就是发生了幻读。

举例

其实上面的解释已经是一个例子了，但是还是要举个例子。

比如，丸趣 TV 小编准备提取你打赏的一分钱，提取完了，这时又有其他热心网友打赏了一分钱，丸趣 TV 小编一看，明明已经取出了，怎么又有一分钱！？

丸趣 TV 小编此时以为像做梦一样，我觉得也可以叫「梦读」，哈哈。

幻读和不可重复读都是读取了另一条已经提交的事务（这点就脏读不同），所不同的是不可重复读查询的都是同一个数据项，而幻读针对的是一批数据整体（比如数据的个数）。

事务的隔离级别

为了解决上面可能出现的问题，我们就需要设置隔离级别，也就是事务之间按照什么规则进行隔离，将事务隔离到什么程度。

首先，需要明白一点，隔离程度越强，事务的执行效率越低。

ANSI/ISO SQL 定义了 4 种标准隔离级别：

① Serializable（串行化）：花费最高代价但最可靠的事务隔离级别。

“写”会加“写锁”，“读”会加“读锁”。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。

事务 100% 隔离，可避免脏读、不可重复读、幻读的发生。

② Repeatable read（可重复读，默认级别）：多次读取同一范围的数据会返回第一次查询的快照，即使其他事务对该数据做了更新修改。事务在执行期间看到的数据前后必须是一致的。

但如果这个事务在读取某个范围内的记录时，其他事务又在该范围内插入了新的记录，当之前的事务再次读取该范围的记录时，会产生幻行，这就是幻读。

可避免脏读、不可重复读的发生。但是可能会出现幻读。

③ Read committed (读已提交)：保证一个事物提交后才能被另外一个事务读取。另外一个事务不能读取该事物未提交的数据。

可避免脏读的发生，但是可能会造成不可重复读。

大多数数据库的默认级别就是 Read committed，比如 Sql Server , Oracle。

④ Read uncommitted (读未提交)：最低的事务隔离级别，一个事务还没提交时，它做的变更就能被别的事务看到。

任何情况都无法保证。

隔离级别

下图中是一个很好的例子，分别解释了四种事务隔离级别下，事务 B 能够读取到的结果。

看着还是有点懵逼？那我们再举个例子。

A，B 两个事务，分别做了一些操作，操作过程中，在不同隔离级别下查看变量的值：

隔离级别是串行化，则在事务 B 执行「将 1 改成 2」的时候，会被锁住。直到事务 A 提交后，事务 B 才可以继续执行。

再次总结

读未提交：别人改数据的事务尚未提交，我在我的事务中也能读到。
读已提交：别人改数据的事务已经提交，我在我的事务中才能读到。
可重复读：别人改数据的事务已经提交，我在我的事务中也不去读。
串行：我的事务尚未提交，别人就别想改数据。

这 4 种隔离级别，并行性能依次降低，安全性依次提高。

总的来说，事务隔离级别越高，越能保证数据的完整性和一致性，但是付出的代价却是并发执行效率的低下。

隔离级别的实现

事务的机制是通过视图（read-view）来实现的并发版本控制（MVCC），不同的事务隔离级别创建读视图的时间点不同。

可重复读是每个事务重建读视图，整个事务存在期间都用这个视图。

读已提交是每条 SQL 创建读视图，在每个 SQL 语句开始执行的时候创建的。隔离作用域仅限该条 SQL 语句。

读未提交是不创建，直接返回记录上的最新值

串行化隔离级别下直接用加锁的方式来避免并行访问。

这里的视图可以理解为数据副本，每次创建视图时，将当前已持久化的数据创建副本，后续直接从副本读取，从而达到数据隔离效果。

隔离级别的实现

我们每一次的修改操作，并不是直接对行数据进行操作。

比如我们设置 id 为 3 的行的 A 属性为 10，并不是直接修改表中的数据，而是新加一行。

同时数据表其实还有一些隐藏的属性，比如每一行的事务 id，所以每一行数据可能会有多个版本，每一个修改过它的事务都会有一行，并且还会有关联的 undo 日志，表示这个操作原来的数据是什么，可以用它做回滚。

那么为什么要这么做？

因为如果我们直接把数据修改了，那么其他事务就用不了原先的值了，违反了事务的一致性。

那么一个事务读取某一行的数据到底返回什么结果呢？

取决于隔离级别，如果是 Read Committed，那么返回的是最新的事务的提交值，所以未提交的事务修改的值是不会读到的，这就是 Read Committed 实现的原理。

如果是 Read Repeatable 级别，那么只能返回发起时间比当前事务早的事务的提交值，和比当前事务晚的删除事务删除的值。这其实就是 MVCC 方式。

undo log

undo log 中存储的是老版本数据。假设修改表中 id=2 的行数据，把 Name= B 修改为 Name = B2，那么 undo 日志就会用来存放 Name= B 的记录，如果这个修改出现异常，可以使用 undo 日志来实现回滚操作，保证事务的一致性。

当一个旧的事务需要读取数据时，为了能读取到老版本的数据，需要顺着 undo 链找到满足其可见性的记录。当版本链很长时，通常可以认为这是个比较耗时的操作。

假设一个值从 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 对应的事务是不会冲突的。

另外，在回滚段中的 undo log 分为: insert undo log 和 update undo log：

insert undo log : 事务对 insert 新记录时产生的 undolog，只在事务回滚时需要，并且在事务提交后就可以立即丢弃。（谁会对刚插入的数据有可见性需求呢！！）

update undo log : 事务对记录进行 delete 和 update 操作时产生的 undo log。不仅在事务回滚时需要，一致性读也需要，所以不能随便删除，只有当数据库所使用的快照中不涉及该日志记录，对应的回滚日志才会被 purge 线程删除。

何时删除？

在不需要的时候才删除。也就是说，系统会判断，当没有事务再需要用到这些回滚日志时，回滚日志会被删除。

就是当系统里没有比这个回滚日志更早的 read-view 的时候。

长事务

直观感觉，一个事务花费很长时间不能够结束，就是一个长的事务，简称长事务（Long Transaction）。

长事务是数据库用户经常会碰到且是非常令人头疼的问题。长事务处理需要恰当进行，如处理不当可能引起数据库的崩溃，为用户带来不必要的损失。

根据上面的论述，长事务意味着系统里面会存在很老的事务视图。

由于这些事务随时可能访问数据库里面的任何数据，所以这个事务提交之前，数据库里面它可能用到的 undo log 都必须保留，这就会导致大量占用存储空间。

在 MySQL 5.5 及以前的版本，回滚日志是跟数据字典一起放在 ibdata 文件里的，即使长事务最终提交，回滚段被清理，文件也不会变小。

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

因此，我们要尽量避免长事务。

“MySQL 的事务隔离级别介绍”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注丸趣 TV 网站，丸趣 TV 小编将为大家输出更多高质量的实用文章！