(三) Mysql 之MVCC

mvcc介绍

MVCC是数据库提供并发访问控制的一种技术。其核心理念是数据快照，不同的事务访问不同版本的数据快照，从而实现不同的事务隔离级别。虽然是说具有多个版本的数据快照，但这并不意味着数据库必须拷贝数据，保存多份数据文件，这样会浪费大量的存储空间。mysql的InnoDB通过事务的undo日志巧妙地实现了多版本的数据快照。与基于锁的并发控制 Lock-Based Concurrency Control （LBCC）相比，MVCC最大的好处：读不加锁，读写不冲突。

InnoDB的MVCC是通过在每行记录后面保存两个隐藏的列来实现的。这两个列，一个保存了行的事务ID，一个保存了行的回滚指针。每开始一个新的事务，都会自动递增产生一个新的事务id。

MVCC只在REPEATABLE READ和READ COMMITIED两个隔离级别下工作。其他两个隔离级别都和MVCC不兼容 ，因为READ UNCOMMITIED总是读取最新的数据行，而不是符合当前事务版本的数据行。而SERIALIZABLE则会对所有读取的行都加锁。

MVCC 在mysql 中的实现依赖的是undo log与read view。

undo log

为了更好的支持并发，InnoDB的多版本一致性读是采用了基于回滚段的的方式。另外，对于更新和删除操作，InnoDB并不是真正的删除原来的记录，而是设置记录的delete mark为1。因此为了解决数据Page和Undo Log膨胀的问题，需要引入purge机制进行回收。Undo log保存了记录修改前的镜像。在InnoDB存储引擎中，undo log分为：insert undo log 与 update undo log。

insert undo log是指在insert操作中产生的undo log。由于insert操作的记录，只是对本事务可见，其他事务不可见，所以undo log可以在事务提交后直接删除，而不需要purge。
update undo log是指在delete和update操作中产生的undo log。该undo log会被后续用于MVCC当中，因此不能提交的时候删除。提交后会放入undo log的链表，等待purge线程进行最后的删除。

如下图所示（第一次修改）：
当事务2使用UPDATE语句修改该行数据时，会首先使用排他锁锁定该行，将该行当前的值复制到undo log中，然后再真正地修改当前行的值，最后填写事务ID，使用回滚指针指向undo log中修改前的行。

 ReadView

对于使用 READ UNCOMMITTED 隔离级别的事务来说，直接读取记录的最新版本就好了。对于使用SERIALIZABLE 隔离级别的事务来说，使用加锁的方式来访问记录。对于使用 READ COMMITTED 和REPEATABLE READ 隔离级别的事务来说，就需要用到我们上边所说的 版本链 了。核心问题就是需要判断一下版本链中的哪个版本是当前事务可见的。所以设计 InnoDB 的设计者提出了一个ReadView的概念，这个 ReadView 中主要包含当前系统中还有哪些活跃的读写事务，把它们的事务id放到一个列表中，我们把这个列表命名为m_ids，并确定三个变量的值：

m_up_limit_id：m_ids事务列表中的最小事务id，如果当前列表为空那么就等于m_low_limit_id。事务id的下限。

m_low_limit_id：系统中将要产生的下一个事务id的值。事务id的上限。

m_creator_trx_id：当前事务id，m_ids中不包含当前事务id

这样在访问某条记录时，只需要按照下边的步骤判断记录的某个版本（版本链中的版本）是否可见：
1）如果被访问版本的 trx_id 属性值小于 m_up_limit_id ，表明生成该版本的事务在生成 ReadView前已经提交，所以该版本可以被当前事务访问。
2）如果被访问版本的 trx_id 属性值等于 m_creator_trx_id 既当前事务id，可以被访问。
3）如果被访问版本的 trx_id 属性值大于等于 m_low_limit_id ，在生成 ReadView 后才生成，所以该版本不可以被当前事务访问。
4）如果被访问版本的 trx_id 属性值在 m_up_limit_id 和 m_low_limit_id 之间，那就需要判断一下 trx_id 属性值是不是在 m_ids 列表中。
如果在，说明创建 ReadView 时生成该版本的事务还是活跃的，该版本不可以被访问；
如果不在，说明创建 ReadView 时生成该版本的事务已经被提交，该版本可以被访问

在 MySQL 中， READ COMMITTED 和 REPEATABLE READ 隔离级别的的一个非常大的区别就是它们生成ReadView 的时机不同，如下。
1.READ COMMITTED

每次读取数据前都生成一个ReadView

数据库中的记录是id为1，c为刘备，该行记录的版本是80
# Transaction 100
BEGIN;
UPDATE t SET c = '关羽' WHERE id = 1;
UPDATE t SET c = '张飞' WHERE id = 1;
select c from t where id =1时
在执行SELECT语句时会先生成一个 ReadView，ReadView 的 m_ids 列表的内容就是 [100]
然后从版本链中挑选可见的记录，最新版本的列 c 的内容是 '张飞' ，该版本的trx_id值为100，
在 m_ids 列表内，所以不符合可见性要求，根据 roll_pointer 跳到下一个版本。
下一个版本的列 c 的内容是 '关羽' ，该版本的 trx_id 值也为 100 ，也在m_ids 列表内，所以也
不符合要求，继续跳到下一个版本。
下一个版本的列c的内容是'刘备'，该版本的trx_id值为80，小于m_ids列表中最小的事务id 100，
所以这个版本是符合要求的，最后返回给用户的版本就是这条列c为'刘备'的记录。

# Transaction 200
BEGIN;
UPDATE t SET c = '赵云' WHERE id = 1;
UPDATE t SET c = '诸葛亮' WHERE id = 1;

执行如下操作：
select c from t where id =1时
在执行SELECT语句时会先生成一个 ReadView，ReadView 的 m_ids 列表的内容就是 [100，200]，查找的结果仍然为刘备
此时可以看出，Transaction 100与200没有提交时，查询的结果仍然是刘备的，这就达到了RC隔离级别下的mvcc控制的效果

Transaction 100 事务提交
select c from t where id =1时
在执行SELECT语句时会重新生成一个 ReadView，ReadView 的 m_ids 列表的内容是 [200]，查找的结果为张飞。事务1提交了，才查询到了最新的记录。

2.READ REPEATABLE

在事务开始后第一次读取数据时生成一个ReadVie
数据库中的记录是id为1，c为刘备，该行记录的版本是80
# Transaction 100
BEGIN;
UPDATE t SET c = '关羽' WHERE id = 1;
UPDATE t SET c = '张飞' WHERE id = 1;
select c from t where id =1时
在执行SELECT语句时会先生成一个 ReadView，ReadView 的m_ids列表的内容是 [100]
然后从版本链中挑选可见的记录，最新版本的列c的内容是'张飞'，该版本的trx_id值为100，
在m_ids列表内，所以不符合可见性要求，根据 roll_pointer 跳到下一个版本。
下一个版本的列c的内容是'关羽' ，该版本的trx_id值也为100，也在m_ids 列表内，所以也
不符合要求，继续跳到下一个版本。
下一个版本的列c的内容是'刘备'，该版本的trx_id值为80，小于m_ids列表中最小的事务id 100，
所以这个版本是符合要求的，最后返回给用户的版本就是这条列c为'刘备'的记录。

# Transaction 200
BEGIN;
UPDATE t SET c = '赵云' WHERE id = 1;
UPDATE t SET c = '诸葛亮' WHERE id = 1;

执行如下操作：
select c from t where id =1时
在执行SELECT语句时会第一次产生的ReadView 的 m_ids列表的内容就是[100]，查找的结果仍然为刘备

Transaction 100 事务提交，
select c from t where id =1时
之前的ReadView的m_ids 列表的内容仍然是[100]，查找的结果仍然为刘备，
这就可以看出，Transaction 100第一次查询时，在READ REPEATABLE隔离级别下，产生的ReadView的m_ids列表的内容是[100]，尽管
之后Transaction 100 事务提交了，但是ReadView的m_ids列表没变，所以查询的结果仍然为刘备，达到了可重复读的效果。

 

每次读取数据前都生成一个ReadView