vlambda博客
学习文章列表

扫码二维码

获取更多精彩

1  MVCC概述

事务隔离级别怎么实现的呢？

MySQL InnoDB存储引擎的事务隔离级别主要是MVCC（MVCC,Multiversion Currency Control）实现的。

多版本控制: 指的是一种提高并发的技术。最早的数据库系统，只有读读之间可以并发，读写，写读，写写都要阻塞。引入多版本控制之后，只有写写之间相互阻塞，其他三种操作都可以并行，这样大幅度提高了InnoDB的并发度。在内部实现中，与Postgres在数据行上实现多版本不同，InnoDB是在undolog中实现的，通过undolog可以找回数据的历史版本。找回的数据历史版本可以提供给用户读(按照隔离级别的定义，有些读请求只能看到比较老的数据版本)，也可以在回滚的时候覆盖数据页上的数据。在InnoDB内部中，会记录一个全局的活跃读写事务数组，其主要用来判断事务的可见性。

事务

实现

MVCC概述

1. MySQL的大多数事务型存储引擎实现的其实都不是简单的行级锁。基于提升并发性能的考虑, 它们一般都同时实现了多版本并发控制(MVCC)。不仅是MySQL, 包括Oracle,PostgreSQL等其他数据库系统也都实现了MVCC, 但各自的实现机制不尽相同, 因为MVCC没有一个统一的实现标准。

2. 可以将MVCC看成是行级锁的一个变种, 但是它在很多情况下避免了加锁操作, 因此开销更低。虽然实现机制有所不同, 但大都实现了非阻塞的读操作，写操作也只锁定必要的行。

3. MVCC的实现方式有多种, 典型的有乐观(optimistic)并发控制 和 悲观(pessimistic)并发控制。

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

• MVCC是被MySQL中事务型存储引擎InnoDB 所支持的

• 应对高并发事务, MVCC比单纯的加锁更高效

• MVCC只在READ COMMITTED和REPEATABLE READ两个隔离级别下工作

• MVCC可以使用 乐观(optimistic)锁 和 悲观(pessimistic)锁来实现

• 各数据库中MVCC实现并不统一

• InnoDB的MVCC是通过在每行记录后面保存3个隐藏的列来实现的

2  相关概念介绍

3  案例分析

创建数据表t，用于做案例分析。

CREATE TABLE `t` ( `id` int(11) NOT NULL, `k` varchar(32) DEFAULT NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB;
insert into t(id, k) values(1, 1);

插入数据后，数据的初始状态如下图所示。

设置隔离级别为MySQL默认的隔离级别——Repeatable Read。

分别开启4个事务用于实验。

上图中第 8，10，12，13 行，

查询的结果分别是什么呢？

结果应该分别是：2，1，3，1 ~

下面我们来逐步回放，MySQL 底层是如何实现这整个过程的。

• 第 5 行为修改 k 的值，自增 1，按照上面所说的规则，修改后数据的状态如下：

• 第 6 行，提交 ID 为 102 的事务。

• 第 7 行执行了一个简单查询，未手动开启事务，但也会自动开启并生成 read view 及 max id，分别为 read-view: [100, 101] ，max-id: 103

  此时会根据查询规则，进行查找，规则如下：

  1. 如果数据的 db_trx_id < min id ，则说明数据在开启当前事务前已提交的，内容可见。

  2. 如果数据的 db_trx_id > max id ，则说明数据在此事务启动后生成的，内容不可见。

  3. 如果数据的 min id <= db_trx_id <= max id ，则还分为两种情况：

      3.1 若 db_trx_id 在 read view 的数组中，表示这个版本是由还没提交的事务生成的，不可见，但如果是自己的事务，则可见。

      3.2. 若不在数据中，则表示这个版本是已经提交了的事务生成的，可见。

  示意图如下

  
  

  

  当前的事务的一致性视图为 read view: [100, 101] ，max id: 103，那么根据这个规则，在上面的数据链中查询数据，从最新的蓝色，开始找，找到第一个数据的 db_trx_id 为 102，符合规则 3.2 属于可见范围，查询结果为 2。

  
  

• 第 8 行，当前的事务的一致性视图为 read view: [100, 101] ，max id: 101。同样根据规则，第一个数据的 db_trx_id 为 102，符合规则 2，不可见，那么根据指针 db_roll_pt 继续查找，找到 db_trx_id 为 10 的数据，符合规则 1，数据可见，查询结果为 1。

• 第 9 行，修改 k 的值，自增 1，按照上面所说的规则，修改后：
  

• 第 10 行，当前的事务的一致性视图为 read view: [100] ，max id: 100 同样根据规则，第一个数据的 db_trx_id 为 100，符合规则 3.1，在 read view 数组中，但是此 id 为当前事务 id，所以可是可见的，查询结果为 3。

  
  

• 第 11 行，当前的事务的一致性视图为 read view: [100, 101] ，max id: 101 同样根据规则，第一个数据的 db_trx_id 为 100，符合规则 3.1，在 read view 中，但是此 id 不为当前事务 id，所以内容不可见的，那么根据指针 db_roll_pt 继续查找，找到 db_trx_id 为 102 的数据，符合规则 2，不可见，继续根据指针 db_roll_pt 查找，找到 db_trx_id 为 10 的数据，符合规则 1，数据可见，查询结果为 1。

• 第 12 - 13 行，为提交事务语句。

处于 Read Committed 读已提交 也可套用上面的规则，不过一致性视图：read view 和 max id 的创建时机，是每一条 select 语句时重新生成。你根据上面的内容，可以自己动手试验下读已提交。

4  总结

一般我们认为MVCC有下面几个特点：

• 每行数据都存在一个版本，每次数据更新时都更新该版本

• 修改时Copy出当前版本, 然后随意修改，各个事务之间无干扰

• 保存时比较版本号，如果成功(commit)，则覆盖原记录, 失败则放弃copy(rollback)

• 就是每行都有版本号，保存时根据版本号决定是否成功，听起来含有乐观锁的味道, 因为这看起来正是，在提交的时候才能知道到底能否提交成功

InnoDB实现MVCC的方式是:

• 事务以排他锁的形式修改原始数据

• 把修改前的数据存放于undo log，通过回滚指针与主数据关联

• 修改成功（commit）啥都不做，失败则恢复undo log中的数据（rollback）

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

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

• 比如, 如果事务A执行理想的MVCC, 修改Row1成功, 而修改Row2失败, 此时需要回滚Row1, 但因为Row1没有被锁定, 其数据可能又被事务B所修改, 如果此时回滚Row1的内容，则会破坏事务B的修改结果，导致事务B违反ACID。这也正是所谓“第一类更新丢失”的情况。

• 也正是因为InnoDB使用的MVCC中结合了排他锁, 不是纯的MVCC, 所以第一类更新丢失”是不会出现了, 一般说更新丢失都是指第二类丢失更新。

扫码二维码

获取更多精彩