MVCC（多版本并发控制）
一、什么是MVCC
MVCC是为了解决数据库在不加锁的前提下提升并发性和读取效率的一种思想
数据库有已下几种并发情况
- 读-读：不会产生并发问题
- 读-写：发生隔离性问题，可能导致脏读、幻读、不可重复度
- 写-写：可能存在数据丢失
为了防止并发问题，一般采用两种读取方式；
- 当前读：DML语句和加排它锁，select lock in share mode加共享锁，确保读取为最新数据
- 快照读：读写时不加锁、可能读取到历史数据
当前读（加锁）+快照（MVCC）读保证了事务的隔离性
MVCC 就是为了实现读-写冲突不加锁，而这个读指的就是
快照读, 而非当前读，当前读实际上是一种加锁的操作，是悲观锁的实现
二、MVCC实现原理
三个部分：隐式字段+undo版本链+read view视图
2.1、隐式字段
表内的每行记录除了我们自定义的字段外，还有数据库隐式字段段DB_TRX_ID, DB_ROLL_PTR, DB_ROW_ID
- DB_TRX_ID ：记录创建这条记录或最后一次修改该记录的事务 ID
- DB_ROLL_PTR：回滚指针，指向这条记录的上一个版本
- DB_ROW_ID：隐含的自增 ID（隐藏主键），当前表没有主键，InnoDB 自动产生聚集索引
2.2、undo版本链
不同的事务或相同事务对同一条记录修改是，会将当前记录先copy一份当undo log中，同时该记录的DB_TRX_ID会自增，DB_ROLL_PTR指向修改前记录的地址。以此形成版本链表
2.3、read view视图
如上图，现在我们生成了4个版本，当select的时候会选取哪个版本呢？这时候就需要根据read view里维护的字段通过一定规则对比后最终确认所读取的版本
当然，不同隔离级别下生成read view的时机不同
RC级别下：每次select都会生成一个read view
RR级别下：开启事务后第一个select生成read view，后续的select复用当前read view（由此可知在read view相同的情况下，根据一定规则匹配后读取到的版本肯定是相同的，也就解决了不可重复读的问题）
- m_ids:未提交事务的DTX_ID的集合
- creator_trx_id：创建read view视图视图的事务ID
总结一下：
当前事务或其它事务修改同一个数据时，会被undolog记录，并通过roll_point形成版本链，接着read view会根据里面维护的字段通过一定规则对比各个版本数据的隐式字段，最终匹配出可查询的版本具体为哪一个。当然，由于隔离级别不同，产生read view的时机不同，读取到的版本也不同，RC：每一次快照度都会产生read view、RR：第一次快照度后产生read view，后续复用