InnoDB存储引擎核心特性：MVCC

MVCC概念

多版本并发控制(Multiversion Concurrency Control)指的是一种提高并发性能的技术。最早的数据库系统，只有读读之间可以并发，读写、写读、写写都要被阻塞。引入MVCC之后，只有写写之间相互阻塞，其它三种操作都可以并行，这样就大幅提高InnoDB存储引擎的并发性能。
在内部实现中，InnoDB存储引擎通过undo log保存每条数据的多个版本，并且能够找回数据历史版本提供给用户读，每个事务读到的数据版本可能是不一样的。在同一个事务中，用户只能看到该事务创建快照之前已经提交的修改和该事务本身做的修改。
MVCC只在"Read Committed"和"Repeatable Read"两个隔离级别下工作
MySQL的InnoDB存储引擎默认事务隔离级别是RR(可重复读)，是通过"行级锁+MVCC"一起实现的，正常读的时候不加锁，写的时候加锁。而MVCC的实现依赖：隐藏字段、Undo log中的版本链和Read View。

隐藏字段

首先需要知道的是，InnoDB存储引擎会默认在表中的每行数据的后面添加了三个隐藏字段：

• DB_ROW_ID：行ID，随着新行插入而单调递增的行ID。InnoDB存储引擎的B*树索引特性要求每个表必须要有一个主键。如果没有设置的话，会自动寻找第一个不包含NULL的唯一索引列作为主键。如果还找不到，就会在这个DB_ROW_ID上自动生成一个唯一值，以此来当作主键
• DB_TRX_ID：事务ID，记录的是当前事务在做"insert"或"update"语句操作时的事务ID。至于"delete"操作，InnoDB存储引擎认为是一个特殊的"update"操作，不过会更新一个删除位，将行表示为"deleted"，并非真正删除
• DB_ROLL_PTR：回滚指针，通过它可以将不同的版本串联起来，形成版本链。相当于链表的next指针

ReadView(快照)

ReadView一致性试图主要由两部分组成：所有未提交的事务的ID数组和已经创建的最大事务ID组成(实际上ReadView还有其它的字段，但是不影响这里对MVCC的讲解)。
比如：[100,200],300
事务100和200是当前未提交的事务，而事务300是当前创建的最大事务(已经提交了)。当执行"select"语句的时候会创建ReadView，但是在"Read Committed"和"Repeatable Read"两个隔离级别下，生成ReadView的策略是不一样的

• "Read Committed"隔离级别：事务在begin之后，执行每条"select"语句时，Read View都会被重新创建一次
• "Read Repeatable"隔离级别：只有事务在begin之后，执行第一条"select"时，才会创建一个Read View，将当前系统中活跃的其它事务记录起来；并且事务之后都是使用这个Read View(即使事务开始后有更新的语句，也会继续沿用)，不会重建创建，直到事务结束。

Undo log

Undo log中存储的是老版数据，当一个事务需要读取记录时，如果当前记录不可见，可以顺着Undo log中的版本链找到满足其可见性条件的记录行版本。
大多数对数据的变更操作包括"insert/update/delete"，在InnoDB存储引擎中，Undo log分为如下两类：

• insert undo log：事务对"insert"新纪录时产生的undo log，只在事务回滚时需要，并且在事务提交后就可以立即丢弃。
• update undo log：事务对记录进行"delete"和"update"操作时产生的undo log，不仅在事务回滚时需要，快照读也需要，只有当数据库所使用的快照中不涉及该日志记录，对应的回滚日志才会被purge线程删除。

purge线程：为了实现InnoDB存储引擎的MVCC机制，更新或者删除操作都是只设置一下旧纪录的deleted_bit，并不是真正将旧纪录删除。
为了节省磁盘空间，InnoDB存储引擎有专门的purge线程来清理deleted_bit为true的记录。purge线程自己也维护了一个read view,如果某个记录的deleted_bit为true,并且DB_TRX_ID相对于purge线程的read view可见，那么这条记录一定是可以被安全清除的。

记录修改的具体流程

假设有一条记录如下，字段有Name和Honor，值分别为"curry"和"mvp"，最新修改这条记录的事务ID为1。

1、现在事务A（事务ID为2）对该记录的Honor字段做出了修改，将Honor字段改为"fmvp"：

1. 事务A先对该行加排它锁
2. 然后把该行数据拷贝到undo log中，作为旧版本
3. 拷贝完毕后，修改该行的Honor字段的值为"fmvp"，并且修改DB_TRX_ID为2（事务A的ID），回滚指针指向拷贝到undo log中的旧版本。（然年还会将修改后的最新数据写入redo log）
4. 事务提交、释放排它锁
   

2、接着事务B（事务ID为3）修改同一个记录行，将Name字段的值修改为"iguodala"：

1. 事务B先对该行加排它锁
2. 然后把该行数据拷贝到undo log中，作为旧版本
3. 拷贝完毕后，修改该行Name字段的值为"iguodala"，并且修改DB_TRX_ID为3（事务B的ID），回滚指针指向拷贝到undo log最新的旧版本。
4. 事务提交，释放排它锁
   
   从上面可以看出，不同事务或者相同事务对同一记录行的修改，会使该记录行的undo log成为一条链表，undo log的链首就是最新的旧纪录，链尾就是最早的旧纪录。

可见性比较算法

在InnoDB存储引擎中，创建一个新事物后，执行第一个select语句的时候，InnoDB存储引擎会创建一个Read View(快照)，快照中会保存系统当前所有未提交的事务的ID数组（即trx_ids）和已经创建的最大事务ID。但用户在这个事务中要读取某个记录行的时候，InnoDB存储引擎会将该记录行的DB_TRX_ID与Read View中的一些变量进行比较，判断是否满足可见性条件。
假设当前事务要读取某一个记录行，该记录行的DB_TRX_ID（即最新修改该行的事务ID）为trx_id，Read View中所有未提交事务ID数组trx_ids中最早的事务ID为"up_limit_id"（源码中的一个参数），将在生成这个Read View时系统出现过的最大的事务ID+1记为"low_limit_id"（即还未分配的事务ID）。
具体的比较算法如下：

1. 如果trx_id < up_limit_id，那么表明"最新修改该行的事务"在"当前事务"创建快照之前就已经提交了，所以该记录行的值对当前事务是可见的。跳到步骤5

2. 如果trx_id >= low_limit_id，那么表明"最新修改行的事务"在"当前事务"创建快照之后才修改该行，所以该记录行的值对当前事务不可见。跳到步骤4。

3. 如果up_limit_id <= trx_id <=low_limit_id，表明"最新修改行的事务"在"当前事务"创建快照的时候可能处于"活跃状态"或者"已提交状态"；所以就要对Read View中未提交的事务列表trx_ids进行查找（源码中是二分查找，因为是有序的）：
   （1）如果在Read View中未提交事务列表trx_ids中能够找到ID为trx_id的事务，有两种情况：一、在 “当前事务” 创建快照前，“该记录行的值” 被 "id号为trx_id的事务"修改了，但是没有提交；二、在 “当前事务” 创建快照后，“该记录行的值” 被 “id号为trx_id的事务"修改了（不关有无提交）；这两种情况下，这个记录行的值对当前事务都是不可见的，跳到步骤4；
   （2）在Read View中未提交事务列表中找不到，则表明"id为trx_id的事务” 在修改 "该记录行的值"后，在"当前事务"创建快照前就已经提交了，所以记录行对当前事务可见，跳到步骤5。

4. 在该记录行的DB_ROLL_PTR指针所指向的undo log回滚段中，取出最新的旧事物号DB_TRX_ID，将它赋值给trx_id，然后跳到步骤1重新开始判断。

5. 将该可见行的值返回。

当前读和快照读

• 快照读(snapshot read)：普通的"select"查询语句就是快照读
• 当前读(current read)：所谓当前读就是从表中读取当前的数据，“select … lock in share mode”、’'select … for update"、“insert”、“update”、"delete"语句都是当前读，读取的是表中最新数据

只靠MVCC实现RR隔离级别，可以保证重复读，还可能防止部分幻读，但是并不是完全防止。

比如事务A开始后，执行了普通"select"语句，创建了Read View ；之后事务B执行"insert"语句；然后事务A再执行普通"select"语句，得到的还是之前事务B没有"insert"过的数据。因为这时候事务A读的数据是符合快照可见性条件的数据。这样就防止不可重复读

但是，如果事务A执行的不是普通"select"查询语句，而是"select … for update"等语句，这时候，事务A是当前读，每次执行此类语句时都是获取最新的数据。也就是说，在只有MVCC时，事务A先执行"select … where id between 1 and 10 … for update"，然后事务B再执行"insert … id=5 …"，最后事务A再执行"select … where id between 1 and 10 … for update"就会发现多了一条事务B"insert"进去的记录(因为"select … for update"等语句获取的是表中当前数据)。这就产生了幻读了。所以单靠MVCC并不能完全防止幻读。

因此，InnoDB存储引擎在实现RR隔离级别是，不仅使用了MVCC，还会对"当前读语句"读取的记录行加上行锁和间隙锁，来防止幻读。也就是前文说的"行级锁+MVCC".

参考文章：
https://blog.csdn.net/Waves___/article/details/105295060
https://blog.csdn.net/weixin_30342639/article/details/107552255