1.MVCC
MVCC(Mutil-Version Concurrency Control)，就是多版本并发控制。这种并发控制的方法，主要应用在RC和RR隔离级别的事务当中，利用执行select操作时，访问记录版本链，使得不同事物的读写，写读可以并发执行，提高系统性能。
2.版本链
Innodb 有两个隐藏字段 trx_id(事务id)和roll_pointer(回滚指针)。
transaction id：
innoDB里面每个事务有一个唯一的事务ID，叫作transaction id，它是在事务开始的时候向InnoDB的事务系统申请的，是按申请顺序严格递增的。
roll_pointer：
指向上一事务版本的指针。
版本链：
是一个单链表结构，对于同一行数据，每一个事务对其进行更新的时候都会产生一个新的版本，就会存储在这个链表当中。
3.ReadView
一个存储事务id的列表。
readview的几个参数：
m_ids:表示活跃事务id列表
min_trx_id:活跃事务中的最小事务id
max_trx_id:已创建的最大事务id
creator_trx_id:当前的事务id。
readview的生成时机：
RC隔离级别：每次读取数据前，都生成一个readview；
RR隔离级别：在第一次读取数据前，生成一个readview；
使用场景：
[ 创建事务节点 ] 当我创建一个新的事务需要读取一行数据, 我会查询活跃的事务列表; 假设我当前的事务id是200, 当前活跃的事务id没有我的200, 因此需要去拷贝一个最新的不活跃事务并在版本链最后插入一个新节点200; mysql会去对比版本链和readView, 假设版本链数据为[1,50,100,150], 活跃列表为[100,150], 说明100和150都是未提交的活跃事务, 再向前一个节点50不在活跃事务列表说明事务50已经提交, 所以事务200拷贝事务50并插入版本链最后, 且将200追加到readView活跃列表的最后一个元素
[ 使用事务节点 ] 当我再次进行200号事务的查询或修改, 我需要读版本链的数据, 因为上一次操作已经在版本链做了200号节点, 因此我读的数据都是200号节点的数据, 这样就隔离了其他未提交的事务; 我的全部增删查改都在200号版本链上进行
[ readView实现事务隔离级别 ]以上两点都是基于隔离级别"读已提交"来进行说明的; 当mysql设置为"可重复读"时, 不同事务仍然是保存在版本链的不同节点上, 只不过新的事务创建的时候拷贝了当下的readView列表, 只要新事物不提交就一直使用这个拷贝的活跃列表; 假设此时100号数据提交了, 我在新事务执行了select 会去查活跃列表发现100号事务还是未提交状态, 因此读取到的还是50号事务提交的记录。
4.事务的四大特性
原子性，一致性，隔离性，持久性。
- 原子性(Atomicity) :强调的事务的不可分割.
- 一致性(Consistency) :强调的事务的执行前后,数据库的的完整性保持一致.
- 隔离性(Isolation) :强调的事务的并发的访问,一个事务的执行,不应该受到另一个事务的打扰.
- 持久性(Durability) :强调的事务结束之后,数据就永久的保存的数据库中.
5.事务隔离级别
未提交读（read uncommitted）、提交读（read committed）、可重复读（repeatable read）、序列化读（serializable）
- read uncommitted：
可以读到其他事务未提交的数据，有可能产生脏读 - read committed：
读提交，就是一个事务要等另一个事务提交后才能读取数据。
有可能产生无法读取到最初的原数据，即不可重复读。 - repeatable read：
重复读，就是在开始读取数据（事务开启）时，不再允许修改操作。
但是，不可重复读对应的是修改，即UPDATE操作。但是可能还会有幻读问题。因为幻读问题对应的是插入INSERT操作，而不是UPDATE操作。 - Serializable ：
Serializable 是最高的事务隔离级别，在该级别下，事务串行化顺序执行，可以避免脏读、不可重复读与幻读。但是这种事务隔离级别效率低下，比较耗数据库性能，一般不使用。
