怎么理解InnoDB数据字典

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

   在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，这样就不会有问题了。

“怎么理解InnoDB数据字典”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注亿速云网站，小编将为大家输出更多高质量的实用文章！