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


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........,算了不开车了)所以事务之间要进行隔离。

隔离性与隔离级别

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

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

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

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

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

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

image-1572272766908.png

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

2.png

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

3.png

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

4.png

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

start transaction with consistent snapshot

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

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

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

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

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

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

9.png

10.png

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

事务到底隔离还是不隔离

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

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

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

11.png

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

12.png

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

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

13.png

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

在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,同时,为了之后可以恢复数据,我们需要保留旧的数据版本。也就是说在当前最新的版本中,我们可以随时获取旧的数据。下图对应修改一行数据的版本图。

14.png                                       注:图片来源极客时间

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

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

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

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

15.png

注:图片来源极客时间

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

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

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

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

16.png

查看上图,我们假设当前有一个活跃的事务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。此时运用的就是当前读。

17.png

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

18.png

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

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

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

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

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

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


Vote Vote Cancel Collect Collect Cancel

<< 上一篇: 程序员内功修炼系列教程

>> 下一篇: 快速定位无用路由 妈妈再也不用担心人工排雷了