MVCC机制
MVCC（Multi-Version Concurrency Control） 即多版本并发控制，了解mvcc机制，需要了解如下这些概念
事务id
事务每次开启时，都会从数据库获得一个自增长的事务ID，可以从事务ID判断事务的执行先后顺序。这就是事务版本号。
隐藏列
对于InnoDB存储引擎，每一行记录都有两个隐藏列trx_id、roll_pointer,如果数据表中存在主键或者非NULL的UNIQUE键时不会创建row_id,否则InnoDB会自动生成单调递增的隐藏主键row_id。
trx_id用来标记最后更新的事务id，roll_pointer用来指向上一个版本的undo_log。这样每次修改都会记录，形成一个undoLog构成的版本链。
undoLog
这个我们上面已经说过了，历史版本日志
快照读和当前读
快照读： 读取的是记录数据的可见版本（有旧的版本）。不加锁,普通的select语句都是快照读
当前读：读取的是记录数据的最新版本，显式加锁的都是当前读。该锁属于悲观锁，防止其他事务来修改更新数据，需要读取到所有提交记录中的最新数据。
select * from user where id = 1 for update; 读写锁，排他锁
select * from user where id = 1 lock in share mode; 读锁，共享锁
由于在可重复读级别中，默认是快照读，并不会读取到其他事务添加的数据。
但是如果是当前读的话，一个事务多次读取就可能会读取到其他事务插入的数据，比如查询id > 10 and id < 15的数据，原本只有11，13这两条数据，但是另一个事务可能会添加一条id=12的数据。导致幻读的产生（幻读只与插入有关）。所以后来InnoDB引入了间隙锁，默认加行锁的时候也会同时加上间隙锁。作用就是行与行直接在该事务中不能插入新的数据。需要注意的是间隙锁的前开后闭原则。
ReadView
就是在事务进行快照读的时候生成的一个记录快照，可以帮助我们解决可见性的问题。
有以下这几个属性
● 当前活跃的事务id列表，也就是操作该数据的所有未提交事务的id，可称为 trx_ids （随便起的名字）
● 当前操作该数据事务id的最小值（up_trx_limit）
● 操作该数据最大事务id+1，就是即将被分配的下一个事务id（up_trx_max）
● 创建该快照的事务id（create_trx）
需要注意，这个ReadView并不存储我们需要查询的真实数据，只有这几个属性，作用就是用来判断真实数据的版本是否符合要求，是否可以被当前事务获取到。
并且在RC可读已提交的级别下，每一次select都会生成ReadView；而在RR可重复读级别下，只有该事务的第一次select会生成ReadView；这就是RC和RR最大的不同
MVCC实现逻辑
mvcc就是通过ReadView + undoLog来实现的
判断的逻辑如下：
- 拿到数据中最新版本的数据，获取其中的trx_id，最近更新的事务id
- 判断这个trx_id是否与ReadView中的创建事务id - create_trx一致，如果一致的话证明该数据没有被其他事务修改过，可以直接返回；否则进入下一步
- 判断trx_id是否小于当前操作事务的最小id-up_trx_limit，是的话证明其他事务还未操作过该版本数据，可以直接返回；否则进入下一步
- 判断trx_id是否小于当前操作事务最大id-up_trx_max，如果大于的话，则证明这个版本的产生时间比当前查询事务还晚，那肯定是不行的，要通过数据的roll_pointer指针来获取undoLog中上一个版本的数据，回到第一步重新判断；如果过是小于的话，进入下一步
- 判断trx_id是否在当前未提交的活跃事务id列表中trx_ids。如果存的话，证明这个事务还未提交，需要要通过数据的roll_pointer指针来获取undoLog中上一个版本的数据，回到第一步重新判断；如果不存的话，那证明修改该数据的事务以及提交，数据可以返回
幻读问题
mvcc没有解决幻读的问题，幻读的问题是通过间隙锁来解决的
在快照读模式下，是通过mvcc机制来解决的；当前读模式下是通过间隙锁来解决的。
预告
下一章开始详细了解一下bufferPool缓存页的构成，以及缓存页如何更新，使用哪些优秀的算法等