MySQL多版本并发控制机制源码分析

本文主要讲解MySQL多版本并发控制机制的源代码分析。感兴趣的朋友不妨看看。本文介绍的方法简单、快速、实用。让边肖带你学习《MySQL多版本并发控制机制源代码分析》！

MVCC(多版本并发控制机制)

隔离也可以称为并发控制、可串行化等。说到并发控制，首先想到的是锁。MySQL通过使用两级锁实现了更新的序列化。同时，为了加快查询性能，采用了MVCC(多版本并发控制)机制，可以在不加锁的情况下获得一致的版本。

Repeatable Read

MySQL通过MVCC和(下一个密钥锁)实现可重复读取。它的想法(MVCC)是记录数据的版本变化，它可以通过精心选择不同版本的数据向用户呈现一致的结果。如下图：所示

在上图中，(A=50|B=50)的初始版本为1。

1.交易t1在选择A时看到了版本1，即A=50。

2.事务t2修改为A和B将版本升级为2，即A=0，B=100。

3.事务t1在选择B时仍然看到版本1，即B=50。

这样就隔离了版本的影响，A B永远是100。

Read Commit

但是，如果您读取最近提交的结果而不是版本控制机制，隔离级别是read commit，如下图：所示。

在这种情况下，需要使用锁定机制(如选择进行更新)来锁定A和B记录，以获得正确一致的结果，如下图所示：

MVCC的优势

当我们想要对一些数据进行一些只读操作来检查一致性时，比如检查帐户是否对齐，我们不想添加性能损失很大的锁。在这个时候，一致版的MVCC有很大的优势。

MVCC(实现机制)

本节开始讨论MVCC的实现机制，注意MVCC只在纯select中有效(不包括锁定操作，如select for update、在共享模式下锁定、updateinsert等。).

select运行栈

首先，让我们在mysql源代码中跟踪一个普通查询sql的运行过程，其中sql是(select * from test)；

它的运行栈是：

由于mysql的默认隔离级别是repeatable_read(RR)，read_record的重载是rr_sequential(目前我们不关心通过索引选择行，然后通过条件过滤的过程)。继续追踪：

我们来看看函数内部的：

boollock _ cluster _ rec _ cons _ read _ sees(constract _ t * rec/* innodb *扫描的一行，) {.//从当前扫描的行中获取其* *修改版本trx_id(事务ID) Trx _ ID=row _ get _ rec。//通过参数(一致的快照视图和事务id)确定行快照返回(read _ view _ sees _ Trx _ id (view，Trx _ ID))；

  }

read_view的创建过程

我们先关注一致性视图的创建过程,我们先看下read_view结构:

然后通过debug，发现创建read_view结构也是在上述的rr_sequential中操作的，继续跟踪调用栈:

我们看下row_search_for_mysql里的一个分支: 

row_search_for_mysql:  // 这边只有select不加锁模式的时候才会创建一致性视图  else if (prebuilt->select_lock_type == LOCK_NONE) { // 创建一致性视图  trx_assign_read_view(trx);  prebuilt->sql_stat_start = FALSE;  }

上面的注释就是select for update(in share model)不会走MVCC的原因。让我们进一步分析trx_assign_read_view函数:

好了，终于到了创建read_view的主要阶段,主要过程如下图所示:

代码过程为:

行版本可见性:

由上面的lock_clust_rec_cons_read_sees可知,行版本可见性由read_view_sees_trx_id函数判断:

其实上述函数就是一个二分法，read_view其实保存的是当前活跃事务的所有事务id,如果当前行版本对应修改的事务id不在当前活跃事务里面的话，就返回true,表示当前版本可见，否则就是不可见,如下图所示。

接上述lock_clust_rec_cons_read_sees的返回:

undolog搜索可见版本的过程

我们现在考察一下row_sel_build_prev_vers_for_mysql函数: 

row_sel_build_prev_vers_for_mysql  |-row_vers_build_for_consistent_read

主要是调用了row_ver_build_for_consistent_read方法返回可见版本:

整个过程如下图所示:

至于undolog怎么恢复出对应版本的row记录就又是一个复杂的过程了，由于篇幅原因，在此略过不表。

read_view创建时机再讨论

在创建一致性视图的row_search_for_mysql的代码中

trx_assign_read_view中由这么一段代码

所以综合这两段代码，即在一个事务中，只有***次运行select(不加锁)的时候才会创建一致性视图,如下图所示:

笔者构造了此种场景模拟过，确实如此。

MVCC和锁的同时作用导致的一些现象

MySQL是通过MVCC和二阶段锁(2PL)来兼顾性能和一致性的，但是由于MySQL仅仅在select时候才创建一致性视图，而在update等加锁操作的时候并不做如此操作，所以就会产生一些诡异的现象。如下图所示:

如果理解了update不走一致性视图(read_view)，而select走一致性视图(read_view)，就可以很好解释这个现象。 如下图所示:

到此，相信大家对“MySQL多版本并发控制机制源码分析”有了更深的了解，不妨来实际操作一番吧！这里是网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！