隐藏字段

每行记录除了我们自定义的字段外，还有数据库隐式定义的 DB_TRX_ID,DB_ROLL_PTR,DB_ROW_ID 等字段

• DB_TRX_ID：6 字节，最近修改事务 id，记录创建这条记录或者最后一次修改该记录的事务 id

• DB_ROLL_PTR：7 字节，回滚指针，指向这条记录的上一个版本,用于配合 undolog，指向上一个旧版本

• DB_ROW_JD：6 字节，隐藏的主键，如果数据表没有主键，那么 innodb 会自动生成一个 6 字节的 row_id

记录如图所示：

在上图中，DB_ROW_ID 是数据库默认为该行记录生成的唯一隐式主键，DB_TRX_ID 是当前操作该记录的事务 ID，DB_ROLL_PTR 是一个回滚指针，用于配合 undo 日志，指向上一个旧版本

undo log

undolog 被称之为回滚日志，表示在进行 insert，delete，update 操作的时候产生的方便回滚的日志

当进行 insert 操作的时候，产生的 undolog 只在事务回滚的时候需要，并且在事务提交之后可以被立刻丢弃

当进行 update 和 delete 操作的时候，产生的 undolog 不仅仅在事务回滚的时候需要，在快照读的时候也需要，所以不能随便删除，只有在快照读或事务回滚不涉及该日志时，对应的日志才会被 purge 线程统一清除（当数据发生更新和删除操作的时候都只是设置一下老记录的 deleted_bit，并不是真正的将过时的记录删除，因为为了节省磁盘空间，innodb 有专门的 purge 线程来清除 deleted_bit 为 true 的记录，如果某个记录的 deleted_id 为 true，并且 DB_TRX_ID 相对于 purge 线程的 read view 可见，那么这条记录一定是可以被清除的）。

下面我们来看一下 undolog 生成的记录链

（1）假设有一个事务编号为 1 的事务向表中插入一条记录，那么此时行数据的状态为：

（2）假设有第二个事务编号为 2 对该记录的 name 做出修改，改为 lisi

在事务 2 修改该行记录数据时，数据库会对该行加排他锁。然后把该行数据拷贝到 undolog 中，作为 旧记录，即在 undolog 中有当前行的拷贝副本。拷贝完毕后，修改该行 name 为 lisi，并且修改隐藏字段的事务 id 为当前事务 2 的 id，回滚指针指向拷贝到 undolog 的副本记录中。事务提交后，释放锁。

（3）假设有第三个事务编号为 3 对该记录的 age 做了修改，改为 32

在事务 3 修改该行数据的时候，数据库会对该行加排他锁。然后把该行数据拷贝到 undolog 中，作为旧记录，发现该行记录已经有 undolog 了，那么最新的旧数据作为链表的表头，插在该行记录的 undolog 最前面。修改该行 age 为 32 岁，并且修改隐藏字段的事务 id 为当前事务 3 的 id，回滚指针指向刚刚拷贝的 undolog 的副本记录。事务提交，释放锁

从上述的一系列图中，大家可以发现，不同事务或者相同事务的对同一记录的修改，会导致该记录的 undolog 生成一条记录版本线性表，即链表，undolog 的链首就是最新的旧记录，链尾就是最早的旧记录。

Read View

上面的流程如果看明白了，那么大家需要再深入理解下 read view 的概念了。

Read View 是事务进行快照读操作的时候生产的读视图，在该事务执行快照读的那一刻，会生成一个数据系统当前的快照，记录并维护系统当前活跃事务的 id，事务的 id 值是递增的。

其实 Read View 的最大作用是用来做可见性判断的，也就是说当某个事务在执行快照读的时候，对该记录创建一个 Read View 的视图，把它当作条件去判断当前事务能够看到哪个版本的数据，有可能读取到的是最新的数据，也有可能读取的是当前行记录的 undolog 中某个版本的数据。

Read View 遵循的可见性算法主要是将要被修改的数据的最新记录中的 DB_TRX_ID（当前事务 id）取出来，与系统当前其他活跃事务的 id 去对比，如果 DB_TRX_ID 跟 Read View 的属性做了比较，不符合可见性，那么就通过 DB_ROLL_PTR 回滚指针去取出 undolog 中的 DB_TRX_ID 做比较，即遍历链表中的 DB_TRX_ID，直到找到满足条件的 DB_TRX_ID,这个 DB_TRX_ID 所在的旧记录就是当前事务能看到的最新老版本数据。

Read View 的可见性规则如下所示：

首先要知道 Read View 中的三个全局属性：

• trx_list:一个数值列表，用来维护 Read View 生成时刻系统正活跃的事务 ID（1,2,3）

• up_limit_id:记录 trx_list 列表中事务 ID 最小的 ID（1）

• low_limit_id:Read View 生成时刻系统尚未分配的下一个事务 ID，（4）

具体的比较规则如下：

• 首先比较 DB_TRX_ID < up_limit_id,如果小于，则当前事务能看到 DB_TRX_ID 所在的记录，如果大于等于进入下一个判断

• 接下来判断 DB_TRX_ID >= low_limit_id,如果大于等于则代表 DB_TRX_ID 所在的记录在 Read View 生成后才出现的，那么对于当前事务肯定不可见，如果小于，则进入下一步判断

• 判断 DB_TRX_ID 是否在活跃事务中，如果在，则代表在 Read View 生成时刻，这个事务还是活跃状态，还没有 commit，修改的数据，当前事务也是看不到，如果不在，则说明这个事务在 Read View 生成之前就已经开始 commit，那么修改的结果是能够看见的

MVCC 的整体处理流程

假设有四个事务同时在执行，如下图所示：

从上述表格中，我们可以看到，当事务 2 对某行数据执行了快照读，数据库为该行数据生成一个 Read View 视图，可以看到事务 1 和事务 3 还在活跃状态，事务 4 在事务 2 快照读的前一刻提交了更新，所以，在 Read View 中记录了系统当前活跃事务 1，3，维护在一个列表中。同时可以看到 up_limit_id 的值为 1，而 low_limit_id 为 5，如下图所示：

在上述的例子中，只有事务 4 修改过该行记录，并在事务 2 进行快照读前，就提交了事务，所以该行当前数据的 undolog 如下所示：

当事务 2 在快照读该行记录的是，会拿着该行记录的 DB_TRX_ID 去跟 up_limit_id,lower_limit_id 和活跃事务列表进行比较，判读事务 2 能看到该行记录的版本是哪个。

具体流程如下：先拿该行记录的事务 ID（4）去跟 Read View 中的 up_limit_id 相比较，判断是否小于，通过对比发现不小于，所以不符合条件，继续判断 4 是否大于等于 low_limit_id,通过比较发现也不大于，所以不符合条件，判断事务 4 是否处理 trx_list 列表中，发现不再次列表中，那么符合可见性条件，所以事务 4 修改后提交的最新结果对事务 2 的快照是可见的，因此，事务 2 读取到的最新数据记录是事务 4 所提交的版本，而事务 4 提交的版本也是全局角度的最新版本。如下图所示：

当上述的内容都看明白了的话，那么大家就应该能够搞清楚这几个核心概念之间的关系了，下面我们讲一个不同的隔离级别下的快照读的不同。

RC、RR 级别下的 InnoDB 快照读有什么不同？

因为 Read View 生成时机的不同，从而造成 RC、RR 级别下快照读的结果的不同

（1）在 RR 级别下的某个事务的对某条记录的第一次快照读会创建一个快照即 Read View,将当前系统活跃的其他事务记录起来，此后在调用快照读的时候，还是使用的是同一个 Read View,所以只要当前事务在其他事务提交更新之前使用过快照读，那么之后的快照读使用的都是同一个 Read View,所以对之后的修改不可见

（2）在 RR 级别下，快照读生成 Read View 时，Read View 会记录此时所有其他活动和事务的快照，这些事务的修改对于当前事务都是不可见的，而早于 Read View 创建的事务所做的修改均是可见

（3）在 RC 级别下，事务中，每次快照读都会新生成一个快照和 Read View,这就是我们在 RC 级别下的事务中可以看到别的事务提交的更新的原因。

总结：在 RC 隔离级别下，是每个快照读都会生成并获取最新的 Read View,而在 RR 隔离级别下，则是同一个事务中的第一个快照读才会创建 Read View，之后的快照读获取的都是同一个 Read View.