其他网址
【MySQL】当前读、快照读、MVCC - wwcom123 - 博客园
正确的理解MySQL的MVCC及实现原理-12172612-51CTO博客
数据库MVCC 隔离级别_数据库_Jaylon Wang的专栏-CSDN博客
简介
多版本并发控制（Multi-Version Concurrency Control, MVCC），顾名思义，在并发访问的时候，数据存在版本的概念，可以有效地提升数据库并发能力，常见的数据库如MySQL、MS SQL Server、IBM DB2、Hbase、MongoDB等等都在使用。简单讲，如果没有MVCC，当想要读取的数据被其他事务用排它锁锁住时，只能互斥等待；而这时MVCC可以通过提供历史版本从而实现读取被锁的数据(的历史版本)，避免了互斥等待。
在 MySQL中，MVCC是 InnoDB 存储引擎实现隔离级别的一种具体方式。
- 未提交读：无需使用 MVCC（总是读取最新的数据行）
- 提交读和可重复读：使用MVCC来实现。
- 可串行化：需要对所有读取的行都加锁，单纯使用 MVCC 无法实现。
MVCC一般有两种实现方式，本文所讲的InnoDB采用的是后者:
- 实时保留数据的一个或多个历史版本
- 在需要时通过undo日志构造出历史版本
快照读与当前读
简介
原理
事务ID是在mysql开启事务时为其分配的递增序列号，由于是递增的，所以可以基于此判断事务先后关系。
MVCC的多版本指的是针对数据库中的一行数据，都可能通过undolog中的数据算出多条行数据，每行数据版本不同(是为多版本)，针对每次写操作，事务提交前，都会在undolog中记录相应的变动(是为回滚log)，以及对应的事务ID，再结合数据表中的当前行数据，就可以回溯出一个行的的多个版本了。
Innodb会为每行数据添加两个字段 up_txid、del_txid,分别是更新事务ID、删除事务ID，事务新增或者更新一个数据行后，会将该事务ID记录在该行数据的up_txid中，事务删除行数据后，会将该事务ID记录在del_txid中。
在read repeatable隔离级别下
该隔离级别下的事务启动时，除了分配上面说的事务ID外，系统还会查出当前活跃的事务ID列表(也就是开启了但还未提交的事务)，分配给该事务存储下来，有了这些信息，就可以实现快照读了，RR隔离级别下，其查询到的行数据需要满足：
- 行数据的up_txid<=当前事务ID，并且不在活跃事务ID列表中
- 行数据的del_txid为null，或者>当前事务ID，或者在活跃事务ID列表中
简单理解下，只查询在当前事务开启之前就已经提交的数据，并且这行数据未被删除或者在当前事务开启后删除，相当于事务启动时，拍了个快照，事务执行期间，就通过这个快照读取数据，其他事务的变动不会再对当前事务产生影响，是为可重复读。
在读取时，会从最新的一条数据开始读起，如果满足条件就以其为准，如果不满足就找到更旧的一行数据继续判断。
read committed隔离级别下
和RR隔离级别一样的是，RC隔离级别下的查询也是快照读，区别就是RC隔离级别下每次select时都会获取下当前活跃事务ID列表，然后从最新一行数据开始，判断是否满足如下条件，不满足则继续判断更旧的一行数据：
- 行数据的up_txid不在活跃事务ID列表中，表示已经提交
- 行数据的del_txid为null，或者在活跃事务ID列表中未提交
简单理解下，就是每次都读取当前已经提交的并且未被删除的最新数据，相当于每次查询都会拍个快照
当前读
如果查询加了锁，就不在mvcc的控制范畴了，因为此时用的是当前读 。当前读的规则，就是要能读到所有已经提交的记录的最新值。当前读是由锁来保证的。Innodb中有行锁，上面举例的几条语句，都会锁住id=1的这行数据，这样其他事务如果要对id=1这行数据进行当前读，只能等行锁释放，等到啥时候？事务完成的时候会释放掉锁，既然事务都完成了，那其他事务自然能读取到已提交的最新值。
MVCC原理简述
在Mysql中MVCC是在Innodb存储引擎中得到支持的，InnoDb的最基本的行中包含一些额外的存储信息：DATA_TRX_ID，DATA_ROLL_PTR，DB_ROW_ID，DELETE BITInnodb为每行记录都实现了三个隐藏字段：
- 6字节的事务ID（
DB_TRX_ID）。
（该行所的事务id，每处理一个事务，其值自动+1。可以基于此判断事务先后关系）- 7字节的回滚指针（DB_ROLL_PTR）。
（指向当前记录项的rollback segment的undo log记录，找之前版本的数据就是通过这个指针）- 6字节的隐式主键（DB_ROW_ID）。
Innodb自动产生聚集索引时，聚集索引包括这个DB_ROW_ID的值，否则聚集索引中不包括这个值，这个用于索引当中。- 删除标识位（DELETE BIT）。
用于标识该记录是否被删除，这里的不是真正的删除数据，而是标志出来的删除。真正意义的删除是在commit的时候
MVCC并发控制的执行过程
以update为例：begin=> 用排他锁锁定该行=> 记录redo log=> 记录undo log=> 修改当前行的值，写事务编号
- SELECT
Innodb检查每行数据，确保他们符合两个标准：
1、InnoDB只查找版本早于当前事务版本的数据行(也就是数据行的版本必须小于等于事务的版本)，这确保当前事务读取的行都是事务之前已经存在的，或者是由当前事务创建或修改的行。
2、行的删除操作的版本一定是未定义的或者大于当前事务的版本号，确定了当前事务开始之前，行没有被删除。
符合了以上两点则返回查询结果。- INSERT
InnoDB为每个新增行记录当前系统版本号作为创建ID。“创建时间”=DB_ROW_ID，这时，“删除时间 ”是未定义的；- DELETE
InnoDB为每个删除行的记录当前系统版本号作为行的删除ID。- UPDATE
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和回滚段是同一意思。- 锁（前边已有讲述）
- 隔离级别（前边已有讲述）
MVCC原理详解
有事务插入persion表插入了一条新记录：name为Jerry, age为24岁。可认为：隐式ID是1，事务ID和回滚指针，我们假设为NULL
事务1对该记录的name做出修改，改为Tom
当事务1更改该行的值时，会进行如下操作：
- 用排他锁锁定该行
- 把该行数据拷贝到undo log中，作为旧记录（即在undo log中有当前行的拷贝副本）
- 拷贝完毕后，有如下操作：
修改该行name为Tom；
修改隐藏字段的事务ID为当前事务1的ID（我们默认从1开始，之后递增）；
回滚指针指向拷贝到undo log的副本记录（即表示我的上一个版本就是它）。- 事务提交后，释放锁
事务2修改person表的同一个记录，将age修改为30岁
当事务2更改该行的值时，会进行如下操作：
- 用排他锁锁定该行
- 把该行数据拷贝到undo log中，作为旧记录。
发现该行记录已经有undo log了，那么最新的旧数据作为链表的表头，插在该行记录的undo log最前面- 拷贝完毕后，有如下操作：
修改该行age为30岁；
修改隐藏字段的事务ID为当前事务2的ID, 那就是2
回滚指针指向刚刚拷贝到undo log的副本记录- 事务提交后，释放锁
从上面，我们就可以看出，不同事务或者相同事务的对同一记录的修改，会导致该记录的undo log成为一条记录版本线性表，即：事务链，undo log的链首就是最新的旧记录，链尾就是最早的旧记录。
因此，如果undo log一直不删除，则会通过当前记录的回滚指针回溯到该行创建时的初始内容，所幸的时在Innodb中存在purge线程，它会查询那些比现在最老的活动事务还早的undo log，并删除它们，从而保证undo log文件不至于无限增长。