【MySQL是怎样运行的 | 第三篇】MySQL的MVCC机制

3.MySQL的MVCC机制

3.1前言

1. MVCC，在数据库中实现并发控制的技术，允许多个事务同时对数据库进行读写操作，而不会导致数据不一致或丢失
2. 核心思想：在数据库中维护多个数据版本，并根据事务的隔离级别来决定哪个版本数据对特定事务是可见的
3. 实现的四个重要部分：
   1. undo log日志
   2. 隐藏字段
   3. undo log版本链
   4. readView

3.2undo log日志

1. undo log（回滚日志）中记录了修改前的数据值，以及撤销操作所需的信息，以便在事务回滚或 MVCC 中使用

3.3三个隐藏字段

1. InnoDB会自动为每个undo log 回滚日志加上三个字段：
   1. DB_ROW_ID：隐藏主键
   2. DB_TRX_ID：创建该undo log 版本数据的事务ID
   3. DB_ROLL_PTR：回滚指针，指向这个事务之前的 undo log

3.4undo log版本链

1. undo log 版本链：基于undo log 回滚日志实现，维护了一条数据的多个版本

3.5当前读VS快照读

1. 当前读

   1. 读取的是当前记录的最新版本，读取的时候需要保证其他并发事务不能修改当前记录，对当前记录加锁
   2. 例子：Insert、Update、Delete、Select… for update（写锁）、Select… lock in share mode（读锁）

2. 快照读：

   1. 最普通的Select查询SQL语句
   2. 读取的是数据的可见版本，有可能是历史数据、当前版本，不加锁，是非阻塞读
   3. 底层依赖：当执行“快照读”SQL语句时，依据ReadView（快照） 来提取数据

3.6ReadView

1. ReadView，一个保存事务ID的list列表。记录的是本事务执行时，MySQL还有哪些事务在执行，且还没有提交
2. 一种数据结构，包含四个字段：
   1. m_ids：当前活跃的事务编号集合
   2. min_trx_id：最小活跃事务编号
   3. max_trx_id：预分配事务编号，即当前最大事务编号+1
   4. creator_trx_id：ReadView创建者的事务编号
3. 不同隔离级别下快照生成的时机：
   1. RC（读已提交）：每一次select，都生成一个 ReadView
   2. RR（可重复读）：开启一个事务之后，只有第一个select语句才会生成一张快照，此后读的都是快照中的数据，直到事务提交
   3. Serializable（可序列化）：快照读退化成当前读（加锁，阻塞，读取到的是最新的数据）
4. 根据ReadView快照访问undo log 版本链数据的规则：
   1. 若 trx_id==creator_trx_id？可以访问该版本，因为数据是当前这个事务更改的；
   2. 若 trx_id < min_trx_id？可以访问该版本，因为数据已经提交了；
   3. 若 trx_id > max_trx_id？不可以访问该版本，因为该事务修改的数据是在 ReadView生成后才开启的；
   4. 若 min_trx_id<=trx_id<=max_trx_id 并且 trx_id不在 m_ids（活跃事务编号集合）中，可以访问该版本，因为该数据已经提交；

3.7举例

3.7.1RC（读已提交）

1. 其中事务4的两次快照读均会产生ReadView，如下：

2. 分析第一个ReadView：

3. 分析第二个ReadView：

4. 小结：

   1. 在RC（读已提交）的事务隔离级别下，同一事务的两次快照读均会产生两个快照（ReadView）；
   2. 第一个快照读读取的数据是 事务一修改并提交的数据：张三
   3. 第二个快照读读取的数据是 事务二修改并提交的数据：张小三
   4. 同一事务的两个不同select（快照读）读取的数据不一样，产生不可重复读现象

5. 思考：应该怎么解决？

6. 解决：设置隔离级别为 RR（可重复读），同一事务从始至终只会生成一个快照

3.7.2RR（可重复读）

1. 隔离级别为 RR（可重复读），同一事务从始至终只会生成一个快照，即不会产生 不可重复读问题

3.8扩展：RR能解决幻读问题吗？

1. 结论：RR（可重复读）可以解决一部分幻读问题

2. 原因：

   1. 同一事务的连续多次快照读，ReadView会产生复用，没有幻读问题

   2. 特例：当两次快照读之间存在当前读，ReadView会重新生成，导致幻读问题

      

4.白云