INNODB 数据页结构

InnoDB
DataPage


16384B

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,,,,,,,后边的紫色的是行存储的实际的值。

      

 
posted @ 2016-05-03 16:50  一眼前望,一眼自省  阅读(2353)  评论(0编辑  收藏  举报