InnoDB原子性和持久性

数据库的原子性包括两个内容：灾难恢复和事务回滚。InnoDB通过redo日志来支持灾难恢复，通过undo日志来支持事务回滚。
数据库的持久性指事务一旦commit就会被持久化：通过在commit时同步写入数据库来支持。

redo日志：实现灾难恢复

InnoDBRedo

为了更好的进行持久化，innodb使用WAL方式进行持久化，WAL通过将对数据的变更以追加的形式写入日志，并且在之后将变更日志应用到数据上，来将随机IO尽可能地转化为批量IO，在innodb中，这个叫做redo日志。
另外，为了增加频繁申请WALBuffer，一般都会预设一个环形内存Buffer区进行重用，在innodb中，这个叫做redo log buffer。
innodb存在两种类型的redo日志：物理日志直接记录对页的修改，而逻辑日志则记录逻辑操作，为了保证redo日志的幂等性，意味着，对于同样状态的物理页，应用逻辑日志或者物理日志后生成的页面数据应该是一样的。
在用户线程中，一个事务包含多个语句，每个语句包含多个MTR，一个MTR是对底层页面的一次完整访问，由多个Redo日志组成；每次向redo log buffer写入的基本粒度是一个MTR，这也是InnoDB引擎支持的最小并发粒度；redo log被划分为很多block，每个block的大小为512字节，等于一个扇区的大小；在commit或者其它时机，redo log被刷入磁盘。
lsn为内存缓冲区已写入的字节数，flushed_lsn为已刷新到磁盘的字节数，ckpt_lsn为已经应用到磁盘数据上的字节数。
ckpt_lsn是通过FlushList进行更新，FlushList按page修改的最小的lsn进行排序，每当队尾page刷新到磁盘上时，ckpt_lsn都进行更新。
崩溃恢复：通过ckpt_lsn，可以确定崩溃恢复的起点，通过依次读取redolog直到一个不足512字节的block，则为崩溃恢复的终点，之后只要重新应用redolog到磁盘数据即可。通过比较page的FIL_PAGE_LSN和将对同一个page的redo日志行为进行划分合并，可以减少恢复的时间。

undo日志：回滚和MVCC

INNODBUndo

B+树索引数据中通过roll_pointer指向undo日志，uodate和delete类型的日志还有roll_pointer，指向更早的undo日志，从而形成版本链，索引数据和undo日志中的trx_id用来实现不同的隔离级别，两者结合，实现支持不同隔离级别的MVCC。
所有的undo日志都保存在undo日志段中，共有128个日志段，每个段中有1024个undo日志链，通过Page5中，可以找到128个undo日志段描述页，通过undo日志段描述页中的undoslots，可以找到1024个日志链，每个日志链中包含多个undo日志页，以链表形式连接起来，第一个undo日志页中不仅记录undo日志，还记录有undo日志链信息。
每个事务最多会使用4个日志链：普通表insert undo链；临时表update undo链；普通表insert undo链；临时表update undo链。划分四个不同类型的链的原因是：临时表不需要写redo日志，insert日志在事务提交后可直接释放，而update日志在事务提交后因需要支持MVCC不能直接释放而需要等待purge线程清理后再释放。
日志链满足仅包含一个undo日志且使用量少于3/4时在事务提交后可以被重用，重用时，对于insert日志直接覆盖写，对于uodate日志，则通过使用UndoLogHeader中的nextLog和prevLog继续增加新的Undo链信息追加写。
为事务分配undo日志链的过程：
- 以轮转方式从128个日志段中分配日志段
- 如果分配到的日志段中有可重用的日志链，则重用
- 若无，则以轮转方式从1024个日志链中分配日志链