MySQL多版本并发控制机制(MVCC)-源码浅析

时间  2019-11-11
标签 mysql 版本 并发 控制 机制 mvcc 源码 浅析 栏目 MySQL 繁體版
原文   原文链接

MySQL多版本并发控制机制(MVCC)-源码浅析

前言

做为一个数据库爱好者，本身动手写过简单的SQL解析器以及存储引擎，但感受仍是不够过瘾。<<事务处理-概念与技术>>诚然讲的很是透彻，但只能提纲挈领，不能让你玩转某个真正的数据库。感谢cmake,可以让我在mac上用xcode去debug MySQL,从而能去领略它的各类实现细节。
笔者一直对数据库的隔离性很好奇，此篇博客就是我debug MySQL过程当中的偶有所得。
(注:本文的MySQL采用的是MySQL-5.6.35版本)mysql

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

隔离性也能够被称做并发控制、可串行化等。谈到并发控制首先想到的就是锁，MySQL经过使用两阶段锁的方式实现了更新的可串行化，同时为了加速查询性能，采用了MVCC(Multi Version Concurrency Control)的机制，使得不用锁也能够获取一致性的版本。sql

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。数据库

Read Commit

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

在这种状况下，就须要使用锁机制(例如select for update)将此A,B记录锁住，从而得到正确的一致结果,以下图所示：
数组

MVCC的优点

当咱们要对一些数据作一些只读操做来检查一致性，例如检查帐务是否对齐的操做时候，并不但愿加上对性能损耗很大的锁。这时候MVCC的一致性版本就有很大的优点了。xcode

MVCC(实现机制)

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

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 这边就是判断并选择版本的地方

让咱们看下该函数内部:性能

bool lock_clust_rec_cons_read_sees(const rec_t* rec /*由innodb扫描出来的一行*/,....){
	...
	// 从当前扫描的行中获取其最后修改的版本trx_id(事务id)
	trx_id = row_get_rec_trx_id(rec, index, offsets);
	// 经过参数(一致性快照视图和事务id)决定看到的行快照
	return(read_view_sees_trx_id(view, trx_id));
}

read_view的建立过程

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

struct read_view_t{
	// 因为是逆序排列，因此low/up有所颠倒
	// 能看到当前行版本的高水位标识,>= low_limit_id皆不能看见
	trx_id_t	low_limit_id;
	// 能看到当前行版本的低水位标识,< up_limit_id皆能看见
	trx_id_t	up_limit_id;
	// 当前活跃事务(即未提交的事务)的数量
	ulint		n_trx_ids;
	// 以逆序排列的当前获取活跃事务id的数组
	// 其up_limit_id<tx_id<low_limit_id
	trx_id_t*	trx_ids;	
	// 建立当前视图的事务id
	trx_id_t	creator_trx_id;
	// 事务系统中的一致性视图链表
	UT_LIST_NODE_T(read_view_t) view_list;
};

而后经过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里的一个分支:

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函数:

trx_assign_read_view
 |-read_view_open_now
 	|-read_view_open_now_low

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

代码过程为:

static read_view_t* read_view_open_now_low(trx_id_t	cr_trx_id,mem_heap_t*	heap)
{
	read_view_t*	view;
	// 当前事务系统中max_trx_id(即还没有被分配的trx_id)设置为low_limit_no
	view->low_limit_no = trx_sys->max_trx_id;
	view->low_limit_id = view->low_limit_no;
	// CreateView构造函数，会将非当前事务和已经在内存中提交的事务给剔除，即判断条件为
	// trx->id != m_view->creator_trx_id&& !trx_state_eq(trx, TRX_STATE_COMMITTED_IN_MEMORY)的
	// 才加入当前视图列表
	ut_list_map(trx_sys->rw_trx_list, &trx_t::trx_list, CreateView(view));
	if (view->n_trx_ids > 0) {
		// 将当前事务系统中的最小id设置为up_limit_id,由于是逆序排列
		view->up_limit_id = view->trx_ids[view->n_trx_ids - 1];
	} else {
		// 若是当前没有非当前事务以外的活跃事务，则设置为low_limit_id
		view->up_limit_id = view->low_limit_id;
	}
	// 忽略purge事务，purge时，当前事务id是0
	if (cr_trx_id > 0) {
		read_view_add(view);
	}
	// 返回一致性视图
	return(view);
}

行版本可见性:

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

/*********************************************************************//**
Checks if a read view sees the specified transaction.
@return	true if sees */
UNIV_INLINE
bool
read_view_sees_trx_id(
/*==================*/
	const read_view_t*	view,	/*!< in: read view */
	trx_id_t		trx_id)	/*!< in: trx id */
{
	if (trx_id < view->up_limit_id) {

		return(true);
	} else if (trx_id >= view->low_limit_id) {

		return(false);
	} else {
		ulint	lower = 0;
		ulint	upper = view->n_trx_ids - 1;

		ut_a(view->n_trx_ids > 0);

		do {
			ulint		mid	= (lower + upper) >> 1;
			trx_id_t	mid_id	= view->trx_ids[mid];

			if (mid_id == trx_id) {
				return(FALSE);
			} else if (mid_id < trx_id) {
				if (mid > 0) {
					upper = mid - 1;
				} else {
					break;
				}
			} else {
				lower = mid + 1;
			}
		} while (lower <= upper);
	}

	return(true);
}

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


接上述lock_clust_rec_cons_read_sees的返回:

if (UNIV_LIKELY(srv_force_recovery < 5)
			    && !lock_clust_rec_cons_read_sees(
				    rec, index, offsets, trx->read_view)){
	// 当前处理的是当前版本不可见的状况
	// 经过undolog来返回到一致的可见版本
	err = row_sel_build_prev_vers_for_mysql(
					trx->read_view, clust_index,
					prebuilt, rec, &offsets, &heap,
					&old_vers, &mtr);			    
} else{
	// 可见，而后返回
}

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方法返回可见版本:

dberr_t row_vers_build_for_consistent_read(...)
{
	......
	for(;;){
		err = trx_undo_prev_version_build(rec, mtr,version,index,*offsets, heap,&prev_version);
		......
		trx_id = row_get_rec_trx_id(prev_version, index, *offsets);
		// 若是当前row版本符合一致性视图，则返回
		if (read_view_sees_trx_id(view, trx_id)) {
			......
			break;
		}
		// 若是当前row版本不符合，则继续回溯上一个版本(回到for循环的地方)
		version = prev_version;
	}
	......
}

整个过程以下图所示:

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

read_view建立时机再讨论

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

// 只有非锁模式的select才建立一致性视图
else if (prebuilt->select_lock_type == LOCK_NONE) {		// 建立一致性视图
		trx_assign_read_view(trx);
		prebuilt->sql_stat_start = FALSE;
}

trx_assign_read_view中由这么一段代码

// 一致性视图在一个事务只建立一次
if (!trx->read_view) {
		trx->read_view = read_view_open_now(
			trx->id, trx->global_read_view_heap);
		trx->global_read_view = trx->read_view;
	}

因此综合这两段代码，即在一个事务中，只有第一次运行select(不加锁)的时候才会建立一致性视图,以下图所示:
笔者构造了此种场景模拟过，确实如此。

MVCC和锁的同时做用致使的一些现象

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

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

总结

MySQL为了兼顾性能和ACID使用了大量复杂的机制，2PL(两阶段锁)和MVCC就是其实现的典型。幸亏能够经过xcode等IDE进行方便的debug，这样就能够很是精确加便捷的追踪其各类机制的实现。但愿这篇文章可以帮助到喜欢研究MySQL源码的读者们。

原文连接

https://my.oschina.net/alchemystar/blog/1927425

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程