Read Commited 隔离级别下锁情况（MVCC实现原理）

如何通过单纯加锁实现RC隔离级别的隔离效果？

对InnoDB引擎下的mysql数据库支持行级锁，通过对事务访问时增加排他锁（X锁）可以防止其他事务的访问，只有在该事务锁提交也就是commit后才可以访问，避免脏读产生。但是在多读的场景下，一个事务假如在进行update操作，后面有许多请求都想要单纯进行读操作（普通的SELECT语句），可是因为有锁的存在只能进行等待。该方法在多读的并发环境下效率大大降低。

真实情况下由于InnoDB在RC和RR隔离级别下使用了MVCC机制，实现了一致性非阻塞读，提高了并发读写效率。其实读到的都是事务发生之前最新的快照版本。MVCC只是实现了快照读，对于当前读还是使用的排他锁（文章最后会总结不同索引条件下排他锁的情况）。

MVCC实现原理（仅对于RC和RR两种隔离级别有MVCC）

1.版本链

对于使用InnoDB存储引擎的表来说，它的聚簇索引记录中都会包含两个必要的隐藏列（row_id并不是必要的，如果我们创建的表中有主键或者非null唯一键都不会再创建row_id）

• 6字节的事务ID（DB_TRX_ID）每次对某条记录进行改动时，会把对应的事务ID值赋给DB_TRX_ID隐藏列（也就是每个行记录上这个字段会记录最近把这个字段修改的事务id）
• 7字节的回滚指针（DB_ROLL_PTR）每次对某条记录进行改进时，这个隐藏列会存一个指针，可以通过这个指针找到该记录修改前的信息
• 隐藏ID

2.MVCC实现的依赖：

• undo log ：undo log记录的时数据表记录行的多个版本，也就是事务执行过程的回滚段，其实就是MVCC中一行原始数据的多个版本镜像数据。
• read view：主要用来判断当前版本数据的可见性
• 创建readvew的时机：在该隔离级别下（RC），每次发起SELECT都会创建readview；在RR隔离级别下，事务中的第一个SELECT请求才会开始创建readview。正是由于创建readview时机不同，决定了RC隔离级别可以避免脏读，但不能避免不可重复读。

  read view中包含四个重要的内容

  1. m_ids：在生成readview时当前系统系统中活跃的读写事务的事务id列表【当前事务（新建事务）与正在内存中commit的事务不在活跃事务列表中】
  2. min_trx_id：表示在生成readview时当前系统中活跃的读写事务中最小的事务id，也就是m_ids中的最小值
  3. max_trx_id：表示生成readview时系统中应该分配给下一个事务的id值
  4. creator_trx_id：表示生成readview的事务的事务id

  需要注意的是：max_trx_id并不是m_ids中的最大值，事务id是递增分配的。比如现在id为1，2，3这三个事务，之后id为3的事务提交了。事务在生成readview时，m_ids就包括1，2，其中min_trx_id的值就是1，max_trx_id的值就是4

3.当前事务读取某个行记录时的具体过程（注意：当前事务与正在内存中commit的事务不在readview活跃列表中）：

在innodb中，在RC隔离级别下创建新事务并每次执行SELECT语句后，innodb会将当前系统中活跃事务的列表创建一个副本（read view）,副本中保存的是系统当前不应该被本事务看到的其他事务id列表。当前一个用户创建了一个事务，当他想要读取这个行记录的时候，innodb会将这个行记录当前的版本号与readview进行比较，比较过程具体如下：

4.行的更新过程

1. 初始数据行。F1~F6是字段的名，1~6对应该字段的值。后面三个隐藏字段分别对应该行的事务号和回滚指针，假如这条数据是刚insert的，可以认为ID为1，其余两个字段为空。

1. Session1更改该行的各个字段的值，会进行如下图所作操作：

   用排他锁（X锁）锁定改行

   记录redo log

   把改行修改前的值Copy到undo log

   修改当前行的值，当前事务编号为01（示例中填写为01），使回滚指针指向undo log中修改前的行

   

2. Session2再来修改该行的值，与Session1中的步骤基本相同，但此时undo log中有两行记录，并且通过回滚指针连在一起

5.InnoDB的MVCC多版本并发控制优缺点总结

使用MVCC使得在读取数据的时候，Innodb几乎可以不用获得任何锁，每个查询都通过版本检查，只获得自己需要的数据版本，从而大大提高了系统的并发度。但是这种策略的缺点是每行记录都需要额外的存储空间，更多的检查工作和一个额外的维护工作。

但是Innodb并不是单纯的使用MVCC，只是在读操作时使用MVCC代替读锁，在进行其他操作依旧需要用到排他锁。

当事务仅仅修改一行记录的时候使用MVCC是可以的，但是当涉及多行记录的修改，MVCC就力不从心了。比如事务a执行理想的MVCC，想要修改两行数据，第一行修改成功，但是第二行修改失败，此时需要回滚第一行，但是以为第一行没有加行锁，事务b可能此时就对第二行进行了修改，但若后来事务a进行了回滚，那事务b进行的操作就会遭到破坏

所以Innodb只是借了MVCC这个名字，提供了非阻塞读。在写数据时依旧使用的排他锁（不使用间隙锁，所以依旧可以执行插入操作，所以不能避免幻读），其他事务依旧可以读取上锁的数据是因为读的只是镜像版本而已

 6.RC隔离级别下行级锁的情况

在RC隔离级别下，行级锁并不是直接锁记录，而是会锁索引。索引又分为主键索引和唯一索引和非唯一索引。当sql语句操作主键索引时，mysql会直接在该主键索引上加排他锁；当sql语句操作唯一索引时，mysql会对该唯一索引记录加入排他锁，然后使用该条记录的主键通过主键索引（聚簇索引）在主键上加入排他锁；当sql语句操作非唯一索引，首先会将所有满足where条件的非唯一索引加排他锁，依然会通过聚簇索引对主键加锁；在无索引的情况下，因为无法直接定位到记录，所以直接走聚簇索引，走全表扫描，会将聚簇索引上所有的记录都加入排他锁（注意这里的并不是表锁）。mysql对之后的流程进行了优化，会将所有不满足条件的记录放锁，这样保证了最后只会有满足条件的记录上锁，降低了所冲突发生的概率，但这个流程是不会省略的。

7.RC隔离级别下的半一致性读

这是一种夹在普通读和锁定读之间的一种读取方式。它只在READ COMMITTED隔离级别下（或者在开启了innodb_locks_unsafe_for_binlog系统变量的情况下）使用update语句才会使用。具体的含义就是当UPDATE语句读取已经被其他事务加了锁的记录时，InnoDB会将该记录的最新提交的版本读出来，然后判断该版本是否与update语句中的where条件相匹配，如果不匹配则不对该记录加锁，从而跳到下一条记录；如果匹配则再次读取该记录并对其进行加锁。这样子处理只是为了让update语句尽量少被别的语句阻塞。

原文地址：https://www.cnblogs.com/leeeeemz/p/12586815.html