INNODB 数据页结构
|
InnoDB
16K |
38B |
FILE HEADER |
|
56B |
PAGE HEADER |
|
|
RECORD |
Infimum + supremum Records |
|
|
UserRecords |
||
|
|
Free Space |
|
|
|
Page Directory |
|
|
8B |
File Trailer |
|
FILE HEADER 占用38个字节 |
||
|
名称 |
大小 |
|
|
FIL_PAGE_SPACE_OR_CHECKSUM |
4 |
保证页的可靠与完整的CHECKSUM校验码 |
|
FIL_PAGE_OFFSET |
4 |
表空间中页的偏移值 |
|
FIL_PAGE_PREV |
4 |
当前页的上一下的地址 |
|
FIL_PAGE_NEXT |
4 |
当前页的上一下的地址 |
|
FIL_PAGE_LSN |
8 |
该页最后被修改的日志LSN号 |
|
FIL_PAGE_TYPE |
2 |
页的类型 |
|
FIL_PAGE_FILE_FLUSH_LSN |
8 |
该值仅在数据文件的一个页中进行定义，代表已经被更新到了该LSN |
|
FIL_PAGE_ARCH_LOG_NO_OR_SPACE_ID |
4 |
MYSQL4.1开始，代表页属于哪个表空间 |
|
INNODB Page类型 |
||
|
名称 |
十六进制 |
解释 |
|
FIL_PAGE_INDEX |
0x45BF |
B+树叶节点 |
|
FIL_PAGE_UNDO_LOGO |
0x0002 |
UNDO LOG页 |
|
FIL_PAGE_INODE |
0x0003 |
索引节点 |
|
FIL_PAGE_IBUF_FREE_LIST |
0x0004 |
InsertBuffer空闲列表 |
|
FIL_PAGE_TYPE_ALLOCATED |
0x0000 |
该页的最新分配 |
|
FIL_PAGE_IBUF_BITMAP |
0x0005 |
InsertBuffer位图 |
|
FIL_PAGE_TYPE_SYS |
0x0006 |
系统页 |
|
FIL_PAGE_TYPE_TRX_SYS |
0x0007 |
事务系统数据 |
|
FIL_PAGE_TYPE_FSP_HDR |
0x0008 |
FILE SPACE HEADER |
|
FIL_PAGE_TYPE_XDES |
0x0009 |
扩展描述页 |
|
FIL_PAGE_TYPE_BLOB |
0x000A |
BLOB页 |
|
PAGE HEADER |
||
|
名称 |
大小 |
说明 |
|
PAGE_N_DIR_SLOTS |
2 |
在PageDirectory（页目录）中的slot(槽)数。 |
|
PAGE_HEAD_TOP |
2 |
堆中第一个记录的指针 |
|
PAGE_N_HEAP |
2 |
堆中的记录数 |
|
PAGE_FREE |
2 |
指向空间列表的首指针 |
|
PAGE_GARBAGE |
2 |
已经删队记录的字节数，即行记录结构中，delete Flag为1的记录的总数 |
|
PAGE_LAST_INSERT |
2 |
最后插入记录的位置 |
|
PAGE_DIRECTION |
2 |
最后插入记录的所在页的方向，可能会在左侧页PAGE_LEFT(0x01),右侧页， |
|
PAGE_N_DIRECTION |
2 |
一个方向连续插入记录的数量 |
|
PAGE_N_RECS |
2 |
该页中记录的数量 |
|
PAGE_MAX_TRX_ID |
8 |
修改当前页的最大事务ID。仅在辅助索引中定义 |
|
PAGE_LEVEL |
2 |
当前面在索引树中的位置，0x00代表叶节点 |
|
PAGE_INDEX_ID |
8 |
当前页属于哪个索引ID |
|
PAGE_BTR_SEG_LEAF |
10 |
B+树的叶节点中，文件段的首指针位置。仅在B+树ROOT页定义 |
|
PAGE_BTR_SEG_TOP |
10 |
B+树的非叶节点中，文件段的首指针位置。仅在B+树ROOT页定义 |
IFNIMUM极小（首条虚拟记录）与SUPERMUM极大（末条虚拟记录），虚拟的行记录，限定记录的边界。
USER RECORDS：实际存储的行记录内容
FREE SPACES：空闲空间。链表数据结构，当一条记录被删除后，该空间会被加入空间链表中。
PAGE DIRECTORY，存放的是记录的相对于页的位置地址。这些记录指针称为SLOTS或目录槽，DIRECTORY SLOTS。INNODB的PAGE DIRECTORY并不是存放指向所有行记录地址，这稀疏目录(spare directory)，即一个槽中可能属于多少记录，最少属于4条，（也可能是1条），最多属于8条记录。槽中的记录按键的顺序存放。
|
INNODB FILE TRAILER |
||
|
前4字节代表该页CHECKSUM值 |
两者比较 |
后4字节与本页FILE HEADER中的FILE_PAGE_LSN 相同 |
|
通过这两个值的比较，看是否一致。以保证页的完整性。 |
||
实际比较
FILETAIL部分
这里比较的LSN是一致的，但CHECKSUM不一致。 再次DUMP一次。两个CHECKSUM就一致，不理解这是为了什么。Lsn不一致。。。00 00 00 00 22 A5 90 B9=
这个解读折腾一整个下午。这是PAGE HEADER的解读。
PAGE_HEAP_TOP
页内空闲页地址的起始，是当前页起始位置加上这个偏移值获得的。C000+0D9E=CD9E
PAGE_LAST_INSERT
最后插入记录的偏移量，同样也是从页起始算起。C000+0D83=CD83。注意，这个指向，不指向带有RECORDER HEADER和各种ID的，是直接指向记录的。当进了删除操作时，这个位置变为了0000
N_PAGE_RECS。。。0x63是实际记录，0x63=99，是对的。在删除10条后，再看它变成了0x005A。是在更新的，这个项叫。
PAGE_N_HEAP是带有两行伪记录的行数，在删除了10行后，PAGE_N_HEAP是没有变化，还是0x8065，而后边的PAGE_FREE，和PAGE_GARBAGE这两项之前都是0000
PAGE_FREE的，0x18F是399，猜测是本页还可以再插入399条记录。
PAGE_GARBAGE是0x132，306，说是垃圾记录的字节数，应该该。306/已经删除的10=30.6B,一条记录，大概占用，34B，，还真是。
PAGE DIRECTORY的槽数量，本例中为0x0119,就是281条记录。因为是稀疏目录，槽不可能记录所有的记录。
去本页页底找一下。黄标为INNODB FILE TRAILER ，前面就是PAGE DIRECTORY ,存放是记录相对页的位置。
Page Directory中存放了按主键顺序存放着，行的相对位置(是页相对位置而不是偏移量)。因为是稀疏的，还需要RECORD_HEAD中的n_owned去进一步判断。
伪记录Infimum的n_owned值总是1，记录Supremum的n_owned的取值范围为[1,8]，其他用户记录n_owned的取值范围[4,8]。当记录被插入或者删除时需要对槽进行分裂或平衡的维护操作。在Slots中记录是按照索引键值进行存放的，这个样子可以利用二叉查找迅速找到记录的指针。由于InnoDB存储引擎中Page Directory是稀疏目录，二叉查找的结果是一个粗略的结果，因此InnoDB存储引擎必须通过record header中的next_record来继续查找相关记录。B+树索引本身并不能找到具体的一条记录，能找到只是该记录所在的页。数据库把页载入到内存中，然后通过Page Directory在进行二叉查找。二叉查找的时间复杂度很低，同时在内存中的查找很快，因此通常忽略这部分查找所用的时间。
关于行记录RECORD HEADER
两条伪行
实际数据行
白色是recorder header,最后两位是偏移量，第一位是N_OWNED,,,,,,,,红色是 实际的键值 ,,,,,黄色是TRANSACTION id,,,,红砖色是ROLL POINTER,,,,,,,后边的紫色的是行存储的实际的值。
