InnoDB的MVCC大致实现原理 与 锁规则

事务隔离性的支持 —— MVCC

在 MySQL 里，有两个“视图”的概念：一个是 view。它是一个用查询语句定义的虚拟表，在调用的时候执行查询语句并生成结果。创建视图的语法是 create view … ，而它的查询方法与表一样。

概述

MVCC是多版本并发控制（Multi-Version Concurrency Control，简称MVCC），是MySQL中基于 乐观锁 理论实现隔离级别的方式，用于实现已提交读和可重复读隔离级别的实现，也经常称为多版本数据库。MVCC机制会生成一个数据请求时间点的一致性数据快照 （Snapshot)， 并用这个快照来提供一定 级别 （语句级或事务级） 的一致性读取。从用户的角度来看，好象是数据库可以提供同一数据的多个 版本（系统版本号和事务版本号）。

MVCC多版本并发控制中，读操作可以分为两类：

1、快照读（snapshot read） 读的是记录的可见版本，不用加锁。如select

2、当前读（current read） 读取的是记录的最新版本，并且当前读返回的记录。如insert，delete，update，select…lock in share mode/for update

MVCC：每一行记录实际上有多个版本，每个版本的记录除了数据本身之外，增加了其它字段 ：
DB_TRX_ID：记录当前事务ID
DB_ROLL_PTR：指向undo log日志上数据的指针

已提交读：每次执行语句的时候都重新生成一次快照（Read View），每次select查询时。

可重复读：同一个事务开始的时候生成一个当前事务全局性的快照（Read View），第一次select查询 时（事务开始）。

快照内容读取原则：
1、版本未提交无法读取生成快照
2、版本已提交，但是在快照创建后提交的，无法读取
3、版本已提交，但是在快照创建前提交的，可以读取
4、当前事务内自己的更新，可以读到

• 已提交读 原理
  解决了脏读问题 —— 在conmmit完成的表上 生成数据快照

• 可重复读
  解决了脏读问题 和 不可重复读问题
  在commit完成的表上 （第一次select上）生成一次数据快照 以后 一直用这个（不update的情况下）

  为什么部分解决了幻读？
  用的是第一次select的 数据快照

  update
  当前事务是可以看见自己事务修改、更新的数据的! ! !
  而这个更改 可以是在别人提交的事务版本上更改的 —— update了别人已提交的版本

DB_TRX_ID:事务ID
DB_ROLL_PTR:回滚指针

利用undo log 实现 ”保存“ 多版本数据

“快照”在 MVCC 里是怎么工作的？

InnoDB 里面每个事务有一个唯一的事务 ID，叫作 transaction id。它是在事务开始的时候向 InnoDB 的事务系统申请的，是按申请顺序严格递增的。

而每行数据也都是有多个版本的。每次事务更新数据的时候，都会生成一个新的数据版本，并且把 transaction id 赋值给这个数据版本的事务 ID，记为 row trx_id。
同时，旧的数据版本要保留，并且在新的数据版本中，能够有信息可以直接拿到它。

undo log：回滚日志，保存了事务发生之前的数据的一个版本，用于事务执行时的回滚操作，同时也是
实现多版本并发控制（MVCC）下读操作的关键技术。

多了两列
DB_TRX_ID:事务ID
DB_ROLL_PTR:回滚指针

如何确定快照版本 —— 实现一致性读

按照可重复读的定义，一个事务启动的时候，能够看到所有已经提交的事务结果。但是之后，这个事务执行期间，其他事务的更新对它不可见。

在实现上， InnoDB 为每个事务构造了一个数组，用来保存这个事务启动瞬间，当前正在“活跃”的所有事务 ID。“活跃”指的就是，启动了但还没提交。

数组里面事务 ID 的最小值记为低水位，当前系统里面已经创建过的事务 ID 的最大值加 1 记为高水位。 这个视图数组和高水位，就组成了当前事务的一致性视图（read-view）。

这样，对于当前事务的启动瞬间来说，一个数据版本的 row trx_id，有以下几种可能：

1、如果落在绿色部分，表示这个版本是已提交的事务或者是当前事务自己生成的，这个数据是可见的；

2、如果落在红色部分，表示这个版本是由将来启动的事务生成的，是肯定不可见的；

3、如果落在黄色部分，那就包括两种情况

​ a. 若 row trx_id 在数组中，表示这个版本是由还没提交的事务生成的，不可见；——数组保存的就是未提交
​ b. 若 row trx_id 不在数组中，表示这个版本是已经提交了的事务生成的，可见。

这样执行下来，虽然期间这一行数据被修改过，但是事务 A 不论在什么时候查询，看到这行数据的结果都是一致的，所以我们称之为一致性读。

对于一个事务视图来说，除了自己的更新总是可见以外，有三种情况：

• 版本未提交，不可见；
• 版本已提交，但是是在视图创建后提交的，不可见；
• 版本已提交，而且是在视图创建前提交的，可见。

当前读 —— 防止更新丢失

要去更新数据的时候，就不能再在历史版本上更新了，否则会让别的事务的更新丢失

读的是版本已提交的数据

更新数据都是先读后写的，而这个读，只能读当前的值，称为“当前读”（current read）。

若其他事务也有相同数据更新了，且还没提交
根据两阶段所协议，当前事务应等待其他事务提交后才能更新

到这里，我们把一致性读、当前读和行锁就串起来了。

一致性读 —— 事务的可重复读

可重复读的核心就是一致性读（consistent read）；而事务更新数据的时候，只能用当前读。如果当前的记录的行锁被其他事务占用的话，就需要进入锁等待。

而读提交的逻辑和可重复读的逻辑类似，它们最主要的区别是：

• 在可重复读隔离级别下，只需要在事务开始的时候创建一致性视图，之后事务里的其他查询都共用这个一致性视图；

• 在读提交隔离级别下，每一个语句执行前都会重新算出一个新的视图。

加行锁 —— 解决幻读，select的时候加锁，再修改

加锁的基础单位是next-key 锁
next-key = gap lock + 行锁（行对应索引的锁） ( ]

• 原则 1：加锁的基本单位是 next-key lock。希望你还记得，next-key lock 是前开后闭区间。
• 原则 2：查找过程中访问到的对象才会加锁。
• 优化 1：索引上的等值查询，给唯一索引加锁的时候，next-key lock 退化为行锁。
• 优化 2：索引上的等值查询，向右遍历时且最后一个值不满足等值条件的时候，next-key lock 退化为间隙锁。

1.加锁的基本单位，不是行锁，是Next-Key锁，1个左开右闭的区间。
2.凡是扫描过的范围，都会加锁
在此基础上，
如果单行命中，Next-Key锁退化为“行锁”;如果没命中，Next-Key锁退化为“Gap锁”