MVCC多版本并发控制机制：

靠MVCC(Multi-Version Concurrency Control)机制：
对一行数据的读和写两个操作默认 是不会通过加锁互斥来保证隔离性，避免了频繁加锁互斥，而在串行化隔离级别为了保证较高的隔离性是通过将所有操 作加锁互斥来实现的。 Mysql在读已提交和可重复读隔离级别下都实现了MVCC机制。

MVCC机制的实现就是通过read-view机制与undo版本链比对机制，使得不同的事务会根据数据版本链对比规则读取 同一条数据在版本链上的不同版本数据。

读已提交、可重复读：两个事务，可同时update一行数据，但是又能保证事务读的隔离性，靠的是MVCC
串行化: 两个事务，不可同时update一行数据，靠的是互斥锁

undo日志版本链：

一行数据数据被多个事务依次修改（update）过后，在每个事务改完后，Mysql会保留修改前的数据Undo回滚日志，并且用两个隐藏字段trx_id和roll_pointer把这些Undo日志串联起来形成一个日志版本链。

对于删除的情况可以认为是update的特殊情况，会将版本链上最新的数据复制一份，然后将trx_id修改成删除操作的 trx_id，同时在该条记录的头信息（record header）里的（deleted_flag）标记位写上true，来表示当前记录已经被 删除，在查询时按照上面的规则查到对应的记录如果delete_flag标记位为true，意味着记录已被删除，则不返回数 据。

read view一致性视图

在可重复读（RR）级别，当事务开启，执行任何查询sql时会生成事务的一致性视图。
（注意：begin不会马上生成read view，并不是事务的起点，只有查询第一条查询sql或者update时才会生成read view）。
生成read view后，不会再改变，直到事务结束。
（如果是读已提交，那么会每查询一次sql都会生成一次新的read view ）.
read view 由 所有未提交的事务id数组（数组中最小的事务为min_id），和创建的最大事务Id(max_id)
事务里面的任何查询结果需要从对应的版本链里面的最新数据开始逐条跟read view做对比得到快照结果。

对比规则：

1. 如果 row 的 trx_id 落在绿色部分( trx_id<min_id )，表示这个版本是已提交的事务生成的，这个数据是可见的；
2. 如果 row 的 trx_id 落在红色部分( trx_id>max_id )，表示这个版本是由将来启动的事务生成的，是不可见的(若
   row 的 trx_id 就是当前自己的事务，是可见的）；
3. 如果 row 的 trx_id 落在黄色部分(min_id <=trx_id<= max_id)，那就包括两种情况
   a. 若 row 的 trx_id 在视图数组中，表示这个版本是由还没提交的事务生成的，不可见(若 row 的 trx_id 就是当前自
   己的事务是可见的)；
   b. 若 row 的 trx_id 不在视图数组中，表示这个版本是已经提交了的事务生成的，可见。

如图所示，在表格D列中，第一条查询Sql，才开始生成一致性视图：readview:[100,200],300

undo日志如图：

根据undo版本链和readview，可知trx_id事务Id为100,200在视图数组中，D列中的事务不可见。而trx_ix=300的事务id不再视图数组中，可见。