整理一下自己对mvcc的理解

mvcc这个词已经多次接触过了，也知道他叫多版本并发控制，不过对有些知识的认知有时候不是一蹴而就的，需要一个过程，之前读完一些博客，看过视频后觉得自己懂了又好像没有懂，这次同事问自己发现又很陌生了，说明并没有掌握，今天回过头看看资料梳理一下。

首先，mysql的读分为两种：当前读和快照读

当前读就是普通的select

快照读发生在mysql使用锁的时候，主要包括下列几种：

select ... lock in share mode;  共享锁

select ... for update; 排他锁

update ...; 排他锁

insert ...; 排他锁

delete ...; 排他锁

mvcc主要是为了提高并发的独写性能，不用加锁就能让多个事务并发独写（同一行数据多个事务修改会有排他锁）

mvcc是基于快照读的

 下面整理一下mvcc的主要实现原理：

mvcc主要是由undo_log+版本链+read view实现的

undo_log:每一行数据的插入、删除、修改都会记录在undo_log中，以保证事务执行失败时能回滚恢复现场（事务的原子性），此处的增删改包括未提交事务的操作

版本链：每一行数据的增删改操作，在记录修改后数据的同时，会记录该行数据（聚簇索引区分）的执行事务id（trx_id，整个mysql自增的事务id，session在begin开始事务并且执行第一条sql时由mysql生成）和回滚指针（roll_pointer，指向修改前上一个版本的地址）

read view:执行select快照读的时候记录的信息，包括select时所有未提交的trx_id数组（从数组中可以知道最小的未提交事务id，此处称为min_uncommit_trx_id）、当前事务的trx_id（current_trx_id）、最大事务id（max_trx_id，这个可以理解为select时系统准备给最新事务准备的trx_id）

在每次select快照读时，mysql会把read view作为数据筛选条件，按照下列规则一条条的对每一个符合where条件的undo_log进行过滤：

1：undo_log的trx_id如果等于readview中的current_trx_id--》该条数据可见

2：undo_log的trx_id如果小于readview中的min_uncommit_trx_id --》该条数据可见

3：undo_log的trx_id如果大于readview中的max_trx_id，说明该条undo_log是select以后生成的事务产生的--》该条数据不可见

mvcc只作用于已提交读和可重复读

（1）对于已提交读，每次select快照读时，都会生成新的readview，所以max_trx_id一定是最新的，undo_log的trx_id永远也不可能大于max_trx_id

（2）对于可重复读，每次select快照读时，使用的都是第一次生成的相同readview，为了保证可重复读，后续的select数据范围肯定不能超过第一次select的数据范围，所以如果undo_log的trx_id如果大于readview中的max_trx_id，该条数据不可见

4：undo_log_trx_id<= min_uncommit_trx_id <=max_trx_id，此时

如果undo_log_trx_id在uncommit_trx_id_array中，说明生成readview时该条undo_log事务未提交--》不可见；

反之，如果undo_log_trx_id不在uncommit_trx_id_array中，说明生成readview时该条undo_log事务已提交--》可见；

接下来理理可重复读有没有解决幻读的问题

幻读的问题在当前读的操作中是使用间隙锁解决的

在快照读中还是存在幻读的：

反证法：可重复读中第一次查询以后，同一个事务执行了增删操作，影响了返回条数，再查询根据readview自己修改的undo_log肯定是可见的，别的事务增删操作当前事务是不可见的。

对于删除操作，undo_log会复制一份数据，将trx_id改为删除事务的trx_id，同时修改该undo_log的头部信息deleted_flag标识为true