MySQL 中多版本并发控制（MVCC），是现代数据库引擎实现中常用的处理读写冲突的手段，MVCC 作为 MySQL 高级应用特性，目的在于提高数据库高并发场景下的吞吐性能。

一、MVCC出现背景是什么？

事务的4个隔离级别以及对应的3种异常：

• 脏读：一个事务读取到了另外一个事务没有提交的数据；

• 不可重复读：在同一事务中，两次读取同一数据，得到内容不同；

• 幻读：同一事务中，用同样的操作读取两次，得到的记录数不相同。

• 乐观锁：
  其实现如同它的名字一样，是假设比较好的情况。

  每次取数据的时候都认为他人不会对其修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。
• 悲观锁：
  悲观锁也如同它的名字一样，总是假设比较坏的情况，每次取数据的时候都认为他人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。

二、什么是MVCC，它解决了什么问题？

我们可以通过比较版本号决定数据是否显示出来（具体的规则后面会介绍到），读取数据的时候不需要加锁也可以保证事务的隔离效果。

• 快照读：
  读取的是快照数据，不加锁的简单的SELECT都属于快照读（只是普通的读操作）。

• 当前读：
  当前读就是读取最新数据，而不是历史版本的数据。

  加锁的SELECT，或者对数据进行增删改都会进行当前读（包括加锁的读取和DML操作）。

三、应用举例分析

假设有个账户金额表 user_balance，包括三个字段，分别是 username 用户名、balance 余额和 bankcard 卡号，表数据如下所示：

Case1：因为需要采用加行锁的方式，用户 A 给 B 转账时间等待很久，如下图所示。

Case2：当我们读取的时候用了加行锁，可能会出现死锁的情况，如下图所示。

比如当我们读到 A 有 1000 元的时候，此时 B 开始执行给 A 转账。

四、InnoDB如何实现MVCC？

1. 首先获取事务自己的版本号，也就是事务 ID；

2. 获取 Read View；

3. 查询得到的数据，然后与 Read View 中的事务版本号进行比较；
   

4. 如果不符合 ReadView 规则，就需要从 Undo Log 中获取历史快照；

5. 最后返回符合规则的数据。

Read VIew 中的几个重要属性：

• up_limit_id，活跃的事务中最小的事务 ID；

• trx_ids，系统当前正在活跃的事务 ID 集合；

• low_limit_id，活跃的事务中最大的事务 ID；

• creator_trx_id，创建这个 Read View 的事务 ID。

• DB_ROW_ID ：

  6-byte，记录操作该数据事务的事务ID；

• DB_TRX_ID ：

  6-byte，当创建表没有合适的索引作为聚集索引时，会用该隐藏ID创建聚集索引；

• DB_ROLL_PTR ：

  7-byte，回滚指针，指向上一个版本数据在undo log 里的位置指针；

回滚段中回滚指针间关联关系，如下图所示：
五、InnoDB是如何解决幻读的？

1、在读已提交的情况下，即使采用了 MVCC 方式也会出现幻读

我们同时开启事务 A 和事务 B，先在事务 A 中进行某个条件范围的查询，读取的时候采用排它锁，在事务 B 中增加一条符合该条件范围的数据，并进行提交，然后我们在事务 A 中再次查询该条件范围的数据，就会发现结果集中多出一个符合条件的数据，这样就出现了幻读。

• 记录锁：

  针对单个行记录添加锁。

• 间隙锁（Gap Locking）：

  可以锁住一个范围（索引之间的空隙），但不包括记录本身。

  采用间隙锁的方式可以防止幻读情况的产生。

• Next-Key 锁：

  锁住一个范围，同时锁定记录本身，相当于间隙锁 + 记录锁，可以解决幻读的问题。

这是因为采用了 Next-Key 锁，会将 height>2.08 的范围都进行锁定，就无法插入符合这个范围的数据了。然后事务 A 重新进行条件范围的查询，就不会出现幻读的情况。

六、总结

MVCC 的核心就是 Undo Log+ Read View。

• “MV”就是通过 Undo Log 来保存数据的历史版本，实现多版本的管理；

• “CC”是通过 Read View 来实现管理，通过 Read View 原则来决定数据是否显示。

同时针对不同的隔离级别，Read View 的生成策略不同，也就实现了不同的隔离级别。