怎么理解InnoDB数据字典

64次阅读

共计 1939 个字符，预计需要花费 5 分钟才能阅读完成。

本篇内容介绍了“怎么理解 InnoDB 数据字典”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让丸趣 TV 小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

在 InnoDB 中，系统表实际上是看不到的，不像 Oracle 那样可以方便地通过一个查询语句就能得到其中的内容。因为 MySQL 是一个插件式的数据库管理系统。它的结构分为两层，分别是 Server 层和存储引擎层。最早的存储引擎是 MyISAM，它是没有数据字典的，关于表结构，它拥有的只有.frm 文件，所以这导致了 InnoDB 也必须要有这个文件才使得 Server 层识别并管理它。对于 Server 层，一个表是什么存储引擎，这是表的属性。具体深入到每一个存储引擎内部，数据字典就不被 Server 层来管理了，这就导致数据字典不能被用户感知了。
系统表结构
InnoDB 有四个最基本的系统表，用来存储用户定义的表，列，索引及索引列等信息，这些表分别为 SYS_TABLES，SYS_COLUMNS，SYS_INDEXES，SYS_FIELDS。
SYS_TABLES
用来存储所有 InnoDB 为存储引擎的表
NAME：表示一个表的表名
ID：表示这个表的 ID 号
N_COLS：表示这个表的列的个数，建表指定的列数。
TYPE：表示这个表的存储类型，包括记录的格式，压缩等信息。
SPACE：表示这个表所在表空间 ID 号。这个表对应的主键列为 NAME，同时还有一个在 ID 号上的唯一索引。
SYS_COLUMNS
用来存储 InnoDB 中定义的所有表中所有列的信息，每一列对应这个表的一条记录。
TABLE_ID：表示这个列所属的表的 ID 号
POS：表示这个列在表中是第几列。
NAME：表示这个列名。
MTYPE：表示这个列的主数据类型。
PRTYPE：表示这个列的一些精确数据类型，它是一个组合值，包括 NULL 标志，是否有符号数的标志，是否是二进制字符串的标志及表示这个列是真的 varchar
LEN：表示这个列数据的精度，目前没有用到。
SYS_INDEXES
用来存储 InnoDB 中所有表的索引信息，每一条记录对应一个索引
TABLE_ID：表示这个索引所属的表的 ID 号。
ID：表示这个索引的索引 ID 号
NAME：表示这个索引的索引名
N_FIELDS：表示这个索引包括的列个数。
TYPE：表示这个索引的类型，包括聚簇索引，唯一索引，等
SPACE：表示这个索引数据所在的表空间 ID 号
PAGE_NO：表示这个索引对应的 B + 树根页面。
SYS_FIEDS
用来存储所有索引中定义的索引列，每一条记录对应一个索引列。
INDEX_ID：这个列所在的索引
POS：这个列在某个索引中是第几个索引列
COL_NAME：这个索引列的列名。
字典表的加载
InnoDB 启动的时候，如果是新建数据库，则需要初始化库，索引需要创建字典管理的 B + 树信息。因为 InnoDB 中的系统表的结构，个数等都是固定的，所以在初始化库的时候只需要创建这几个表的存储 B + 树即可。同时把将这几个 B + 树的根页号存储在一个固定位置，就不需要将这几个表自身的信息存储在系统表中了。对于一个 B 树，只要找到其根页面，就可以找检索其数据了。
对于数据字典表根页面位置的存储方式，InnoDB 用了一个专门的页面（0 号表空间 0 号文件的 7 号页面）来管理数据字典信息。这个页面用来存储 4 个系统表的五个根页面号(有 5 个索引)。
普通用户表的加载过程，当用户访问一个表时，系统首先会从表对象缓冲池中查找这个表 SHARE 对象，如果找到，则直接从其实例化表对象空间链表中拿一个空闲的实例化的表对象使用，如果没有一个可用的实例化对象，则需要重新打开(实例化这个表)，在实例化这个表的时候，需要找到这个表的字典信息，包括这个表本身，列信息及索引信息等，这些信息很多都是从 SHARE 对象处获得。如果没有 SHARE 对象，则需要从系统表中构造 SHARE 对象。
Rowid 管理
在 InnoDB 中，用户表中的记录不一定都会有一个 Rowid 列，Rowid 只有在一个表没有定义主键时，才会分配。而 Rowid 的管理分配，并不是一个表独享一个 ID 空间，而是全局的，使用表都共享这个 ID 号。
Rowid 的分配并不会直接修改页面，只要这个值为 256 的倍数的时候才会写入一次。那么如果插入 200 次，这些值还没有被写入，这是系统重新启动，ID 号岂不是重复使用，因为数据库启动的时候会调用函数做一个工作，就是将上次写入的 Rowid 值向上对齐 256 后在加上 256，这样就不会有问题了。