简单背景介绍
MySQL
MySQL是现在最流行的关系型数据库（RDB）的选择，为了应用程序提供可靠性数据存储，事务等功能。近些年来也成为了互联网公司的首选。在5.5版本后，默认使用InnoDB存储引擎。
MySQL架构
顶层是接入层，为不同语言实现接入，接入层负责权限校验，线程池管理，线程管理。接下来是MySQL服务层，有SQL解析器，SQL优化器，数据缓冲，缓存。再接下来是存储引擎。最后是系统文件层。
InnoDB与MVCC
MySQL中的InnoDB存储引擎的特性有，默认级别的Repeatable Read，行级锁，实现了MVCC，Consistent nonlocking read（默认读不加锁，一致性非锁定读），Insert Buffer，Adaptive Hash Index，Double Write，Cluster Index。
上面举了这么多例子，说明InnoDB有很多特性，并且很快。
InnoDB中通过Undo Log实现了数据的多版本，而并发控制通过锁来实现。
Undo Log除了实现了MVCC之外，还提供了回滚的功能。
Redo log，Undo log， Bin log
MySQL InnoDB有很多日志，除了错误日志，查询日志还有很多与持久化相关的日志。
bin log：由MySQL服务层产生的日志，通常用于数据恢复，数据库复制。比如常见的master-slave模式，就是通过binlog实现的，另外binlog还能实现mysql复制到其他数据源，比如：ElasticSearch。
redo log：记录了数据在物理层面到修改，MySQL中使用了大量到缓存，当缓存中的数据与磁盘中的数据不一致时，这是内存里的数据称为脏页（dirty page）。为了保证数据的安全性，事务中不断产生redo log，在事务提交的时候会进行一次flush操作，保存到磁盘，redolog是顺序写入，性能远大于随机读写。当MySQL故障恢复时，会加载redo log中的数据，如果redo log中有事务提交，则进行提交修改数据。这样保证了事务的一致性，原子性，持久性。
undo log：除了记录redo log之外，还会记录undo log，undo log记录数据的逆向操作，比如修改删除操作，记录的是数据修改前的值，用于回滚，以及版本回溯。可以根据undo log找到某个特定版本的值，这样就实现了MVCC。
redo log和bin log要具有一致性，为了实现一致性，MySQL采用了二阶段提交。
MVCC实现
undo log分为Insert和Update两种，Delete操作也被看做是一种特殊的Update，在记录上标记被删除。
对于Insert操作，插入时候生成Insert undo log，在事务提交后，即可删除undo log，因为没有其他的事务需要这个undo log。
在进行Update操作的时候，会生成新的undo log，将当前记录中的db_roll_ptr指向新的undo log。
RR级别下事务开始后的第一个snapshot read的时候，会将当前活动的事务id记录下来，记录到read view中。
