概述

• 事务的ACID特性里面，Mysql通过MVCC机制来保证隔离性，实现可重复读的特性，但是可能会出现幻读的情况。

• MVCC的读取需要check3个条件：创建Txid、删除Txid、活跃事务列表中的先后顺序

• 活跃事务列表：记录每个未提交的事务，在事务开始时的数据状态，读取的时候必须要保证小于此时的数据状态，从而保证可重复读

MVCC下的写操作伴随着真实的操作索引的，这是导致了幻读的现象，但是可以保证索引的快速感知。
比如唯一性索引，事务A尝试插入一个值，但是没有提交。此时事务B尝试插入一个相同的值，这个时候就会出现幻读，系统快速反馈插入失败，避免了事务B只有在提交的时候，才感知到这个事情。

Mysql的MVCC依赖：Txid和活跃事务列表

1. 比如当前系统Txid=1000，数据a=100
2. 开始事务A Txid=1001，事务A修改一个数据a=200，该数据的TXID=1001，但是未提交
3. 此时开启事务B，Txid=1002，读取数据a=100
4. 此时事务A提交数据 TXID=1001，数据a的最新版本是1001
5. 此时事务B重复读取数据a，数据a在系统中的Txid为1001，但是仍然读取不到，否则就不叫可重复读了，MVCC会去热点视图中check，Txid1001的数据，是否在Txid1002开启的时候已经提交。如果已经提交就可以读取，如果未提交，则要排除掉这个数据。

读写规则

1. SELECT

• InnoDB只查找数据行的版本必须小于等于事务的版本的数据，这确保当前事务读取的行都是事务之前已经存在的，或者是由当前事务创建或修改的行
• 热点数据表中，该数据的Txid在开启当前Txid是已经提交过了的，未提交也不能读取
• 行的删除操作的版本一定是未定义的或者大于当前事务的版本号。确定了当前事务开始之前，行没有被删除

这种机制避免了3种情况：

• Txid比拼：数据是后来事务写入的数据，避免读到
• 热点视图check：避免A事务先于B事务开启但是未提交，B事务在A事务提交之前和提交之后读取的数据不一致
• 避免在读取到在事务开始时就已经删除了的数据

2. INSERT:InnoDB为每个新增行记录当前系统版本号作为创建ID。
3. DELETE:InnoDB为每个删除行的记录当前系统版本号作为行的删除ID。
4. UPDATE:InnoDB复制了一行。这个新行的版本号使用了系统版本号。它也把系统版本号作为了删除行的版本。

参考

官网说明
https://dev.mysql.com/doc/refman/5.7/en/innodb-multi-versioning.html

热点视图
https://www.cnblogs.com/chinesern/p/7592537.html