InnoDB对MVCC的实现

淡淡的烟草味﹌ 2022-01-21 08:39 214阅读 0赞

# 1、什么是MVCC #

MVCC（Multi-Version Concurrency Control）即多版本并发控制。MVCC 是一种并发控制的方法，一般在数据库管理系统中，实现对数据库的并发访问。MVCC使得大部分支持行锁的事务引擎，不再单纯的使用行锁来进行数据库的并发控制，取而代之的是把数据库的行锁与行的多个版本结合起来，只需要很小的开销，就可以实现非锁定读，从而大大提高数据库系统的并发性能。

如果有人从数据库中读数据的同时，有另外的人写入数据，有可能读数据的人会看到『半写』或者不一致的数据。有很多种方法来解决这个问题，叫做并发控制方法。最简单的方法，通过加锁，让所有的读者等待写者工作完成，但是这样效率会很差。MVCC 使用了一种不同的手段，每个连接到数据库的读者，在某个瞬间看到的是数据库的一个快照，写者写操作造成的变化在写操作完成之前（或者数据库事务提交之前）对于其他的读者来说是不可见的。

基于提升并发性能的考虑，各大数据库厂商的事务型存储引擎一般都同时实现了多版本并发控制（MVCC）。不仅是MySQL，包括Oracle、PostgreSQL等其他数据库系统也都实现了。MVCC就像是Java语言中的接口，各个数据库厂商的实现机制不尽相同。可以认为MVCC是行级锁的一个变种，但是它在很多情况下避免了加锁操作，因此开销更低。虽然实现机制有所不同，但大都实现了非阻塞的读操作，写操作也只是锁定必要的行。MVCC会保存某个时间点上的数据快照。这意味着事务可以看到一个一致的数据视图，不管他们需要跑多久。这同时也意味着不同的事务在同一个时间点看到的同一个表的数据可能是不同的。前面说到不同的存储引擎的MVCC实现是不同的，典型的有乐观并发控制和悲观并发控制。

MVCC实现的读写不阻塞正如其名：多版本并发控制---->通过一定机制生成一个数据请求时间点的一致性数据快照（Snapshot)，并用这个快照来提供一定级别（语句级或事务级）的一致性读取。从用户的角度来看，好像是数据库可以提供同一数据的多个版本。

# 2、MySQL的InnoDB存储引擎实现MVCC的策略 #

来看看InnoDB的MVCC是怎么样的吧，以下摘抄自《高性能MySQL》。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z1emhvbmdtaW4wNQ_size_16_color_FFFFFF_t_70]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z1emhvbmdtaW4wNQ_size_16_color_FFFFFF_t_70 1]

*  INSERT：InnoDB为新插入的每一行保存当前系统版本号作为行版本号。
 *  DELETE：InnoDB为删除的每一行保存当前系统版本号作为行删除标识。
 *  UPDATE：InnoDB为插入一行新记录，保存当前系统版本号作为行版本号，同时保存当前系统版本号到原来的行作为删除标识（这只是理论，innoDB实际是通过undo log来备份旧记录的）。

在每一行数据中额外保存两个隐藏的列：当前行创建时的版本号和删除时的版本号（可能为空，其实还有一列称为回滚指针，用于事务回滚，不在本文范畴）。这里的版本号并不是实际的时间值，而是系统版本号。每开始新的事务，系统版本号都会自动递增。事务开始时刻的系统版本号会作为事务的版本号，用来和查询每行记录的版本号进行比较。每个事务又有自己的版本号，这样事务内执行CRUD操作时，就通过版本号的比较来达到数据版本控制的目的。

innoDB存储的最基本row中包含一些额外的存储信息 DATA\_TRX\_ID、DATA\_ROLL\_PTR、DB\_ROW\_ID、DELETE BIT。

*  DATA\_TRX\_ID标记了最新更新这条行记录的transaction id，每处理一个事务，其值自动+1
 *  DATA\_ROLL\_PTR 指向当前记录项的rollback segment的undo log记录，找之前版本的数据就是通过这个指针
 *  DB\_ROW\_ID，当由innodb自动产生聚集索引时，聚集索引包括这个DB\_ROW\_ID的值，否则聚集索引中不包括这个值，这个用于索引当中
 *  DELETE BIT位用于标识该记录是否被删除，这里的不是真正的删除数据，而是标志出来的删除，真正意义的删除是在commit的时候。

1、初始插入数据行  
![在这里插入图片描述][20190609135712587.png]  
F1～F6是某行列的名字，1～6是其对应的数据。后面三个隐含字段分别对应该行的事务号和回滚指针，假如这条数据是刚INSERT的，可以认为ID为1，其他两个字段为空

2、事务1更改该行的各字段的值  
![在这里插入图片描述][20190609135902445.png]  
当事务1更改该行的值时，会进行如下操作：

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

3、事务2修改该行的值

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z1emhvbmdtaW4wNQ_size_16_color_FFFFFF_t_70 2]  
与事务1相同，此时undo log中有两行记录，并且通过回滚指针连在一起。因此，如果undo log一直不删除，则会通过当前记录的回滚指针回溯到该行创建时的初始内容，所幸的是在Innodb中存在purge线程，它会查询那些比现在最老的活动事务还早的undo log，并删除它们，从而保证undo log文件不至于无限增长。

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

下面用更浅显易懂的例子说明 MVCC 下的 INSERT/DELETE/UPDATE/SELECT 操作。  
假如 test 表有两个字段 name 和 age；MVCC 的三个隐藏列字段名为 transaction\_id、 create\_version 和 delete\_version。

insert  
![在这里插入图片描述][20190923212100502.png]

update  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z1emhvbmdtaW4wNQ_size_16_color_FFFFFF_t_70 3]

delete  
![在这里插入图片描述][20190923212133311.png]  
满足以下两个条件的记录才能被 select 读取出来：

*  delete\_version 未定义或者大于 select 所在事务的 delete\_version 的行
 *  create\_version 小于或等于 select 所在事务的的 create\_version的行

通过这个例来看下为什么MVCC 在 REPEATABLE READ 隔离级别下能解决幻读。假如有个事务开始于 update 之后 delete 之前，且结束于 delete 之后，如下：

start transaction;  //假如事务 id = 2.5
    select * from test; //执行时间在 update 之后 delete 之前
    select * from test; //执行时间在 delete 之后
    commit;

如果不使用 MVCC 第一条 select \* from test 能读到 1 条记录，而 第二条将读取到 0 条记录，同一事务中多次 select 范围查询读取到的记录不一致即幻读。而使用 MVVC 之后，两条select 语句读取到的记录相同。

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

*  READ\_UNCOMMITTED，读未提交，读事务直接读取主记录，无论更新事务是否完成
 *  READ\_COMMITTED，读已提交，读事务每次都读取距离undo log最近的那个版本，因此两次对同一字段的读可能读到不同的数据（幻读），但能保证每次都读到最新的数据
 *  REPEATABLE\_READ，每次都读取指定的版本，这样保证不会产生幻读，但可能读不到最新的数据
 *  SERIALIZABLE，锁表，读写相互阻塞，使用较少

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

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

# 3、InnoDB实现的MVCC有何特殊性 #

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

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

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

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

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

MVCC可以保证不阻塞地读到一致的数据。但是MVCC理论并没有对实现细节做约束，为此不同的数据库的语义有所不同，比如：

*  postgres 对写操作也是乐观并发控制；在表中保存同一行数据记录的多个不同版本，每次写操作都是创建，而回避更新；在事务提交时，按版本号检查当前事务提交的数据是否存在写冲突，则抛异常告知用户，回滚事务；
 *  innodb 则只对读无锁，写操作仍是上锁的悲观并发控制，这也意味着，innodb中只能见到因死锁和不变性约束而回滚，而见不到因为写冲突而回滚；不像 postgres 那样对数据修改在表中创建新纪录，而是每行数据只在表中保留一份，在更新数据时上行锁，同时将旧版数据写入 undo log；表和 undo log 中行数据都记录着事务ID，在检索时根据事务隔离级别去读取行数据。可见 MVCC中的写操作仍可以按悲观并发控制实现；

MVCC解决的问题是读写互相不阻塞的问题，每次更新都产生一个新的版本，读的话可以读历史版本。试想，如果一个数据只有一个版本，那么多个事务对这个数据进行读写是不是需要读写锁来保护? 一个读写事务在运行的过程中在访问数据之前先加读/写锁这种实现叫做悲观锁，悲观体现在先加锁，独占数据，防止别人加锁。乐观锁呢，读写事务，在真正的提交之前，不加读/写锁，而是先看一下数据的版本/时间戳，等到真正提交的时候再看一下版本/时间戳，如果两次相同，说明别人期间没有对数据进行过修改，那么就可以放心提交。乐观体现在，访问数据时不提前加锁。在资源冲突不激烈的场合，用乐观锁性能较好。如果资源冲突严重，乐观锁的实现会导致事务提交的时候经常看到别人在他之前已经修改了数据，然后要进行回滚或者重试，还不如一上来就加锁。

# 4、快照读与当前读 #

快照读就是读取数据的时候会根据一定规则读取事务可见版本的数据（可能是过期的数据），不用加锁。

当前读, 读取的是最新版本, 并且对读取的记录加锁，保证其他事务不会再并发的修改这条记录，避免出现安全问题。

使用当前读的场景：

*  select…lock in share mode (共享读锁)
 *  select…for update
 *  update
 *  delete
 *  insert

使用快照读的场景：

*  单纯的select操作，不包括上述 select … lock in share mode、select … for update

通过举例来理解快照读与当前读吧：MySQL innoDB的RR隔离级别下，假设你开启了两个事务，分别是A和B，这里有个张user表，里面有四条数据。

CREATE TABLE `user` (
      `id` int(11) NOT NULL,
      `name` varchar(64) NOT NULL,
      PRIMARY KEY (`id`),
      KEY `name` (`name`)
    ) ENGINE=InnoDB;
    
    insert into user values(0,"Jack"),(5,"Tom"),
    (10,"Jerry"),(15,"ZhangSan");

当你执行select \*之后，在A与B事务中都会返回4条一样的数据，这是不用想的，RR隔离级别下当执行普通的select查询时，innodb默认会执行快照读，相当于就是给你目前的状态找了一张照片，以后执行select 的时候就会返回当前照片里面的数据，当其他事务提交了也对你不造成影响，和你没关系，这就实现了可重复读，那这个照片是什么时候生成的呢？不是开启事务的时候，是当你第一次执行select的时候，也就是说，当A开启了事务，然后没有执行任何操作，这时候B insert了一条数据然后commit，这时候A在事务中执行select，那么就能看到有B在自己在事务中添加的那条数据…，在这之后无论再有其他事务commit都没有关系，因为照片已经生成了，而且不会再生成了，以后都会参考这张照片。

# 总结 #

所谓的MVCC（Multi-Version Concurrency Control 多版本并发控制）指的就是**在使用读已提交（READ COMMITTD）、可重复读（REPEATABLE READ）这两种隔离级别的事务在执行普通的SELECT操作时访问记录的版本链的过程，这样子可以使不同事务的读-写、写-读操作并发执行，从而提升系统性能**。

这两个隔离级别的一个很大不同就是：生成ReadView的时机不同，READ COMMITTD在每一次进行普通SELECT操作前都会生成一个ReadView，而REPEATABLE READ只在第一次进行普通SELECT操作前生成一个ReadView，数据的可重复读其实就是ReadView的重复使用。

InnoDB通过为每一行记录添加两个额外的隐藏的值来实现MVCC，这两个值一个记录这行 数据何时被创建，另外一个记录这行数据何时过期（或者被删除）。但是InnoDB并不存储这些事件发生时的实际时间，相反它只存储这些事件发生时的系统版本号。这是一个随着事务的创建而不断增长的数字。每个事务在事务开始时会记录它自己的系统版本号。每个查询必须去检查每行数据的版本号与事务的版本号是否相同。

这种额外的记录所带来的结果就是对于大多数查询来说根本就不需要获得一个锁。他们只是简单地以最快的速度来读取数据，确保只选择符合条件的行。这个方案的缺点在于存储引擎必须为每一行存储更多的数据，做更多的检查工作，处理更多的善后操作。使用MVCC多版本并发控制比锁定模型的主要优点是在MVCC里， 对检索（读）数据的锁要求与写数据的锁要求不冲突， 所以读不会阻塞写，而写也从不阻塞读。在数据库里也有表和行级别的锁定机制， 用于给那些无法轻松接受 MVCC 行为的应用。 不过，恰当地使用 MVCC 总会提供比锁更好地性能。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z1emhvbmdtaW4wNQ_size_16_color_FFFFFF_t_70]: /images/20220121/5c7ef3702a7f4fe49d469f252345277e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z1emhvbmdtaW4wNQ_size_16_color_FFFFFF_t_70 1]: /images/20220121/b21e33402cec4d6585c64638bf32d0fa.png
[20190609135712587.png]: /images/20220121/2b7e4aa15de64fb8995289b53e6a0035.png
[20190609135902445.png]: /images/20220121/92d80741afc347dc9595a5b3a1259c0c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z1emhvbmdtaW4wNQ_size_16_color_FFFFFF_t_70 2]: /images/20220121/b670aad1659e46a18a0d9fc50f9f90b5.png
[20190923212100502.png]: /images/20220121/dd9de895cdbc4fb7b57e49e9bcb61bb3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z1emhvbmdtaW4wNQ_size_16_color_FFFFFF_t_70 3]: /images/20220121/db104c34a4394d48a82fb80f39f6e9d1.png
[20190923212133311.png]: /images/20220121/0f7240def6bc4f57b61b0d135f958c0f.png