MySQL-2 ：MVCC及实现介绍

Mysql到底是怎么实现MVCC的？这个问题无数人都在问，但google中并无答案，本文尝试从Mysql源码中寻找答案。

  在Mysql中MVCC是在Innodb存储引擎中得到支持的，Innodb为每行记录都实现了三个隐藏字段：

• 6字节的事务ID（DB_TRX_ID ）
• 7字节的回滚指针（DB_ROLL_PTR）
• 隐藏的ID

6字节的事物ID用来标识该行所述的事务，7字节的回滚指针需要了解下Innodb的事务模型。

1. Innodb的事务相关概念

为了支持事务，Innbodb引入了下面几个概念：

• redo log
  redo log就是保存执行的SQL语句到一个指定的Log文件，当Mysql执行recovery时重新执行redo log记录的SQL操作即可。当客户端执行每条SQL（更新语句）时，redo log会被首先写入log buffer；当客户端执行COMMIT命令时，log buffer中的内容会被视情况刷新到磁盘。redo log在磁盘上作为一个独立的文件存在，即Innodb的log文件。
• undo log
  与redo log相反，undo log是为回滚而用，具体内容就是copy事务前的数据库内容（行）到undo buffer，在适合的时间把undo buffer中的内容刷新到磁盘。undo buffer与redo buffer一样，也是环形缓冲，但当缓冲满的时候，undo buffer中的内容会也会被刷新到磁盘；与redo log不同的是，磁盘上不存在单独的undo log文件，所有的undo log均存放在主ibd数据文件中（表空间），即使客户端设置了每表一个数据文件也是如此。
• rollback segment
  回滚段这个概念来自Oracle的事物模型，在Innodb中，undo log被划分为多个段，具体某行的undo log就保存在某个段中，称为回滚段。可以认为undo log和回滚段是同一意思。
• 锁
  Innodb提供了基于行的锁，如果行的数量非常大，则在高并发下锁的数量也可能会比较大，据Innodb文档说，Innodb对锁进行了空间有效优化，即使并发量高也不会导致内存耗尽。
  对行的锁有分两种：排他锁、共享锁。共享锁针对对，排他锁针对写，完全等同读写锁的概念。如果某个事务在更新某行（排他锁），则其他事物无论是读还是写本行都必须等待；如果某个事物读某行（共享锁），则其他读的事物无需等待，而写事物则需等待。通过共享锁，保证了多读之间的无等待性，但是锁的应用又依赖Mysql的事务隔离级别。
• 隔离级别
  隔离级别用来限制事务直接的交互程度，目前有几个工业标准：
  - READ_UNCOMMITTED：脏读
  - READ_COMMITTED：读提交
  - REPEATABLE_READ：重复读
  - SERIALIZABLE：串行化
  Innodb对四种类型都支持，脏读和串行化应用场景不多，读提交、重复读用的比较广泛，后面会介绍其实现方式。

2. 行的更新过程

下面演示下事务对某行记录的更新过程：

1. 初始数据行

F1～F6是某行列的名字，1～6是其对应的数据。后面三个隐含字段分别对应该行的事务号和回滚指针，假如这条数据是刚INSERT的，可以认为ID为1，其他两个字段为空。

2.事务1更改该行的各字段的值

当事务1更改该行的值时，会进行如下操作：

• 用排他锁锁定该行
• 记录redo log
• 把该行修改前的值Copy到undo log，即上图中下面的行
• 修改当前行的值，填写事务编号，使回滚指针指向undo log中的修改前的行

3.事务2修改该行的值

与事务1相同，此时undo log，中有有两行记录，并且通过回滚指针连在一起。

因此，如果undo log一直不删除，则会通过当前记录的回滚指针回溯到该行创建时的初始内容，所幸的时在Innodb中存在purge线程，它会查询那些比现在最老的活动事务还早的undo log，并删除它们，从而保证undo log文件不至于无限增长。

4. 事务提交

当事务正常提交时Innbod只需要更改事务状态为COMMIT即可，不需做其他额外的工作，而Rollback则稍微复杂点，需要根据当前回滚指针从undo log中找出事务修改前的版本，并恢复。如果事务影响的行非常多，回滚则可能会变的效率不高，根据经验值没事务行数在1000～10000之间，Innodb效率还是非常高的。很显然，Innodb是一个COMMIT效率比Rollback高的存储引擎。据说，Postgress的实现恰好与此相反。

5. Insert Undo log

上述过程确切地说是描述了UPDATE的事务过程，其实undo log分insert和update undo log，因为insert时，原始的数据并不存在，所以回滚时把insert undo log丢弃即可，而update undo log则必须遵守上述过程。

3. 事务级别

众所周知地是更新（update、insert、delete）是一个事务过程，在Innodb中，查询也是一个事务，只读事务。当读写事务并发访问同一行数据时，能读到什么样的内容则依赖事务级别：

• READ_UNCOMMITTED
  读未提交时，读事务直接读取主记录，无论更新事务是否完成
• READ_COMMITTED
  读提交时，读事务每次都读取undo log中最近的版本，因此两次对同一字段的读可能读到不同的数据（幻读），但能保证每次都读到最新的数据。
• REPEATABLE_READ
  每次都读取指定的版本，这样保证不会产生幻读，但可能读不到最新的数据
• SERIALIZABLE
  锁表，读写相互阻塞，使用较少

读事务一般有SELECT语句触发，在Innodb中保证其非阻塞，但带FOR UPDATE的SELECT除外，带FOR UPDATE的SELECT会对行加排他锁，等待更新事务完成后读取其最新内容。就整个Innodb的设计目标来说，就是提供高效的、非阻塞的查询操作。

4. MVCC

上述更新前建立undo log，根据各种策略读取时非阻塞就是MVCC，undo log中的行就是MVCC中的多版本，这个可能与我们所理解的MVCC有较大的出入，一般我们认为MVCC有下面几个特点：

• 每行数据都存在一个版本，每次数据更新时都更新该版本
• 修改时Copy出当前版本随意修改，个事务之间无干扰
• 保存时比较版本号，如果成功（commit），则覆盖原记录；失败则放弃copy（rollback）

就是每行都有版本号，保存时根据版本号决定是否成功，听起来含有乐观锁的味道。。。，而Innodb的实现方式是：

• 事务以排他锁的形式修改原始数据
• 把修改前的数据存放于undo log，通过回滚指针与主数据关联
• 修改成功（commit）啥都不做，失败则恢复undo log中的数据（rollback）

二者最本质的区别是，当修改数据时是否要排他锁定，如果锁定了还算不算是MVCC？ 

Innodb的实现真算不上MVCC，因为并没有实现核心的多版本共存，undo log中的内容只是串行化的结果，记录了多个事务的过程，不属于多版本共存。但理想的MVCC是难以实现的，当事务仅修改一行记录使用理想的MVCC模式是没有问题的，可以通过比较版本号进行回滚；但当事务影响到多行数据时，理想的MVCC据无能为力了。

比如，如果Transaciton1执行理想的MVCC，修改Row1成功，而修改Row2失败，此时需要回滚Row1，但因为Row1没有被锁定，其数据可能又被Transaction2所修改，如果此时回滚Row1的内容，则会破坏Transaction2的修改结果，导致Transaction2违反ACID。

理想MVCC难以实现的根本原因在于企图通过乐观锁代替二段提交。修改两行数据，但为了保证其一致性，与修改两个分布式系统中的数据并无区别，而二提交是目前这种场景保证一致性的唯一手段。二段提交的本质是锁定，乐观锁的本质是消除锁定，二者矛盾，故理想的MVCC难以真正在实际中被应用，Innodb只是借了MVCC这个名字，提供了读的非阻塞而已。

5.总结

也不是说MVCC就无处可用，对一些一致性要求不高的场景和对单一数据的操作的场景还是可以发挥作用的，比如多个事务同时更改用户在线数，如果某个事务更新失败则重新计算后重试，直至成功。这样使用MVCC会极大地提高并发数，并消除线程锁。

6. 参考资料

• Mysql官网
• http://blog.chinaunix.net/link.php?url=http://forge.mysql.com%2Fwiki%2FMySQL_Internals
• Understanding MySQL Internals

三个隐藏字段：

1、DB_TRX_ID：一个6byte的标识，每处理一个事务，其值自动+1，上述说到的“创建时间”和“删除时间”记录的就是这个DB_TRX_ID的值，如insert、update、delete操作时，删除操作用1个bit表示。 DB_TRX_ID是最重要的一个，可以通过语句“show engine innodb status”来查找，如下：

   -----------------------------------------

   ……

      TRANSACTIONS

------------

Trx id counter 0 430621

Purge done for trx's n:o < 0 430136 undo n:o < 0 0

History list length 7

……

   ------------------------------------------

2、DB_ROLL_PTR: 大小是7byte,指向写到rollback segment（回滚段）的一条undo log记录（update操作的话，记录update前的ROW值）

3、DB_ROW_ID: 大小是6byte,该值随新行插入单调增加，当由innodb自动产生聚集索引时，聚集索引包括这个DB_ROW_ID的值，不然的话聚集索引中不包括这个值. 这个用于索引当中

深入MVCC实现机制

1、到这里很多人就会发现，如果确实根据creat_num 即时事务DB_TRX_ID去比较获取事务的话，按道理在一个事务B（比A后，但A还没commit）select的话B. DB_TRX_ID>A.DB_TRX_ID则应该能返回A事务对数据的操作以及修改。那不是和前面矛盾？其实不然，只是前面没有讲到以下内容。

InnoDB每个事务在开始的时候，会将当前系统中的活跃事务列表（trx_sys->trx_list）创建一个副本（read view），然后一致性读去比较记录的tx id的时候，并不是根据当前事务的tx id，而是根据read view最早一个事务的tx id（read view->up_limit_id）来做比较的，这样就能确保在事务B之前没有提交的所有事务的变更，B事务都是看不到的。当然，这里还有个小问题要处理一下，就是当前事务自身的变更还是需要看到的。

storage/innobase/include/read0read.h 如下

及storage/innobase/read/read0read.c    read_view_open_now()

storage/innobase/include/read0read.ic   read_view_sees_trx_id()

 

在storage/innobase/read/read0read.c中实现了创建read view的函数read_view_open_now，在storage/innobase/include/read0read.ic中实现了判断一致性读是否可见的read_view_sees_trx_id

代码：

1. read_view_t*  
2. read_view_open_now(  
3.   
4.          trx_id_t    cr_trx_id,            
5.          mem_heap_t*          heap)                   
6. {  
7.          read_view_t*  view;  
8.          trx_t*                trx;  
9.          ulint          n;  
10.          ut_ad(mutex_own(&kernel_mutex));  
11.          view = read_view_create_low(UT_LIST_GET_LEN(trx_sys->trx_list), heap);  
12.          view->creator_trx_id = cr_trx_id;  
13.          view->type = VIEW_NORMAL;  
14.          view->undo_no = 0;  
15.            
16.          view->low_limit_no = trx_sys->max_trx_id;  
17.          view->low_limit_id = view->low_limit_no;  
18.          n = 0;  
19.          trx = UT_LIST_GET_FIRST(trx_sys->trx_list);  
20.            
21.          while (trx) {  
22.                    if (trx->id != cr_trx_id  
23.                        && (trx->conc_state == TRX_ACTIVE  
24.                             || trx->conc_state == TRX_PREPARED)) {  
25.                             read_view_set_nth_trx_id(view, n, trx->id);  
26.                            n++;  
27.                               
28.                             if (view->low_limit_no > trx->no) {  
29.                                      view->low_limit_no = trx->no;  
30.                             }  
31.                    }  
32.                    trx = UT_LIST_GET_NEXT(trx_list, trx);  
33.          }  
34.          view->n_trx_ids = n;  
35.          if (n > 0) {  
36.                      
37.                    view->up_limit_id = read_view_get_nth_trx_id(view, n - 1);  
38.          } else {  
39.                    view->up_limit_id = view->low_limit_id;  
40.          }  
41.          UT_LIST_ADD_FIRST(view_list, trx_sys->view_list, view);  
42.          return(view);  
43.   
44. }  

 

2、MVCC如何控制update操作

前面说先复制新数据，并插入DB_TRX_ID的值，在把旧数据的删除标志DB_TRX_ID

现在先介绍几个概念：

DB_ROLL_PTR是指向回滚段中旧版本7byte回滚指针。

redo log：重做日志，就是每次mysql在执行写入数据前先把要写的信息保存在重写日志中，但出现断电，奔溃，重启等等导致数据不能正常写入期望数据时，服务器可以通过redo_log中的信息重新写入数据。

undo log：撤销日志，与redo log恰恰相反，当一些更改在执行一半时，发生意外，而无法完成，则可以根据撤消日志恢复到更改之前的壮态。

mvcc中update步骤：

1、 记录事务中修改行数据的相应字段和值（包括旧版本事务id）在undo-log中记录。

2、 修改相应数据。

3、 在redo-log中保存要修改的相应（新版本事务id）数据写入

4、 假如update不能正常运行怎根据undo-log redo-log 来回复

5、 当然如果当前版本事务没有commit的话则通过undo-log信息恢复原始数据状态

• innodb可见性判断

到这里我们也就不难看出实际实现就是这两个数据结构进行比较：

InnoDB每个事务在开始的时候，会将当前系统中的活跃事务列表（trx_sys->trx_list）创建一个副本（read view）在read_vied_sees_trx_id方法里我们有如下比较：

low_limit_id 是“高水位”即当时活跃事务的最大id，如果读到row的db_tx_id>=low_limit_id，说明这些id在此之前的数据都没有提交，如注释中的描述，这些数据都不可见。

if (trx_id >= view->low_limit_id) {

return(FALSE); 
}

up_limit_id 是“低水位”即当时活跃事务列表的最小事务id，如果row的db_tx_id

if (trx_id < view->up_limit_id) {

return(TRUE); 
}

在两个limit_id之间的我们需要从小到大逐个比较一下：

n_ids = view->n_trx_ids;

for (i = 0; i < n_ids; i++) { 
trx_id_t        view_trx_id 
= read_view_get_nth_trx_id(view, n_ids – i – 1);

if (trx_id <= view_trx_id) { 
return(trx_id != view_trx_id); 
} 
}

这样我们在要在事务中获取100行数据，我们就能根据这100行的row db_tx_id即本事务的read_view来判断此版本的数据在事务中是否可见。

如果数据不可见我们需要去哪里找上版本的数据呢？就是通过刚才提到过的7BIT的DATA_ROLL_PTR去undo信息中寻找，同时再判断下这个版本的数据是否可见，以此类推。

 

• innodb更新

更新这个大家一般都比较熟悉，我这里简单表述一下，如一个测试表：

create table test (key int primary key,value varchar(10));

insert

InnoDB为每个新增行记录，如insert into test value(’1′,’aaa’), 会创建新的row，row db_tx_id即为当前系统版本号作为创建ID。

update

如update test set value=’bbb’  where key =’bbb’，InnoDB会复制了一行，这个新行的版本号使用了本次db_tx_id更新的版本号。它也把之前版本号作为了删除行的版本，即把原有row delete bit置为删除，不可见。

delete

InnoDB为每个删除行的记录当前系统版本号作为行的删除ID,也就是说把之前说的BIT位置成不可见的。

多版本并发控制（Multiversion Concurrency Controll MVCC）

第一点：

MVCC并不是MySql独有的，Oracle，PostgreSQL等都在使用。

MVCC并没有简单地使用行锁，而是使用“行级别锁”（row-level locking）。

MVCC的基本原理是：

MVCC的实现，通过保存数据在某个时间点的快照来实现的。这意味着一个事务无论运行多长时间，在同一个事务里能够看到数据一致的视图。根据事务开始的时间不同，同时也意味着在同一个时刻不同事务看到的相同表里的数据可能是不同的。

MVCC的基本特征：

• 每行数据都存在一个版本，每次数据更新时都更新该版本。
• 修改时Copy出当前版本随意修改，各个事务之间无干扰。
• 保存时比较版本号，如果成功（commit），则覆盖原记录；失败则放弃copy（rollback）

InnoDB存储引擎MVCC的实现策略：

在每一行数据中额外保存两个隐藏的列：当前行创建时的版本号和删除时的版本号（可能为空）。这里的版本号并不是实际的时间值，而是系统版本号。每开始 个新的事务，系统版本号都会自动递增。事务开始时刻的系统版本号会作为事务的版本号，用来和查询每行记录的版本号进行比较。

每个事务又有自己的版本号，这样事务内执行CRUD操作时，就通过版本号的比较来达到数据版本控制的目的。具体做法见下面的示意图。

　　

 MVCC具体的操作如下：

SELECT:InnoDB会根据以下两个条件检查每行记录：

1）InnoDB只查找版本早于当前事务版本的数据行（也就是，行的系统版本号小于或等于事务的系统版本号），这样可以确保事务读取的行，只么是在事务开始前已经存在的，要么是事务自身插入或者修改过的。

2）行的删除版本要么未定义，要么大于当前事务版本号。这可以确保事务读取到的行，在事务开始之前未被删除。

INSERT:InnoDB为新插入的每一行保存当前系统版本号作为行版本号。

DELETE:InnoDB为删除的每一行保存当前系统版本号作为行删除标识。

UPDATE:InnoDB为插入一行新记录，保存当前系统版本号作为行版本号，同时保存当系统的版本号为原来的行作为删除标识。

保存这两个额外系统版本号，使大多数操作都可以不用加锁。这样设计使得计数据操作很简单，性能很好，并且也能保证只会读取到符合标准的行。不足之处是每行记录都需要额外的存储空间，需要做更多的行检查工作，以及一些额外的维护工作。

MVCC只在REPEATABLE READ和READ COMMITED两个隔离级别下工作，其它两个隔离级别和MVCC不兼容。

Innodb的实现算不上MVCC，因为并没有实现核心的多版本共存，undo log中的内容只是串行化的结果，记录了多个事务的过程，不属于多版本共存。但理想的MVCC是难以实现的，当事务仅修改一行记录使用理想的MVCC模式是没有问题的，可以通过比较版本号进行回滚；但当事务影响到多行数据时，理想的MVCC据无能为力了。

比如，如果Transaciton1执行理想的MVCC，修改Row1成功，而修改Row2失败，此时需要回滚Row1，但因为Row1没有被锁定，其数据可能又被Transaction2所修改，如果此时回滚Row1的内容，则会破坏Transaction2的修改结果，导致Transaction2违反ACID。

 

理想MVCC难以实现的根本原因在于企图通过乐观锁代替二段提交。修改两行数据，但为了保证其一致性，与修改两个分布式系统中的数据并无区别，而二段提交是目前这种场景保证一致性的唯一手段。二段提交的本质是锁定，乐观锁的本质是消除锁定，二者矛盾，故理想的MVCC难以真正在实际中被应用，Innodb只是借了MVCC这个名字，提供了读的非阻塞而已。

转自：

 http://blog.csdn.net/chen77716/article/details/6742128

http://www.tuicool.com/articles/UvIN32

http://blog.sina.com.cn/s/blog_711b11fd0101bhks.html

http://blog.csdn.net/xifeijian/article/details/45230053