人阅读
一、说到mvcc就少不了事务隔离级别（大白话解释）
序列化（SERIALIZABLE）：事务之间完全隔离，当成一个序列，一个一个执行。
1
可重复读（REPEATABLE READ）：不会被看成一个序列，但是这个事务里发生的改变，另一个事务中是看不到的，即同时执行两个select结果是一样的。（默认）
1
提交读（READ COMMITTED）：这个事务里发生改变并且提交，在另一个事务里是可见的，两条select中间提交过数据，两次结果可能不同。
1
未提交读（READ UNCOMMITTED）：可以读到未提交的数据，容易产生幻读脏读。
1
幻读和脏读：
幻读是每次查询的数据不一样。
脏读是查询到了错误的数据。（查询到结果后有个事务回滚了）
二、mvcc
三个隐藏字段
DB_TRX_ID:记录最近更新这条行记录的事务ID，大小为6个字节。
DB_ROLL_PTR:表示指向该行回滚段的指针，innodb便是通过这个指针找到之前的版本数据。该行记录上所有旧版本，在undo中都通过链表的形式组织。
DB_ROW_ID:行标识，如果表没有主键，就会生成一个隐藏的主键。
三
MyISAM不支持事务，所以这里就说InnoDB
undo log是为了回滚用的。
虽然mvcc保证了读是一致的，能解决幻读，但是那是历史数据，并不是真的数据，涉及到的列，我直接锁住，别的事务在这里阻塞。
问：那提交读就不锁了吗？ 提交读中没有加间隙锁。但肯定使用了行锁，只有提交之后才能修改
事务和锁区别对待：
问：可提交读为啥不能解决幻读，可重复读为啥能解决幻读
后者间隙锁
仅仅行锁无法保证幻读，除非表锁。 这里说明可提交读如果表锁就能保证幻读。行锁的时候，就无法保证幻读。
未提交读 直接读取最新的数据
已提交读 每次查询的时候生成一个readview快照
可重读读 第一次读的时候生成一个快照，以后的就直接取这个快照
串行化：因为加锁，也不存在这个问题
几个数据：
当前活跃的事务id们 活跃最小 活跃最大+1（就是下次事务的id） 当前的事务id
判断版本：
1、如果版本和当前的是事务一样，就说明是当前的事务做的修改，可以直接使用
2、判断是不是小于最小活跃，如果小于，则说明生成readView的时候已经提交了，可以读
3、如果大于等于活跃最大+1,就说明是在这个事务之后开启的，不可见
4、如果是处于活跃列表中，则说明创建readView的时候，不在活跃列表中，就说明当时未提交，继续往前找