多版本并发控制：读取数据时通过一种类似快照的方式将数据保存下来，这样读锁就和写锁不冲突了，不同事务会话看到自己特定版本的数据，使用版本链。

MVCC只在READ COMMITTED 和 REPEATABLE READ 两个隔离级别下工作。其他两个隔离级别和MVCC不兼容，因为READ UNCOMMITTED总是读取最新的数据行，而不是符合当前事务版本的数据行。而SERIALIZABLE则会对所有读取的行都加锁。

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

行记录的隐藏列：InnoDB的叶子段存储了数据页，数据页中保存了行记录，而在行记录中有一些重要的隐藏字段，如下所示：

db_row_id:隐藏的行ID，用来生成默认的聚簇索引。如果我们创建数据表的时候没有指定聚簇索引，并且没有唯一索引，这时候InnoDb就会使用这个隐藏ID来创建聚簇索引，采用聚簇索引的方式可以提升数据的查询效率。
db_trx_id : 操作这个数据的事务ID，也就是最后一个对该数据进行插入或更新的事务ID。
db_roll_ptr：回滚指针，也就是指向上一个事务的undo log 日志记录 。这样就形成了版本链。

已提交读和可重复读的区别就在于他们生成ReadView的策略不同

ReadView是如何工作的
在mvcc机制中，多个事务对同一个记录进行更新会产生多个历史快照，这些历史快照保存在Undo log里。如果一个事务要查询这些记录，需要读取哪个版本的历史数据呢？这时就需要用到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，那么会出现以下几种情况。

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

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

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

了解了这写概念之后，我们看一下当查询一条记录的时候，系统如何通过多版本并发控制技术找到它：

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

已提交读隔离级别下的事务在每次查询的开始都会生成一个独立的Read View，而可重复读隔离级别则在第一次读的时候生成Read View，之后都复用这个Read View。