实际存储undo记录的Page类型为FIL_PAGE_UNDO_LOG，undo header结构如下
MacrobytesDescTRX_UNDO_PAGE_HDR 38 Page 头
TRX_UNDO_PAGE_TYPE 2 记录Undo类型，是TRX_UNDO_INSERT还是TRX_UNDO_UPDATE
TRX_UNDO_PAGE_START 2 事务所写入的最近的一个undo log在page中的偏移位置
TRX_UNDO_PAGE_FREE 2 指向当前undo page中的可用的空闲空间起始偏移量
TRX_UNDO_PAGE_NODE 12 链表节点，提交后的事务，其拥有的undo页会加到history list上
undo页内结构及其与回滚段头页的关系参阅下图：
InnoDB Undo 页内结构
关于具体的Undo log如何存储，本文不展开描述，可阅读我之前的这篇文章：MySQL · 引擎特性 · InnoDB undo log 漫游
FSP_DICT_HDR_PAGE_NO
ibdata的第8个page，用来存储数据词典表的信息 （只有拿到数据词典表，才能根据其中存储的表信息，进一步找到其对应的表空间，以及表的聚集索引所在的page no）
Dict_Hdr Page的结构如下表所示：
MacrobytesDescDICT_HDR 38 Page头
DICT_HDR_ROW_ID 8 最近被赋值的row id，递增，用于给未定义主键的表，作为其隐藏的主键键值来构建btree
DICT_HDR_TABLE_ID 8 当前系统分配的最大事务ID，每创建一个新表，都赋予一个唯一的table id，然后递增
DICT_HDR_INDEX_ID 8 用于分配索引ID
DICT_HDR_MAX_SPACE_ID 4 用于分配space id
DICT_HDR_MIX_ID_LOW 4
DICT_HDR_TABLES 4 SYS_TABLES系统表的聚集索引root page
DICT_HDR_TABLE_IDS 4 SYS_TABLE_IDS索引的root page
DICT_HDR_COLUMNS 4 SYS_COLUMNS系统表的聚集索引root page
DICT_HDR_INDEXES 4 SYS_INDEXES系统表的聚集索引root page
DICT_HDR_FIELDS 4 SYS_FIELDS系统表的聚集索引root page
dict_hdr页的创建参阅函数 dict_hdr_create
double write buffer
InnoDB使用double write buffer来防止数据页的部分写问题，在写一个数据页之前，总是先写double write buffer，再写数据文件。当崩溃恢复时，如果数据文件中page损坏，会尝试从dblwr中恢复。
double write buffer存储在ibdata中，你可以从事务系统页(ibdata的第6个page)获取dblwr所在的位置。总共128个page，划分为两个block。由于dblwr在安装实例时已经初始化好了，这两个block在Ibdata中具有固定的位置，Page64 ~127 划属第一个block，Page 128 ~191划属第二个block。
在这128个page中，前120个page用于batch flush时的脏页回写，另外8个page用于SINGLE PAGE FLUSH时的脏页回写。
外部存储页对于大字段，在满足一定条件时InnoDB使用外部页进行存储。外部存储页有三种类型：
FIL_PAGE_TYPE_BLOB：表示非压缩的外部存储页，结构如下图所示：
