mysql行锁+可重复读+读提交
Posted jimmyhe
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了mysql行锁+可重复读+读提交相关的知识,希望对你有一定的参考价值。
行锁
-
innodb支持行锁,myisam只支持表锁,同一时刻每张表只能有一条数据被更新
-
在InnoDB事务中,行锁是在需要的时候才加上的,但并不是不需要了就立刻释放, 而是要等到事务结束时才释放。这个就是两阶段锁协议。
-
如果你的事务中需要锁多个行,要把最可能造成锁冲突、最可能影响并 发度的锁的申请时机尽量往后放。
-
例子:假设你负责实现一个电影票在线交易业务,顾客A要在影院B购买电影票。我们简化一点,这个业务需要涉及到以下操作:
-
从顾客A账户余额中扣除电影票价;
-
给影院B的账户余额增加这张电影票价;
-
记录一条交易日志。
-
也就是说,要完成这个交易,我们需要update两条记录,并insert一条记录。当然,为了保证交易的原子性,我们要把这三个操作放在一个事务中。那么,你会怎样安排这三个语句在事务中的顺序呢? 试想如果同时有另外一个顾客C要在影院B买票,那么这两个事务冲突的部分就是语句2了。因为它们要更新同一个影院账户的余额,需要修改同一行数据。根据两阶段锁协议,不论你怎样安排语句顺序,所有的操作需要的行锁都是在事务提交的时候才 释放的。所以,如果你把语句2安排在最后,比如按照3、1、2这样的顺序,那么影院账户余额这一行的锁时间就最少。这就最大程度地减少了事务之间的锁等待,提升了并发度
-
-
死锁:事务A和事务B在互相等待对方的资源释放,就是进入了死锁状态。
-
一种策略是,直接进入等待,直到超时。这个超时时间可以通过参数 innodb_lock_wait_timeout来设置。
-
默认是50s,在正常生产环境中是不可接受的
-
设置时间过短可能会误伤很多,比如简单的锁等待
-
-
另一种策略是,发起死锁检测,发现死锁后,主动回滚死锁链条中的某一个事务,让其他事务得以继续执行。将参数innodb_deadlock_detect设置为on,表示开启这个逻辑。
-
如果有1000条并发更新同一行,那么会有1000*1000并发量死锁检测,导致cpu上升
-
如果确定不会出现死锁,可以关闭死锁检测。但是这种操作本身带有一定的风险,因为业务设计的时候一般不会把死锁当做一个严重错误,毕竟出现死锁了,就回滚,然后通过业务重试一般就没问题了,这是业务无损的。而关掉死锁检测意味着可能会出现大量的超时,这是业务有损的。
-
-
-
进行以下流程操作:
-
注意:begin/start transaction 命令并不是一个事务的起点,在执行到它们之后的第一个操作InnoDB表的语句(第一个快照读语句),事务才真正启动。如果你想要马上启动一个事务,可以使用start transaction with consistent snapshot 这个命令。
-
mysql有两个视图的概念
-
view,用查询语句定义的虚拟表,在调用的时候执行查询语句并生成结果,创建视图的语法是create view
-
innodb在实现mvcc时用到的一致性读视图,用于支持读提交,可重复度隔离级别的实现。
-
-
快照
-
innodb里面每个事物有唯一的事物id,叫做transaction id,在事物开始时想innodb事物系统申请的,是按申请顺序严格递增的。
-
每行数据有多个版本的,每次更新数据的时候,都会生成一个新的数据版本,并且将transaction id赋值给这个数据版本的事物id 记为row trx_id,同时旧的数据版本要保留,并且在新的数据版本中,能够有信息可以直接拿到它。所以数据表中的一行记录,其实有多个版本,每个版本有自己的row trx_id
-
-
-
虚线就是回滚日志,V1,V2,V3都不是物理存在的,而是需要根据当前版本和undolog计算出来的。
-
回顾快照
-
可重复度:一个事物启动后,能够看到所有已提交事物结果,但是,这个事物执行期间,其它事物的更新对他不可见。因此一个事物只需在启动的时候说明,,“以我启动的时刻为准,如果一个数据版本是在我启动之前生成的,就认;如果是我启动以后才生成的,我就不认,我必须要找到它的上一个版本”。当然,如果“上一个版本”也不可见,那就得继续往前找。还有,如果是这个事务自己更新的数据,它自己还是要认的。
-
innodb还为每个事物构造了数组,用来保存事物启动的瞬间,当前启动了还没提交的事物id。
-
数组里事物id的最小值记为低水位,系统里事物id最大值+1记为高水位
-
试图数组和高水位就构成了当前事物的一致性视图
-
这个视图数组把所有的row trx_id分成了几种不同的情况。
-
-
-
-
-
落在绿色部分,表示这个版本是已提交的事物或者是自己生成的,可见
-
落在红色部分,这个版本是由将来事物生成的,不可见。
-
如果在黄色部分
-
若row trx_id在数组中,表示这个版本是由还没提交的事物生成的,不可见
-
若row trx_id不再数组中,表示这个版本是已提交的事物生成的,课件
-
-
-
比如上方图(数据的四个版本),如果有一个事物,它的低水位是18,那么当他访问这一行数据时,v4通过u3算出v3,得到值是11。
-
-
第一张图中的三个事物
-
假设事物A开始前,系统里只有一个活跃事物id是99,
-
事物A,B,C版本号分别是100,101,102,并且当前只有这四个事物
-
三个事物开始前(1,1)这一行的数据row trx_id是90
-
所以事物A的数组就是[99,100],B[99,100,101],C[99,100,101,102]
-
-
-
-
第二个有效更新是事务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不论在什么时候查询,看到这行数据的结果都是一致的,所以我们称之为一致性读。
-
-
一个数据版本,对于一个事务视图来说,除了自己的更新总是可见以外,有三种情况:
-
版本未提交,不可见
-
版本已提交,但是是在视图创建后提交的,不可见;
-
版本已提交,而且是在视图创建前提交的,可见。
-
-
事务A的查询语句的视图数组是在事务A启动的时候生成的,这时候:
-
(1,3)还没提交,属于情况1,不可见;
-
(1,2)虽然提交了,但是是在视图数组创建之后提交的,属于情况2,不可见;
-
(1,1)是在视图数组创建之前提交的,可见。
-
可重复读的核心就是一致性读(consistent read);而事务更新数据的时候,只能用当前读。如果当前的记录的行锁被其他事务占用的话,就需要进入锁等待。
而读提交的逻辑和可重复读的逻辑类似,它们最主要的区别是:在可重复读隔离级别下,只需要在事务开始的时候创建一致性视图,之后事务里的其他查询都共用这个一致性视图;在读提交隔离级别下,每一个语句执行前都会重新算出一个新的视图。
小结
-
对于可重复读,查询只承认在事务启动前就已经提交完成的数据;
-
对于读提交,查询只承认在语句启动前就已经提交完成的数据;
-
而当前读,总是读取已经提交完成的最新版本。
以上是关于mysql行锁+可重复读+读提交的主要内容,如果未能解决你的问题,请参考以下文章