redo log 实现了事务的持久性
如果没有redo log，可能出现脏页现象，导致从缓冲池中更改后加载到硬盘的过程中出现脏页，无法保证持久性。
redo log会记录内存结构中缓冲区中的增删改变化，即时出现脏页，redo log把变化加载到硬盘中，进行数据恢复，这样就保证了事务的持久性。
undo log 实现了事务的原子性
回滚日志 ，用于记录数据被修改前的信息 , 作用包含两个 : 提供回滚(保证事务的原子性) 和MVCC(多版本并发控制) 。
undo log和 redo log记录的物理日志不一样，它是逻辑日志。可以认为当delete一条记录时，undo log中会记录一条对应的insert记录，反之亦然，当update一条记录时，它记录一条对应相反的 update 记录。当执行rollback时，就可以从undo log中的逻辑记录读取到相应的内容并进行回滚。
undo log销毁：undo log在事务执行时产生，事务提交时，并不会立即删除undo log，因为这些日志可能还用于MVCC。
undo log存储：undo log采用段的方式进行管理和记录，存放在前面介绍的 rollback segment回滚段中，内部包含1024个undo log segment。
MVCC
全称 Multi-Version Concurrency Control，多版本并发控制。指维护一个数据的多个版本，使得读写操作没有冲突，快照读为MySQL实现MVCC提供了一个非阻塞读功能。MVCC的具体实现，还需要依赖于数据库记录中的三个隐式字段、undo log日志、readView。
MVCC的几个概念
1）快照读
简单的select（不加锁）就是快照读，读取的是记录数据的可见版本，有可能是历史数据，不加锁，是非阻塞读。
• Read Committed：每次select，都生成一个快照读。
• Repeatable Read：开启事务后第一个select语句才是快照读的地方。
• Serializable：快照读会退化为当前读。
2）当前读
读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。对于我们日常的操作，如：select ... lock in share mode(共享锁)，select ...for update、update、insert、delete(排他锁)都是一种当前读。
隐藏字段
创建表时，MySQL会自动为当前表创建三个隐藏的字段。
- DB_TRX_ID
最近一次修改事务ID，记录插入这条记录或最后一次修改该记录的事务ID。 - DB_ROLL_PTR
回滚指针，指向这条记录的上一个版本，用于配合undo log，指向上一个版本。 - DB_ROW_ID
隐藏主键，如果表结构没有指定主键，将会生成该隐藏字段。
undo log 版本链
不同事务对同一条记录 修改，会导致记录的undo log生成一条记录版本的链表，链表头部是最新的旧记录，链表尾部是最早的旧记录。
readview
readview（读视图）是快照读 SQL执行时MVCC提取数据的依据，记录并维护系统当前活跃的事务（未提交的）id。
- m_ids：当前活跃的事务（未提交）集合。
- trx_id：当前记录的事务id
- creator_trx_id：readview创建者的事务id
- min_trx_id：最小事务id
- max_trx_id：预分配事务id，最大事务id + 1
不同的隔离级别,生成ReadView的时机不同：
READ COMMITTED：在事务中每一次执行快照读时生成ReadView。
REPEATABLE READ：仅在事务中第一次执行快照读时生成ReadView,后续复用该ReadView。
MVCC-实现原理
在RC隔离级别中，每次简单的select操作就会生成一个快照读对应的readview，readview 中记录了当前行的事务id等信息，undo log 中记录了当前行的版本链，保存了各个版本修改前的数据，根据版本链路访问规则，找到对应事务id的版本和数据，则就是 select操作实际访问到的数据。
这也是READ COMMITTED隔离级别下，发生脏读的原因。
脏读： 读到了其他事务对本行数据的修改未提交的版本。
