共计 2575 个字符，预计需要花费 7 分钟才能阅读完成。
本篇内容主要讲解“MySQL 多版本并发控制机制源码分析”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让丸趣 TV 小编来带大家学习“MySQL 多版本并发控制机制源码分析”吧!
MVCC(多版本并发控制机制)
隔离性也可以被称作并发控制、可串行化等。谈到并发控制首先想到的就是锁，MySQL 通过使用两阶段锁的方式实现了更新的可串行化，同时为了加速查询性能，采用了 MVCC(Multi Version Concurrency Control)的机制，使得不用锁也可以获取一致性的版本。
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 的一致性版本就有很大的优势了。
MVCC(实现机制)
本节就开始谈谈 MVCC 的实现机制, 注意 MVCC 仅仅在纯 select 时有效(不包括 select for update,lock in share mode 等加锁操作, 以及 updateinsert 等)。
select 运行栈
首先我们追踪一下一条普通的查询 sql 在 mysql 源码中的运行过程,sql 为(select * from test);
其运行栈为:
由于 mysql 默认隔离级别是 repeatable_read(RR), 所以 read_record 重载为 rr_sequential(当前我们并不关心 select 通过 index 扫描出 row 之后再通过 condition 过滤的过程)。继续追踪:
让我们看下该函数内部:
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 结构:
然后通过 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 多版本并发控制机制源码分析”有了更深的了解，不妨来实际操作一番吧！这里是丸趣 TV 网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
