mysql innodb的表由.frm .ibd 组成，ibd：存了每个表的元数据，包括表结构的定义等；frm：存了每个表的元数据，包括表结构的定义等；
1.0 idb文件基本结构
ibd文件结构由segment inode、extent和page组成。page是InnoDB管理存储空间的基本单位，一个页的大小一般是16KB。
1.1 PAGE类型是FIL_PAGE_TYPE_FSP_HDR的文件结构
是ibd的一个page，记录整个表的Page管理信息
space id 当前表空间的ID
size 当前space最大可容纳的page数,文件扩大时才会改变这个值
limit 当前space已经分配初始化的page数,包括空闲的和已经使用的
flag 未起作用
frage used FSP_FREE_FRAG列表中已经被使用的page数
free list space中可用的extent对象列表，extent里面没有一个page被使用
frag free list 有可用碎叶page的extent列表，exntent里面有部分page被使用
frag full list 没有有可用page的extent列表，exntent里面全部page被使用
segment id 下一个可利用的segment id
full inode list space当前完全占满的segment inode页列表
free inode list space当前完全占满的segment inode页列表
file segment id：段id，如果extent属于某个段的话，记录其段id，占用8个字节
xdes list node：extent链表的双向指针节点，占用12个字节，fsp header中的链表头指向的目标就是这里
state：该extent的状态，比如空闲或者已完全被使用等等，该状态是枚举类型，值为XDES_FREE，XDES_FREE_FRAG，XDES_FULL_FRAG，XDES_FSEG，占用4字节
page state bitmap： 用2个bit表示extent中的一个page，其中一个bit表示该page是否是空闲(XDES_FREE_BIT)，另一个bit保留，尚未使用(XDES_CLEAN_BIT)，占用16字节，16*8/2=64，正好可以标记一个extent 64个页的使用情况
1.2 PAGE类型是FIL_PAGE_INODE的文件结构
是ibd的用于记录段信息的page。inode管理xdes，xdes管理page
1.1 PAGE类型是FIL_PAGE_INDEX的文件结构
是ibd的用于管理页节点和叶子节点的page。
User Records记录具体的数据内容，其中就包括数据库每行数据的具体数据，单条记录文件结构如下
如果是聚簇索引，存储的内容：[主键列][TRXID][ROLLPTR][其他建表的非主键列]
如果是二级非唯一索引,存储的内容：[非唯一索引列][主键列]
2.0 通过py_innodb_page_info查看ibd的基本信息，如下：
没有找到趁手的二进制分析工具分析idb文件，如果谁找到好的工具还望告知哈！我现在用的是Analysis这个工具
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 | page offset 00000000, page type <File Space Header> //page类型FIL_PAGE_TYPE_FSP_HDR page offset 00000001, page type <Insert Buffer Bitmap> page offset 00000002, page type <File Segment inode> //page类型FIL_PAGE_INODE page offset 00000003, page type <B-tree Node>, page level <0002> //page类型FIL_PAGE_INDEX，Page Header->PAGE_LEVEL=2，是叶节点 page offset 00000004, page type <B-tree Node>, page level <0002> page offset 00000005, page type <B-tree Node>, page level <0002> page offset 00000006, page type <B-tree Node>, page level <0001> //page类型FIL_PAGE_INDEX，Page Header->PAGE_LEVEL=1，是叶节点 page offset 00000007, page type <B-tree Node>, page level <0001> page offset 00000008, page type <B-tree Node>, page level <0002> page offset 00000009, page type <B-tree Node>, page level <0002> page offset 0000000a, page type <B-tree Node>, page level <0000> //page类型FIL_PAGE_INDEX，Page Header->PAGE_LEVEL=0，是叶子节点 page offset 0000000b, page type <B-tree Node>, page level <0000> page offset 0000000c, page type <B-tree Node>, page level <0000> page offset 0000000d, page type <B-tree Node>, page level <0000> page offset 0000000e, page type <B-tree Node>, page level <0000> page offset 0000000f, page type <B-tree Node>, page level <0000> ... page offset 00000000, page type <Freshly Allocated Page> page offset 00000000, page type <Freshly Allocated Page> page offset 00000000, page type <Freshly Allocated Page> page offset 00000000, page type <Freshly Allocated Page> Total number of page: 14592: Freshly Allocated Page: 2584 Insert Buffer Bitmap: 1 File Space Header: 1 B-tree Node: 12005 File Segment inode: 1 |
3.0 分析文件结构，对我们优化数据库的帮助
1.我们知道mysql的其中一个重要的性能瓶颈就是磁盘IO。如果一张表的字段越多，字段的值越大，意味着一个Page能存放的数据量越少，造成数据查询需要加载更多的Page进行更多的IO操作。
2.我们知道磁盘的顺序读写要比随机读写快，但是频繁的插入和删除后，逻辑上相邻的数据可能分散在不同的Page中（数据是以链表形式存放在Page中的）。所以有的时候删除重建索引可以提高查询效率，即：将逻辑上相邻的数据顺序存储在Page上，将随机读写变成顺序读写同时也减少了IO操作。
3.如果我们通过主键id查询某行数据，由于mysql数据本身就是索引，所以只需要执行一次IO；如果我们通过非主键索引查询一个某行数据的某个字段，如果该字段也属于该索引只执行一次IO即可，如果是非索引字段第一次IO取到主键id，第二次IO才是获取数据（这里说的可能有点片面）
4.0 参考借鉴：
MySQL系列：innodb源码分析之表空间管理
MYSQL INNODB数据存储结构
InnoDB INODE 页结构
MySQL InnoDB ibd 文件格式解析(fsp header & xdes entry)