mysql行锁+可重复读+读提交

2022/3/28 19:23:08

本文主要是介绍mysql行锁+可重复读+读提交,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

行锁

  • innodb支持行锁,myisam只支持表锁,同一时刻每张表只能有一条数据被更新

  • 在InnoDB事务中,行锁是在需要的时候才加上的,但并不是不需要了就立刻释放, 而是要等到事务结束时才释放。这个就是两阶段锁协议。

  • 如果你的事务中需要锁多个行,要把最可能造成锁冲突、最可能影响并 发度的锁的申请时机尽量往后放。

  • 例子:假设你负责实现一个电影票在线交易业务,顾客A要在影院B购买电影票。我们简化一点,这个业务需要涉及到以下操作:

    1. 从顾客A账户余额中扣除电影票价;

    2. 给影院B的账户余额增加这张电影票价;

    3. 记录一条交易日志。

    • 也就是说,要完成这个交易,我们需要update两条记录,并insert一条记录。当然,为了保证交易的原子性,我们要把这三个操作放在一个事务中。那么,你会怎样安排这三个语句在事务中的顺序呢? 试想如果同时有另外一个顾客C要在影院B买票,那么这两个事务冲突的部分就是语句2了。因为它们要更新同一个影院账户的余额,需要修改同一行数据。根据两阶段锁协议,不论你怎样安排语句顺序,所有的操作需要的行锁都是在事务提交的时候才 释放的。所以,如果你把语句2安排在最后,比如按照3、1、2这样的顺序,那么影院账户余额这一行的锁时间就最少。这就最大程度地减少了事务之间的锁等待,提升了并发度

  • 死锁:事务A和事务B在互相等待对方的资源释放,就是进入了死锁状态。

    • 一种策略是,直接进入等待,直到超时。这个超时时间可以通过参数 innodb_lock_wait_timeout来设置。

      • 默认是50s,在正常生产环境中是不可接受的

      • 设置时间过短可能会误伤很多,比如简单的锁等待

    • 另一种策略是,发起死锁检测,发现死锁后,主动回滚死锁链条中的某一个事务,让其他事务得以继续执行。将参数innodb_deadlock_detect设置为on,表示开启这个逻辑。

      • 如果有1000条并发更新同一行,那么会有1000*1000并发量死锁检测,导致cpu上升

      • 如果确定不会出现死锁,可以关闭死锁检测。但是这种操作本身带有一定的风险,因为业务设计的时候一般不会把死锁当做一个严重错误,毕竟出现死锁了,就回滚,然后通过业务重试一般就没问题了,这是业务无损的。而关掉死锁检测意味着可能会出现大量的超时,这是业务有损的。

      • 控制并发度,在进入mysql服务端设置中间件,或者通过修改mysql源码来是这样的并发线程排队,不会出现死锁检测。

 

事物隔离      

  

进行以下流程操作:

  • 注意:begin/start transaction 命令并不是一个事务的起点,在执行到它们之后的第一个操作InnoDB表的语句(第一个快照读语句),事务才真正启动。如果你想要马上启动一个事务,可以使用start transaction with consistent snapshot 这个命令。

  • mysql有两个视图的概念

    1. view,用查询语句定义的虚拟表,在调用的时候执行查询语句并生成结果,创建视图的语法是create view

    2. innodb在实现mvcc时用到的一致性读视图,用于支持读提交,可重复度隔离级别的实现。

  • 快照

    • innodb里面每个事物有唯一的事物id,叫做transaction id,在事物开始时想innodb事物系统申请的,是按申请顺序严格递增的。

    • 每行数据有多个版本的,每次更新数据的时候,都会生成一个新的数据版本,并且将transaction id赋值给这个数据版本的事物id 记为row trx_id,同时旧的数据版本要保留,并且在新的数据版本中,能够有信息可以直接拿到它。所以数据表中的一行记录,其实有多个版本,每个版本有自己的row trx_id

 

  • 如图:同一行数据四个版本,最新版本是v4,k的值是22,它被transaction id为25的事物更新,因此它的row trx_id也是25

  • 虚线就是回滚日志,V1,V2,V3都不是物理存在的,而是需要根据当前版本和undolog计算出来的。

  • 回顾快照

    • 可重复度:一个事物启动后,能够看到所有已提交事物结果,但是,这个事物执行期间,其它事物的更新对他不可见。因此一个事物只需在启动的时候说明,,“以我启动的时刻为准,如果一个数据版本是在我启动之前生成的,就认;如果是我启动以后才生成的,我就不认,我必须要找到它的上一个版本”。当然,如果“上一个版本”也不可见,那就得继续往前找。还有,如果是这个事务自己更新的数据,它自己还是要认的。

    • innodb还为每个事物构造了数组,用来保存事物启动的瞬间,当前启动了还没提交的事物id。

      • 数组里事物id的最小值记为低水位,系统里事物id最大值+1记为高水位

      • 试图数组和高水位就构成了当前事物的一致性视图

      • 这个视图数组把所有的row trx_id分成了几种不同的情况。

  

 

    • 对于当前事物启动瞬间来说,一个数据版本的row trx_id有以下几种可能

      1. 落在绿色部分,表示这个版本是已提交的事物或者是自己生成的,可见

      2. 落在红色部分,这个版本是由将来事物生成的,不可见。

      3. 如果在黄色部分

        1. 若row trx_id在数组中,表示这个版本是由还没提交的事物生成的,不可见

        2. 若row trx_id不再数组中,表示这个版本是已提交的事物生成的,课件

    • 比如上方图(数据的四个版本),如果有一个事物,它的低水位是18,那么当他访问这一行数据时,v4通过u3算出v3,得到值是11。

  • 第一张图中的三个事物

    1. 假设事物A开始前,系统里只有一个活跃事物id是99,

    2. 事物A,B,C版本号分别是100,101,102,并且当前只有这四个事物

    3. 三个事物开始前(1,1)这一行的数据row trx_id是90

    • 所以事物A的数组就是[99,100],B[99,100,101],C[99,100,101,102]

 

 

 

    • 从图中可以看到,第一个有效更新是事务C,把数据从(1,1)改成了(1,2)。这时候,这个数据的最新版本的row trx_id是102,而90这个版本已经成为了历史版本。

    • 第二个有效更新是事务B,把数据从(1,2)改成了(1,3)。这时候,这个数据的最新版本(即row trx_id)是101,而102又成为了历史版本。

    • 在事务A查询的时候,其实事务B还没有提交,但是它生成的(1,3)这个版本已经变成当前版本了。但这个版本对事务A必须是不可见的,否则就变成脏读了。事务A查询语句的读数据流程是这样的

      • 找到(1,3)的时候,判断出row trx_id=101,比高水位大,处于红色区域,不可见;

      • 接着,找到上一个历史版本,一看row trx_id=102,比高水位大,处于红色区域,不可见;

      • 再往前找,终于找到了(1,1),它的row trx_id=90,比低水位小,处于绿色区域,可见。

    • 这样执行下来,虽然期间这一行数据被修改过,但是事务A不论在什么时候查询,看到这行数据的结果都是一致的,所以我们称之为一致性读。

  • 一个数据版本,对于一个事务视图来说,除了自己的更新总是可见以外,有三种情况:

    1. 版本未提交,不可见

    2. 版本已提交,但是是在视图创建后提交的,不可见;

    3. 版本已提交,而且是在视图创建前提交的,可见。

  • 事务A的查询语句的视图数组是在事务A启动的时候生成的,这时候:

    • (1,3)还没提交,属于情况1,不可见;

    • (1,2)虽然提交了,但是是在视图数组创建之后提交的,属于情况2,不可见;

    • (1,1)是在视图数组创建之前提交的,可见。

 对于B来说,遵循更新规则:更新数据都是先读后写的,而这个读,只能读当前的值,称 为“当前读”(current read)。除了update语句外,如果select语句加锁,也是当前读。所以,如果把事务A的查询语句select * from t where id=1修改一下,加上lock in share mode或 for update,也都可以读到版本号是101的数据,返回的k的值是3。

 

 

事务C’的不同是,更新后并没有马上提交,在它提交前,事务B的更新语句先发起了。前面说过了,虽然事务C’还没提交,但是(1,2)这个版本也已经生成了,并且是当前的最新版本。那么,事务B的更新语句会怎么处理呢? 这时候,我们在上一篇文章中提到的“两阶段锁协议”就要上场了。事务C’没提交,也就是说(1,2)这个版本上的写锁还没释放。而事务B是当前读,必须要读最新版本,而且必须加锁,因此就被锁住了,必须等到事务C’释放这个锁,才能继续它的当前读。

 

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

而读提交的逻辑和可重复读的逻辑类似,它们最主要的区别是:在可重复读隔离级别下,只需要在事务开始的时候创建一致性视图,之后事务里的其他查询都共用这个一致性视图;在读提交隔离级别下,每一个语句执行前都会重新算出一个新的视图。

 

那么,我们再看一下,在读提交隔离级别下,事务A和事务B的查询语句查到的k,分别应该是多少呢? 这里需要说明一下,“start transaction with consistent snapshot; ”的意思是从这个语句开始,创建一个持续整个事务的一致性快照。所以,在读提交隔离级别下,这个用法就没意义了,等效于普通的start transaction。下面是读提交时的状态图,可以看到这两个查询语句的创建视图数组的时机发生了变化,就是图中的read view框。(注意:这里,我们用的还是事务C的逻辑直接提交,而不是事务C’)

 

 

这时,事务A的查询语句的视图数组是在执行这个语句的时候创建的,时序上(1,2)、(1,3)的生成时间都在创建这个视图数组的时刻之前。但是,在这个时刻: (1,3)还没提交,属于情况1,不可见; (1,2)提交了,属于情况3,可见。 所以,这时候事务A查询语句返回的是k=2。 显然地,事务B查询结果k=3。

 

小结

innoDB的行数据有多个版本,每个数据版本有自己的row trx_id,每个事务或者语句有自己的一致性视图。普通查询语句是一致性读,一致性读会根据row trx_id和一致性视图确定数据版本的可见性。

  • 对于可重复读,查询只承认在事务启动前就已经提交完成的数据;

  • 对于读提交,查询只承认在语句启动前就已经提交完成的数据;

  • 而当前读,总是读取已经提交完成的最新版本。

 



这篇关于mysql行锁+可重复读+读提交的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!


扫一扫关注最新编程教程