手把手带你探索 MySQL 事务的隔离

开篇声明，这篇文章是最近学习极客专栏后所写的，文中部分内容和图片来自于极客专栏。学习的最好方式就是把自己学的东西通过文字表现出来，并传递给他人。本篇文章会从理论到实践一步步验证。本文默认InnoDB引擎。

事务的概念

日常开发的时候，对事务再熟悉不过了吧。典型的一个事务场景就是转账功能吧。A账户有100元，B账户有0元。当前A给B转账100元。转账过程中涉及到查余额，做加减账户余额，这些操作必须都是一体的。余额大于等于转账金额才能进行转账，从A账户减100，往B账户加100，如果这个时候，给B加100成功了，A账户还没减，我完全可以利用时间差再转一次钱，这时候多出来的100不就乱了嘛。所以说在上述整个操作中，要么全做(A-100, B+100),要么什么都别动，不能只动一边，保证数据原子性。就像你被带绿帽的同时总有另一个人给你带绿帽，是一个道理，话糙理不糙。

简单的说，为了保证数据的一致性和正确性，数据库必须保证事务具有四个性质ACID(原子性，一致性，隔离性，持续性)。接下来会使用例子来理解隔离性。隔离性又是什么呢？还是上个例子，如果我在上面操作的时候，有其他的操作插入进来修改A或者B金额，那么就会导致数据错乱，（就像emmm........，算了不开车了）所以事务之间要进行隔离。

隔离性与隔离级别

我们应该知道，事务之间的隔离，隔离的越严实，相应的效率也会越低，所以在操作的过程中，需要针对当前的环境，寻找一个平衡点。标准的事务隔离包括读未提交，读已提交，可重复读以及可串行性。

• 读未提交: 一个事务做的操作还未提交，它做的变更就能被其他事务看到。

• 读已提交: 一个事务做的操作要等到他提交了事务之后才能被其他事务看到

• 可重复读: 一个事务在执行过程中看到的数据，总是和它在启动的时候看到的数据是一样的。当然它自己未提交的事务对其他事务来说也是不可见的。

• 可串行性：对于同一行数据，写会加“写”锁，读会加"读"锁，当出现读写冲突的时候，后一个事务必须等待前一个事务提交事务，才能进行。

下面来实践一个例子说明以上的内容。我们先创建一个表，并往其插入一条数据。

MySQL的默认隔离级别是可重复读。可以使用命令查看一下。确实是可重复读。通过修改隔离级别来验证以上的内容。

我们先修改成读未提交，跑命令，然后查看是否修改成功。

我们同时开启两个窗口，代表着两个事务，来验证隔离级别为读未提交的情况下，其他事务是否可以查看到未提交事务的更改数据。

窗口1在修改完值后并未提交事务，但是此时在窗口2事务中查询已经可以看到窗口1修改的值。这里开启事务我使用了

start transaction with consistent snapshot

因为在MySQL中，begin/start transaction 并不是真正开启事务，而是在执行InnoDB的第一句语句的时候，事务才真正的启动。如果你想马上开启事务，那么使用上面的语句。

接下来我们把隔离修改成读已提交。把c=2重新修改成c=1，但是修改过程中不提交事务，看另一个事务是否对修改可见。

查看结果,可以看到当在读已提交的隔离下，另一个事务看不到未提交事务的修改。

我们可以接着看，把修改的事务提交之后，再进行查询。可以很清楚的看到，在事务commit之后，另一个事务再查询能看到对应修改的值。\

接下来我们主要再看一下可串行性。首先我们修改对应的Mysql的隔离级别，然后开始执行。同时开启两个事务，查询的时候没有问题，当其中一个事务准备更新数据的时候，被锁住了，光标停止不动。

此时需要commit其中一个事务释放锁，另一个事务才可以执行操作。但是对于此时的改动，其他事务并不能看见，因为修改的事务并未提交。但是对于自己来说，我修改的东西当然可见(涉及到之后的知识)，等到修改事务commit提交的时候，那么再次查询就可以看见修改的操作了。

理解了事务隔离的级别，那具体是咋么实现的呢。在实现上,数据库会生成一个视图，访问的时候以视图的逻辑结果为准。在可重复读的情况下，这个视图是在事务开启的时候就启动的。整个事务存在期间使用的都是这个视图。读提交的情况下，视图是在每个sql语句执行的时候创建的。如果是读未提交隔离下，直接返回记录的最新值，并不会创建视图。至于串行性则是通过加锁的方式来实现并发控制。

事务到底隔离还是不隔离

上面说到，在可重复读的隔离下，事务在启动的时候创建一个视图，之后即使其他事务更改了数据，对当前这个执行中的事务来说，看到的视图依然是启动时的视图，似乎不受外界影响。

但是上面有一个场景，在更新行数据的时候，如果刚好有另一个事务拥有这个行锁，那么当前事务更新行的时候将会被锁住，等到另一个事务释放了锁，当前事务获取了锁之后，此时它查询得到的值还是事务启动时的值吗？下面的实践内容将围绕这个话题展开。

首先这是表的结构和对应当前的两条记录。

接下来我们有事务A.B.C的执行流程.

还有一点就是MySQL有一个参数设置值autocommit，默认是1表示的是事务自动提交，每一个查询都是一个单独的事务自动提交，就像图中事务C,update就是一个单独的事务，更新完自己提交。当然你可以使用显式的begin/commit。

让我们把目光对准上面的图，事务B的查询结果K是3，事务A的查询结果K是1，你是不是想骂我？你先别急着骂，让我们来看下结果。打开三个控制台。

好吧我没瞎说吧，现在你可以开始骂我了，你不是说在可重复读隔离的情况下，当前事务执行过程中看到的视图始终是启动时的视图嘛。

在MySQL中有两个视图概念:

• 一个是view。也就是创建视图，语句是 create view xxx() as.....,它并不是一个真实的表，它的内容是由存储在数据库中进行查询操作的SQL语句定义的。

• 另一个就是InnoDB在实现MVCC是用到的一致性读视图(consistent read view)。用于支持读已提交RC(Read Committed) 和可重复读RR(Repeatable Read)的隔离级别实现。

InnoDB每一个事物都存在一个事务唯一ID，叫做transaction id,它是一个事务在启动的时候InnoDB向系统申请的，严格按照递增的形式生成。

每一行数据都有对应多个版本，每次通过事务更新的数据都会生成新的版本，然后把transaction id 赋值给这个版本事务ID，记为row trx_id,同时，为了之后可以恢复数据，我们需要保留旧的数据版本。也就是说在当前最新的版本中，我们可以随时获取旧的数据。下图对应修改一行数据的版本图。

                                      注:图片来源极客时间

从上图可以知道，最新版本是V4,且是由事务 transaction id =25更新的，所以对应此行数据的数据版本row trx_id =25。

按照可重复读的定义。一个事务启动的时候，可以看到所有已经提交的事务，但是接下来的事务对它来说是不可见的。所以对于一个事务启动的时候，如果一个事务在我启动时刻之前生成的，我就认，如果在我启动之后生成的，我就不认，我必须要找到它的上一个版本。有点渣男的嫌疑。如果上一个版本还不可见，那就继续往前面找，当然在这个过程中，自己更新的东西得认。

在实现上，InnoDB为每一个事务创建了一个数组。事务中ID最小的称为低水位，当前系统中已经创建的事务ID最大值加1就是高水位。这个数组和水位图，就组成了当前事务的一致性图。数据版本可见性，就是基于数据版本数组和水位视图的比较而得到的结果。

这个视图数组把所有的row trx_id分为以下几种情况

注:图片来源极客时间

1. 如果当前事务启动的时候，一个数据版本(row trx_id)落在绿色部分,表示这个事务是已提交的版本或者是自己生成的，可见。

2. 如果落在红色部分，说明这个版本是由将来启动的事务生成的，肯定不可见。

3. 如果落在黄色，又分为两种情况。如果 row trx_id 存在数组中，说明， 此时版本数据还未提交事务，不可见，如果不在，说明已经提交事务了，可见。

接下来可以分析为什么上面A查询的k=1，B查询的k=3了。

查看上图，我们假设当前有一个活跃的事务99，目前我们更新的这一行数据的数据版本row trx_id=90，此时系统存在4个事务，那么对于A的视图数组就是[99,100],B的视图数组就是[99,100,101],C的活跃数组就是[99,100,101,102]。当前版本101。

从图中知道，事务A先启动，接着事务B，最后事务C，但是第一个有效更新的是事务C,设置k为2(k=1+1),然后是事务B 把k设置为3(k=2+1),接着到A查询了，他的视图数组是[99,100],此时数据版本(1,3)也就是row trx_id=101 ,一对比，发现这货在高水位。不可见，再往回追，(1,2)数据版本row trx_id=102,我去还是在高水位，不可见，最后追到(1,1)数据版本row trx_id=90，比水位低，可见，一看上面的值K=1,所以查询结果就等于1。

这样一个流程走下来，虽然中间修改了数据，数据版本也发生了变化，但是对于事务A来说，对他都是不可见的，所以看到的结果还是之前的数据。

到这里还有一个疑问，也就是开头的，事务B是在事务C之前开启事务的啊，对于事务B来说，事务C的操作对他来说是不可见的啊，事务B为什么获取的值是2，然后再2的基础上更新了，它启动事务的时候k可不等于2。

是的道理是没错，前提是如果事务B在更新之前先查询一遍数据，那么之后在它更新完数据以后，再次查询得到的值将会是1,而不是3。这里运用到一条规则，更新数据的时候都是先读后写的。而这个读，只能读当前的值，叫做"当前读"。对于B来说，在它更新之前，并没有执行读操作，所以在更新的时候，不能再在历史版本上直接更新了，否则C的更新将会丢失。所以B在更新的时候当前读(1,2)，更新之后(1,3)，当前的版本也就是 row trx_id=101了。等到他查询的时候，一看当前版本号101就是自己，所以查询的时候就等于3。

下面可以试验一下当B在更新之前查询一遍数据,然后更新数据再查询，符合上面所说的，得到的值就是1。此时运用的就是当前读。

最后如果改动一下C事务中的执行，结果又是什么?\

这时候的事务C不再是自动提交事务，也是显式提交。事务C'更新语句，先获取写锁，但是C'事务还未提交，此时事务B是当前读，必须读取当前最新版本，而且必须加锁，等到C提交了，事务B才得以继续进行。那么B查询的结果不会变依然是之前的3，而事务C的事务已经提交了，在读隔离的情况下，是在创建新视图之前，所以A的结果k=2。

可重复读的核心就是一致性读。而事务更新数据的时候，只能用当前读，如果当前要读的记录的行数被其他事务占用的时候，就需要等待。

而读提交的逻辑和可重复读的逻辑类似，最主要的区别在于:

• 在可重复读隔离级别下，只需要在事务开始的时候创建一致性视图，之后事务里的其他查询都共用这个一致性视图；

• 在读提交隔离级别下，每一个语句执行前都会重新算出一个新的视图

还是把这篇文章写完了，极客专栏的质量真的很高，如果有理解有误的地方，请慷慨指正。微信发布地址: 手机文章地址