MVCC解决了什么问题

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

InnoDB 中的 MVCC 是如何实现的

1. 事务版本号 每开启一个事务，我们都会从数据库中获得一个事务 ID（也就是事务版本号），这个事务 ID 是自增长的，通过 ID 大小，我们就可以判断事务的时间顺序。

2. 行记录隐藏列

• db_row_id：隐藏的行 ID，用来生成默认聚集索引。如果我们创建数据表的时候没有指定聚集索引，这时 InnoDB 就会用这个隐藏 ID 来创建聚集索引。采用聚集索引的方式可以提升数据的查找效率。
• db_trx_id：操作这个数据的事务 ID，也就是最后一个对该数据进行插入或更新的事务 ID。
• db_roll_ptr：回滚指针，也就是指向这个记录的 Undo Log 信息。

3. Undo Log

4. Read View 是如何工作的 Read View 保存了当前事务开启时所有活跃（还没有提交）的事务列表，换个角度你可以理解为 Read View 保存了不应该让这个事务看到的其他的事务 ID 列表。

在 Read VIew 中有几个重要的属性：

• trx_ids，系统当前正在活跃的事务 ID 集合。
• low_limit_id，活跃的事务中最大的事务 ID。
• up_limit_id，活跃的事务中最小的事务 ID。
• creator_trx_id，创建这个 Read View 的事务 ID。

假设当前有事务 creator_trx_id 想要读取某个行记录，这个行记录的事务 ID 为 trx_id，那么会出现以下几种情况。

• 如果 trx_id < 活跃的最小事务 ID（up_limit_id），也就是说这个行记录在这些活跃的事务创建之前就已经提交了，那么这个行记录对该事务是可见的。

• 如果 trx_id > 活跃的最大事务 ID（low_limit_id），这说明该行记录在这些活跃的事务创建之后才创建，那么这个行记录对当前事务不可见。

• 如果 up_limit_id < trx_id < low_limit_id，说明该行记录所在的事务 trx_id 在目前 creator_trx_id 这个事务创建的时候，可能还处于活跃的状态，因此我们需要在 trx_ids 集合中进行遍历，如果 trx_id 存在于 trx_ids 集合中，证明这个事务 trx_id 还处于活跃状态，不可见。否则，如果 trx_id 不存在于 trx_ids 集合中，证明事务 trx_id 已经提交了，该行记录可见。

当查询一条记录的时候，系统如何通过多版本并发控制技术找到它：

• 首先获取事务自己的版本号，也就是事务 ID；
• 获取 Read View；查询得到的数据，然后与 Read View 中的事务版本号进行比较；
• 如果不符合 ReadView 规则，就需要从 Undo Log 中获取历史快照；
• 最后返回符合规则的数据。

读已提交：每次查询都会获取readView 可重复读：事务开启时获取readView

解决幻读

在可重复读的情况下，InnoDB 可以通过 Next-Key 锁 +MVCC 来解决幻读问题。

InnoDB 三种行锁的方式：

• 记录锁：针对单个行记录添加锁。
• 间隙锁（Gap Locking）：可以帮我们锁住一个范围（索引之间的空隙），但不包括记录本身。采用间隙锁的方式可以防止幻读情况的产生。
• Next-Key 锁：帮我们锁住一个范围，同时锁定记录本身，相当于间隙锁 + 记录锁，可以解决幻读的问题。

---

此文章为4月Day24学习笔记，内容来源于极客时间《SQL必知必会》