MySQL MVCC多版本并发控制（脏读和不可重复读解决原理）

专栏持续更新中：MySQL详解

一、MVCC概念

MVCC是多版本并发控制（Multi-Version Concurrency Control），是MySQL中基于乐观锁理论实现隔离级别的方式，用于实现已提交读和可重复读隔离级别，也经常称为多版本数据库。MVCC机制会生成一个数据请求时间点的一致性数据快照（Snapshot)，并用这个快照来提供一定级别（语句级或事务级）的一致性读取。从用户的角度来看，好象是数据库可以提供同一数据的多个版本（系统版本号和事务版本号）

快照读（非锁定读）：读的是记录的可见版本，不用加锁。如 select做的都是快照读，会把已经commit的数据（即整表数据）生成一个快照（这就可以防止不可重复读）
当前读：读取的是记录的最新版本，返回当前读的记录，并且对数据加锁。如 insert，delete，update，select...lock in share mode/for update这些操作，都是读的是最新的数据

MVCC：每一行记录实际上有多个版本，每个版本的记录除了数据本身之外，增加了其它字段（DB_ROW_ID、DB_TRX_ID、DB_ROLL_PTR）

已提交读隔离级别：每个语句执行前都会重新生成一个 Read View，快照中只包含已commit的数据可重复读隔离级别：启动事务时生成一个 Read View，然后整个事务期间都在用这个 Read View，后续的查询语句利用这个 Read View，通过这个 Read View 就可以在 undo log 版本链找到事务开始时的数据，所以事务过程中每次查询的数据都是一样的

什么叫事务启动呢？

执行了 begin/start transaction 命令后，并不代表事务启动了。只有在执行这个命令后，执行了增删查改操作的 SQL 语句，才是事务真正启动的时机
执行了 start transaction with consistent snapshot 命令，就会马上启动事务

快照内容读取原则：

版本未commit，无法读取生成快照
版本已commit，但是在快照创建后提交的，无法读取
版本已commit，但是在快照创建前提交的，可以读取
当前事务做的修改，是需要重新生成快照的。读取的是最新版本，并且对数据加锁，阻塞其他操作事务修改记录。核心逻辑就是判断版本链中的哪个版本是当前事务可见可处理的

"数据快照"中并不是数据，存储的是一些事务id

Read View 有四个重要的字段：

creator_trx_id ：指的是创建该 Read View 的事务的事务 id
m_ids ：指的是在创建 Read View 时，当前数据库中「活跃事务」的事务 id 列表，注意是一个列表，"活跃事务"指的就是，启动了但还没提交的事务。重新生成数据快照m_ids可能会有更新，不重新生成数据快照m_ids就不会更新
min_trx_id ：指的是在创建 Read View 时，当前数据库中「活跃事务」中事务 id 最小的事务，也就是 m_ids 的最小值
max_trx_id ：这个并不是 m_ids 的最大值，而是创建 Read View 时当前数据库中应该给下一个事务的 id 值 ，也就是所有已提交的和未提交的事务中最大的事务 id 值 + 1

Innodb如何判断某条记录是否对当前事务可见呢？一个事务去访问记录的时候，除了自己的更新记录总是可见之外，还有这几种情况：

如果记录的 trx_id 值小于 Read View 中的 min_trx_id 值 ，表示这个版本的记录是在创建 Read View 前已经提交的事务生成的，所以该版本的记录对当前事务可见。
如果记录的 trx_id 值大于等于 Read View 中的 max_trx_id 值 ，表示这个版本的记录是在创建 Read View 后才启动的事务生成的，所以该版本的记录对当前事务不可见。
如果记录的 trx_id 值在 Read View 的 min_trx_id 和 max_trx_id 之间，需要判断 trx_id 是否在 m_ids 列表中：
- 如果记录的 trx_id 在 m_ids 列表中 ，表示生成该版本记录的活跃事务依然活跃着（还没提交事务），所以该版本的记录对当前事务不可见。
- 如果记录的 trx_id 不在 m_ids列表中 ，表示生成该版本记录的活跃事务已经被提交，所以该版本的记录对当前事务可见。