细说Mysql MVCC多版本控制

本文主要解决问题:

1:MVCC的具体含义
2:mysql 中MVCC 是如何实现的

MVCC 多版本控制 说这个之前先要了解几个东西

一:事务ID
a:mysql 中每个事务会有ID(只有在第一次改动表时分配,否则为0) 被分配的事务id是唯一自增的;
b:mysql 表中每条记录都会有一个trx_id 隐藏列,记录的是当前数据被修改时对应的事务ID(还有个roll_pointer 隐藏列 指向的是它被修改时的undo日志记录,就是上个版本的数据)

二:undo 日志
a:每条记录被修改时都会产生一条undo日志,日志跟记录数据类似就是保存了被修改之前的数据信息,一般只记录被修改的列

b:一个记录被多次修改后,每个版本的undo日志的roll_pointer 会把多次修改的记录串成一个版本链表(简单点说就是每条undo 日志也有roll_pointer 列记录着该记录的上一个undo日志)
这里上个图

三:隔离级别
sql 一共4个隔离级别 读未提交, 读已提交, 可重复读,串行化;
这里读未提交 跟串行化两种隔离级别是直接读最新版本即可,也不存在多版本一说;
所以这里讨论的MVCC 一般指的是 :

对于使用 READ COMMITTED(读已提交)和 REPEATABLE READ(可重复读) 隔离级别的事务来说，都必须保证读到已经提交的事务修改过的记录;就是说假如另一个事务已经修改了记录但是尚未提交，则不能直接读取最新版本的记录.核心问题就是 需要判断版本链中的哪个版本是当前事务可访问的

解决方案:ReadView,可读视图(一致性视图)

这个 ReadView 中主要包含4个比较重要的内容:
• m_ids :在生成ReadView时，当前系统中活跃的读写事务的所有事务 id 列表
• min_trx_id: 在生成 ReadView 时，当前系统中活跃的读写事务中最小的事务 id,也就m_ids 中的最小值.
• max_trx_id : 在生成 ReadView 时，系统应该分配给下一个事务的事务id值(不是m_ids 中的最大值,是下一个)
• creator_trx_id : 生成该 ReadView 的事务 id

查找流程:(以读已提交隔离级别为例)
在访问某条记录时 只需要按照下面的步骤来判断记录的某个版本是否可见.

**1:**获取系统信息生成该记录的readView

**2:**找到此记录的最新版本,并获取的它的 trx_id 值

**3:**判断trx_id 值是否包含在ReadView 的 m_ids中(这里会优先通过creator_trx_id,min_trx_id,max_trx_id 来判断,详细看下面注释)
如果存在则该版本数据不可读,直接从版本链中找到上一个版本继续判断;
如果不存在则表示该版本数据可读,直接返回此版本数据;

//注释
a:如果被访问版本的 trx_id 属性值与 ReadView 中的 creator_trx_id 值相同， 意味着当前事务在访问它自己修改过的记录 ，所以该版本数据可读,直接返回;
b:如果被访问版本的 trx_id 属性值小 ReadView 中的 min_trx_id 值，表明生成该版本的事务在当前事务生成 ReadView 已经提交，所以该版本可以被当前事务访问,直接返回该版本数据;
c:如果被访问版本的 trx_id 属性值大于或等于 ReadView 中的 max_trx_id 表明生成该版本的事务在当前事择生成 ReadView 后才开启，所以该版本不可以被当前事务访问,继续判断trx_id是否包含在在m_ids中;

最后:

对于可重复读隔离级别的实现只需要控制ReadView 的生成时间就可以
在读已提交隔离级别下是每次查询都会生成 ReadView ,而可重复读下只需要事务第一个读时生成 ReadView 即可