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,id
来源： https://www.cnblogs.com/xiaoxi-jinchen/p/16066017.html