InnoDB 层系统字典表 | 全方位认识 information_schema

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
简介: 在《Server 层混杂信息字典表 | 全方位认识 information_schema》中,我们详细介绍了information_schema下的状态变量、系统变量、进程状态、字符集和校对规则等字典表,本期我们将为大家带来系列第五篇《InnoDB 层系统字典表 | 全方位认识 information_schema》,下面请跟随我们一起开始information_schema 系统库的系统学习之旅吧。


《Server 层混杂信息字典表 | 全方位认识 information_schema》中,我们详细介绍了information_schema下的状态变量、系统变量、进程状态、字符集和校对规则等字典表,本期我们将为大家带来系列第五篇《InnoDB 层系统字典表 | 全方位认识 information_schema》,下面请跟随我们一起开始information_schema 系统库的系统学习之旅吧。


1、INNODB_SYS_DATAFILES

该表提供查询InnoDB file-per-table和常规表空间数据文件的路径信息,等同于InnoDB数据字典中SYS_DATAFILES表中的信息

  • 该表为memory引擎临时表,查询该表的用户需要有process权限

  • 该表中的信息包含InnoDB所有表空间类型的元数据,包括独立表空间、常规表空间、系统表空间、临时表空间和undo表空间(如果开启了独立表空间的话)

下面是该表中存储的信息内容

admin@localhost : information_schema 06:26:55> select * from INNODB_SYS_DATAFILES limit 5;
+-------+---------------------------+
| SPACE | PATH                      |
+-------+---------------------------+
|
    6 | ./mysql/plugin.ibd        |
|    7 | ./mysql/servers.ibd      |
|
    8 | ./mysql/help_topic.ibd    |
|    9 | ./mysql/help_category.ibd |
|
    10 | ./mysql/help_relation.ibd |
+-------+---------------------------+
5 rows in set (0.00 sec)


字段含义如下:

  • SPACE:表空间文件ID

  • PATH:表空间数据文件所在路径。如果独立表空间文件在MySQL数据目录中,则该路径为一个相对路径,如果在MySQL数据目录之外,则该路径值为一个绝对路径


2、INNODB_SYS_VIRTUAL

该表提供查询有关InnoDB虚拟生成列和与之关联的列的元数据信息,等同于InnoDB数据字典中SYS_VIRTUAL表中的信息

  • INNODB_SYS_VIRTUAL表中展示的行信息是虚拟生成列相关联列的每个列的信息

  • 该表为memory引擎临时表,查询该表的用户需要有process权限

下面是该表中存储的信息内容

# 建表
root@localhost : (none) 01:03:42> use test
Database changed
root@localhost : test 01:13:25> CREATE TABLE `t1` (
->          `a` int(11) DEFAULT NULL,
->          `b` int(11) DEFAULT NULL,
->          `c` int(11) GENERATED ALWAYS AS (a+b) VIRTUAL,
->          `h` varchar(10) DEFAULT NULL
->        );
Query OK, 0 rows affected (0.10 sec)

# 查询INNODB_SYS_VIRTUAL表
root@localhost : test 01:13:28> SELECT * FROM INFORMATION_SCHEMA.INNODB_SYS_VIRTUAL
->        WHERE TABLE_ID IN (SELECT TABLE_ID FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES WHERE NAME LIKE "test/t1");
+----------+-------+----------+
| TABLE_ID | POS   | BASE_POS |
+----------+-------+----------+
|      487 | 65538 |        0 |
|      487 | 65538 |        1 |
+----------+-------+----------+
2 rows in set (0.00 sec)

# 如果将常量值分配给虚拟生成列(如以下示例中所示),则此时该列不会在INNODB_SYS_VIRTUAL表中记录(虚拟生成列必须是一个表达式在该表中才会进行记录)
root@localhost : test 01:13:42> CREATE TABLE `t2` (
->          `a` int(11) DEFAULT NULL,
->          `b` int(11) DEFAULT NULL,
->          `c` int(11) GENERATED ALWAYS AS (5) VIRTUAL
->        );
Query OK, 0 rows affected (0.04 sec)

root@localhost : test 01:15:56> SELECT * FROM INFORMATION_SCHEMA.INNODB_SYS_VIRTUAL WHERE TABLE_ID IN (SELECT TABLE_ID FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES WHERE NAME LIKE "test/t2");
Empty set (0.00 sec)

# 虽然在innodb_sys_virtual表中未记录,但是此类列信息记录到了innodb_sys_columns表中
root@localhost : (none) 01:22:53> select c.* from information_schema.innodb_sys_tables as t join information_schema.innodb_sys_columns as c on t.table_id=c.table_id where t.name='test/t2';
+----------+------+-------+-------+--------+-----+
| TABLE_ID | NAME | POS   | MTYPE | PRTYPE | LEN |
+----------+------+-------+-------+--------+-----+
|
      488 | a    |     0 |     6 |   1027 |   4 |
|      488 | b    |     1 |     6 |   1027 |   4 |
|
      488 | c    | 65538 |     6 |   9219 |   4 |
+----------+------+-------+-------+--------+-----+
3 rows in set (0.00 sec)


字段含义如下:

  • TABLE_ID:表示与虚拟列关联的表ID,与INNODB_SYS_TABLES.TABLE_ID字段值相同

  • POS:虚拟生成列的位置顺序值。该数字较大,因为它同时编码了列序号和序号位置。且用于计算该值的公式使用了位移运算。公式为:((InnoDB实例的第n个虚拟生成列+ 1) << 16)+虚拟生成列的顺序位置值。例如:如果InnoDB实例中的第一个虚拟生成列是该表的第三列,则公式为(0 + 1)<< 16)+ 2

  • BASE_POS:虚拟生成列的关联列的顺序位置


3、INNODB_SYS_INDEXES

该表提供查询有关InnoDB索引的元数据信息,等同于InnoDB数据字典内部SYS_INDEXES表中的信息

  • 该表为memory引擎临时表,查询该表的用户需要具有process权限

下面是该表中存储的信息内容

admin@localhost : information_schema 06:39:20> select * from INNODB_SYS_INDEXES limit 1\G;
*************************** 1. row ***************************
  INDEX_ID: 11
      NAME: ID_IND
  TABLE_ID: 11
      TYPE: 3
  N_FIELDS: 1
    PAGE_NO: 45
      SPACE: 0
MERGE_THRESHOLD: 50
1 row in set (0.00 sec)


字段含义如下:

  • INDEX_ID:索引ID,在实例中的所有数据库中唯一

  • NAME:索引名称。索引名称可以在创建时指定,如果不指定InnoDB将隐含地创建名称与列名一致的索引,但索引名称在整个实例中不一定是唯一的(但在每个表中需要唯一)。例如:PRIMARY用于主键索引、GEN_CLUST_INDEX用于表示未指定主键时innodb隐式创建的一个主键索引、以及ID_IND,FOR_IND和REF_IND用于外键约束等

  • TABLE_ID:表示与索引关联的表ID,该字段值与INNODB_SYS_TABLES.TABLE_ID的字段值相同

  • TYPE:表示索引类型的数字ID,0 =二级索引、1 =集群索引、2 =唯一索引、3 =主键索引、32 =全文索引、64 =空间索引、128 =包含虚拟生成列的二级索引

  • N_FIELDS:索引key中的列数量。对于GEN_CLUST_INDEX索引(innodb隐式创建的主键),此字段值为0,因为该索引是使用伪造的列值而非实际表列创建的

  • PAGE_NO:索引B-tree的根页编号。对于全文索引,PAGE_NO字段未使用且设置为-1(FIL_NULL),因为全文索引中的数据被分散在多个B树(辅助表)中

  • SPACE:索引所在表空间ID。0表示InnoDB系统表空间。任何其他非0数字都表示使用了独立的表空间且具有独立的.ibd文件的表。该ID值在执行TRUNCATE TABLE语句后保持不变。由于一个表中存在着多个索引,所以在该表中该列值不一定是唯一的

  • MERGE_THRESHOLD:索引页的合并阈值。如果索引页面中的数据量在发生删除行或发生更新操作缩短行长度之后,整个索引页中的实际数据长度与页大小的比例降至MERGE_THRESHOLD值以下,InnoDB会尝试合并索引页与相邻索引页。默认阈值是50%


4、INNODB_SYS_TABLES

该表提供查询有关InnoDB表的元数据,等同于InnoDB数据字典中SYS_TABLES表的信息

  • 该表为memory引擎临时表,查询该表的用户需要有process权限

下面是该表中存储的信息内容

root@localhost : (none) 12:53:44> select * from information_schema.INNODB_SYS_TABLES where NAME like 'sbtest%';
+----------+-------------------+------+--------+-------+-------------+------------+---------------+------------+
| TABLE_ID | NAME              | FLAG | N_COLS | SPACE | FILE_FORMAT | ROW_FORMAT | ZIP_PAGE_SIZE | SPACE_TYPE |
+----------+-------------------+------+--------+-------+-------------+------------+---------------+------------+
|      323 | sbtest/sbtest1    |  33 |      7 |  151 | Barracuda  | Dynamic    |            0 | Single    |
|      318 | sbtest/sbtest2    |  33 |      7 |  146 | Barracuda  | Dynamic    |            0 | Single    |
|      320 | sbtest/sbtest3    |  33 |      7 |  148 | Barracuda  | Dynamic    |            0 | Single    |
|      321 | sbtest/sbtest4    |  33 |      7 |  149 | Barracuda  | Dynamic    |            0 | Single    |
|      325 | sbtest/sbtest5    |  33 |      7 |  153 | Barracuda  | Dynamic    |            0 | Single    |
|      322 | sbtest/sbtest6    |  33 |      7 |  150 | Barracuda  | Dynamic    |            0 | Single    |
|      324 | sbtest/sbtest7    |  33 |      7 |  152 | Barracuda  | Dynamic    |            0 | Single    |
|      319 | sbtest/sbtest8    |  33 |      7 |  147 | Barracuda  | Dynamic    |            0 | Single    |
|      347 | sbtest/test_table |  33 |      4 |  295 | Barracuda  | Dynamic    |            0 | Single    |
+----------+-------------------+------+--------+-------+-------------+------------+---------------+------------+
9 rows in set (0.00 sec)


字段含义如下:

  • TABLE_ID:Innodb表ID,在整个实例中唯一

  • NAME:表名称。该字符串包含db_name+tb_name,例如"test/t1",该字符串值可能受lower_case_table_names系统参数设置的影响

  • FLAG:有关表格式和存储特性的位级信息数据,包括行格式,压缩页大小(如果适用)以及DATA DIRECTORY子句是否与CREATE TABLE或ALTER TABLE一起使用等

  • N_COLS:表中的列数量。该字段值包含了Innodb表的三个隐藏列(DB_ROW_ID、DB_TRX_ID、DB_ROLL_PTR),另外,如果存在虚拟生成列,则该字段值还包含虚拟生成列

  • SPACE:表所在表空间ID。0表示InnoDB系统表空间。任何其他非0数字独立表空间或普通表空间。该ID值在执行过TRUNCATE TABLE语句后保持不变。对于每个表的表空间ID记录,在此表中的ID值是唯一的

  • FILE_FORMAT:表空间文件的存储格式(有效值为:Antelope、Barracuda)

  • ROW_FORMAT:表的数据行存储格式(有效值为:Compact,、Redundant,、Dynamic、Compressed)

  • ZIP_PAGE_SIZE:压缩页大小。仅适用于使用压缩行格式的表

  • SPACE_TYPE:表所属的表空间类型。可能的值包括:System(系统表空间)、General(普通表空间)、Single(独立表空间)、使用CREATE TABLE或ALTER TABLE 语句时使用TABLESPACE建表选项指定表空间名称,例如:TABLESPACE = innodb_system,表示分配该表到系统表空间,如果需要指定到一个普通表空间(针对NDB存储引擎适用)


PS:flag列bit位值解释

  • 详见链接:https://dev.mysql.com/doc/refman/5.7/en/innodb-sys-tables-table.html

  • 链接中的表格查看方法:例如flag列值为33,则在"Decimal Numeric Value" 列表示的十进制数字中,找到存在32与1的值的行,即第一行 和第三行,然后,从这两行的"Description"列的解释我们可以得出,该表的行存储格式要么为Dynamic要么为Compressed,而从ZIP_PAGE_SIZE 列值我们可以看到该表是否有使用压缩格式,从而可以进一步确定该表到底使用的何种行存储格式(当然,这个值对于一般使用者并无多大用处,了解即可)


5、INNODB_SYS_FIELDS

该表提供查询有关InnoDB索引列(字段)的元数据信息,等同于InnoDB数据字典中SYS_FIELDS表的信息

  • 该表为memory引擎临时表,查询该表的用户需要有process权限

下面是该表中存储的信息内容

admin@localhost : information_schema 06:41:33> select * from INNODB_SYS_FIELDS limit 10;
+----------+----------+-----+
| INDEX_ID | NAME    | POS |
+----------+----------+-----+
|      11 | ID      |  0 |
|      12 | FOR_NAME |  0 |
|      13 | REF_NAME |  0 |
|      14 | ID      |  0 |
|      14 | POS      |  1 |
|      15 | SPACE    |  0 |
|      16 | SPACE    |  0 |
|      17 | TABLE_ID |  0 |
|      17 | POS      |  1 |
|      17 | BASE_POS |  2 |
+----------+----------+-----+
10 rows in set (0.00 sec)


字段含义如下:

  • INDEX_ID:与此索引字段关联的索引ID,与INNODB_SYS_INDEXES表中的INDEX_ID字段值相同

  • NAME:与此索引列相关的表中原始列的名称,与INNODB_SYS_COLUMNS表中的NAME字段值相同

  • POS:索引中的索引字段的序号位置,从0开始依次递增。 当一个列被删除时,剩下的列被重新排序,以便该序列无间隙


6、INNODB_SYS_TABLESPACES

该表提供查询有关InnoDB独立表空间和普通表空间的元数据信息(也包含了全文索引表空间),等同于InnoDB数据字典中SYS_TABLESPACES表中的信息

  • 该表为memory引擎临时表,查询该表的用户需要有process权限

  • INFORMATION_SCHEMA.FILES表提供查询的信息中包含所有InnoDB表空间类型的元数据信息,包括独立表空间、普通表空间、系统表空间、临时表空间和undo表空间(如果有)

  • 因为对于所有Antelope文件格式的表空间文件(注意与表的FLAG不同),表空间FLAG信息始终为零,所以如果表空间行格式为 Redundant 或 Compact,则无法使用该FLAG信息确定一个十进制的整数(也就是说在Antelope文件格式的表空间文件中,无法通过表空间文件的FLAG信息判断行格式是Compact、 Redundant、Compressed、Dynamic中的哪一种)

  • 普通表空间引入之后,系统表空间的元数据信息也在INNODB_SYS_TABLESPACES表暴露出来提供了查询

下面是该表中存储的信息内容

admin@localhost : information_schema 06:48:10> select * from INNODB_SYS_TABLESPACES where name like '%sbtest%' limit 10;
+-------+------------------------------------------------------+------+-------------+------------+-----------+---------------+------------+---------------+------------+----------------+
| SPACE | NAME                                                | FLAG | FILE_FORMAT | ROW_FORMAT | PAGE_SIZE | ZIP_PAGE_SIZE | SPACE_TYPE | FS_BLOCK_SIZE | FILE_SIZE  | ALLOCATED_SIZE |
+-------+------------------------------------------------------+------+-------------+------------+-----------+---------------+------------+---------------+------------+----------------+
|    28 | sbtest/sbtest6                                      |  33 | Barracuda  | Dynamic    |    16384 |            0 | Single    |          4096 | 1547698176 |    1547702272 |
|    29 | sbtest/sbtest5                                      |  33 | Barracuda  | Dynamic    |    16384 |            0 | Single    |          4096 | 1551892480 |    1551896576 |
|    30 | sbtest/sbtest3                                      |  33 | Barracuda  | Dynamic    |    16384 |            0 | Single    |          4096 | 1551892480 |    1551896576 |
|    31 | sbtest/sbtest7                                      |  33 | Barracuda  | Dynamic    |    16384 |            0 | Single    |          4096 | 1547698176 |    1547702272 |
|    32 | sbtest/sbtest1                                      |  33 | Barracuda  | Dynamic    |    16384 |            0 | Single    |          4096 | 2533359616 |    2533363712 |
|    33 | sbtest/sbtest2                                      |  33 | Barracuda  | Dynamic    |    16384 |            0 | Single    |          4096 | 1547698176 |    1547702272 |
|    34 | sbtest/sbtest4                                      |  33 | Barracuda  | Dynamic    |    16384 |            0 | Single    |          4096 | 1551892480 |    1551896576 |
|    35 | sbtest/sbtest8                                      |  33 | Barracuda  | Dynamic    |    16384 |            0 | Single    |          4096 | 1547698176 |    1547702272 |
|  167 | sbtest/xx                                            |  33 | Barracuda  | Dynamic    |    16384 |            0 | Single    |          4096 |    114688 |        114688 |
|  168 | sbtest/FTS_0000000000000076_000000000000008e_INDEX_1 |  33 | Barracuda  | Dynamic    |    16384 |            0 | Single    |          4096 |      98304 |          98304 |
+-------+------------------------------------------------------+------+-------------+------------+-----------+---------------+------------+---------------+------------+----------------+
10 rows in set (0.00 sec)


字段含义如下:

  • SPACE:表空间文件ID

  • NAME:数据库和表名组合字符串,例如:test/t1

  • FLAG:有关表空间文件存储格式和存储特性的bit位级数据

  • FILE_FORMAT:表空间文件存储格式。例如:Antelope、Barracuda或普通表空间支持的任何行格式。该字段中的数据是根据驻留在.ibd文件中的表空间FLAG信息进行解释的。有关InnoDB文件格式的更多信息,详见链接:https://dev.mysql.com/doc/refman/5.7/en/innodb-file-format.html

  • ROW_FORMAT:表空间的行格式(Compact、 Redundant、Compressed、Dynamic),该字段中的数据是根据驻留在.ibd文件中的表空间FLAG信息进行解释的

  • PAGE_SIZE:表空间中的页大小。该字段中的数据是根据驻留在.ibd文件中的表空间FLAG信息进行解释的

  • ZIP_PAGE_SIZE:表空间zip页大小。该字段中的数据是根据驻留在.ibd文件中的表空间FLAG信息进行解释的

  • SPACE_TYPE:表空间文件的类型。可能的值包括:General (普通表空间)和Single (独立表空间文件) *

  • FS_BLOCK_SIZE:文件系统中的块大小,它是用于hole punching技术的单位大小。该字段是在InnoDB透明页压缩功能被引入之后新增的

  • FILE_SIZE:文件表面上的大小(即表示文件未压缩时的最大大小)。该字段是在InnoDB透明页压缩功能被引入之后新增的

  • ALLOCATED_SIZE:文件的实际大小,即在磁盘上分配的空间大小。该字段是在InnoDB透明页压缩功能被引入之后新增的

  • PS:关于Innodb透明页压缩详见链接:https://dev.mysql.com/doc/refman/5.7/en/innodb-page-compression.html


7、INNODB_SYS_FOREIGN_COLS

该表提供查询有关InnoDB外键列的状态信息,等同于InnoDB数据字典中SYS_FOREIGN_COLS表的信息

  • 该表为memory引擎临时表,查询该表的用户需要有process权限

下面是该表中存储的信息内容

root@localhost : (none) 11:44:52> SELECT * FROM INFORMATION_SCHEMA.INNODB_SYS_FOREIGN_COLS;
+-------------------------------+--------------+--------------+-----+
| ID                            | FOR_COL_NAME | REF_COL_NAME | POS |
+-------------------------------+--------------+--------------+-----+
|
 employees/dept_emp_ibfk_1    | emp_no      | emp_no      |  0 |
| employees/dept_emp_ibfk_2    | dept_no      | dept_no      |  0 |
|
 employees/dept_manager_ibfk_1 | emp_no      | emp_no      |  0 |
| employees/dept_manager_ibfk_2 | dept_no      | dept_no      |  0 |
|
 employees/salaries_ibfk_1    | emp_no      | emp_no      |  0 |
| employees/titles_ibfk_1      | emp_no      | emp_no      |  0 |
+-------------------------------+--------------+--------------+-----+
6 rows in set (0.00 sec)


字段含义如下:

  • ID:与此外键索引key字段关联的外键约束名称(注意是约束名称,不是索引名称),与INNODB_SYS_FOREIGN.ID字段值相同

  • FOR_COL_NAME:外键索引的子表中外键列的名称

  • REF_COL_NAME:外键索引的父表中关联列(引用列)的名称

  • POS:外键索引内该key字段的位置序号,从0开始


8、INNODB_SYS_COLUMNS

该表提供查询有关InnoDB表列的元数据信息,等同于InnoDB数据字典中SYS_COLUMNS表的信息

  • 该表为memory引擎临时表,查询该表的用户需要具有process权限

下面是该表中存储的信息内容

admin@localhost : information_schema 06:51:17> select * from INNODB_SYS_COLUMNS limit 10;
+----------+--------------+-----+-------+---------+-----+
| TABLE_ID | NAME        | POS | MTYPE | PRTYPE  | LEN |
+----------+--------------+-----+-------+---------+-----+
|
      11 | ID          |  0 |    1 | 5439492 |  0 |
|      11 | FOR_NAME    |  1 |    1 | 5439492 |  0 |
|
      11 | REF_NAME    |  2 |    1 | 5439492 |  0 |
|      11 | N_COLS      |  3 |    6 |      0 |  4 |
|
      12 | ID          |  0 |    1 | 5439492 |  0 |
|      12 | POS          |  1 |    6 |      0 |  4 |
|
      12 | FOR_COL_NAME |  2 |    1 | 5439492 |  0 |
|      12 | REF_COL_NAME |  3 |    1 | 5439492 |  0 |
|
      13 | SPACE        |  0 |    6 |      0 |  4 |
|      13 | NAME        |  1 |    1 | 5439492 |  0 |
+----------+--------------+-----+-------+---------+-----+
10 rows in set (0.00 sec)


字段含义如下:

  • TABLE_ID:表示与该列关联的表的ID,与来自INNODB_SYS_TABLES表的TABLE_ID的值相同

  • NAME:列名称,名称可以是大写也可以是小写字母,具体取决于lower_case_table_names系统变量的设置

  • POS:列在表中的顺序位置,从0开始并依次递增。当一个列被删除时,剩下的列会被重新排序,以使得该序列无间隙

  • MTYPE:列类型的数字ID编号。1 = VARCHAR、2 = CHAR、3 = FIXBINARY、4 = BINARY、5 = BLOB、6 = INT、7 = SYS_CHILD、8 = SYS、9 = FLOAT、10 = DOUBLE、11 = DECIMAL、12 = VARMYSQL、13 = MYSQL、14 = GEOMETRY

  • PRTYPE:InnoDB“精确类型”,是一个二进制表示值,位数代表MySQL数据类型、字符集代码、是否为空

  • LEN:列字节长度,例如INT为4字节,BIGINT为8字节。对于多字节字符集中的列字节长度,此长度值是为定义长度所需的最大字节,如VARCHAR(N),如果字符集为laitin1,则该字段的字节长度为N,如果字符集为gbk,则字段长度为2N,如果字符集为utf8,则字段长度为3N


9、INNODB_SYS_FOREIGN

该表提供查询有关InnoDB外键的元数据信息,等同于InnoDB数据字典中SYS_FOREIGN表的信息

  • 该表为memory引擎临时表,查询该表的用户需要有process权限

下面是该表中存储的信息内容

root@localhost : (none) 11:44:09> SELECT * FROM INFORMATION_SCHEMA.INNODB_SYS_FOREIGN;
+-------------------------------+------------------------+-----------------------+--------+------+
| ID                            | FOR_NAME              | REF_NAME              | N_COLS | TYPE |
+-------------------------------+------------------------+-----------------------+--------+------+
| employees/dept_emp_ibfk_1    | employees/dept_emp    | employees/employees  |      1 |    1 |
| employees/dept_emp_ibfk_2    | employees/dept_emp    | employees/departments |      1 |    1 |
| employees/dept_manager_ibfk_1 | employees/dept_manager | employees/employees  |      1 |    1 |
| employees/dept_manager_ibfk_2 | employees/dept_manager | employees/departments |      1 |    1 |
| employees/salaries_ibfk_1    | employees/salaries    | employees/employees  |      1 |    1 |
| employees/titles_ibfk_1      | employees/titles      | employees/employees  |      1 |    1 |
+-------------------------------+------------------------+-----------------------+--------+------+
6 rows in set (0.00 sec)


字段含义如下:

  • ID:外键约束的名称(注意不是数值,该字符串是约束名称,不是索引名称),该ID值由外键名称字符串+数据库名称组成,例如:"test/products_fk"

  • FOR_NAME:外键相关的子表的名称(即外键索引列所在的表)

  • REF_NAME:外键相关的父表的名称(即外键索引列引用列所在的表)

  • N_COLS:外键索引中的列数量

  • TYPE:带有关于外键列的信息的位标志集合,1 = ON DELETE CASCADE、2 = ON UPDATE SET NULL、4 = ON UPDATE CASCADE、8 = ON UPDATE SET NULL、16 = ON DELETE NO ACTION、32 = ON UPDATE NO ACTION


10、INNODB_SYS_TABLESTATS

该表提供查询有关InnoDB表的较低级别的状态信息视图。 MySQL优化器会使用这些统计信息数据来计算并确定在查询InnoDB表时要使用哪个索引。这些信息保存在内存中的数据结构中,与存储在磁盘上的数据无对应关系。InnoDB内部也无对应的系统表

  • 该表中保存着自上次服务器重新启动以来已打开并且未超出表缓存时间的表统计信息数据

  • 该表中记录的表统计信息仅针对DELETE或UPDATE操作对索引的修改更新。其他对非索引列的修改的更新操作该表中不会进行记录

  • 该表为memory引擎临时表,查询该表的用户需要有process权限

下面是该表中存储的信息内容

admin@localhost : information_schema 06:52:25> select * from INNODB_SYS_TABLESTATS where name like '%sbtest%' limit 20;
+----------+------------------------------------------------------+-------------------+----------+------------------+------------------+------------------+----------+-----------+
| TABLE_ID | NAME                                                | STATS_INITIALIZED | NUM_ROWS | CLUST_INDEX_SIZE | OTHER_INDEX_SIZE | MODIFIED_COUNTER | AUTOINC  | REF_COUNT |
+----------+------------------------------------------------------+-------------------+----------+------------------+------------------+------------------+----------+-----------+
|      119 | sbtest/FTS_0000000000000076_000000000000008e_INDEX_1 | Uninitialized    |        0 |                0 |                0 |                0 |        0 |        0 |
|      120 | sbtest/FTS_0000000000000076_000000000000008e_INDEX_2 | Uninitialized    |        0 |                0 |                0 |                0 |        0 |        0 |
|      121 | sbtest/FTS_0000000000000076_000000000000008e_INDEX_3 | Uninitialized    |        0 |                0 |                0 |                0 |        0 |        0 |
|      122 | sbtest/FTS_0000000000000076_000000000000008e_INDEX_4 | Uninitialized    |        0 |                0 |                0 |                0 |        0 |        0 |
|      123 | sbtest/FTS_0000000000000076_000000000000008e_INDEX_5 | Uninitialized    |        0 |                0 |                0 |                0 |        0 |        0 |
|      124 | sbtest/FTS_0000000000000076_000000000000008e_INDEX_6 | Uninitialized    |        0 |                0 |                0 |                0 |        0 |        0 |
|      125 | sbtest/FTS_0000000000000076_BEING_DELETED            | Uninitialized    |        0 |                0 |                0 |                0 |        0 |        0 |
|      126 | sbtest/FTS_0000000000000076_BEING_DELETED_CACHE      | Uninitialized    |        0 |                0 |                0 |                0 |        0 |        0 |
|      127 | sbtest/FTS_0000000000000076_CONFIG                  | Uninitialized    |        0 |                0 |                0 |                0 |        0 |        0 |
|      128 | sbtest/FTS_0000000000000076_DELETED                  | Uninitialized    |        0 |                0 |                0 |                0 |        0 |        0 |
|      129 | sbtest/FTS_0000000000000076_DELETED_CACHE            | Uninitialized    |        0 |                0 |                0 |                0 |        0 |        0 |
|      45 | sbtest/sbtest1                                      | Initialized      |  4392380 |            62720 |            5929 |                0 | 10730975 |        2 |
|      46 | sbtest/sbtest2                                      | Initialized      |  4707512 |            67264 |            7145 |                0 | 10727715 |        1 |
|      43 | sbtest/sbtest3                                      | Initialized      |  4451936 |            63616 |            6057 |                0 | 10731473 |        1 |
|      47 | sbtest/sbtest4                                      | Initialized      |  4728110 |            67520 |            7337 |                0 | 10730695 |        1 |
|      42 | sbtest/sbtest5                                      | Initialized      |  4372701 |            62464 |            5737 |                0 | 10729813 |        1 |
|      41 | sbtest/sbtest6                                      | Initialized      |  4550283 |            65024 |            6569 |                0 | 10729407 |        1 |
|      44 | sbtest/sbtest7                                      | Initialized      |  4630701 |            66112 |            6889 |                0 | 10729717 |        1 |
|      48 | sbtest/sbtest8                                      | Initialized      |  4596733 |            65664 |            6633 |                0 | 10727951 |        1 |
|      118 | sbtest/xx                                            | Initialized      |        2 |                1 |                1 |                0 |        0 |        1 |
+----------+------------------------------------------------------+-------------------+----------+------------------+------------------+------------------+----------+-----------+
20 rows in set (0.00 sec)


字段含义如下:

  • TABLE_ID:表示统计信息相关的表ID,与INNODB_SYS_TABLES.TABLE_ID字段值相同

  • NAME:数据库名称+表名称字符串值,与INNODB_SYS_TABLES.NAME字段值相同

  • STATS_INITIALIZED:如果某表已经收集了统计信息,则该值为“Initialized”;如果未收集,则为“Uninitialized”

  • NUM_ROWS:表中当前的估计行数。每次DML操作后更新该值。但该值可能不准确,例如:如果存在未提交的事务正在插入或从表中删除记录时,该列值的统计可能不准确

  • CLUST_INDEX_SIZE:磁盘上存储聚簇索引的页数量,聚集索引是存储结构,以主键的顺序保存InnoDB表数据。如果未收集过表的统计信息,则此列值可能为空(0值)

  • OTHER_INDEX_SIZE:磁盘上存储的表的所有二级索引的页数量。如果未收集过表的统计信息,则此列值可能为空(0值)

  • MODIFIED_COUNTER:DML操作修改的行数量,例如:INSERT、UPDATE、DELETE,以及外键更新时的级联更新操作都会触发重新计算行数量统计并覆盖之前的值

  • AUTOINC:自增操作的下一个数字值。AUTOINC列值的更新速率取决于自增数量的请求次数以及每个请求被授予的自增数量

  • REF_COUNT:当此计数器达到零值时,表元数据信息可能会从表缓存中逐出出去


本期内容就介绍到这里,本期内容参考链接如下:

  • https://dev.mysql.com/doc/refman/5.7/en/innodb-sys-datafiles-table.html

  • https://dev.mysql.com/doc/refman/5.7/en/innodb-sys-virtual-table.html

  • https://dev.mysql.com/doc/refman/5.7/en/innodb-sys-indexes-table.html

  • https://dev.mysql.com/doc/refman/5.7/en/innodb-sys-tables-table.html

  • https://dev.mysql.com/doc/refman/5.7/en/innodb-sys-fields-table.html

  • https://dev.mysql.com/doc/refman/5.7/en/innodb-sys-tablespaces-table.html

  • https://dev.mysql.com/doc/refman/5.7/en/innodb-sys-foreign-cols-table.html

  • https://dev.mysql.com/doc/refman/5.7/en/innodb-sys-columns-table.html

  • https://dev.mysql.com/doc/refman/5.7/en/innodb-sys-foreign-table.html

  • https://dev.mysql.com/doc/refman/5.7/en/innodb-sys-tablestats-table.html



| 关于作者

罗小波·沃趣科技数据库技术专家

相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
5月前
|
存储 关系型数据库 分布式数据库
PolarDB产品使用问题之如何用InnoDB引擎创建Federated表
PolarDB产品使用合集涵盖了从创建与管理、数据管理、性能优化与诊断、安全与合规到生态与集成、运维与支持等全方位的功能和服务,旨在帮助企业轻松构建高可用、高性能且易于管理的数据库环境,满足不同业务场景的需求。用户可以通过阿里云控制台、API、SDK等方式便捷地使用这些功能,实现数据库的高效运维与持续优化。
52 1
|
存储 关系型数据库 MySQL
MySQL使用InnoDB引擎时一张表最大可以储存数据大小为 64TB,那为什么当表中的单行数据达到16KB时,这张表只能储存一条数据?
MySQL使用InnoDB引擎时一张表最大可以储存数据大小为 64TB,那为什么当表中的单行数据达到16KB时,这张表只能储存一条数据?
169 0
|
存储 运维 安全
数据库运维之InnoDB存储引擎表损坏修复方法
InnoDB存储引擎表的损坏可能是多种因素导致的,比如服务器断电、系统崩溃、硬盘损坏、写数据过程中mysqld进程被kill掉。
1051 0
|
关系型数据库 MySQL 测试技术
只有.frm和.ibd文件时如何批量恢复InnoDB的表---发表到爱可生开源社区
很多时候因为MySQL数据库不能启动而造成数据无法访问,但应用的数据通常没有丢失,只是系统表空间等其它文件损坏了,或者遇到MySQL的bug。
135 0
|
存储 关系型数据库 MySQL
MySQL InnoDB表和索引之聚簇索引与第二索引
MySQL InnoDB表和索引之聚簇索引与第二索引
92 0
|
存储 SQL 缓存
【MySQL从入门到精通】【高级篇】(六)MySQL表的存储引擎,InnoDB与MyISAM的对比
上一篇文章介绍了MySQL中SQL语句的执行流程 【MySQL从入门到精通】【高级篇】(五)MySQL的SQL语句执行流程,在介绍执行流程时提到了InnoDB和MyISAM两种存储引擎。这篇文章将来详细介绍下这两种存储引擎。
264 0
【MySQL从入门到精通】【高级篇】(六)MySQL表的存储引擎,InnoDB与MyISAM的对比
|
SQL 关系型数据库 MySQL
[MySQL优化案例]系列 — 索引、提交频率对InnoDB表写入速度的影响
[MySQL优化案例]系列 — 索引、提交频率对InnoDB表写入速度的影响
137 0
[MySQL优化案例]系列 — 索引、提交频率对InnoDB表写入速度的影响
|
存储 Oracle 关系型数据库
[MySQL优化案例]系列 — 优化InnoDB表BLOB列的存储效率
[MySQL优化案例]系列 — 优化InnoDB表BLOB列的存储效率
179 0
[MySQL优化案例]系列 — 优化InnoDB表BLOB列的存储效率
|
关系型数据库 MySQL
InnoDB系统表空间定义规则
1. InnoDB系统表空间定义规则 2. 并行复制设置不当可能导致主从数据不一致
100 0
|
存储 关系型数据库 MySQL
InnoDB表聚集索引层高什么时候发生变化(2)
InnoDB表聚集索引层高什么时候发生变化