MySQL--深入理解MVCC机制原理_mysql mvcc了解吗?展开说说

什么是MVCC？

MVCC全称 Multi-Version Concurrency Control，即多版本并发控制，维持一个数据的多个版本，主要是为了提升数据库的并发访问性能，用更高性能的方式去处理数据库读写冲突问题，实现无锁并发。

什么是快照读和当前读？

• 快照读：不加锁非阻塞读，快照读要求数据库隔离级别不能是串行化，否则会退化到当前读，快照读是基于多版本并发控制的，因为是基于多版本并发控制，所以快照读可能读取的不是最新的数据。
• 当前读：当前读就是读取最新的数据版本，快照读读取的时候，会对读取的数据加锁，读取的时候其他事务不能修改当前数据。

MVCC和快照读、当前读的关系?

MVCC 多版本并发控制，而快照就是数据的一个版本，MVCC 的无锁并发就是依赖快照读机制实现的。

MVCC的实现原理?

MVCC 实现依赖于数据库记录中的三个隐式字段、undo日志、Read View 版本链，本篇讨论皆基于 MySQL 的 InnoDB 存储引擎。

三个隐式字段：

隐式字段，是我们正常来看看不到的字段，数据库的每行数据除了我们看到的字段之外，还有三个我们看不到的字段。

• DB_TRX_ID：记录当前事务最后一次修改的事务ID，即事务 ID，事务 ID 是递增的。
• DB_ROW_ID：隐藏的自增主键ID，如果数据库没有主键ID，数据库会自动生成一个 6个字节的 DB_ROW_ID。
• DB_ROLL_PTR：回滚指针，指向上一个数据版本。

简单图例：

undo log 日志：

我们都知道undo log 日志是回滚日志，是数据库保证数据一致性的一个支撑，当出现异常情况时候，通过 undo log 日志来进行数据回滚，其实它还有其他作用，undo log 又分为两种，如下：

• insert undo log，insert 操作时候产生的日志，只会在发生异常需要进行回滚的时候使用，事务提交后，undo log 就没有用处了，就会被丢弃。
• update undo log 和 delete undo log，这两类 undo log 不仅在事务回滚时候要用到，同时在快照读的时候也会用到。

undo log 也会记录一条版本链表，每次修改数据的时候，数据库会先把当前数据拷贝一份到 undo log中，然后再对数据进行修改，最在undo log 中最新修改的数据副本会在链的头部，同时它有一个回滚指针指向他的上一个版本。

Read View：

Read View 是事务执行快照读产生的视图，在事务执行快照读的时候，系统会以当前时刻生成一个快照，以此来维护系统此时活跃的事务id，用来做可见性判断，当某个事务进行快照读的时候，我们根据 Read View 来判断当前事务可以读取哪个版本的数据，然后就去该数据的 undo log 里面找数据，当然也可能是读取最新的数据。

Read View 遵守可见性规则，它的三个属性如下：

• trx_list：用来维护 Read View 生成时候系统活跃的事务ID，是一个列表。
• up_limit_id：活跃事务ID中最小的ID。
• low_limit_id：Read View 生成时候，系统将要分配的下一个事务ID。

可见性算法主要是把要修改的数据的最新版本的事务ID，即DB_TRX_ID取出来，与当前系统中活跃的其他事务ID去对比，而Read View 就维护了这些活跃的事务ID，如果在 Read View 中找不到合适条件的数据记录，就会去 undo log 日志根据回滚指针 DB_ROLL_PTR 来找数据记录直到找到为止。

Read View 的比较流程如下：

注意事务ID 是递增的。

• 第一步，比较 DB_TRX_ID < up_limit_id， 是否小于活跃事务 Read View中最小的事务ID，如果小于，则当前事务能看到 DB_TRX_ID 所在的记录，否则进入第二个判断。
• 第二步，比较 DB_TRX_ID >=low_limit_id， 是否大于等于下一个将要发生的事务ID，如果大于等于则代表 DB_TRX_ID 所在的记录在 Read View生成后才出现的，那对当前事务肯定不可见，否则进入第三个判断。
• 第三步， 判断 DB_TRX_ID 是否在活跃事务 Read View 之中，如果在，则代表我 Read View 生成时刻，你这个事务还在活跃，还没有Commit，你修改的数据，我当前事务也是看不见的，如果不在，则说明，这个事务在 Read View 生成之前就已经 Commit 了，因为第一步、第二步已经判断了是否小于最小活跃事务ID和是否是将要发生的事务ID，两者都不是，同时又不在 活跃事务 Read View 中，只能说明在这个事务 Read View 在当前是事务发生之前了，当前事务理所当然能够看到。

简易流程如下：

读已提交(Read Committed)、可重复读(Repeatable Read) 隔离级别下的快照读的区别？

读已提交(Read Committed)、可重复读(Repeatable Read) 隔离级别下的快照读最大的区别就是生成 Read View 时机不同。

• 可重复读(Repeatable Read) 隔离级别下，一个事务只有在第一次读取数据的时候生成一个Read View，Read View 记录当前活跃的事务ID，后面继续读取数据时候，如果用到快照读，那他使用的还是第一次读取时候的 Read View，这也是为什么可重复读(Repeatable Read) 隔离级别下，看不到别的事务的修改记录的原因。
• 读已提交(Read Committed) 隔离级别下，事务开启后，每次使用快照读的时候，都会重新生成一个活跃事务ID，第一读取和第二次读取使用的不是同一个 Read View，那第二次读取的时候，第一次读取时候的 Read View 中的某些事务可能已经提交了，那在第二次快照读的时候就可以看到了，这也是在读已提交(Read Committed) 隔离级别下可以看到别的事务提交的记录的原因 。

MVCC解决了什么问题？

想要知道MVCC解决了什么问题，我们要先知道数据库多个事务并发访问会有什么问题，数据库并发访问场景如下：

• 读读并发：多个事务同时读取同一份数据，不存在问题，无需进行并发控制。
• 读写并发：多个事务同时读写同一份数据，有线程安全问题，可能会脏读、幻读、不可重复度问题。
• 写写并发：多个事务同时对同一份数据写，可能会有更新丢失的情况。

而MVCC 就是解决以上三种并发中的读写并发问题，是一种无所并发控制，可以解决脏读、不可重复读问题，可以解决部分场景的幻读问题。

什么是幻读？MVCC可以解决幻读问题吗？

MVCC 可以解决快照读的幻读问题，MVCC 机制是依赖 快照读、undo log、Read View 来实现的，可以解决快照读的幻读问题，但是不能解决 update、delete 的幻读问题，因为这些操作是当前读。

以下讨论基于可重复读(Repeatable Read) 隔离级别。

当前读幻读演示：

流程解释：

• 在第2个时间点的时候，快照读，可以得到 id 大于 1的数据。
• 在第6个时间点的时候，虽然时间点4插入了一条 id 为6的数据，并且在时间点5提交了事务，但是时间点6还是查询不到 id 为6的这条数据，查询结果和第2个时间点的查询结果没有区别。
• 在第7个时间点的时候，查询结果就有了变化，因为 update 操作是当前读，而事务B在第5个时间点已经提交了一条 id 为6的数据，根据当前读的规则，此刻是可以读取到 id 为6 的数据，也就可以更新 id 为 6 的数据。
• 第8个时间点的时候，执行第三次查询，此时是基于当前最新版本查询的，所以会查询到事务B提交的 id 为6的数据，对比第一次、第二次查询，多出了 id 为6的数据，这就是幻读。

当前读的幻读问题怎么解决？

加锁解决，关于锁的介绍，传送门如下：

MySQL–锁机制详解

#共享锁
SELECT * FROM user LOCK IN SHARE MODE;  
# 排他锁
SELECT * FROM user FOR UPDATE; 
# 排他锁
INSERT INTO  user 
# 排他锁
UPDATE user 
# 排他锁
DELETE FROM  user 
1
2
3
4
5
6
7
8
9
10

注意：INSERT、UPDATE 、DELETE 操作数据库默认加排他锁。

解决幻读问题演示：

• 在第2个时间点的时候，使用 lock in share mode 语法显示加锁了，不仅表中存在的数据加锁了，而且还给 id>5 的区间加了间隙锁。
• 因为时间点2的操作，给 id>5 的区间加了间隙锁 ，所以事务B 在时间点5的时候执行 INSERT 操作的时候，出现了阻塞。
• 因为时间点5的 INSERT 操作被阻塞了，所以这次查询的数据跟时间点2的查询结果完全一致。
• 事务B想要执行 INSERT 成功，必须要等待事务A 提交事务释放锁，这就解决了幻读问题。

MVCC可以解决更新丢失问题吗？

MVCC 解决的是读写并发问题，而更新丢失是写写并发问题，MVCC不能解决更新丢失问题，更新丢失依赖数据库的隔离级别来解决。

如有不正确的地方请各位指出纠正。