Data dictionary header(2) --系统表空间结构（三十四)

前面说了系统表空间的整体结构，与独立表空间大致类似，多了五个特有的系统属性页，因为整个表空间只有一个系统表空间，所以他的重要性不言而喻，space id为0

Data dirctionary header

只要有四个基本表，就意味着可以获取其他系统表以及用户定义表的所有元数据。有表的名称之后：

可以从sys_table里获取到表的table_id。

通过table_id可以在sys_columnts表里获取表的所有列信息。

通过table_id可以在sys_indexes表里获取到所有索引信息和index_id。

通过index_id可以到sys_filds表里获取到索引列的信息。

也就是这四个表是表中之表，那这四个表的元数据从哪里获取呢？没法搞了，于是系统空间结构表出来了第7个页面，data dirctionary header，也就是数据字典的头部信息，除了记录这些数据信息和索引信息，还记着整个innoDB的存储引擎一些全局属性。

file_header：文件头部，38个字节，页的一些通用信息。

data_dirctionary_header：数据字典头部信息，56个字节，记录着基本系统的根页位子和innoDB存储引擎的一些全局变量。

segment header：段头部信息，10个字节，记录着本页所在段对应的inode entry信息。

enpty space：尚未使用，16272字节，用于页结构的填充。

file trailer：文件尾部，8个字节，效验页是否完整。

这里可以看到我们熟悉的segment header，大家还记得这里存着什么吗，存着叶子节点段和非叶子节点段的inode entry表空间位子，所在页面号，和页面偏移量，而这些数据就存在这里。这里重点介绍一下data_dirctionary_header：

Max_row_id：当我们没有指定主键，也没有unique键，那么innoDB会生成一个名为row_id的列作为主键。因为是主键，所以不会重复，原则上一个表中只有一个的row_id作为键，不同表是可以相同的，不过innoDB只设计了换一个字段max_row_id，这个是全局共享，当哪个表插入一条数据，就是把max_Row_id的值记录到row_id的表中，再把max_row_id加1。

Max table id：全局的table_id，当建表时候，吧这个id给这个表，再把table_id加1。

Max_index_id：全局的索引id，因为索引也是，当哪个表建立哪个索引，就把这个字段的值赋值给当前索引，再把max_index_id加1。

Max_space_id：每个表都对应一个表空间，表空间的值就是取max_space_id，再把 max_space_id加1。

Max_id_low(unused)：暂时没啥用。

Root_of_sys_tables_clust_index：本字段代表sys tables表聚簇索引的根页面的页号。

Root of sys_tables_ids sec index：本字段代表sys tables表为id 建立的二级索引的根页面的页号。

Root of sys_columns clust index：本字段代表sys_columns页聚簇索引的根页面页号。

Root of sys_indexes clust index：a本字段代表sys_indexes表聚簇索引根页面页号。

Root of sys_fields clust index：本字段代表sys_fileds表聚簇索引根页面页号。

Unused：暂时没用到。

Information_schema系统数据库

一般情况下，这些系统表是不可以访问的，但考虑到用户需要看着信息来分析问题，所以可以去信息模式 数据库下查看：

user information_chema；

show tables like ‘innodb_sys%’;

大家会发现查询出来的表是innodb_sys_tables，innodb_sys_columns等，严格来说查询出来的并不是系统表，系统表是我们前面说sys开头的表，这些是记录系统表数据的时候，填充进来innodb_sys表的，但这些数据足够我们排查问题了。