CFSDN坚持开源创造价值，我们致力于搭建一个资源共享平台，让每一个IT人在这里找到属于你的精彩世界.

这篇CFSDN的博客文章详解MySQL多版本并发控制机制(MVCC)源码由作者收集整理，如果你对这篇文章有兴趣，记得点赞哟.

1、前言

作为一个数据库爱好者，自己动手写过简单的sql解析器以及存储引擎，但感觉还是不够过瘾。<<事务处理-概念与技术>>诚然讲的非常透彻，但只能提纲挈领，不能让你玩转某个真正的数据库。感谢cmake,能够让我在mac上用xcode去debug mysql,从而能去领略它的各种实现细节.

(注:本文的mysql采用的是mysql-5.6.35版本) 。

2、mvcc(多版本并发控制机制)

隔离性也可以被称作并发控制、可串行化等。谈到并发控制首先想到的就是锁，mysql通过使用两阶段锁的方式实现了更新的可串行化，同时为了加速查询性能，采用了mvcc(multi version concurrency control)的机制，使得不用锁也可以获取一致性的版本.

2.1、repeatable read

mysql的通过mvcc以及(next-key lock)实现了可重复读(repeatable read),其思想(mvcc)就是记录数据的版本变迁，通过精巧的选择不同数据的版本从而能够对用户呈现一致的结果。如下图所示

上图中，(a=50|b=50)的初始版本为1.

1.事务t1在select a时候看到的版本为1，即a=50 。

2.事务t2对a和b的修改将版本升级为2,即a=0,b=100 。

3.事务t1再此select b的时候看到的版本还是1, 即b=50 。

这样就隔离了版本的影响，a+b始终为100.

2.2、read commit

而如果不通过版本控制机制，而是读到最近提交的结果的话，则隔离级别是read commit,如下图所示

在这种情况下，就需要使用锁机制(例如select for update)将此a,b记录锁住，从而获得正确的一致结果,如下图所示:

2.3、mvcc的优势

当我们要对一些数据做一些只读操作来检查一致性，例如检查账务是否对齐的操作时候，并不希望加上对性能损耗很大的锁。这时候mvcc的一致性版本就有很大的优势了.

3、mvcc(实现机制)

本节就开始谈谈mvcc的实现机制,注意mvcc仅仅在纯select时有效(不包括select for update,lock in share mode等加锁操作,以及update\insert等).

3.1、select运行栈

首先我们追踪一下一条普通的查询sql在mysql源码中的运行过程,sql为(select * from test),

其运行栈为

handle_one_connection  mysql的网络模型是one request one thread 。

 |-do_handle_one_connection 。

|-do_command 。

|-dispatch_command 。

|-mysql_parse 解析sql 。

|-mysql_execute_command 。

|-execute_sqlcom_select 执行select语句 。

|-handle_select 。

...一堆parse join 等的操作，当前并不关心 。

|-*tab->read_record.read_record 读取记录 。

由于mysql默认隔离级别是repeatable_read(rr),所以read_record重载为 rr_sequential(当前我们并不关心select通过index扫描出row之后再通过condition过滤的过程)。继续追踪

read_record 。

 |-rr_sequential 。

|-ha_rnd_next 。

|-ha_innobase::rnd_next 这边就已经到了innodb引擎了 。

|-general_fetch 。

|-row_search_for_mysql 。

|-lock_clust_rec_cons_read_sees 这边就是判断并选择版本的地方 。

让我们看下该函数内部

3.2、read_view的创建过程

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

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

rr_sequential 。

 |-ha_rnd_next 。

  |-rnd_next 。

  |-index_first 在start_of_scan为true时候走当前分支index_first 。

  |-index_read 。

  |-row_search_for_mysql 。

  |-trx_assign_read_view 。

我们看下row_search_for_mysql里的一个分支

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

trx_assign_read_view 。

 |-read_view_open_now 。

  |-read_view_open_now_low 。

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

代码过程为

3.3、行版本可见性

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

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

接上述lock_clust_rec_cons_read_sees的返回

3.4、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记录就又是一个复杂的过程了，由于篇幅原因，在此略过不表.

3.5、read_view创建时机再讨论

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

trx_assign_read_view中由这么一段代码 。

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

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

4、mvcc和锁的同时作用导致的一些现象

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

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

5、总结

mysql为了兼顾性能和acid使用了大量复杂的机制，2pl(两阶段锁)和mvcc就是其实现的典型。幸好可以通过xcode等ide进行方便的debug，这样就可以非常精确加便捷的追踪其各种机制的实现。希望这篇文章能够帮助到喜欢研究mysql源码的读者们.

以上就是详解mysql多版本并发控制机制(mvcc)源码的详细内容，更多关于mysql 并发控制机制 mvcc的资料请关注我其它相关文章！ 。

原文链接：https://www.cnblogs.com/alchemystar/p/13784292.html 。

最后此篇关于详解MySQL多版本并发控制机制(MVCC)源码的文章就讲到这里了,如果你想了解更多关于详解MySQL多版本并发控制机制(MVCC)源码的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。