MySQL8.0.37

统计

1	ADMINISTRABLE_ROLE_AUTHORIZATIONS
2	APPLICABLE_ROLES
3	CHARACTER_SETS	提供了关于可用字符集的信息
4	CHECK_CONSTRAINTS
5	COLLATIONS	提供了关于字符集的排序规则的信息
6	COLLATION_CHARACTER_SET_APPLICABILITY
7	COLUMNS	提供了表中列的详细信息，如列名、数据类型、是否允许 NULL、所属表和数据库等
8	COLUMNS_EXTENSIONS
9	COLUMN_PRIVILEGES	包含了列级别的权限信息
10	COLUMN_STATISTICS	直方图
11	ENABLED_ROLES	提供当前会话中启用角色的信息
12	ENGINES	记录MySQL支持的存储引擎的信息
13	EVENTS	提供有关MySQL事件调度器事件的信息
14	FILES	提供了有关存储MySQL表空间数据的文件的信息
15	INNODB_BUFFER_PAGE
16	INNODB_BUFFER_PAGE_LRU
17	INNODB_BUFFER_POOL_STATS
18	INNODB_CACHED_INDEXES
19	INNODB_CMP
20	INNODB_CMPMEM
21	INNODB_CMPMEM_RESET
22	INNODB_CMP_PER_INDEX
23	INNODB_CMP_PER_INDEX_RESET
24	INNODB_CMP_RESET
25	INNODB_COLUMNS
26	INNODB_DATAFILES
27	INNODB_FIELDS
28	INNODB_FOREIGN
29	INNODB_FOREIGN_COLS
30	INNODB_FT_BEING_DELETED
31	INNODB_FT_CONFIG
32	INNODB_FT_DEFAULT_STOPWORD
33	INNODB_FT_DELETED
34	INNODB_FT_INDEX_CACHE
35	INNODB_FT_INDEX_TABLE
36	INNODB_INDEXES
37	INNODB_METRICS
38	INNODB_SESSION_TEMP_TABLESPACES
39	INNODB_TABLES	记录表的元数据信息
40	INNODB_TABLESPACES	记录表空间使用情况
41	INNODB_TABLESPACES_BRIEF
42	INNODB_TABLESTATS
43	INNODB_TEMP_TABLE_INFO
44	INNODB_TRX	记录表中每个事务的详细信息
45	INNODB_VIRTUAL	记录表中的虚拟列
46	KEYWORDS
47	KEY_COLUMN_USAGE	描述了具有约束的键列
48	OPTIMIZER_TRACE
49	PARAMETERS
50	PARTITIONS
51	PLUGINS	插件
52	PROCESSLIST	show processlist;
53	PROFILING	show profiles;
54	REFERENTIAL_CONSTRAINTS
55	RESOURCE_GROUPS
56	ROLE_COLUMN_GRANTS
57	ROLE_ROUTINE_GRANTS
58	ROLE_TABLE_GRANTS
59	ROUTINES	包含了存储过程和函数的信息，如函数名、定义、字符集等
60	SCHEMATA	提供了关于数据库的信息，如数据库名、默认字符集和排序规则等
61	SCHEMATA_EXTENSIONS
62	SCHEMA_PRIVILEGES	包含了数据库级别的权限信息
63	STATISTICS	包含了表索引的信息，如索引名称、所属数据库和表、索引类型等
64	ST_GEOMETRY_COLUMNS
65	ST_SPATIAL_REFERENCE_SYSTEMS
66	ST_UNITS_OF_MEASURE
67	TABLES	包含了数据库中所有表的信息，包括表名、所属数据库、表类型（如基础表或视图）、存储引擎、行数、存储占用、创建时间等
68	TABLESPACES
69	TABLESPACES_EXTENSIONS
70	TABLES_EXTENSIONS
71	TABLE_CONSTRAINTS	描述了表的约束信息，如主键、唯一约束等
72	TABLE_CONSTRAINTS_EXTENSIONS
73	TABLE_PRIVILEGES	包含了表级别的权限信息
74	TRIGGERS	提供了触发器的信息，包括触发器名称、触发条件和执行的语句等
75	USER_ATTRIBUTES
76	USER_PRIVILEGES	包含了全局权限的信息，如用户的全局权限
77	VIEWS	存储了数据库视图的信息，包括视图定义、字符集等
78	VIEW_ROUTINE_USAGE
79	VIEW_TABLE_USAGE

ADMINISTRABLE_ROLE_AUTHORIZATIONS

ADMINISTRABLE_ROLE_AUTHORIZATIONS 表是 MySQL INFORMATION_SCHEMA 数据库中的一个表，它提供有关当前用户或角色可以授予给其他用户或角色的角色的信息。这个表在 MySQL 8.0.19 及以后的版本中可用。此表包含以下列：

• USER: 当前用户账户的用户名部分。
• HOST: 当前用户账户的主机名部分。
• GRANTEE: 被授予角色的账户的用户名部分。
• GRANTEE_HOST: 被授予角色的账户的主机名部分。
• ROLE_NAME: 被授予角色的用户名部分。
• ROLE_HOST: 被授予角色的主机名部分。
• IS_GRANTABLE: 一个 YES 或 NO 值，表示该角色是否可以授予给其他账户。
• IS_DEFAULT: 一个 YES 或 NO 值，表示角色是否为默认角色。
• IS_MANDATORY: 一个 YES 或 NO 值，表示角色是否是强制性的。

这个表对于数据库管理员来说是有价值的，因为它可以帮助他们理解和管理数据库中的角色和权限。例如，管理员可以使用此表来确定哪些角色可以被特定用户授予，以及这些角色的授予权限情况。

APPLICABLE_ROLES

APPLICABLE_ROLES 表是 MySQL INFORMATION_SCHEMA 数据库中的一个表，它提供有关当前用户或启用的角色的所有适用角色的信息。这个表在 MySQL 8.0.19 及以后的版本中可用。此表包含以下列：

• USER: 当前用户账户的用户名部分。
• HOST: 当前用户账户的主机名部分。
• GRANTEE: 角色被授予的账户的用户名部分。
• GRANTEE_HOST: 授予角色的账户的主机名部分。
• ROLE_NAME: 授予角色的用户名部分。
• ROLE_HOST: 授予角色的主机名部分。
• IS_GRANTABLE: 一个 YES 或 NO 值，表示该角色是否可以授予给其他账户。
• IS_DEFAULT: 一个 YES 或 NO 值，表示角色是否为默认角色。
• IS_MANDATORY: 一个 YES 或 NO 值，表示角色是否是强制性的。

这个表对于数据库管理员来说是有价值的，因为它可以帮助他们理解和管理数据库中的角色和权限。例如，管理员可以使用此表来确定哪些角色适用于当前用户，以及这些角色的授予权限情况。

CHARACTER_SETS

CHARACTER_SETS 表是 MySQL 的 INFORMATION_SCHEMA 数据库中的一个表，它提供有关 MySQL 服务器支持的字符集的信息。以下是 CHARACTER_SETS 表中的一些关键列及其描述：

• CHARACTER_SET_NAME: 字符集的名称。
• DEFAULT_COLLATE_NAME: 字符集的默认排序规则（collation）。
• DESCRIPTION: 字符集的描述性文字。
• MAXLEN: 存储一个字符所需的最大字节数。

该表列出了 MySQL 服务器支持的所有字符集及其相关信息。例如，utf8mb4 是一种常用的字符集，支持存储任意 Unicode 字符，而 latin1 是一种西欧语言的字符集。通过查询这个表，可以了解服务器上可用的不同字符集及其属性。

要查看 MySQL 中的字符集信息，除了查询 CHARACTER_SETS 表外，还可以使用 SHOW CHARACTER SET 语句。这些方法提供了一个关于服务器支持的字符集的概览，这对于处理国际化应用程序和数据迁移非常重要。

CHECK_CONSTRAINTS

CHECK_CONSTRAINTS 表是 MySQL INFORMATION_SCHEMA 数据库中的一个表，它提供有关表或列上的 CHECK 约束的信息。从 MySQL 8.0.16 版本开始，CREATE TABLE 语句允许使用 CHECK 约束，这些约束用于确保表中的数据满足一定的条件。CHECK_CONSTRAINTS 表包含了这些约束的详细信息，具体列如下：

• CONSTRAINT_CATALOG: 约束所属目录的名称，对于 MySQL，这个值通常是 def。
• CONSTRAINT_SCHEMA: 约束所属的数据库（模式）的名称。
• CONSTRAINT_NAME: 约束的名称。
• CHECK_CLAUSE: 定义约束条件的表达式。

这个表可以用来查询数据库中所有 CHECK 约束的详细信息，包括约束名称、所属表、以及约束的具体条件。这对于数据库管理员在进行数据完整性管理时非常有用。

例如，如果你想查看某个特定表的所有 CHECK 约束，你可以使用以下 SQL 查询：

SELECT CONSTRAINT_NAME, CHECK_CLAUSE 
FROM information_schema.CHECK_CONSTRAINTS
WHERE TABLE_SCHEMA = 'your_database_name' AND TABLE_NAME = 'your_table_name';

这将返回指定表的所有 CHECK 约束及其条件表达式。

COLLATIONS

COLLATIONS 表是 MySQL 的 INFORMATION_SCHEMA 数据库中的一个表，它提供有关每个字符集的排序规则（collation）的信息。以下是 COLLATIONS 表中的一些关键列及其描述：

• COLLATION_NAME: 排序规则的名称。
• CHARACTER_SET_NAME: 与排序规则关联的字符集名称。
• ID: 排序规则的唯一标识符（ID）。
• IS_DEFAULT: 表示这个排序规则是否是其字符集的默认排序规则，YES 或 NO。
• IS_COMPILED: 表示这个排序规则是否被编译到 MySQL 服务器中，YES 或 NO。
• SORTLEN: 与排序操作相关的内存长度要求。

排序规则定义了字符数据如何比较和排序。例如，某些排序规则可能是大小写敏感的，而其他排序规则可能是大小写不敏感的。排序规则通常与字符集一起使用，以确保数据的正确处理和显示。

要查询 COLLATIONS 表，可以使用以下 SQL 语句：

SELECT COLLATION_NAME, CHARACTER_SET_NAME, IS_DEFAULT, IS_COMPILED, SORTLEN 
FROM information_schema.COLLATIONS;

这个查询将返回服务器上所有可用排序规则的列表，以及每个规则所属的字符集和一些属性。

排序规则的信息也可以通过 SHOW COLLATION 语句获得。例如：

SHOW COLLATION WHERE Charset = 'utf8mb4';

这个命令将显示所有 utf8mb4 字符集的排序规则。

COLLATION_CHARACTER_SET_APPLICABILITY

COLLATION_CHARACTER_SET_APPLICABILITY 表是 MySQL 的 INFORMATION_SCHEMA 数据库中的一个表，它指示了哪个字符集适用于哪个排序规则（collation）。这个表在 MySQL 8.0.11 及以后的版本中可用。此表包含以下列：

• COLLATION_NAME: 排序规则的名称。
• CHARACTER_SET_NAME: 与排序规则关联的字符集名称。

这个表可以用来查询数据库中所有可用的排序规则及其对应的字符集。这对于数据库管理员在进行数据排序和国际化处理时非常有用。

COLUMNS

COLUMNS 表是 INFORMATION_SCHEMA 数据库中的一个表，它提供了关于数据库中所有表的列的信息。这个表对于查询和管理数据库结构非常有用，可以帮助您了解每个表中的列定义、数据类型、约束等细节。

以下是 COLUMNS 表的一些主要列及其含义：

• TABLE_CATALOG: 包含列的表所属的目录的名称，通常为 def。
• TABLE_SCHEMA: 包含列的表所属的数据库（模式）的名称。
• TABLE_NAME: 包含列的表的名称。
• COLUMN_NAME: 列的名称。
• ORDINAL_POSITION: 列在表中的顺序位置，从1开始。
• COLUMN_DEFAULT: 列的默认值。
• IS_NULLABLE: 是否允许NULL值，可以是 YES 或 NO。
• DATA_TYPE: 列的数据类型，如 int, varchar, datetime 等。
• CHARACTER_MAXIMUM_LENGTH: 对于字符类型，此列的最大长度。
• CHARACTER_OCTET_LENGTH: 对于字符类型，此列的最大字节长度。
• NUMERIC_PRECISION: 对于数值类型，精度（总位数）。
• NUMERIC_SCALE: 对于数值类型，小数位数。
• DATETIME_PRECISION: 对于日期和时间类型，精度（小数点后的位数）。
• CHARACTER_SET_NAME: 字符集名称。
• COLLATION_NAME: 排序规则名称。
• COLUMN_TYPE: 列的完整类型定义，包括类型和约束。
• COLUMN_KEY: 列的键类型，可以是 PRI（主键）、MUL（多值索引）等。
• EXTRA: 列的附加信息，如 AUTO_INCREMENT, ON UPDATE CURRENT_TIMESTAMP 等。
• PRIVILEGES: 列的权限，如 SELECT, INSERT, UPDATE, REFERENCES 等。
• COLUMN_COMMENT: 列的注释。

通过查询 COLUMNS 表，您可以获取特定数据库或表的列信息。例如，要获取特定数据库中的所有表和列信息，可以使用以下 SQL 查询：

SELECT TABLE_NAME, COLUMN_NAME, DATA_TYPE, CHARACTER_MAXIMUM_LENGTH
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = 'your_database_name';

要获取特定表的所有列信息，可以使用：

SELECT *
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = 'your_database_name' AND TABLE_NAME = 'your_table_name';

这些查询将返回表的列信息，包括列名、数据类型、是否允许为空、默认值等。

COLUMNS_EXTENSIONS

COLUMNS_EXTENSIONS 表是 MySQL INFORMATION_SCHEMA 数据库中的一个表，从 MySQL 8.0.21 版本开始提供。它提供有关数据库表列的扩展属性信息，这些属性是为主存储引擎和辅助存储引擎定义的。

以下是 COLUMNS_EXTENSIONS 表的列及其描述：

• TABLE_CATALOG: 表所属目录的名称，此值始终为 def 。
• TABLE_SCHEMA: 表所属的数据库（模式）的名称。
• TABLE_NAME: 表的名称。
• COLUMN_NAME: 列的名称。
• ENGINE_ATTRIBUTE: 为主存储引擎定义的列属性。这个属性是保留以供将来使用的 。
• SECONDARY_ENGINE_ATTRIBUTE: 为辅助存储引擎定义的列属性。这个属性也是保留以供将来使用的 。

这个表目前主要保留供将来使用，当前版本中这些列属性可能不包含实际的数据，但是它们为MySQL未来版本的存储引擎扩展提供了基础架构。

COLUMN_PRIVILEGES

COLUMN_PRIVILEGES 表是 INFORMATION_SCHEMA 数据库中的一个表，它提供有关列权限的信息。这些信息是从 mysql.columns_priv 系统表中获取的。以下是 COLUMN_PRIVILEGES 表中的一些关键列及其描述：

• GRANTEE: 授予权限的账户的名称，格式为 'user_name'@'host_name'。
• TABLE_CATALOG: 包含该列的表所属目录的名称，此值总是 def。
• TABLE_SCHEMA: 包含该列的表所属的数据库（模式）的名称。
• TABLE_NAME: 包含该列的表的名称。
• COLUMN_NAME: 列的名称。
• PRIVILEGE_TYPE: 授予的权限类型，可以是 SELECT、INSERT、UPDATE、REFERENCES 等。
• IS_GRANTABLE: 如果用户具有 GRANT OPTION 权限，则为 YES，否则为 NO。

这个表可以用来查询数据库中特定列的权限信息，包括哪些用户或角色拥有对这些列的特定权限。例如，如果你想查看某个特定表的所有列权限，可以使用以下 SQL 查询：

SELECT * 
FROM information_schema.COLUMN_PRIVILEGES
WHERE TABLE_SCHEMA = 'your_database_name' AND TABLE_NAME = 'your_table_name';

这个查询将返回指定表的所有列权限信息，包括哪些用户有权限访问这些列，以及他们拥有哪些类型的权限。

需要注意的是，COLUMN_PRIVILEGES 表是一个非标准的 INFORMATION_SCHEMA 表，因此在使用时需要特别注意，例如 SELECT ... FROM INFORMATION_SCHEMA.COLUMN_PRIVILEGES 与 SHOW GRANTS ... 语句的输出并不等效 。

COLUMN_STATISTICS

在 MySQL 中，information_schema.COLUMN_STATISTICS 表包含了数据库中每个表的列的统计信息，这些信息通常以直方图的形式存在。直方图是一种统计工具，它提供了关于数据分布的概览，可以帮助数据库优化器更有效地生成查询计划。

当你执行以下查询时：

SELECT * FROM COLUMN_STATISTICS;

你将看到以下几列：

1. SCHEMA_NAME: 数据库的名称。
2. TABLE_NAME: 表的名称。
3. COLUMN_NAME: 列的名称。
4. HISTOGRAM: 以 JSON 格式存储的直方图数据。

例如，返回的结果可能如下所示：

+-------------+------------+-------------+-----------+
| SCHEMA_NAME | TABLE_NAME | COLUMN_NAME | HISTOGRAM |
+-------------+------------+-------------+-----------+
| mydatabase  | mytable    | mycolumn    | {...}     |
+-------------+------------+-------------+-----------+

其中 HISTOGRAM 列将包含关于 mycolumn 列值分布的统计信息，这些信息以 JSON 对象的形式存储。例如：

{
  "buckets": [
    {
      "low_value": "10",
      "high_value": "20",
      "repeat_count": 100,
      "null_count": 0
    },
    ...
  ],
  "null_count": 0,
  "totalRowCount": 1000
}

在这个 JSON 示例中：

• buckets: 包含了一系列的区间（buckets），每个区间定义了列值的范围（low_value 到 high_value），以及这个范围内值出现的频率（repeat_count）。
• null_count: 列中 NULL 值的数量。
• totalRowCount: 表中行的总数。

直方图数据可以帮助优化器估计查询条件的匹配行数，从而选择最佳的查询执行计划。例如，如果一个查询条件是 mycolumn BETWEEN 10 AND 20，优化器可以使用直方图数据来估计大约有 100 行数据满足这个条件。

要查看具体的直方图数据，你可以选择特定的列，例如：

SELECT SCHEMA_NAME, TABLE_NAME, COLUMN_NAME, HISTOGRAM
FROM information_schema.COLUMN_STATISTICS
WHERE SCHEMA_NAME = 'mydatabase' AND TABLE_NAME = 'mytable' AND COLUMN_NAME = 'mycolumn';

这将返回 mydatabase 数据库中 mytable 表的 mycolumn 列的统计信息。

ENABLED_ROLES

ENABLED_ROLES 表是 INFORMATION_SCHEMA 数据库中的一个表，从 MySQL 8.0.19 版本开始引入。此表提供关于当前会话中启用的角色的信息。每个角色可以包含一组权限，并且可以在用户的当前会话中被激活。

以下是 ENABLED_ROLES 表的列及其描述：

• ROLE_NAME: 授予角色的用户名部分。
• ROLE_HOST: 授予角色的主机名部分。
• IS_DEFAULT: 一个 YES 或 NO 值，指示角色是否为默认角色。
• IS_MANDATORY: 一个 YES 或 NO 值，指示角色是否为强制性角色。

要查看当前会话中启用的角色，可以使用以下 SQL 查询：

SELECT ROLE_NAME, ROLE_HOST, IS_DEFAULT, IS_MANDATORY
FROM information_schema.ENABLED_ROLES;

这个查询将返回当前会话中启用的角色的列表，以及每个角色是否是默认角色或强制性角色的信息。默认角色是会话自动激活的角色，而强制性角色是服务器配置为所有用户会话必须激活的角色。

ENGINES

ENGINES 表是 INFORMATION_SCHEMA 数据库中的一个表，它提供了有关 MySQL 服务器支持的存储引擎的信息。这个表对于检查是否支持特定的存储引擎或查看默认引擎是什么特别有用。

以下是 ENGINES 表中的一些关键列及其描述：

• ENGINE: 存储引擎的名称。
• SUPPORT: 服务器对存储引擎的支持程度。可能的值包括 YES（引擎受支持并处于活动状态）、DEFAULT（除了 YES，还表示这是默认引擎）、NO（引擎不受支持）、DISABLED（引擎受支持但已被禁用）。
• COMMENT: 对存储引擎的简要描述。
• TRANSACTIONS: 存储引擎是否支持事务。
• XA: 存储引擎是否支持 XA 事务。
• SAVEPOINTS: 存储引擎是否支持保存点。

存储引擎是 MySQL 中用于数据存储和检索的底层软件组件。不同的存储引擎针对不同的应用场景进行了优化，例如 InnoDB 存储引擎支持事务、行级锁定和外键，而 MyISAM 存储引擎则提供了高速读取操作但不支持事务。MEMORY 存储引擎将所有数据保存在内存中，适合用于临时表或快速访问的小型数据集。

要查看 MySQL 中所有可用存储引擎的信息，可以使用以下 SQL 查询：

SELECT * FROM information_schema.ENGINES;

这个查询将返回服务器上所有可用存储引擎的列表，以及它们各自的支持级别、描述、事务支持情况等信息。

EVENTS

EVENTS 表是 INFORMATION_SCHEMA 数据库中的一个表，它提供有关 MySQL 事件调度器事件的信息。这些事件可以是按照一定频率自动执行的 SQL 语句或存储过程。以下是 EVENTS 表中的一些关键列及其描述：

• EVENT_CATALOG: 事件所属目录的名称，此值总是 def。
• EVENT_SCHEMA: 事件所属的数据库（模式）的名称。
• EVENT_NAME: 事件的名称。
• DEFINER: 创建事件的用户，格式为 'user_name'@'host_name'。
• TIME_ZONE: 事件执行的时区，默认为 SYSTEM，即操作系统使用的时区。
• EVENT_BODY: 事件 DO 子句中使用的语言，总是 SQL。
• EVENT_DEFINITION: 事件的 DO 子句的文本，即事件执行的 SQL 语句。
• EVENT_TYPE: 事件的重复类型，可以是 ONE TIME（一次性）或 RECURRING（重复执行）。
• EXECUTE_AT: 对于一次性事件，这是在创建事件的语句中指定的 DATETIME 值。
• INTERVAL_VALUE: 如果事件是重复执行的，则为两次执行的时间间隔。
• INTERVAL_FIELD: 两次事件执行之间的时间单位。
• STARTS: 重复性事件的开始时间。
• ENDS: 重复性事件的结束时间。
• STATUS: 事件的状态，可以是 ENABLED、DISABLED 或 SLAVESIDE_DISABLED。
• ON_COMPLETION: 事件完成后的行为，可以是 PRESERVE 或 NOT PRESERVE。
• CREATED: 事件的创建时间。
• LAST_ALTERED: 最后一次修改事件的时间。
• LAST_EXECUTED: 事件最后一次执行的时间。

要查看数据库中的事件及其相关信息，可以使用以下 SQL 查询：

SELECT EVENT_NAME, EVENT_DEFINITION, STATUS, LAST_EXECUTED
FROM information_schema.EVENTS
WHERE EVENT_SCHEMA = 'your_database_name';

这个查询将返回指定数据库中所有事件的名称、定义、状态和最后一次执行的时间。通过查询 EVENTS 表，您可以管理和诊断数据库中的定时任务事件。

FILES

FILES 表是 INFORMATION_SCHEMA 数据库中的一个表，它提供了有关存储 MySQL 表空间数据的文件的信息。这个表对于 InnoDB 存储引擎是特别有用的，因为它提供 InnoDB 数据文件的信息。在 NDB Cluster 中，此表还提供有关存储 NDB Cluster 磁盘数据表的文件的信息。

以下是 FILES 表中的一些关键列及其描述：

• FILE_ID: 表空间的 ID。
• FILE_NAME: 数据文件的名称。例如，.ibd 文件扩展名用于 file-per-table 和 general 表空间，undo 前缀用于撤消表空间，ibdata 前缀用于系统表空间，ibtmp 前缀用于临时表空间。
• FILE_TYPE: 文件的类型，可以是 TABLESPACE、TEMPORARY 或 UNDO LOG。
• TABLESPACE_NAME: 表空间的 SQL 名称。
• ENGINE: 存储引擎的名称，例如 InnoDB 或 ndbcluster。
• FREE_EXTENTS: 当前文件中完全空闲的段的个数。
• TOTAL_EXTENTS: 当前文件完全使用的段的个数。
• EXTENT_SIZE: 数据文件段的大小。
• INITIAL_SIZE: 文件的初始大小。
• MAXIMUM_SIZE: 数据文件的最大大小。
• AUTOEXTEND_SIZE: 数据文件的自动扩展大小。
• DATA_FREE: 整个表空间的剩余大小。
• STATUS: 文件的状态，通常为 NORMAL。

要查询 FILES 表，可以使用以下 SQL 语句：

SELECT FILE_NAME, FILE_TYPE, TABLESPACE_NAME, EXTENT_SIZE, INITIAL_SIZE, MAXIMUM_SIZE, AUTOEXTEND_SIZE, DATA_FREE
FROM information_schema.FILES
WHERE ENGINE='InnoDB';

这个查询将返回 InnoDB 存储引擎的文件信息，包括文件名、类型、表空间名称、段大小、初始大小、最大大小、自动扩展大小和剩余空间。

INNODB_BUFFER_PAGE

INNODB_BUFFER_PAGE 表是 INFORMATION_SCHEMA 数据库中的一个表，它提供有关 InnoDB 缓冲池中每个页面的信息。此表对于监控和诊断 InnoDB 缓冲池性能非常有用。以下是该表的一些关键列及其描述：

• POOL_ID: 缓冲池的 ID，用于区分多个缓冲池实例。
• BLOCK_ID: 缓冲池块的 ID。
• SPACE: 表空间 ID，与 INNODB_TABLES.SPACE 相同。
• PAGE_NUMBER: 页面编号。
• PAGE_TYPE: 页面类型，可能的值包括 INDEX、DATA、SYSTEM 等。
• FLUSH_TYPE: 冲洗类型。
• FIX_COUNT: 缓冲池中使用该块的线程数。
• IS_HASHED: 页面是否建立了哈希索引。
• NEWEST_MODIFICATION: 最新的修改的日志序列号。
• OLDEST_MODIFICATION: 最早的修改的日志序列号。
• ACCESS_TIME: 页面的访问时间。
• TABLE_NAME: 页所属表的名称。
• INDEX_NAME: 页面所属索引的名称。
• NUMBER_RECORDS: 页内的记录数。
• DATA_SIZE: 记录大小的总和。
• COMPRESSED_SIZE: 压缩页面的大小。
• PAGE_STATE: 页面状态，如 FILE_PAGE。
• IO_FIX: 页面是否有任何 I/O 挂起。
• IS_OLD: 该块是否在 LRU 列表中旧块的子列表中。
• FREE_PAGE_CLOCK: 当块最后被放置在 LRU 列表的头部时计数器的值。
• IS_STALE: 页面是否过时（在 MySQL 8.0.24 中添加）。

查询此表需要具有 PROCESS 权限。此表主要用于专家级性能监控，或在为 MySQL 开发与性能相关的扩展时使用。当表、表行、分区或索引被删除时，关联的页面将保留在缓冲池中，直到其他数据需要空间为止。该 INNODB_BUFFER_PAGE 表报告有关这些页面的信息，直到它们被从缓冲池中逐出。

INNODB_BUFFER_PAGE_LRU

INNODB_BUFFER_PAGE_LRU 表是 INFORMATION_SCHEMA 数据库中的一个表，它提供有关 InnoDB 缓冲池中页面的信息，特别是这些页面在最近最少使用（LRU）列表中的排序方式。这个排序决定了当缓冲池空间不足时，哪些页面应该被逐出缓冲池。

以下是 INNODB_BUFFER_PAGE_LRU 表中的一些关键列及其描述：

• POOL_ID: 缓冲池的 ID，用于区分多个缓冲池实例。
• LRU_POSITION: 页面在 LRU 列表中的位置。
• SPACE: 表空间 ID，与 INNODB_TABLES.SPACE 相同。
• PAGE_NUMBER: 页面编号。
• PAGE_TYPE: 页面类型，可能的值包括 INDEX、DATA、SYSTEM 等。
• FLUSH_TYPE: 页面的刷新类型。
• FIX_COUNT: 固定该页面的线程数量。当此值为零时，该页面有资格被逐出。
• IS_HASHED: 页面是否已经建立哈希索引。
• NEWEST_MODIFICATION: 页面的最新修改时间。
• OLDEST_MODIFICATION: 页面的最旧修改时间。
• ACCESS_TIME: 页面的访问时间。
• TABLE_NAME: 页面所属的表的名称。
• INDEX_NAME: 页面所属的索引的名称。
• NUMBER_RECORDS: 页面中的记录数。
• DATA_SIZE: 页面中数据的大小。
• COMPRESSED_SIZE: 压缩页面的大小。
• COMPRESSED: 页面是否被压缩。
• IO_FIX: 页面是否有任何挂起的 I/O 操作。
• IS_OLD: 页面是否在 LRU 列表中的旧页面子列表中。
• FREE_PAGE_CLOCK: 页面最后被放置在 LRU 列表头部时的 free_page_clock 计数器的值。

查询此表通常需要具有 PROCESS 权限，并且可能会对性能产生影响，因此不建议在生产环境中频繁查询此表。如果您需要监控或诊断缓冲池性能，应谨慎使用此表，并在测试环境中重现问题。

INNODB_BUFFER_POOL_STATS

INNODB_BUFFER_POOL_STATS 表是 INFORMATION_SCHEMA 数据库中的一个表，它提供有关 InnoDB 缓冲池的统计信息，这些信息与 SHOW ENGINE INNODB STATUS 命令的输出类似。此表包含许多关于 InnoDB 缓冲池的列，可以用于监控和性能调优。

以下是 INNODB_BUFFER_POOL_STATS 表中的一些关键列及其描述：

• POOL_ID: 缓冲池的 ID，用于区分多个缓冲池实例 。
• POOL_SIZE: InnoDB 缓冲池的大小，以页为单位 。
• FREE_BUFFERS: InnoDB 缓冲池中的空闲页数 。
• DATABASE_PAGES: InnoDB 缓冲池中包含数据的页数，包括脏页和干净页 。
• OLD_DATABASE_PAGES: 旧缓冲池子列表中的页数 。
• MODIFIED_DATABASE_PAGES: 已修改（脏）的数据库页数 。
• PENDING_DECOMPRESS: 等待解压的页数 。
• PENDING_READS: 等待读取的页数 。
• PENDING_FLUSH_LRU: LRU 列表中等待刷新的页数 。
• PENDING_FLUSH_LIST: 刷新列表中等待刷新的页数 。
• PAGES_MADE_YOUNG: 标记为“年轻”的页数 。
• PAGES_NOT_MADE_YOUNG: 未标记为“年轻”的页数 。
• PAGES_MADE_YOUNG_RATE: 每秒标记为“年轻”的页数 。
• PAGES_MADE_NOT_YOUNG_RATE: 每秒未标记为“年轻”的页数 。
• NUMBER_PAGES_READ: 读取的页数 。
• NUMBER_PAGES_CREATED: 创建的页数 。
• NUMBER_PAGES_WRITTEN: 写入的页数 。
• PAGES_READ_RATE: 每秒读取的页数 。
• PAGES_CREATE_RATE: 每秒创建的页数 。
• PAGES_WRITTEN_RATE: 每秒写入的页数 。
• NUMBER_PAGES_GET: 逻辑读取请求的数量 。
• HIT_RATE: 缓冲池命中率 。
• YOUNG_MAKE_PER_THOUSAND_GETS: 每千个获取请求中标记为“年轻”的页数 。
• NOT_YOUNG_MAKE_PER_THOUSAND_GETS: 每千个获取请求中未标记为“年轻”的页数 。
• NUMBER_PAGES_READ_AHEAD: 预读的页数 。
• NUMBER_READ_AHEAD_EVICTED: 由预读后台线程读入 InnoDB 缓冲池但未被查询访问即被驱逐的页数 。
• READ_AHEAD_RATE: 每秒预读的页数 。
• READ_AHEAD_EVICTED_RATE: 每秒驱逐的预读页数 。

要查询 INNODB_BUFFER_POOL_STATS 表，可以使用以下 SQL 语句：

SELECT * FROM information_schema.INNODB_BUFFER_POOL_STATS;

这个查询将返回 InnoDB 缓冲池的统计信息，包括页数、读取率、命中率等。这些信息对于监控缓冲池性能和调整缓冲池大小非常有用。

INNODB_CACHED_INDEXES

INNODB_CACHED_INDEXES 表是 INFORMATION_SCHEMA 数据库中的一个表，从 MySQL 8.0 开始引入。它提供了有关 InnoDB 缓冲池中缓存的索引页面的信息。

以下是 INNODB_CACHED_INDEXES 表中的一些关键列及其描述：

• SPACE_ID: 表空间的 ID。
• INDEX_ID: 索引的唯一标识符。这个标识符在实例中是唯一的。
• N_CACHED_PAGES: InnoDB 缓冲池中缓存的索引页面数。

这个表可以用来查看哪些索引被缓存在缓冲池中以及缓存的页面数。这对于性能调优和监控索引使用情况非常有用。例如，如果您想要查看特定索引在缓冲池中的缓存页面数，可以使用以下查询：

SELECT * FROM information_schema.INNODB_CACHED_INDEXES WHERE INDEX_ID=你的索引ID;

此外，如果您想获取表名和索引名，可以将 INNODB_CACHED_INDEXES 与其他表如 INNODB_INDEXES 和 INNODB_TABLES 联查：

SELECT
tables.NAME AS table_name,
indexes.NAME AS index_name,
cached.N_CACHED_PAGES AS n_cached_pages
FROM
INFORMATION_SCHEMA.INNODB_CACHED_INDEXES AS cached,
INFORMATION_SCHEMA.INNODB_INDEXES AS indexes,
INFORMATION_SCHEMA.INNODB_TABLES AS tables
WHERE
cached.INDEX_ID = indexes.INDEX_ID
AND indexes.TABLE_ID = tables.TABLE_ID;

要查询此表，您需要具有 PROCESS 权限。这个表对于数据库管理员在监控和优化数据库性能时非常有用，尤其是在处理大量索引和表空间的情况下 。

INNODB_CMP

INNODB_CMP 表是 INFORMATION_SCHEMA 数据库中的一个表，它提供有关 InnoDB 存储引擎的压缩操作的信息。这个表主要用于存储 InnoDB 引擎的压缩字典的比较信息，包括压缩前后的页数量和大小的统计，有助于评估和监控 InnoDB 表和索引使用压缩功能的效果。

以下是 INNODB_CMP 表中的一些关键列及其描述：

• PAGE_SIZE: 表示压缩评估中涉及的页面大小。
• COMPRESS_OPS: 自上次重置以来，压缩操作的总数。
• COMPRESS_OPS_OK: 自上次重置以来，成功完成的压缩操作数。
• COMPRESS_TIME: 执行所有压缩操作所花费的时间（微秒）。
• UNCOMPRESS_OPS: 自上次重置以来，解压缩操作的总数。
• UNCOMPRESS_TIME: 执行所有解压缩操作所花费的时间（微秒）。

通过查询这个表，数据库管理员或开发者可以了解压缩如何影响存储空间的使用和数据库的整体性能。例如，如果发现压缩操作耗时较长，但节省的空间不多，可能需要重新考虑是否继续使用压缩或者调整压缩级别。

要查询 INNODB_CMP 表，可以使用以下 SQL 语句：

SELECT * FROM information_schema.INNODB_CMP;

这个查询将返回 InnoDB 压缩操作的统计信息，包括页面大小、压缩操作次数、成功压缩操作次数、压缩操作耗时、解压缩操作次数和解压缩操作耗时。这些信息对于监控压缩性能和优化数据库配置非常有用。

INNODB_CMPMEM

INNODB_CMPMEM 表是 INFORMATION_SCHEMA 数据库中的一个表，它提供有关 InnoDB 缓冲池中压缩页面使用情况的详细信息。此表对于监控和管理 InnoDB 缓冲池中压缩页面的内存使用情况非常有用。

以下是 INNODB_CMPMEM 表中的一些关键列及其描述：

• PAGE_SIZE: 表示压缩的页有效块大小（以字节为单位）。
• BUFFER_POOL_INSTANCE: 缓冲池实例的唯一标识符。
• PAGES_USED: 表示对应每行记录中的 PAGE_SIZE 块大小的块数（页数）。
• PAGES_FREE: 表示每行记录对应的 PAGE_SIZE 块大小的当前可分配的块数。此列显示内存池中的外部碎片。理想情况下，该列值不应该超过1。
• RELOCATION_OPS: 表示 PAGE_SIZE 列值对应的块大小的块被重新设置的次数。
• RELOCATION_TIME: 表示用于重新定位 PAGE_SIZE 列值大小的块的总时间（以微秒为单位）。

通过查询这个表，您可以了解不同块大小的页面在缓冲池中的使用情况，以及这些页面的重定位操作次数和时间。这有助于评估压缩对性能的影响和缓冲池的内存使用效率。

要查询 INNODB_CMPMEM 表，可以使用以下 SQL 语句：

SELECT * FROM information_schema.INNODB_CMPMEM;

这个查询将返回 InnoDB 缓冲池中压缩页面的统计信息，包括块大小、使用的页数、空闲页数、重定位操作次数和重定位时间。

INNODB_CMPMEM_RESET

INNODB_CMPMEM_RESET 表是 INFORMATION_SCHEMA 数据库中的一个表，它提供有关 InnoDB 存储引擎缓冲池中压缩页面内存使用情况的统计信息。该表的统计信息可以帮助你了解压缩页面在缓冲池中的分布和使用情况。

以下是 INNODB_CMPMEM_RESET 表中的一些关键列及其描述：

• PAGE_SIZE: 表示压缩页的大小（以字节为单位）。
• BUFFER_POOL_INSTANCE: 缓冲池实例的唯一标识符。
• PAGES_USED: 表示当前正在使用的指定 PAGE_SIZE 的页数。
• PAGES_FREE: 表示当前可用于分配的指定 PAGE_SIZE 的空闲页数。这个值表示缓冲池的碎片情况，理想情况下，这些数字最多应为 1。
• RELOCATION_OPS: 表示大小为 PAGE_SIZE 的页面已被重定位的次数。当伙伴系统试图形成更大的释放块时，可以重新分配释放块的分配的“伙伴邻居”。
• RELOCATION_TIME: 表示用于重新定位大小为 PAGE_SIZE 的页面的总时间（以微秒为单位）。当从 INNODB_CMPMEM_RESET 表中读取时，此计数会被重置。

这些统计信息可以用来衡量 InnoDB 表压缩的有效性。例如，你可以创建多个版本的表（每个候选值一个），在它们上运行实际的工作负载，然后使用这些表来查看不同页面大小下的操作如何执行。

要查询 INNODB_CMPMEM_RESET 表，可以使用以下 SQL 语句：

SELECT * FROM information_schema.INNODB_CMPMEM_RESET;

这个查询将返回 InnoDB 缓冲池中压缩页面的统计信息，包括块大小、使用的页数、空闲页数、重定位操作次数和重定位时间。这些信息对于监控压缩性能和优化数据库配置非常有用 。

INNODB_CMP_PER_INDEX

INNODB_CMP_PER_INDEX 表是 INFORMATION_SCHEMA 数据库中的一个表，它为 InnoDB 存储引擎的压缩表和索引提供操作状态信息。此表为数据库、表和索引的每个组合提供单独的统计信息，帮助评估特定表的压缩性能和有用性。对于压缩的 InnoDB 表，表数据和所有二级索引都会被压缩。此表中的统计信息可以用于衡量 InnoDB 表压缩对特定表、索引或两者的有效性 。

以下是 INNODB_CMP_PER_INDEX 表中的一些关键列及其描述：

• DATABASE_NAME: 包含适用表的架构（数据库）。
• TABLE_NAME: 要监视压缩统计信息的表。
• INDEX_NAME: 要监视压缩统计信息的索引。
• COMPRESS_OPS: 尝试的压缩操作数。每当创建空白页或未压缩的修改日志空间用完时，页面会被压缩。
• COMPRESS_OPS_OK: 成功的压缩操作数。从 COMPRESS_OPS 值中减去此数值可得到压缩失败的次数。
• COMPRESS_TIME: 用于压缩此索引中的数据的总时间（以秒为单位）。
• UNCOMPRESS_OPS: 执行的解压缩操作数。每当压缩失败或第一次在缓冲池中访问压缩页面且未压缩页面不存在时，压缩的 InnoDB 页面会被解压缩。
• UNCOMPRESS_TIME: 用于解压缩此索引中的数据的总时间（以秒为单位）。

要查询此表，您需要具有 PROCESS 权限。此外，因为收集每个索引的单独测量值会带来很大的性能开销，所以 INNODB_CMP_PER_INDEX 统计信息默认情况下不会收集，您必须在执行要监控的压缩表操作之前启用 innodb_cmp_per_index_enabled 系统变量 。

查询示例：

SELECT * FROM information_schema.INNODB_CMP_PER_INDEX;

这个查询将返回特定表的压缩操作统计信息，包括数据库名、表名、索引名、压缩操作次数、成功压缩操作次数、压缩操作耗时、解压缩操作次数和解压缩操作耗时。这些信息对于监控压缩性能和优化数据库配置非常有用。

INNODB_CMP_PER_INDEX_RESET

INNODB_CMP_PER_INDEX_RESET 表是 INFORMATION_SCHEMA 数据库中的一个表，它提供有关 InnoDB 存储引擎的压缩表和索引的操作状态信息。这个表为数据库、表和索引的每个组合提供单独的统计信息，帮助评估特定表的压缩性能和有用性。对于压缩的 InnoDB 表，表数据和所有二级索引都被压缩。此表中的统计信息可以用于衡量压缩对性能的影响和缓冲池的内存使用效率。

以下是 INNODB_CMP_PER_INDEX_RESET 表中的一些关键列及其描述：

• DATABASE_NAME: 包含适用表的架构（数据库）。
• TABLE_NAME: 要监视压缩统计信息的表。
• INDEX_NAME: 要监视压缩统计信息的索引。
• COMPRESS_OPS: 尝试的压缩操作数。每当创建空白页或未压缩的修改日志空间用完时，页面会被压缩。
• COMPRESS_OPS_OK: 成功的压缩操作数。从 COMPRESS_OPS 值中减去此数值可得到压缩失败的次数。
• COMPRESS_TIME: 执行所有压缩操作所花费的时间（以秒为单位）。
• UNCOMPRESS_OPS: 自上次重置以来，解压缩操作的总数。
• UNCOMPRESS_TIME: 执行所有解压缩操作所花费的时间（以秒为单位）。

通过查询这个表，数据库管理员或开发者可以了解压缩如何影响存储空间的使用和数据库的整体性能。例如，如果发现压缩操作耗时较长，但节省的空间不多，可能需要重新考虑是否继续使用压缩或者调整压缩级别。

要查询 INNODB_CMP_PER_INDEX_RESET 表，可以使用以下 SQL 语句：

SELECT * FROM information_schema.INNODB_CMP_PER_INDEX_RESET;

这个查询将返回 InnoDB 缓冲池中压缩页面的统计信息，包括数据库名、表名、索引名、压缩操作次数、成功压缩操作次数、压缩操作耗时、解压缩操作次数和解压缩操作耗时。这些信息对于监控压缩性能和优化数据库配置非常有用。

INNODB_CMP_RESET

INNODB_CMP_RESET 表是 INFORMATION_SCHEMA 数据库中的一个表，它提供有关 InnoDB 存储引擎的压缩表操作的状态信息。该表与 INNODB_CMP 表具有相同的内容，但读取 INNODB_CMP_RESET 会重置统计信息，因此可以用来监控压缩和解压缩操作的统计数据。

以下是 INNODB_CMP_RESET 表中的一些关键列及其描述：

• PAGE_SIZE: 表示压缩页面的大小（以字节为单位）。
• COMPRESS_OPS: 自上次重置以来，尝试压缩操作的总数。
• COMPRESS_OPS_OK: 自上次重置以来，成功完成的压缩操作数。
• COMPRESS_TIME: 执行所有压缩操作所花费的时间（以秒为单位）。
• UNCOMPRESS_OPS: 自上次重置以来，解压缩操作的总数。
• UNCOMPRESS_TIME: 执行所有解压缩操作所花费的时间（以秒为单位）。

通过查询这个表，您可以了解压缩操作的频率、成功率以及它们对性能的影响。例如，如果发现压缩操作耗时较长，但节省的空间不多，可能需要重新考虑是否继续使用压缩或者调整压缩级别。

要查询 INNODB_CMP_RESET 表，可以使用以下 SQL 语句：

SELECT * FROM information_schema.INNODB_CMP_RESET;

这个查询将返回自上次重置以来的压缩操作统计信息，包括页面大小、压缩操作次数、成功压缩操作次数、压缩操作耗时、解压缩操作次数和解压缩操作耗时。这些信息对于监控压缩性能和优化数据库配置非常有用 。

INNODB_COLUMNS

INNODB_COLUMNS 表是 INFORMATION_SCHEMA 数据库中的一个表，它提供有关 InnoDB 表列的元数据。这些信息通常与 InnoDB 内部数据字典中的 SYS_COLUMNS 表中的数据相对应。以下是 INNODB_COLUMNS 表中的一些关键列及其描述：

• TABLE_ID: 一个标识符，代表与列关联的表；与 INNODB_TABLES.TABLE_ID 的值相同 。
• NAME: 列的名称。这些名称可以是大写或小写，具体取决于 lower_case_table_names 设置。列没有特殊的系统保留名称 。
• POS: 表中列的序号位置，从 0 开始依次递增。当删除一列时，剩余的列将重新排序，以便序列没有间隙 。
• MTYPE: 代表“主要类型”。列类型的数字标识符，例如：1 表示 VARCHAR，2 表示 CHAR 等 。
• PRTYPE: InnoDB“精确类型”，一个二进制值，其中的位表示 MySQL 数据类型、字符集代码和可空性 。
• LEN: 列长度，例如 4 表示 INT，8 表示 BIGINT。对于多字节字符集中的字符列，此长度值是表示定义（如 VARCHAR(N)）所需的最大字节长度 。

要查询此表，您需要具有 PROCESS 权限。使用 INFORMATION_SCHEMA.COLUMNS 表或 SHOW COLUMNS 语句查看有关此表的列的其他信息，包括数据类型和默认值 。

INNODB_DATAFILES

INNODB_DATAFILES 表是 INFORMATION_SCHEMA 数据库中的一个表，它为 InnoDB 的 file-per-table 和通用表空间提供数据文件路径信息。这个表对于监控和管理 InnoDB 数据文件非常有用。

以下是 INNODB_DATAFILES 表中的一些关键列及其描述：

• SPACE: 表空间的 ID。
• PATH: 表空间数据文件的路径。如果 file-per-table 表空间是在 MySQL 数据目录之外的位置创建的，则路径值是绝对路径。否则，路径是相对于数据目录的。

要查询此表，可以使用以下 SQL 语句：

SELECT SPACE, PATH FROM information_schema.INNODB_DATAFILES;

这个查询将返回 InnoDB 数据文件的列表，包括文件的路径和表空间 ID。这些信息对于了解数据文件的存储位置和进行数据库维护非常有用 。

INNODB_FIELDS

INNODB_FIELDS 表是 INFORMATION_SCHEMA 数据库中的一个表，它提供有关 InnoDB 索引的键列（字段）的元数据。此表对于查看和管理 InnoDB 索引的列信息非常有用。

以下是 INNODB_FIELDS 表中的一些关键列及其描述：

• INDEX_ID: 与此键字段关联的索引的标识符；与 INNODB_INDEXES.INDEX_ID 的值相同。
• NAME: 表中原始列的名称；与 INNODB_COLUMNS.NAME 的值相同。
• POS: 索引中关键字段的序号位置，从 0 开始并按顺序递增。当列被删除时，剩余的列将重新排序，以使序列没有间隙。

要查询此表，可以使用以下 SQL 语句：

SELECT * FROM information_schema.INNODB_FIELDS WHERE INDEX_ID = [指定索引ID];

这个查询将返回指定索引ID的字段元数据，包括字段名称和位置。这些信息对于了解索引结构和优化索引非常有用 。

INNODB_FOREIGN

INNODB_FOREIGN 表是 INFORMATION_SCHEMA 数据库中的一个表，它提供有关 InnoDB 存储引擎中定义的外键的元数据。这个表对于查看和管理 InnoDB 外键约束非常有用。

以下是 INNODB_FOREIGN 表中的一些关键列及其描述：

• ID: 外键索引的名称（不是数字值）。例如，test/fk1。
• FOR_NAME: 外键关系中子表的名称。例如，test/child。
• REF_NAME: 外键关系中父表的名称。例如，test/parent。
• N_COLS: 外键索引中的列数。
• TYPE: 包含有关外键列的信息的位标志集合，或者是组合在一起的 OR 操作。例如，1 表示 ON DELETE CASCADE 。

要查询此表，可以使用以下 SQL 语句：

SELECT * FROM information_schema.INNODB_FOREIGN;

这个查询将返回数据库中所有 InnoDB 外键的列表，包括外键名称、子表和父表的名称、列数以及外键类型。这些信息对于了解和维护数据库的外键约束非常有用。

INNODB_FOREIGN_COLS

INNODB_FOREIGN_COLS 表是 INFORMATION_SCHEMA 数据库中的一个表，它提供有关 InnoDB 存储引擎中外键约束中涉及的列的详细信息。这个表对于查看和管理 InnoDB 外键列非常有用。

以下是 INNODB_FOREIGN_COLS 表中的一些关键列及其描述：

• ID: 与外键约束关联的索引的标识符，与 INNODB_FOREIGN 表中的 ID 列相同。
• FOR_COL_NAME: 子表（即外键所在的表）中参与外键关系的列的名称。
• REF_COL_NAME: 父表（即外键引用的主表）中被外键关系引用的列的名称。
• POS: 外键索引中的列的位置，从 0 开始计数。

要查询此表，可以使用以下 SQL 语句：

SELECT * FROM information_schema.INNODB_FOREIGN_COLS;

这个查询将返回数据库中所有 InnoDB 外键的列信息，包括外键约束的索引 ID、子表列名称、父表列名称以及列的位置。这些信息对于了解和维护数据库的外键约束非常有用 。

INNODB_FT_BEING_DELETED

INNODB_FT_BEING_DELETED 表是 INFORMATION_SCHEMA 数据库中的一个表，它在 OPTIMIZE TABLE 维护操作期间作为 INNODB_FT_DELETED 表的快照使用。当执行 OPTIMIZE TABLE 语句时，INNODB_FT_BEING_DELETED 表会被清空，并且 DOC_ID 值会从 INNODB_FT_DELETED 表中移除。这个表通常具有较短的生命周期，因此对于监控或调试的实用性有限 。

该表通常在最初是空的，在查询之前，需要设置 innodb_ft_aux_table 系统变量的值为包含 FULLTEXT 索引的表的名称（包括数据库名称）。例如，如果表名为 test/articles，则需要执行以下命令：

SET GLOBAL innodb_ft_aux_table = 'test/articles';

这样，INNODB_FT_BEING_DELETED 表将显示正在被删除的行的文档 ID，这些 ID 用于在物理删除 FULLTEXT 索引中的行之前跳过 INNODB_FT_INDEX_TABLE 表中的行 。

INNODB_FT_BEING_DELETED 表结构简单，通常只包含一个列 DOC_ID，表示正在删除的行的文档 ID。这个 ID 可能反映了基础表中定义的 ID 列的值，或者是 InnoDB 生成的序列值 。

由于 INNODB_FT_BEING_DELETED 表是在 OPTIMIZE TABLE 操作期间使用的临时表，因此其内容会随着操作的完成而被清空，这也是为什么它对于日常监控和调试的实用性有限的原因 。

INNODB_FT_CONFIG

INNODB_FT_CONFIG 表是 INFORMATION_SCHEMA 数据库中的一个表，它提供有关 InnoDB 表的全文索引及其相关处理的元数据信息。这个表最初是空的，在查询之前，需要将 innodb_ft_aux_table 系统变量的值设置为包含全文索引的表的名称（包括数据库名称），例如 test/articles。

INNODB_FT_CONFIG 表包含以下几列：

• KEY: 指定包含全文索引的 InnoDB 表的元数据项的名称。可能的键包括：

• • optimize_checkpoint_limit: OPTIMIZE TABLE 运行停止的秒数。
  • synced_doc_id: 下一个要发放的 DOC_ID。
  • stopword_table_name: 用户定义的停用词表的数据库/表名称。如果没有用户定义的停用词表，则该列为空。
  • use_stopword: 表示是否使用停用词表，在创建全文索引时定义。

• VALUE: 与相应的 KEY 列关联的值，反映 InnoDB 表的 FULLTEXT 索引的某个方面的一些限制或当前值。

例如，查询 INNODB_FT_CONFIG 表可以提供如下信息：

mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_FT_CONFIG;
+---------------------------+-------------------+
| KEY                       | VALUE             |
+---------------------------+-------------------+
| optimize_checkpoint_limit | 180               |
| synced_doc_id             | 0                 |
| stopword_table_name       | test/my_stopwords |
| use_stopword              | 1                 |
+---------------------------+-------------------+

这些信息对于性能调优和调试 InnoDB 全文索引处理非常有用 。

INNODB_FT_DEFAULT_STOPWORD

INNODB_FT_DEFAULT_STOPWORD 表是 INFORMATION_SCHEMA 数据库中的一个表，它存储了 InnoDB 存储引擎在创建 FULLTEXT 索引时默认使用的停用词列表。这些停用词是在全文搜索中通常被忽略的常见词汇，因为它们对于搜索通常不具有区分度。

以下是 INNODB_FT_DEFAULT_STOPWORD 表中的列及其描述：

• value: 这是一个字符串列，包含了默认的停用词。例如，"a", "about", "an", "are", "as", "at", "be", "by", "com", "de", "en", "for", "from", "how", "i", "in", "is", "it", "la", "of", "on", "or", "that", "the", "this", "to", "was", "what", "when", "where", "who", "will", "with", "und", "the", "www" 等 。

要查看默认的停用词列表，可以执行以下 SQL 查询：

SELECT * FROM information_schema.INNODB_FT_DEFAULT_STOPWORD;

这个查询将返回 InnoDB 默认的停用词列表。这些信息对于了解和调整全文索引的搜索效果非常有用。如果您需要为特定的 FULLTEXT 索引设置不同的停用词列表，可以通过创建自己的停用词表并使用 innodb_ft_user_stopword_table 系统变量来指定 。

请注意，查询 INNODB_FT_DEFAULT_STOPWORD 表需要有 PROCESS 权限，并且这个表是 MEMORY 引擎的临时表 。

INNODB_FT_DELETED

INNODB_FT_DELETED 是 MySQL 中的一个特殊表，它位于 INFORMATION_SCHEMA 数据库中。这个表的目的是为了存储那些已经被删除的行的文档 ID（DOC_ID），这些行原本存在于一个 InnoDB 表的 FULLTEXT 索引中。这样做的目的是为了优化性能，避免在进行删除操作（DML）时对 FULLTEXT 索引进行昂贵的重组。

当一个带有 FULLTEXT 索引的 InnoDB 表中的行被删除时，相关的信息（而不是实际的行数据）会被存储在 INNODB_FT_DELETED 表中。在执行文本搜索时，这些被删除的行的信息会被过滤掉，以确保搜索结果不包含这些已经不存在的数据。只有当执行了 OPTIMIZE TABLE 语句后，这些被删除的行的信息才会从主搜索索引中物理删除。

INNODB_FT_DELETED 表通常在初始化时是空的。在查询这个表之前，需要设置系统变量 innodb_ft_aux_table 的值为包含 FULLTEXT 索引的表的名称（包括数据库名称）。例如，如果表名为 test/articles，则需要执行以下命令：

SET GLOBAL innodb_ft_aux_table = 'test/articles';

INNODB_FT_DELETED 表只包含一个列 DOC_ID，它表示新删除行的文档 ID。这个值可能是基础表定义的 ID 列的值，或者是当表不包含合适的列时由 InnoDB 生成的序列值。

在进行文本搜索时，DOC_ID 用于跳过 INNODB_FT_INDEX_TABLE 表中的行，直到通过 OPTIMIZE TABLE 语句从 FULLTEXT 索引中物理删除删除行的数据。

需要注意的是，查询 INNODB_FT_DELETED 表需要有 PROCESS 权限。此外，可以通过 INFORMATION_SCHEMA.COLUMNS 表或 SHOW COLUMNS 语句来查看这个表的列的更多信息，包括数据类型和默认值。

在某些情况下，即使执行了删除操作，INNODB_FT_DELETED 表中的记录也不会立即减少，因为这些记录只有在执行 OPTIMIZE TABLE 后才会被清除。如果需要立即清除这些记录，可以通过设置 innodb_optimize_fulltext_only 系统变量为 1，然后执行 OPTIMIZE TABLE 来实现。

INNODB_FT_INDEX_CACHE

INNODB_FT_INDEX_CACHE 是 MySQL 中 INFORMATION_SCHEMA 数据库的一个表，它提供了关于 FULLTEXT 索引中新插入行的标记信息。为了避免在 DML 操作期间昂贵的索引重组，新索引的词的信息被单独存储，并仅在执行 OPTIMIZE TABLE、服务器关闭或当缓存大小超过 innodb_ft_cache_size 或 innodb_ft_total_cache_size 系统变量定义的限制时，才与主搜索索引合并。

这个表最初是空的。在查询它之前，需要设置 innodb_ft_aux_table 系统变量的值为包含 FULLTEXT 索引的表的名称（包括数据库名称）。例如，如果表名为 test/articles，则需要执行以下命令：

SET GLOBAL innodb_ft_aux_table = 'test/articles';

INNODB_FT_INDEX_CACHE 表包含以下字段：

• WORD：从新插入行的文本中提取的单词。
• FIRST_DOC_ID：这个词首次出现的文档 ID。
• LAST_DOC_ID：这个词最后出现的文档 ID。
• DOC_COUNT：这个词在 FULLTEXT 索引中出现的行数。同一个词可以在缓存表中出现多次，每次对应不同的 DOC_ID 和 POSITION 值组合。
• DOC_ID：新插入行的文档 ID。这个值可能反映了你为底层表定义的 ID 列的值，或者当表不包含合适的列时，它可以是 InnoDB 生成的序列值。
• POSITION：这个词在由 DOC_ID 值标识的相关文档中的特定实例的位置。该值不代表绝对位置；它是添加到前面那个词的 POSITION 的偏移量。

这个表是 InnoDB 全文索引的调试和性能优化的重要工具，它可以帮助开发者了解文档被标记化后如何被添加到索引中，并且可以监控索引的插入和缓存行为。

INNODB_FT_INDEX_TABLE

INNODB_FT_INDEX_TABLE 是 MySQL 中 INFORMATION_SCHEMA 数据库的一个表，它提供了关于 InnoDB 表中 FULLTEXT 索引的倒排索引的信息。这个表最初是空的，需要通过设置 innodb_ft_aux_table 系统变量为包含 FULLTEXT 索引的表的名称（包括数据库名）后，才会显示相关信息。

该表包含以下列：

• WORD: 从 FULLTEXT 索引的列文本中提取的单词。
• FIRST_DOC_ID: 该词在 FULLTEXT 索引中出现的的第一个文档 ID。
• LAST_DOC_ID: 该词在 FULLTEXT 索引中出现的最后一个文档 ID。
• DOC_COUNT: 该词在 FULLTEXT 索引中出现的行数。同一个词可以在表中出现多次，每个 DOC_ID 和 POSITION 值组合出现一次。
• DOC_ID: 包含该词的行的文档 ID。这个值可能是你为基础表定义的 ID 列的值，或者当表不包含合适的列时，它可以是 InnoDB 生成的序列值。
• POSITION: 单词的这个特定实例在由 DOC_ID 值标识的相关文档中的位置。

在查询 INNODB_FT_INDEX_TABLE 之前，需要设置 innodb_ft_aux_table 系统变量，例如：

SET GLOBAL innodb_ft_aux_table = 'test/articles';

然后可以查询 INNODB_FT_INDEX_TABLE 来获取倒排索引的信息。例如：

SELECT WORD, DOC_COUNT, DOC_ID, POSITION FROM INFORMATION_SCHEMA.INNODB_FT_INDEX_TABLE LIMIT 5;

这个表对于监视和调试全文索引非常有用，尤其是在优化全文索引的时候。需要注意的是，查询这个表需要有 PROCESS 权限。

INNODB_INDEXES

INNODB_INDEXES 是 MySQL INFORMATION_SCHEMA 数据库中的一个表，它提供了关于 InnoDB 存储引擎索引的详细信息和元数据。这个表对于数据库管理员和开发者在进行数据库性能优化和索引管理时非常有用。

以下是 INNODB_INDEXES 表中包含的一些关键列：

1. INDEX_ID: 索引的唯一标识符，在所有数据库中唯一。
2. NAME: 索引的名称。大多数由 InnoDB 隐式创建的索引具有一致的名称，但请注意，索引名称不一定是唯一的。
3. TABLE_ID: 索引所属表的标识符，与 INNODB_TABLES.TABLE_ID 相同。
4. TYPE: 表示索引类型的数值，例如：

• • 0 = 非唯一二级索引
  • 1 = 自动生成聚集索引 (GEN_CLUST_INDEX)
  • 2 = 唯一非聚集索引
  • 3 = 聚簇索引
  • 32 = 全文索引
  • 64 = 空间索引
  • 128 = 虚拟生成列上的二级索引

1. N_FIELDS: 索引键中的列数。对于 GEN_CLUST_INDEX 索引，此值为 0，因为它使用的是人工值而不是真实的表列创建的。
2. PAGE_NO: 索引 B+ 树的根页码。对于全文索引，这个字段未使用并设置为 -1，因为全文索引布局在多个 B+ 树中。
3. SPACE: 索引所在的表空间的标识符。0 表示 InnoDB 系统表空间，其他数字表示每个表文件模式下使用单独 .ibd 文件创建的表。
4. MERGE_THRESHOLD: 索引页的合并阈值。如果删除行或通过更新操作缩短行时索引页中的数据量低于该值，则 InnoDB 尝试将索引页与相邻索引页合并。

要查询 INNODB_INDEXES 表，你通常需要具备 PROCESS 权限。这个表的信息可以帮助你了解索引的物理结构和特性，从而进行更有效的索引策略规划和优化。

例如，要查看某个表的所有索引信息，你可以使用以下 SQL 语句：

SELECT * FROM INFORMATION_SCHEMA.INNODB_INDEXES WHERE TABLE_ID = [特定的TABLE_ID];

将 [特定的TABLE_ID] 替换为你想要查询的表的 TABLE_ID。

INNODB_METRICS

INNODB_METRICS 是 MySQL 的 INFORMATION_SCHEMA 数据库中的一个表，它提供了关于 InnoDB 存储引擎性能和资源相关的计数器信息。这个表在 MySQL 5.6 版本中引入，用以补充 Performance Schema 表中对 InnoDB 的监控。

这个表包含许多列，每个列代表一个特定的性能指标或计数器，例如：

• NAME: 计数器的唯一名称。
• SUBSYSTEM: 指标适用的 InnoDB 方面。
• COUNT: 自启用计数器以来的值。
• MAX_COUNT: 自启用计数器以来的最大值。
• MIN_COUNT: 自启用计数器以来的最小值。
• AVG_COUNT: 自启用计数器以来的平均值。
• COUNT_RESET: 自上次重置以来的计数器值。
• MAX_COUNT_RESET: 自上次重置以来的最大计数器值。
• MIN_COUNT_RESET: 自上次重置以来的最小计数器值。
• AVG_COUNT_RESET: 自上次重置以来的平均计数器值。
• TIME_ENABLED: 最后一次启动的时间戳。
• TIME_DISABLED: 最后一次停用的时间戳。
• TIME_ELAPSED: 自计数器启动以来经过的秒数。
• TIME_RESET: 上次重置的时间戳。
• STATUS: 计数器是否仍在运行（enabled）或已停止（disabled）。
• TYPE: 该项目是累积计数器，还是测量某些资源的当前值。
• COMMENT: 计数器的描述。

通过查询 INNODB_METRICS 表，数据库管理员可以监控 InnoDB 的性能状况，诊断问题如性能瓶颈、资源短缺和应用程序问题。每个监控器代表 InnoDB 源代码中的一个点，用于收集计数器信息。每个计数器都可以启动、停止和重置，也可以使用它们的公共模块名称对一组计数器执行这些操作。

默认情况下，不会收集太多的数据，但是可以通过设置系统变量 innodb_monitor_enable、innodb_monitor_disable、innodb_monitor_reset 或 innodb_monitor_reset_all 来控制计数器的状态。需要注意的是，每个计数器都会增加一定程度的运行时开销，因此在生产服务器上应谨慎使用计数器，以诊断特定问题或监视特定功能。建议在测试或开发服务器上更广泛地使用计数器。

要查询 INNODB_METRICS 表，你需要有 PROCESS 权限。通过查看该表，可以了解 InnoDB 的内部运行状况，比如插入、更新、删除等 DML 操作的次数，以及其他如锁等待、索引查找等操作的统计信息。这些信息对于数据库的性能优化和故障排查非常有用。

INNODB_SESSION_TEMP_TABLESPACES

INNODB_SESSION_TEMP_TABLESPACES 是 MySQL INFORMATION_SCHEMA 数据库中的一个表，它提供有关会话临时表空间的元数据，这些临时表空间用于存储用户创建的临时表和优化器创建的内部临时表。这个表是在 MySQL 8.0.13 版本中引入的。

以下是 INNODB_SESSION_TEMP_TABLESPACES 表中的一些关键列：

• ID: 进程或会话 ID。
• SPACE: 表空间 ID。为会话临时表空间保留了一个空间 ID 范围。
• PATH: 表空间数据文件的路径。会话临时表空间的文件有 .ibt 扩展名。
• SIZE: 表空间的大小，单位是字节。
• STATE: 表空间的状态，ACTIVE 表示当前正被会话使用，INACTIVE 表示该表空间位于可用会话临时表空间池中。
• PURPOSE: 表空间的用途。INTRINSIC 表示用于优化器使用的内部临时表，USER 表示用于用户创建的临时表，NONE 表示表空间未被使用。

会话临时表空间在服务器启动时创建，并在会话第一次请求创建磁盘临时表时分配给会话。一个会话最多可以分配两个表空间，一个用于用户创建的临时表，另一个用于优化器创建的内部临时表。当会话断开连接时，其临时表空间将被截断并释放回池中。

可以通过查询 INNODB_SESSION_TEMP_TABLESPACES 来监控会话临时表空间的使用情况，例如：

SELECT * FROM INFORMATION_SCHEMA.INNODB_SESSION_TEMP_TABLESPACES;

这个表对于数据库管理员在进行性能监控和优化时特别有用，因为它可以帮助他们了解临时表空间的使用模式和潜在的资源瓶颈。

INNODB_TABLES

INNODB_TABLES 是 MySQL INFORMATION_SCHEMA 数据库中的一个表，它提供有关 InnoDB 存储引擎管理的表的元数据。这个表包含了 InnoDB 表的各种信息，例如表的标识符、名称、列数、所在表空间的ID、行格式等。

以下是 INNODB_TABLES 表中的一些关键列：

• TABLE_ID: 表的唯一标识符，在 InnoDB 实例中全局唯一。
• NAME: 表的名称，通常包括数据库名称作为前缀（例如 test/t1）。
• FLAG: 表示表的格式和存储特性的位掩码标志。
• N_COLS: 表中的列数，包括隐藏的 DB_ROW_ID、DB_TRX_ID 和 DB_ROLL_PTR 列。
• SPACE: 表所在的表空间的标识符。0 表示系统表空间，其他值表示单独的表空间。
• ROW_FORMAT: 表的行格式，如 Compact、Redundant、Dynamic 或 Compressed。
• ZIP_PAGE_SIZE: 对于行格式为 Compressed 的表，表示压缩页面的大小。
• SPACE_TYPE: 表所属的表空间类型，如 System、General 或 Single。

这个表对于数据库管理员和开发者在进行数据库性能优化和表管理时非常有用。例如，可以通过查询 INNODB_TABLES 来获取表的物理存储信息，从而进行更有效的表空间规划和管理。

要查询 INNODB_TABLES 表，你可以使用如下 SQL 语句：

SELECT * FROM INFORMATION_SCHEMA.INNODB_TABLES WHERE NAME = 'test/t1';

这将返回名为 test/t1 的表的相关信息。需要注意的是，查询这个表通常需要有 PROCESS 权限。

INNODB_TABLESPACES

INNODB_TABLESPACES 是 MySQL INFORMATION_SCHEMA 数据库中的一个表，它提供有关 InnoDB 存储引擎管理的文件-per-table、通用（general）和 undo 表空间的元数据信息。

以下是 INNODB_TABLESPACES 表中的一些关键列：

• SPACE: 表空间的ID。
• NAME: 表空间的名称，通常包括数据库名和表名。
• FLAG: 表示表空间格式和存储特征的位掩码值。
• ROW_FORMAT: 表空间的行格式，可能的值包括 Compact, Redundant, Dynamic, 或 Compressed。
• PAGE_SIZE: 表空间的页面大小。
• ZIP_PAGE_SIZE: 压缩表空间的页面大小。
• SPACE_TYPE: 表空间的类型，可能的值包括 System, Single, General, 或 Undo。
• FS_BLOCK_SIZE: 文件系统块大小，这是磁盘读写的最小单位。
• FILE_SIZE: 表空间文件的显示大小。
• ALLOCATED_SIZE: 分配给表空间的实际磁盘空间量。
• AUTOEXTEND_SIZE: 表空间的自动扩展大小。
• SERVER_VERSION: 创建表空间时的 MySQL 版本号。
• SPACE_VERSION: 表空间版本，用于跟踪表空间格式的变化。
• ENCRYPTION: 表空间是否加密。
• STATE: 表空间的状态，例如 normal, discarded, 或 corrupted。

要查询 INNODB_TABLESPACES 表，你可以使用如下 SQL 语句：

SELECT * FROM INFORMATION_SCHEMA.INNODB_TABLESPACES WHERE SPACE = [特定的SPACE_ID];

将 [特定的SPACE_ID] 替换为你想要查询的表空间的ID。需要注意的是，查询这个表通常需要有 PROCESS 权限。

这个表对于数据库管理员在进行数据库性能优化和表空间管理时特别有用，因为它可以帮助他们了解表空间的使用情况和配置。

INNODB_TABLESPACES_BRIEF

INNODB_TABLESPACES_BRIEF 是 MySQL INFORMATION_SCHEMA 数据库中的一个表，它提供了简洁的表空间元数据信息，包括空间 ID、名称、路径、标志和空间类型。这个表为 file-per-table、通用（general）、回滚（undo）和系统表空间提供了元数据。

以下是 INNODB_TABLESPACES_BRIEF 表中的一些关键列：

• SPACE: 表空间的 ID。
• NAME: 表空间的名称。对于 file-per-table 表空间，名称通常以 <schema_name>/<table_name> 的形式出现。
• PATH: 表空间数据文件的路径。如果 file-per-table 表空间在 MySQL 数据目录之外的位置创建，则路径值是完整的目录路径。否则，路径是相对于数据目录的。
• FLAG: 一个数值，表示有关表空间格式和存储特征的位级信息。
• SPACE_TYPE: 表空间的类型。可能的值包括 General（通用表空间）、Single（file-per-table 表空间）和 System（系统表空间）。

INNODB_TABLESPACES_BRIEF 表提供了比 INNODB_TABLESPACES 更快加载的元数据子集，因为它不包含如 FS_BLOCK_SIZE、FILE_SIZE 和 ALLOCATED_SIZE 等需要动态加载的其他元数据。空间和路径元数据也可以通过 INNODB_DATAFILES 表获得。

例如，要查询特定表空间的信息，可以使用以下 SQL 语句：

SELECT * FROM INFORMATION_SCHEMA.INNODB_TABLESPACES_BRIEF WHERE SPACE = [特定的SPACE_ID];

将 [特定的SPACE_ID] 替换为你想要查询的表空间的 ID。这个表对于数据库管理员在进行表空间管理和监控时非常有用，因为它提供了快速访问表空间基本信息的方式 。

INNODB_TABLESTATS

INNODB_TABLESTATS 提供了一个视图，展示了关于 InnoDB 表的低层次状态信息。这些数据被 MySQL 优化器用来计算查询 InnoDB 表时应该使用哪个索引。这些信息来源于内存中的数据结构，而不是存储在磁盘上的数据。如果表自从上次服务器重启后被打开过，并且没有从表缓存中老化出去，那么这个表就会在视图中表示出来。如果持久性统计信息可用，那么这些表也总是会在这个视图中表示出来。

INNODB_TABLESTATS 表包含以下列：

• TABLE_ID：表的标识符，与 INNODB_TABLES.TABLE_ID 的值相同。
• NAME：表的名称，与 INNODB_TABLES.NAME 的值相同。
• STATS_INITIALIZED：如果已经收集了统计信息，值为 Initialized；如果没有，则为 Uninitialized。
• NUM_ROWS：表中当前估计的行数。每次 DML 操作后更新。如果未提交的事务正在向表中插入或从表中删除数据，则这个值可能不精确。
• CLUST_INDEX_SIZE：存储聚集索引的磁盘上的页数，它以主键顺序保存 InnoDB 表数据。如果尚未为表收集统计信息，则此值可能为 null。
• OTHER_INDEX_SIZE：存储表的所有二级索引的磁盘上的页数。如果尚未为表收集统计信息，则此值可能为 null。
• MODIFIED_COUNTER：DML 操作修改的行数，例如 INSERT、UPDATE、DELETE，以及外键的级联操作。每次表统计信息被重新计算时，此列都会被重置。
• AUTOINC：下一次任何基于自动增量的操作将发出的数字。AUTOINC 值变化的速度取决于请求自动增量号码的次数以及每次请求授予的号码数量。
• REF_COUNT：当此计数器达到零时，表的元数据可以从表缓存中逐出。

例如，要查看表的统计信息，可以使用以下 SQL 语句：

SELECT * FROM INFORMATION_SCHEMA.INNODB_TABLESTATS WHERE TABLE_ID = [特定的TABLE_ID];

将 [特定的TABLE_ID] 替换为你想要查询的表的 TABLE_ID。需要注意的是，查询这个视图通常需要有 PROCESS 权限。

INNODB_TEMP_TABLE_INFO

INNODB_TEMP_TABLE_INFO 提供了关于 InnoDB 实例中活动的用户创建的临时表的信息。这个表不包括关于 InnoDB 优化器使用的内部临时表的信息。这个表在第一次被查询时创建，只存在于内存中，不会持久化到磁盘。

以下是 INNODB_TEMP_TABLE_INFO 表中的一些关键列：

• TABLE_ID: 临时表的表 ID。
• NAME: 临时表的名称。系统为临时表生成的名称，该名称以 "#sql" 为前缀。
• N_COLS: 临时表中的列数。这个数字包括由 InnoDB 创建的三个隐藏列：DB_ROW_ID、DB_TRX_ID 和 DB_ROLL_PTR。
• SPACE: 临时表所在的临时表空间的 ID。在 MySQL 5.7 中，非压缩的 InnoDB 临时表驻留在共享临时表空间中。共享临时表空间的数据文件由 innodb_temp_data_file_path 系统变量定义。压缩的临时表驻留在单独的文件表空间中，这些表空间位于由 tmpdir 定义的临时目录中。
• PER_TABLE_TABLESPACE: 如果值为 TRUE 表示临时表驻留在单独的 file-per-table 表空间中。如果值为 FALSE 表示临时表驻留在共享临时表空间中。
• IS_COMPRESSED: 如果值为 TRUE 表示临时表已压缩。

这个表对于专家级别的监控非常有用，需要 PROCESS 权限才能查询此表。重启 MySQL 后，查询 INNODB_TEMP_TABLE_INFO 会返回空集，因为数据不会持久保存到磁盘 。

INNODB_TRX

INNODB_TRX 是 MySQL INFORMATION_SCHEMA 数据库中的一个表，它提供了当前在 InnoDB 存储引擎中执行的每个事务的详细信息。这些信息包括事务是否正在等待锁、事务何时开始以及事务正在执行的 SQL 语句（如果有的话）。

以下是 INNODB_TRX 表中的一些关键列：

• TRX_ID: InnoDB 内部生成的事务唯一 ID 号。
• TRX_WEIGHT: 事务的权重，反映（但不一定是确切的计数）更改的行数和事务锁定的行数。InnoDB 在解决死锁时会选择权重最小的事务作为“受害者”进行回滚。
• TRX_STATE: 事务的执行状态，可能的值包括 RUNNING、LOCK WAIT、ROLLING BACK 和 COMMITTING。
• TRX_STARTED: 事务开始的时间戳。
• TRX_REQUESTED_LOCK_ID: 如果事务处于 LOCK WAIT 状态，此字段标识它正在等待的锁的 ID。
• TRX_WAIT_STARTED: 如果事务在等待锁，记录等待开始的时间。
• TRX_MYSQL_THREAD_ID: MySQL 线程 ID，与执行事务的客户端线程相关联。
• TRX_QUERY: 正在执行的事务中的 SQL 语句文本。
• TRX_TABLES_IN_USE: 当前事务中涉及的表数量。
• TRX_TABLES_LOCKED: 被事务锁定的表数量。
• TRX_LOCK_STRUCTS: 事务保留的锁数量。
• TRX_LOCK_MEMORY_BYTES: 此事务的锁结构在内存中占用的总大小。
• TRX_ROWS_LOCKED: 此事务锁定的大概行数。
• TRX_ROWS_MODIFIED: 此事务中修改和插入的行数。
• TRX_CONCURRENCY_TICKETS: 一个值，表示当前事务在被换出之前可以做多少工作，由 innodb_concurrency_tickets 系统变量指定。
• TRX_ISOLATION_LEVEL: 当前事务的隔离级别。
• TRX_UNIQUE_CHECKS: 是否为当前事务打开或关闭唯一检查。
• TRX_FOREIGN_KEY_CHECKS: 是否为当前事务打开或关闭外键检查。
• TRX_LAST_FOREIGN_KEY_ERROR: 最后一次的外键错误信息，如果有的话；否则 NULL。
• TRX_ADAPTIVE_HASH_LATCHED: 自适应哈希索引是否被当前事务锁定。
• TRX_ADAPTIVE_HASH_TIMEOUT: 是否为了自适应哈希索引立即放弃查询锁，或者通过调用 MySQL 函数保留它。
• TRX_IS_READ_ONLY: 值为 1 表示事务是只读的。
• TRX_AUTOCOMMIT_NON_LOCKING: 值为 1 表示该事务是一个 SELECT 语句，该语句没有使用 FOR UPDATE 或 LOCK IN SHARED MODE 子句，并且执行开启了 autocommit，因此该事务只包含这一条语句。

这个表对于监控和诊断数据库中的事务活动、识别长期运行的事务、检测死锁以及分析性能问题非常有帮助。查询这个表需要有 PROCESS 权限。

INNODB_VIRTUAL

INNODB_VIRTUAL 是 MySQL 中的一个系统表，它包含了 InnoDB 存储引擎中所有虚拟生成列的信息。虚拟生成列是一种特殊类型的列，它在查询时动态生成值，而不是存储在表中。这些列的值通常基于表中的其他列计算得出。

在 InnoDB 的数据字典中，INNODB_VIRTUAL 表扮演着重要的角色，它存储了虚拟列的元数据，包括列的名字、类型、表达式等信息。这些信息对于 InnoDB 存储引擎在查询时动态计算虚拟列的值至关重要。

虚拟生成列可以在创建表时定义，也可以在后续通过 ALTER TABLE 语句添加。它们的值是由用户定义的表达式计算得出的，表达式可以包含表中的其他列。

例如，如果有一个包含 name 和 lastname 列的表，可以定义一个虚拟列 full_name 来存储全名：

ALTER TABLE my_table
ADD full_name AS (name || lastname) VIRTUAL;

在这个例子中，full_name 就是一个虚拟生成列，它的值是通过连接 name 和 lastname 列的值来计算的。

INNODB_VIRTUAL 表是 InnoDB 存储引擎内部使用的，通常不需要用户直接查询或修改。它作为数据字典的一部分，由 MySQL 服务器在启动时自动填充和管理。

查询结果显示了 INNODB_VIRTUAL 表中的一些行。这个表通常包含以下字段：

• TABLE_ID: 表的唯一标识符。
• POS: 虚拟列在表中的位置上的偏移量。
• BASE_POS: 基柱（base column）的位置，虚拟列的值通常依赖于这个基柱。

KEYWORDS

在MySQL中，information_schema 是一个特殊的数据库，它包含了所有其他数据库的元数据，比如表结构、权限、字符集等信息。information_schema 中的 KEYWORDS 表列出了MySQL中所有的保留关键字及其状态。

从你提供的查询结果来看，KEYWORDS 表包含两列：

1. WORD：这是MySQL中的保留关键字。
2. RESERVED：这个列显示了关键字的状态，其中：

• • 1 表示该关键字是保留的，不能用作任何标识符（除非使用反引号）。
  • 0 表示该关键字不是保留的，可以作为标识符使用。

这个表对于开发者来说很有用，因为它可以帮助他们避免在创建数据库对象时使用保留关键字作为标识符，从而避免语法错误。

如果你想查看所有保留关键字，可以使用以下命令：

SELECT WORD FROM information_schema.KEYWORDS WHERE RESERVED = 1;

这将列出所有保留关键字。如果你需要查看所有非保留关键字，可以使用：

SELECT WORD FROM information_schema.KEYWORDS WHERE RESERVED = 0;

希望这能帮助你更好地理解 information_schema.KEYWORDS 表。

KEY_COLUMN_USAGE

KEY_COLUMN_USAGE 是 information_schema 数据库中的一个表，它描述了哪些键列具有约束。这个表包含了关于表中列的键约束信息，包括主键、唯一键以及外键的详细信息。以下是 KEY_COLUMN_USAGE 表的主要字段及其含义：

• CONSTRAINT_CATALOG: 约束所属目录的名称，通常为 def。
• CONSTRAINT_SCHEMA: 约束所属的数据库名称。
• CONSTRAINT_NAME: 约束的名称。
• TABLE_CATALOG: 表所属目录的名称，通常为 def。
• TABLE_SCHEMA: 表所属的数据库名称。
• TABLE_NAME: 具有约束的表的名称。
• COLUMN_NAME: 具有约束的列的名称。如果约束是外键，那么这是外键的列，而不是外键引用的列。
• ORDINAL_POSITION: 列在约束中的位置，列位置从 1 开始编号。
• POSITION_IN_UNIQUE_CONSTRAINT: 对于唯一和主键约束，此值为 NULL。对于外键约束，此列是被引用表的键中的序号位置。
• REFERENCED_TABLE_SCHEMA: 约束引用的模式（数据库）的名称。
• REFERENCED_TABLE_NAME: 约束引用的表的名称。
• REFERENCED_COLUMN_NAME: 约束引用的列的名称。

这个表对于理解和管理数据库中的约束关系非常有用。例如，如果你想查看特定数据库中所有表的键列信息，可以使用以下查询：

SELECT TABLE_NAME, COLUMN_NAME, CONSTRAINT_NAME
FROM information_schema.KEY_COLUMN_USAGE
WHERE TABLE_SCHEMA = 'your_database_name';

替换 'your_database_name' 为你的数据库名称，这将列出该数据库中所有表的键列及其约束名称。

如果你想要获取特定表的所有键列信息，可以进一步指定表名：

SELECT TABLE_NAME, COLUMN_NAME, CONSTRAINT_NAME
FROM information_schema.KEY_COLUMN_USAGE
WHERE TABLE_SCHEMA = 'your_database_name' AND TABLE_NAME = 'your_table_name';

替换 'your_database_name' 和 'your_table_name' 为你的数据库名称和表名称。

此外，如果你想获取特定表的外键信息，可以使用：

SELECT TABLE_NAME, COLUMN_NAME, CONSTRAINT_NAME, REFERENCED_TABLE_NAME, REFERENCED_COLUMN_NAME
FROM information_schema.KEY_COLUMN_USAGE
WHERE TABLE_SCHEMA = 'your_database_name' AND TABLE_NAME = 'your_table_name' AND REFERENCED_TABLE_NAME IS NOT NULL;

这将列出所有作为外键的列及其引用的表和列的信息。

information_schema 是一个只读模式的数据库，不能对其进行修改，查询它通常不需要锁定表，因此性能影响较小。

OPTIMIZER_TRACE

OPTIMIZER_TRACE 是 MySQL INFORMATION_SCHEMA 数据库中的一个表，它存储了关于 SQL 语句优化过程的跟踪信息。这个表是从 MySQL 5.6 版本开始引入的，用于帮助开发者和数据库管理员理解 MySQL 优化器是如何工作的。

要使用 OPTIMIZER_TRACE，你首先需要通过设置 optimizer_trace 系统变量来启用跟踪功能。之后，当你执行一个 SQL 语句时，优化器的决策过程会被记录下来，并以 JSON 格式保存在 OPTIMIZER_TRACE 表的 TRACE 列中。

以下是 OPTIMIZER_TRACE 表中的一些关键列：

• QUERY: 被跟踪的 SQL 语句文本。
• TRACE: 跟踪信息，以 JSON 格式表现。
• MISSING_BYTES_BEYOND_MAX_MEM_SIZE: 如果跟踪信息超过了 optimizer_trace_max_mem_size 指定的内存大小限制，则该列显示丢失的字节数。
• INSUFFICIENT_PRIVILEGES: 如果被跟踪的 SQL 使用了没有权限的视图或存储过程，则该列值为 1，表示没有足够的权限查看完整的跟踪信息。

使用 OPTIMIZER_TRACE 可以帮助你分析和解决查询性能问题，理解为什么优化器选择了特定的执行计划，以及是否有更优的执行计划未被选择。通过分析 TRACE 列中的 JSON 数据，你可以获得关于优化器决策的深入信息，比如是否使用了索引、是否进行了表的合并、是否进行了子查询优化等。

例如，要启用优化器跟踪并执行一个查询，你可以按照以下步骤操作：

1. 启用优化器跟踪：

SET SESSION OPTIMIZER_TRACE="enabled=on";

1. 执行你的查询语句。
2. 查看跟踪结果：

SELECT * FROM information_schema.OPTIMIZER_TRACE;

1. （可选）关闭优化器跟踪：

SET SESSION OPTIMIZER_TRACE="enabled=off";

需要注意的是，OPTIMIZER_TRACE 表只会显示最近一次的跟踪结果，如果你需要跟踪多个语句，可以使用 optimizer_trace_offset 和 optimizer_trace_limit 来控制跟踪的条目数量和偏移量。

此外，如果跟踪信息过于复杂，为了提高可读性，你可以设置 optimizer_trace_one_line 为 on，这样跟踪信息会以单行的形式展示，但这可能会牺牲可读性。

更多详细信息，可以参考 MySQL 官方文档 。

例子：

MySQL (none)@(none):information_schema> select * from  OPTIMIZER_TRACE\G
***************************[ 1. row ]***************************
QUERY                             | select * from demo1.t1
TRACE                             | {
  "steps": [
    {
      "join_preparation": {
        "select#": 1,
        "steps": [
          {
            "expanded_query": "/* select#1 */ select `demo1`.`t1`.`a` AS `a`,`demo1`.`t1`.`b` AS `b`,`demo1`.`t1`.`c` AS `c`,`demo1`.`t1`.`c11` AS `c11` from `demo1`.`t1`"
          }
        ]
      }
    },
    {
      "join_optimization": {
        "select#": 1,
        "steps": [
          {
            "table_dependencies": [
              {
                "table": "`demo1`.`t1`",
                "row_may_be_null": false,
                "map_bit": 0,
                "depends_on_map_bits": [
                ]
              }
            ]
          },
          {
            "rows_estimation": [
              {
                "table": "`demo1`.`t1`",
                "table_scan": {
                  "rows": 3,
                  "cost": 0.25
                }
              }
            ]
          },
          {
            "considered_execution_plans": [
              {
                "plan_prefix": [
                ],
                "table": "`demo1`.`t1`",
                "best_access_path": {
                  "considered_access_paths": [
                    {
                      "rows_to_scan": 3,
                      "access_type": "scan",
                      "resulting_rows": 3,
                      "cost": 0.55,
                      "chosen": true
                    }
                  ]
                },
                "condition_filtering_pct": 100,
                "rows_for_plan": 3,
                "cost_for_plan": 0.55,
                "chosen": true
              }
            ]
          },
          {
            "attaching_conditions_to_tables": {
              "original_condition": null,
              "attached_conditions_computation": [
              ],
              "attached_conditions_summary": [
                {
                  "table": "`demo1`.`t1`",
                  "attached": null
                }
              ]
            }
          },
          {
            "finalizing_table_conditions": [
            ]
          },
          {
            "refine_plan": [
              {
                "table": "`demo1`.`t1`"
              }
            ]
          }
        ]
      }
    },
    {
      "join_execution": {
        "select#": 1,
        "steps": [
        ]
      }
    }
  ]
}
MISSING_BYTES_BEYOND_MAX_MEM_SIZE | 0
INSUFFICIENT_PRIVILEGES           | 0

1 row in set
Time: 0.002s

PARAMETERS

在 MySQL 中，PARAMETERS 表属于 INFORMATION_SCHEMA 数据库，它提供了关于存储过程、函数、触发器、事件等数据库对象的参数的详细信息。这个表通常用于查看这些数据库对象的参数定义，包括参数名称、类型、方向（如输入、输出或两者兼有）等。

根据你提供的查询结果，PARAMETERS 表显示了某个特定数据库对象（在这个例子中是一个函数）的参数信息。以下是你提供的结果中的列的解释：

• SPECIFIC_CATALOG: 包含数据库对象的数据库名称。
• SPECIFIC_SCHEMA: 包含数据库对象的数据库的默认模式或数据库。
• SPECIFIC_NAME: 数据库对象的名称。
• ORDINAL_POSITION: 参数在对象定义中的位置（从 1 开始）。
• PARAMETER_MODE: 参数的方向（如 IN、OUT、INOUT）。对于存储过程和函数的参数，这个值可能是 NULL，因为这些对象通常只使用 IN 类型的参数。
• PARAMETER_NAME: 参数的名称。在这个例子中，该列为 NULL，可能是因为这是一个函数，而函数可能不需要参数。
• DATA_TYPE: 参数的数据类型。
• CHARACTER_MAXIMUM_LENGTH: 如果参数是字符类型，这是最大长度。
• CHARACTER_OCTET_LENGTH: 如果参数是字符类型，这是最大字节长度。
• NUMERIC_PRECISION: 如果参数是数字类型，这是精度。
• NUMERIC_SCALE: 如果参数是数字类型，这是小数点后的位数。
• DATETIME_PRECISION: 如果参数是日期或时间类型，这是精度。
• CHARACTER_SET_NAME: 参数使用的字符集名称。
• COLLATION_NAME: 参数使用的排序规则名称。
• DTD_IDENTIFIER: 参数的数据类型标识符，通常与 DATA_TYPE 列相同。

PARTITIONS

在 MySQL 中，PARTITIONS 表是 INFORMATION_SCHEMA 数据库的一部分，它提供了关于分区表的分区信息。分区是一种数据库优化技术，它允许你将一个大表分割成多个更小的、更易于管理的部分，每个部分称为一个分区。分区可以提高查询性能，优化数据维护任务，如备份和恢复。

以下是 INFORMATION_SCHEMA.PARTITIONS 表中可能包含的一些关键列：

1. TABLE_CATALOG: 表所在的数据库名称。
2. TABLE_SCHEMA: 表的模式（通常称为数据库）。
3. TABLE_NAME: 表的名称。
4. PARTITION_EXPRESSION: 定义分区的表达式。
5. PARTITION_DESCRIPTION: 分区的描述。
6. TABLE_ROWS: 表中估计的行数。
7. AVG_ROW_LENGTH: 表中行的平均长度。
8. DATA_LENGTH: 分区中数据的长度。
9. MAX_DATA_LENGTH: 分区中数据的最大长度。
10. INDEX_LENGTH: 分区索引的长度。
11. DATA_FREE: 分区中的空闲空间。
12. CREATE_TIME: 分区创建的时间。
13. UPDATE_TIME: 分区上次更新的时间。
14. CHECK_TIME: 分区上次检查的时间。
15. CHECKSUM: 分区的校验和。
16. PARTITION_COMMENT: 分区的注释。
17. NODEGROUP: 分区所属的节点组。
18. TABLESPACE_NAME: 分区使用的表空间名称。

要查询 PARTITIONS 表，你可以使用以下 SQL 语句：

SELECT * FROM INFORMATION_SCHEMA.PARTITIONS
WHERE TABLE_SCHEMA = 'your_database_name' AND TABLE_NAME = 'your_table_name';

将 your_database_name 和 your_table_name 替换为你要查询的数据库和表的名称。这将返回指定表的所有分区信息。

例如，如果你想查看 employees 表的所有分区信息，你可以执行：

SELECT * FROM INFORMATION_SCHEMA.PARTITIONS
WHERE TABLE_SCHEMA = 'your_database_name' AND TABLE_NAME = 'employees';

这将返回 employees 表的分区方案的详细信息，包括每个分区的行数、大小、索引长度等。

请注意，PARTITIONS 表可能不包含所有 MySQL 版本中的所有列。某些列可能在特定版本中不可用。

PLUGINS

PLUGINS 表是 MySQL INFORMATION_SCHEMA 数据库中的一个表，它提供了关于 MySQL 服务器上可用插件的信息。插件通常是动态加载的库，它们为 MySQL 服务器提供额外的功能，比如身份验证插件、存储引擎插件、审计插件等。

以下是 INFORMATION_SCHEMA.PLUGINS 表中可能包含的一些关键列：

1. PLUGIN_NAME: 插件的名称。
2. PLUGIN_VERSION: 插件的版本。
3. PLUGIN_STATUS: 插件的状态（例如 ACTIVE、INACTIVE、DISABLED）。
4. PLUGIN_TYPE: 插件的类型（例如 AUTHENTICATION、STORAGE ENGINE、SERVICE）。
5. PLUGIN_TYPE_VERSION: 插件类型的版本。
6. PLUGIN_LIBRARY: 插件使用的库文件的名称。
7. PLUGIN_LIBRARY_VERSION: 库文件的版本。
8. PLUGIN_SOURCE: 插件的来源（例如 FILE、FUNCTION、KEYRING）。
9. PLUGIN_AUTHOR: 插件的作者。
10. PLUGIN_DESCRIPTION: 插件的描述。

要查询 PLUGINS 表，你可以使用以下 SQL 语句：

SELECT * FROM INFORMATION_SCHEMA.PLUGINS;

这将返回服务器上所有插件的列表及其相关信息。这对于了解服务器上安装了哪些插件以及它们的当前状态非常有用。

例如，如果你想查看所有激活的存储引擎插件，你可以执行：

SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS
WHERE PLUGIN_TYPE = 'STORAGE ENGINE' AND PLUGIN_STATUS = 'ACTIVE';

这将返回所有当前激活的存储引擎插件的名称和状态。

PLUGINS 表是管理和维护 MySQL 服务器时的一个有用资源，特别是在处理存储引擎或身份验证机制时。

PROCESSLIST

在 MySQL 中，PROCESSLIST 表是 INFORMATION_SCHEMA 数据库中的一个表，它提供了当前 MySQL 服务器上所有活动线程的列表。这个表对于监控和诊断数据库性能问题、锁定问题和其他并发问题非常有用。

以下是 INFORMATION_SCHEMA.PROCESSLIST 表中可能包含的一些关键列：

1. ID: 线程的唯一标识符。
2. USER: 执行线程的 MySQL 用户名。
3. HOST: 用户连接的主机名和端口号。
4. DB: 当前线程正在操作的数据库名称。如果线程没有操作数据库，则此列为 NULL。
5. COMMAND: 线程正在执行的命令类型（例如 Query、Sleeping、Connect 等）。
6. TIME: 线程执行当前命令的时间长度（秒）。对于 Sleeping 线程，这是它等待的时长。
7. STATE: 线程的状态，例如 Sleeping、Locked、Query 等。
8. INFO: 线程正在执行的 SQL 语句的前 100 个字符。对于非查询命令，此列可能包含额外的状态信息。

要查询 PROCESSLIST 表，你可以使用以下 SQL 语句：

SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST;

这将返回服务器上所有当前活动的线程的列表。

例如，如果你想查看特定用户的活动线程，你可以执行：

SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST WHERE USER = 'your_username';

将 your_username 替换为你要查询的用户名。

PROCESSLIST 表通常用于以下情况：

• 性能监控：查看哪些查询正在执行以及它们的执行时长。
• 锁定诊断：识别可能导致锁定问题的长时间运行的查询。
• 资源使用：了解哪些线程正在使用数据库资源。

请注意，PROCESSLIST 表中显示的信息可能会随着 MySQL 版本的不同而有所变化。此外，为了保护用户隐私，某些列（如 INFO）可能会截断显示的查询文本。

PROFILING

PROFILING 表是 MySQL INFORMATION_SCHEMA 数据库中的一个表，它提供了关于执行过的 SQL 语句的分析信息。这些信息可以帮助数据库管理员和开发者了解 SQL 语句执行过程中的资源消耗情况，例如 CPU 使用时间、I/O 操作、上下文切换、页面错误等。

要使用 PROFILING 表，你需要先启用 MySQL 的分析功能，可以通过设置 profiling 系统变量为 1 来启用：

SET profiling = 1;

启用后，执行的 SQL 语句将被记录在 PROFILING 表中。这个表包含以下列：

• QUERY_ID: 一个数字标识符，唯一地标识执行的 SQL 语句。
• SEQ: 一个序列号，指示具有相同 QUERY_ID 值的行的显示顺序。
• STATE: 行测量适用的分析状态，例如 "Sending data"、"Creating sort index" 等。
• DURATION: 语句执行在给定状态下保持多长时间，以秒为单位。
• CPU_USER, CPU_SYSTEM: 用户和系统 CPU 使用情况，以秒为单位。
• CONTEXT_VOLUNTARY, CONTEXT_INVOLUNTARY: 自愿和非自愿上下文切换的次数。
• BLOCK_OPS_IN, BLOCK_OPS_OUT: 块输入和输出操作的数量。
• MESSAGES_SENT, MESSAGES_RECEIVED: 发送和接收的通信消息数。
• PAGE_FAULTS_MAJOR, PAGE_FAULTS_MINOR: 主要和次要页面错误的数量。
• SWAPS: 发生了多少次交换。
• SOURCE_FUNCTION, SOURCE_FILE, SOURCE_LINE: 指示分析状态在源代码中执行位置的信息。

你可以通过以下 SQL 语句查询 PROFILING 表：

SELECT * FROM INFORMATION_SCHEMA.PROFILING WHERE QUERY_ID = [特定的QUERY_ID];

将 [特定的QUERY_ID] 替换为你想要查询的 SQL 语句的 QUERY_ID。这将返回指定 SQL 语句的分析信息。

PROFILING 表是分析和优化 SQL 性能的有力工具，它可以帮助识别性能瓶颈和资源消耗的热点。不过，需要注意的是，频繁地使用 PROFILING 可能会对数据库性能产生一定影响，因此建议在分析问题时开启，在不需要时关闭该功能 。

REFERENTIAL_CONSTRAINTS

REFERENTIAL_CONSTRAINTS 表是 INFORMATION_SCHEMA 数据库中的一个表，它提供了数据库中所有外键约束的详细信息。外键约束用于维护两个表之间的关系，确保引用完整性，即子表中的外键值必须在父表中有对应的值。

以下是 INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS 表中的一些关键列：

• CONSTRAINT_CATALOG: 约束所属目录的名称，对于 MySQL，这个值通常是 def。
• CONSTRAINT_SCHEMA: 约束所属的数据库（模式）名称。
• CONSTRAINT_NAME: 外键约束的名称。
• UNIQUE_CONSTRAINT_CATALOG: 引用的唯一约束所在的目录名称，对于 MySQL，这个值通常是 def。
• UNIQUE_CONSTRAINT_SCHEMA: 引用的唯一约束所在的数据库（模式）名称。
• UNIQUE_CONSTRAINT_NAME: 被引用的唯一约束的名称。
• MATCH_OPTION: 匹配选项，通常是 NONE，表示没有特殊的匹配规则。
• UPDATE_RULE: ON UPDATE 动作的规则，可能的值包括 CASCADE、SET NULL、SET DEFAULT、RESTRICT、NO ACTION。
• DELETE_RULE: ON DELETE 动作的规则，可能的值与 UPDATE_RULE 相同。
• TABLE_NAME: 包含外键的表的名称。
• REFERENCED_TABLE_NAME: 被引用的表的名称。

通过查询 REFERENTIAL_CONSTRAINTS 表，可以查看数据库中外键约束的详细信息，例如：

SELECT CONSTRAINT_NAME, UPDATE_RULE, DELETE_RULE, TABLE_NAME, REFERENCED_TABLE_NAME
FROM INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS
WHERE CONSTRAINT_SCHEMA = 'your_database_name';

将 your_database_name 替换为你要查询的数据库名称。这将返回指定数据库中所有外键约束的更新和删除规则，以及它们所在的表和被引用的表的名称。

这个表对于理解和管理数据库的外键约束非常有用，尤其是在进行数据完整性和数据关系管理时。

RESOURCE_GROUPS

RESOURCE_GROUPS 表是 MySQL INFORMATION_SCHEMA 数据库中的一个表，它提供了关于服务器上定义的资源组的信息。资源组是 MySQL 8.0 引入的功能，它允许数据库管理员对服务器上的资源进行更细粒度的控制，特别是 CPU 资源。

资源组可以是 USER 类型或 SYSTEM 类型，分别对应于用户线程和系统线程。通过资源组，管理员可以控制这些线程可以使用的 CPU（称为 vCPU 或虚拟 CPU），以及线程的优先级。

以下是 INFORMATION_SCHEMA.RESOURCE_GROUPS 表中的一些关键列：

• RESOURCE_GROUP_NAME: 资源组的名称。
• RESOURCE_GROUP_TYPE: 资源组的类型，可以是 USER 或 SYSTEM。
• RESOURCE_GROUP_ENABLED: 表示资源组是否启用，1 表示启用，0 表示禁用。
• VCPU_IDS: 资源组可以使用的虚拟 CPU 编号或范围。
• THREAD_PRIORITY: 资源组中线程的优先级，范围从 -20（最高）到 19（最低）。SYSTEM 类型的资源组优先级范围是 -20 到 0，而 USER 类型的资源组优先级范围是 0 到 19。

默认情况下，MySQL 8.0 会创建两个资源组 USR_default 和 SYS_default。管理员可以根据需要创建额外的资源组，并分配特定的 CPU 资源和优先级。例如，可以创建一个资源组来管理不需要高优先级执行的批处理作业。

要查看资源组的信息，可以执行以下 SQL 查询：

SELECT * FROM INFORMATION_SCHEMA.RESOURCE_GROUPS;

这将返回当前服务器上所有资源组的详细信息。管理员可以使用这些信息来监控和调整资源组的配置，以优化服务器的性能和资源利用率。

创建资源组的例子：

CREATE RESOURCE GROUP my_resource_group
TYPE = USER
VCPU = 2-3
THREAD_PRIORITY = 10;

查询特定资源组的信息：

SELECT * FROM INFORMATION_SCHEMA.RESOURCE_GROUPS
WHERE RESOURCE_GROUP_NAME = 'my_resource_group';

这将返回名为 my_resource_group 的资源组的详细信息。

资源组管理是本地化的，不会复制到其他服务器。此外，某些平台或 MySQL 服务器配置可能限制了资源组的功能。例如，在 macOS 上，资源组不可用，因为 macOS 不提供用于将 CPU 绑定到线程的 API。在 Linux 上，除非设置了 CAP_SYS_NICE 功能，否则会忽略资源组线程优先级 。

ROLE_COLUMN_GRANTS

ROLE_COLUMN_GRANTS 是 INFORMATION_SCHEMA 下的一个视图，它提供了关于数据库角色的列级权限的详细信息。此视图显示了授予者或被授予者是当前启用的角色的列上授予的所有权限。这可以帮助数据库管理员了解和维护数据库角色的权限设置。

以下是 INFORMATION_SCHEMA.ROLE_COLUMN_GRANTS 视图中的一些关键列：

• GRANTOR: 授予权限的角色的名称。
• GRANTEE: 被授予权限的角色的名称。
• TABLE_CATALOG: 包含该列的表的数据库名称。
• TABLE_SCHEMA: 包含该列的表的模式（Schema）名称。
• TABLE_NAME: 包含该列的表的名称。
• COLUMN_NAME: 列的名称。
• PRIVILEGE_TYPE: 权限的类型，如 SELECT、INSERT、UPDATE 或 REFERENCES。
• IS_GRANTABLE: 如果权限可授予，显示为 YES，否则为 NO。

要查询 ROLE_COLUMN_GRANTS 视图，你可以使用以下 SQL 语句：

SELECT * FROM INFORMATION_SCHEMA.ROLE_COLUMN_GRANTS;

这将返回当前数据库中所有角色的列级权限的详细信息。通过分析这些信息，管理员可以确保角色具有适当的权限，以执行其职责范围内的操作。

需要注意的是，ROLE_COLUMN_GRANTS 视图仅显示与当前用户相关的角色权限。如果你需要查看所有角色的权限，可以使用 COLUMN_PRIVILEGES 视图，它不限制于当前用户的角色 。

ROLE_ROUTINE_GRANTS

ROLE_ROUTINE_GRANTS 表是 MySQL INFORMATION_SCHEMA 数据库中的一个表，它提供有关当前启用的角色可用的或授予的角色例程权限的信息。这个表在 MySQL 8.0.19 版本中引入，用于显示当前用户或角色的存储过程和函数权限。

以下是 INFORMATION_SCHEMA.ROLE_ROUTINE_GRANTS 表中的一些关键列：

• GRANTOR: 授予角色的账户用户名部分。
• GRANTOR_HOST: 授予角色的账户主机名部分。
• GRANTEE: 被授予角色的账户用户名部分。
• GRANTEE_HOST: 被授予角色的账户主机名部分。
• SPECIFIC_CATALOG: 例程所属的目录名称，对于 MySQL，这个值总是 def。
• SPECIFIC_SCHEMA: 例程所属的模式（数据库）名称。
• SPECIFIC_NAME: 例程的名称。
• ROUTINE_CATALOG: 例程所属的目录名称，对于 MySQL，这个值总是 def。
• ROUTINE_SCHEMA: 例程所属的模式（数据库）名称。
• ROUTINE_NAME: 例程的名称。
• PRIVILEGE_TYPE: 授予的权限类型，可以是 EXECUTE 等。
• IS_GRANTABLE: 表示权限是否可授予其他用户，值为 YES 或 NO。

要查看角色的例程权限，可以执行以下 SQL 查询：

SELECT * FROM INFORMATION_SCHEMA.ROLE_ROUTINE_GRANTS;

这将返回当前用户或角色的所有例程权限信息。此视图有助于数据库管理员审查和维护角色的存储过程和函数权限。

ROLE_TABLE_GRANTS

ROLE_TABLE_GRANTS 视图是 MySQL INFORMATION_SCHEMA 数据库中的一个组成部分，它提供当前启用的角色可用的或授予的表权限信息。这个视图在 MySQL 8.0.19 版本中引入，用于显示当前用户或角色的表级权限。

以下是 INFORMATION_SCHEMA.ROLE_TABLE_GRANTS 视图中的一些关键列：

• GRANTOR: 授予角色的账户用户名部分。
• GRANTOR_HOST: 授予角色的账户主机名部分。
• GRANTEE: 被授予角色的账户用户名部分。
• GRANTEE_HOST: 被授予角色的账户主机名部分。
• TABLE_CATALOG: 应用角色的目录名称，此值始终为 def。
• TABLE_SCHEMA: 应用角色的模式（数据库）名称。
• TABLE_NAME: 应用角色的表名称。
• PRIVILEGE_TYPE: 授予的权限类型，可以是表级权限，如 SELECT、INSERT、UPDATE、DELETE 等。
• IS_GRANTABLE: 表示角色是否可以将权限授予其他账户，值为 YES 或 NO。

要查询 ROLE_TABLE_GRANTS 视图，你可以使用以下 SQL 语句：

SELECT * FROM INFORMATION_SCHEMA.ROLE_TABLE_GRANTS;

这将返回当前用户或角色的所有表级权限信息。此视图有助于数据库管理员审查和维护角色的表权限。

需要注意的是，ROLE_TABLE_GRANTS 视图仅显示与当前用户相关的角色权限。如果你需要查看所有角色的权限，可以使用 TABLE_PRIVILEGES 视图，它不限制于当前用户的角色 。

ROUTINES

ROUTINES 表是 INFORMATION_SCHEMA 数据库中的一个表，它提供了关于存储例程（存储过程和存储函数）的信息。这个表不包括内置（本机）函数或可加载函数。

以下是 INFORMATION_SCHEMA.ROUTINES 表中的一些关键列：

• SPECIFIC_NAME: 例程的名称。
• ROUTINE_CATALOG: 例程所属目录的名称。对于 MySQL，这个值总是 def。
• ROUTINE_SCHEMA: 例程所属的模式（数据库）的名称。
• ROUTINE_NAME: 例程的名称。
• ROUTINE_TYPE: PROCEDURE 表示存储过程，FUNCTION 表示存储函数。
• DATA_TYPE: 如果例程是存储函数，这是返回值的数据类型。如果是存储过程，则此值为空。
• CHARACTER_MAXIMUM_LENGTH: 对于存储的函数字符串返回值，这是最大字符长度。如果是存储过程，则此值为 NULL。
• CHARACTER_OCTET_LENGTH: 对于存储的函数字符串返回值，这是以字节为单位的最大长度。如果是存储过程，则此值为 NULL。
• NUMERIC_PRECISION: 对于存储函数数字返回值，这是数字精度。如果是存储过程，则此值为 NULL。
• NUMERIC_SCALE: 对于存储的函数数字返回值，这是数字比例。如果是存储过程，则此值为 NULL。
• DATETIME_PRECISION: 对于存储函数时间返回值，这是小数秒精度。如果是存储过程，则此值为 NULL。
• CHARACTER_SET_NAME: 对于存储的函数字符串返回值，这是字符集名称。如果是存储过程，则此值为 NULL。
• COLLATION_NAME: 对于存储的函数字符串返回值，这是排序规则名称。如果是存储过程，则此值为 NULL。
• DTD_IDENTIFIER: 如果例程是存储函数，这是返回值数据类型。如果是存储过程，则此值为空。

要查询 ROUTINES 表，你可以使用以下 SQL 语句：

SELECT * FROM INFORMATION_SCHEMA.ROUTINES
WHERE ROUTINE_SCHEMA = 'your_database_name';

将 your_database_name 替换为你要查询的数据库名称。这将返回指定数据库中所有存储过程和函数的详细信息。

这个表对于管理和维护数据库的存储例程非常有用，尤其是在进行代码审查、性能优化和安全审计时。

SCHEMATA

SCHEMATA 表是 INFORMATION_SCHEMA 数据库中的一个表，它提供了关于 MySQL 服务器上所有数据库（在 MySQL 中被称为模式）的信息。这个表包含了数据库的名称、默认字符集、默认排序规则等信息。

以下是 INFORMATION_SCHEMA.SCHEMATA 表中的一些关键列：

• CATALOG_NAME: 数据库所属目录的名称。在 MySQL 中，这个值通常是 def。
• SCHEMA_NAME: 数据库（模式）的名称。
• DEFAULT_CHARACTER_SET_NAME: 数据库的默认字符集名称。
• DEFAULT_COLLATION_NAME: 数据库的默认排序规则名称。
• SQL_PATH: 这个值始终为 NULL。
• DEFAULT_ENCRYPTION: 数据库的默认加密选项（在 MySQL 8.0.16 及以后版本中添加）。

要查询 SCHEMATA 表，你可以使用以下 SQL 语句：

SELECT SCHEMA_NAME FROM INFORMATION_SCHEMA.SCHEMATA;

这将返回 MySQL 服务器上所有数据库的名称列表。这个查询等同于使用 SHOW DATABASES 命令，但通过查询 INFORMATION_SCHEMA 表来实现。

SCHEMATA 表对于管理和维护数据库的元数据非常有用，尤其是在进行数据库结构分析、权限管理或性能优化时。通过这个表，你可以了解数据库的默认字符集和排序规则，这对于确保数据的一致性和性能至关重要。

请注意，你只能看到那些你拥有某种权限的数据库，除非你拥有全局 SHOW DATABASES 特权。这是因为 MySQL 的权限系统限制了对元数据的访问，以保护数据库的安全性 。

SCHEMATA_EXTENSIONS

SCHEMATA_EXTENSIONS 表是 INFORMATION_SCHEMA 数据库中的一个表，它在 MySQL 8.0.22 版本中引入，用于提供有关模式（数据库）选项的额外信息。这个表通常用于查看和管理数据库的只读状态。

以下是 INFORMATION_SCHEMA.SCHEMATA_EXTENSIONS 表中的一些关键列：

• CATALOG_NAME: 模式所属目录的名称。这个值始终为 def。
• SCHEMA_NAME: 模式（数据库）的名称。
• OPTIONS: 模式的选项。如果模式是只读的，则该值包含 READ ONLY=1。如果模式不是只读的，则没有 READ ONLY 选项。

例如，如果你将一个数据库设置为只读，可以使用以下命令：

ALTER SCHEMA mydb READ ONLY = 1;

然后，通过查询 SCHEMATA_EXTENSIONS 表，你可以看到数据库的只读选项：

SELECT * FROM INFORMATION_SCHEMA.SCHEMATA_EXTENSIONS WHERE SCHEMA_NAME = 'mydb';

如果数据库被设置为只读，上述查询将返回包含 READ ONLY=1 的 OPTIONS 列。如果数据库不是只读的，则 OPTIONS 列可能为空。

这个表是非标准的 INFORMATION_SCHEMA 表，意味着它可能不遵循其他数据库管理系统的 INFORMATION_SCHEMA 标准 。

SCHEMA_PRIVILEGES

SCHEMA_PRIVILEGES 表是 MySQL INFORMATION_SCHEMA 数据库中的一个表，它提供有关数据库（schema）权限的信息。这个表从 mysql.db 系统表中获取其值，主要用于管理和审查数据库权限。

以下是 SCHEMA_PRIVILEGES 表中的一些关键列：

• GRANTEE: 授予权限的账户名称，格式为 'user_name'@'host_name'。
• TABLE_CATALOG: schema 所属目录的名称，该值始终为 def。
• TABLE_SCHEMA: schema 的名称。
• PRIVILEGE_TYPE: 授予的特权，可以是任何在 schema 级别授予的权限，例如 SELECT、INSERT、UPDATE 等。
• IS_GRANTABLE: 如果用户具有 GRANT OPTION 权限，则为 YES，否则为 NO。输出不会将 GRANT OPTION 列为具有 PRIVILEGE_TYPE='GRANT OPTION' 的单独行。

每行列出一个权限，因此被授权者拥有的每个 schema 权限对应一行。这使得数据库管理员可以清晰地了解每个用户或角色的权限设置。

SCHEMA_PRIVILEGES 表是一个非标准的 INFORMATION_SCHEMA 表，因此与其他数据库管理系统的实现可能有所不同。通过查询这个表，管理员可以有效地管理和审查数据库的访问权限，确保数据的安全性和完整性。

STATISTICS

STATISTICS 表是 INFORMATION_SCHEMA 数据库中的一个表，它提供有关表索引的信息。这个表中的列保存了缓存值，这些值在默认情况下会在 24 小时后过期。如果没有缓存统计信息或统计信息已过期，则在查询表统计信息列时会从存储引擎中检索统计信息。

以下是 STATISTICS 表中的一些关键列：

• TABLE_CATALOG: 包含索引的表所属目录的名称，该值始终为 def。
• TABLE_SCHEMA: 包含索引的表所属的模式（数据库）的名称。
• TABLE_NAME: 包含索引的表的名称。
• NON_UNIQUE: 如果索引不能包含重复项，则为 0，如果可以，则为 1。
• INDEX_SCHEMA: 索引所属的模式（数据库）的名称。
• INDEX_NAME: 索引的名称。如果索引是主键，则名称始终是 PRIMARY。
• SEQ_IN_INDEX: 索引中的列序号，从 1 开始。
• COLUMN_NAME: 列名称。
• COLLATION: 列在索引中的排序方式，可以是 A（升序）、D（降序）或 NULL（未排序）。
• CARDINALITY: 索引中唯一值数量的估计。要更新此数字，请运行 ANALYZE TABLE。
• SUB_PART: 如果列仅被部分索引，则为索引前缀的字符数；如果整个列被索引，则为 NULL。
• PACKED: 指示密钥的打包方式，如果不是，则为 NULL。
• NULLABLE: 如果列可能包含 NULL 值，则为 YES，否则为空。
• INDEX_TYPE: 索引类型，如 BTREE、FULLTEXT、HASH、RTREE。
• COMMENT: 有关未在其自己的列中描述的索引的信息，例如在禁用索引时禁用。
• INDEX_COMMENT: 创建索引时提供的任何注释。

要查询索引信息，可以使用以下 SQL 语句：

SELECT * FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_NAME = 'your_table_name'
AND TABLE_SCHEMA = 'your_database_name';

将 your_table_name 和 your_database_name 替换为你要查询的表名和数据库名。这将返回指定表的索引信息。

STATISTICS 表对于数据库管理员和优化器来说非常重要，因为它们提供了索引的统计信息，有助于优化查询性能。

ST_GEOMETRY_COLUMNS

ST_GEOMETRY_COLUMNS 表是 INFORMATION_SCHEMA 数据库中的一个表，提供有关存储空间数据的表列的信息。此表基于 SQL/MM (ISO/IEC 13249-3) 标准，并带有注释的扩展。MySQL 实现 ST_GEOMETRY_COLUMNS 作为 INFORMATION_SCHEMA.COLUMNS 表的视图。

以下是 ST_GEOMETRY_COLUMNS 表中的一些关键列：

• TABLE_CATALOG: 包含该列的表所属目录的名称。该值始终为 def。
• TABLE_SCHEMA: 包含该列的表所属的模式（数据库）的名称。
• TABLE_NAME: 包含该列的表的名称。
• COLUMN_NAME: 列的名称。
• SRS_NAME: 空间参照系 (SRS) 名称。
• SRS_ID: 空间参考系统 ID (SRID)。
• GEOMETRY_TYPE_NAME: 列数据类型。允许的值为：geometry, point, linestring, polygon, multipoint, multilinestring, multipolygon, geometrycollection。这一列是 MySQL 对标准的扩展 。

这个表对于管理和使用空间数据类型（如 GEOMETRY）非常有用，尤其是在进行空间数据查询和操作时。通过这个表，用户可以了解哪些列是空间数据类型，它们的空间参考系统是什么，以及它们的几何类型是什么。

ST_SPATIAL_REFERENCE_SYSTEMS

ST_SPATIAL_REFERENCE_SYSTEMS 表是 INFORMATION_SCHEMA 数据库中的一个表，它提供有关空间数据的空间参考系统（SRS）的信息。此表基于 SQL/MM (ISO/IEC 13249-3) 标准，并且以 European Petroleum Survey Group (EPSG) 数据集为基础，除了 SRID 0 之外，它代表 MySQL 中使用的一个特殊 SRS，表示一个无限的平面笛卡尔平面，没有分配单位给它的轴。

以下是 ST_SPATIAL_REFERENCE_SYSTEMS 表中的一些关键列：

• SRS_NAME: 空间参考系统名称，此值是唯一的。
• SRS_ID: 空间参考系统数字 ID，此值是唯一的。SRS_ID 值与几何值的 SRID 或作为 SRID 参数传递给空间函数的值相同。
• ORGANIZATION: 定义坐标系统（空间参考系统基于此坐标系统）的组织的名称。
• ORGANIZATION_COORDSYS_ID: 由定义它的组织提供的 SRS 的数字 ID。
• DEFINITION: 空间参考系统定义。DEFINITION 值是 WKT 值，按照 Open Geospatial Consortium 文档 OGC 12-063r5 中的规定表示。
• DESCRIPTION: 空间参考系统描述。

例如，GPS 系统使用的 SRS 有一个名称（SRS_NAME）WGS 84 和一个 ID（SRS_ID）4326，这是由 EPSG 使用的 ID。DEFINITION 列中的 SRS 定义是 WKT 值，如 所述。

要查询空间参考系统的信息，可以使用以下 SQL 语句：

SELECT * FROM INFORMATION_SCHEMA.ST_SPATIAL_REFERENCE_SYSTEMS
WHERE SRS_ID = 4326;

这将返回与 SRS ID 4326 相关的空间参考系统信息。

ST_UNITS_OF_MEASURE

ST_UNITS_OF_MEASURE 表是 INFORMATION_SCHEMA 数据库中的一个表，它提供有关 ST_Distance() 函数可接受的单位的信息。这个表在 MySQL 8.0.14 版本中引入，包含了空间数据距离测量单位的相关信息。

以下是 ST_UNITS_OF_MEASURE 表中的一些关键列：

• UNIT_NAME: 单位的名称。
• UNIT_TYPE: 单位类型（例如 LINEAR）。
• CONVERSION_FACTOR: 用于内部计算的转换因子。
• DESCRIPTION: 单位的描述。

这个表用于支持 ST_Distance() 函数，该函数可以计算两个几何对象之间的距离，并允许指定返回值的长度单位。如果指定了一个单位但 MySQL 不支持，将会发生 ER_UNIT_NOT_FOUND 错误。如果指定了支持的线性单位且 SRID 为 0，将会发生 ER_GEOMETRY_IN_UNKNOWN_LENGTH_UNIT 错误。如果未指定单位，则结果采用几何 SRS 的单位，无论是笛卡尔还是地理。

例如，如果你想查询所有可用的测量单位及其相关信息，可以使用以下 SQL 语句：

SELECT * FROM INFORMATION_SCHEMA.ST_UNITS_OF_MEASURE;

这将返回所有已定义的测量单位的列表，包括它们的名称、类型、转换因子和描述。这个表对于确保空间数据计算的准确性和理解不同测量单位之间的转换非常有用。

TABLES

TABLES 表是 INFORMATION_SCHEMA 数据库中的一个表，它提供了关于数据库中表的详细信息，包括视图和基础表。这个表包含了数据库中每个表的元数据，如表的名称、类型、使用的存储引擎、行格式、创建时间等信息。

以下是 INFORMATION_SCHEMA.TABLES 表中的一些关键列及其含义：

• TABLE_CATALOG: 表所属目录的名称，对于 MySQL，这个值通常是 def。
• TABLE_SCHEMA: 表所属的数据库（模式）的名称。
• TABLE_NAME: 表的名称。
• TABLE_TYPE: 表的类型，例如 BASE TABLE（基础表）或 VIEW（视图）。
• ENGINE: 表使用的存储引擎，如 InnoDB、MyISAM 等。
• VERSION: 存储引擎的版本号。
• ROW_FORMAT: 行的存储格式，例如 Dynamic、Fixed、Compressed 等。
• TABLE_ROWS: 表中估计的行数。
• AVG_ROW_LENGTH: 表中行的平均长度。
• DATA_LENGTH: 表的数据占用的字节数。
• MAX_DATA_LENGTH: 表数据的最大长度。
• INDEX_LENGTH: 表索引占用的字节数。
• DATA_FREE: 表中的空闲空间。
• AUTO_INCREMENT: 自增字段的当前值。
• CREATE_TIME: 表的创建时间。
• UPDATE_TIME: 表的最后更新时间。
• CHECK_TIME: 表的最后检查时间。
• TABLE_COLLATION: 表的默认字符集排序规则。
• CHECKSUM: 表的校验和，用于验证数据的完整性。
• CREATE_OPTIONS: 创建表时使用的选项。
• TABLE_COMMENT: 表的注释或描述。

要查询 TABLES 表，你可以使用以下 SQL 语句：

SELECT * FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = 'your_database_name';

将 your_database_name 替换为你要查询的数据库名称。这将返回指定数据库中所有表的详细信息。

TABLES 表对于数据库管理员和开发者在进行数据库设计、优化和管理时非常有用。通过这个表，可以快速了解数据库中表的存储和性能特性，以及表的创建和更新时间等信息。

TABLESPACES

TABLESPACES 表是 INFORMATION_SCHEMA 数据库中的一个表，提供关于 InnoDB 存储引擎管理的文件-per-table、通用（general）和 undo 表空间的元数据信息。

以下是 INFORMATION_SCHEMA.TABLESPACES 表中的一些关键列：

• SPACE: 表空间的 ID。
• NAME: 表空间的名称。对于 file-per-table 表空间，名称通常以 <schema_name>/<table_name> 的形式出现。
• FLAG: 表示表空间格式和存储特征的位掩码值。
• FILE_FORMAT: 表空间的文件格式，例如 Antelope、Barracuda 或 Any（通用表空间支持任何行格式）。
• ROW_FORMAT: 表空间的行格式，如 Compact、Redundant、Dynamic 或 Compressed。
• PAGE_SIZE: 表空间的页面大小。
• ZIP_PAGE_SIZE: 表空间的压缩页面大小。
• SPACE_TYPE: 表空间的类型，可能的值包括 System、Single 或 General。
• FS_BLOCK_SIZE: 文件系统块大小，这是磁盘读写的最小单位。
• FILE_SIZE: 表空间文件的显示大小。
• ALLOCATED_SIZE: 分配给表空间的实际磁盘空间量。
• AUTOEXTEND_SIZE: 表空间的自动扩展大小。
• SERVER_VERSION: 创建表空间时的 MySQL 版本号。
• SPACE_VERSION: 表空间版本，用于跟踪表空间格式的变化。
• ENCRYPTION: 表空间是否加密。
• STATE: 表空间的状态，例如 normal、discarded 或 corrupted。

要查询 TABLESPACES 表，可以使用类似以下 SQL 语句：

SELECT * FROM INFORMATION_SCHEMA.TABLESPACES WHERE SPACE = [特定的SPACE_ID];

将 [特定的SPACE_ID] 替换为你想要查询的表空间的ID。这个表对于数据库管理员在进行数据库性能优化和表空间管理时特别有用，因为它可以帮助他们了解表空间的使用情况和配置。

TABLESPACES_EXTENSIONS

TABLESPACES_EXTENSIONS 表是 INFORMATION_SCHEMA 数据库中的一个表，它提供有关存储引擎定义的表空间属性的信息。这个表在 MySQL 8.0.21 版本中引入，包含了表空间的扩展属性。

以下是 TABLESPACES_EXTENSIONS 表中的一些关键列：

• TABLESPACE_NAME: 表空间的名称。
• ENGINE_ATTRIBUTE: 存储引擎定义的表空间属性。

需要注意的是，TABLESPACES_EXTENSIONS 表保留供将来使用，当前版本中可能不包含实际的数据。

TABLES_EXTENSIONS

TABLES_EXTENSIONS 表是 INFORMATION_SCHEMA 数据库中的一个表，从 MySQL 8.0.21 版本开始可用。这个表提供了有关为主存储引擎和辅助存储引擎定义的表属性的信息。

以下是 TABLES_EXTENSIONS 表中的一些关键列：

• TABLE_CATALOG: 表所属目录的名称。此值始终为 def。
• TABLE_SCHEMA: 表所属的模式（数据库）的名称。
• TABLE_NAME: 表的名称。
• ENGINE_ATTRIBUTE: 为主存储引擎定义的表属性。保留以供将来使用。
• SECONDARY_ENGINE_ATTRIBUTE: 为辅助存储引擎定义的表属性。保留以供将来使用。

此表目前保留供将来使用，意味着这些列可能在将来的版本中填充实际的数据。当前版本中，这些属性可能不包含实际的表属性信息。

TABLE_CONSTRAINTS

TABLE_CONSTRAINTS 表是 INFORMATION_SCHEMA 数据库中的一个表，它描述了哪些表具有约束。这个表包含了关于表的约束信息，如约束类型、约束名称、所属数据库和表名等。

以下是 TABLE_CONSTRAINTS 表中的一些关键列：

• CONSTRAINT_CATALOG: 约束所属目录的名称。在 MySQL 中，这个值总是 def 。
• CONSTRAINT_SCHEMA: 约束所属的模式（数据库）的名称。
• TABLE_SCHEMA: 表所属的模式（数据库）的名称。
• TABLE_NAME: 表的名称。
• CONSTRAINT_NAME: 约束的名称。
• CONSTRAINT_TYPE: 约束的类型。可能的值包括 UNIQUE、PRIMARY KEY、FOREIGN KEY，以及从 MySQL 8.0.16 开始支持的 CHECK 。
• ENFORCED: 对于 CHECK 约束，值为 YES 或 NO 以指示是否强制执行约束。对于其他约束，该值始终为 YES 。

要查询 TABLE_CONSTRAINTS 表，你可以使用以下 SQL 语句：

SELECT * FROM INFORMATION_SCHEMA.TABLE_CONSTRAINTS
WHERE TABLE_SCHEMA = 'your_database_name' AND TABLE_NAME = 'your_table_name';

将 your_database_name 和 your_table_name 替换为你要查询的数据库和表的名称。这将返回指定表的约束信息。

TABLE_CONSTRAINTS 表对于数据库管理员和开发者在进行数据库设计、优化和管理时非常有用。通过这个表，可以快速了解数据库中表的约束情况，包括约束类型和约束名称等信息。

TABLE_CONSTRAINTS_EXTENSIONS

TABLE_CONSTRAINTS_EXTENSIONS 表是 INFORMATION_SCHEMA 数据库中的一个表，从 MySQL 8.0.21 版本开始引入。这个表提供有关主要和辅助存储引擎定义的表约束属性的信息。

以下是 TABLE_CONSTRAINTS_EXTENSIONS 表中的一些关键列：

• CONSTRAINT_CATALOG: 表所属目录的名称。
• CONSTRAINT_SCHEMA: 表所属的模式（数据库）的名称。
• CONSTRAINT_NAME: 约束的名称。
• TABLE_NAME: 表的名称。
• ENGINE_ATTRIBUTE: 为主存储引擎定义的约束属性。保留以供将来使用。
• SECONDARY_ENGINE_ATTRIBUTE: 为辅助存储引擎定义的约束属性。保留以供将来使用。

需要注意的是，这个表目前保留供将来使用，意味着这些列可能在将来的版本中填充实际的数据。当前版本中，这些属性可能不包含实际的表约束信息。

TABLE_PRIVILEGESTABLE_PRIVILEGES 表是 INFORMATION_SCHEMA 数据库中的一个表，它提供有关表权限的信息。这个表从 mysql.tables_priv 系统表中获取其值。

以下是 TABLE_PRIVILEGES 表中的一些关键列：

• GRANTEE: 授予权限的账户的名称，格式为 'user_name'@'host_name'。
• TABLE_CATALOG: 表所属目录的名称。在 MySQL 中，这个值总是 def。
• TABLE_SCHEMA: 表所属的模式（数据库）的名称。
• TABLE_NAME: 表的名称。
• PRIVILEGE_TYPE: 授予的权限类型，可以是任何可以在表级别授予的权限，如 SELECT、INSERT、UPDATE、DELETE 等。
• IS_GRANTABLE: 如果用户具有 GRANT OPTION 权限，则为 YES，否则为 NO。

要查询表权限，可以使用以下 SQL 语句：

SELECT * FROM INFORMATION_SCHEMA.TABLE_PRIVILEGES
WHERE TABLE_SCHEMA = 'your_database_name' AND TABLE_NAME = 'your_table_name';

将 your_database_name 和 your_table_name 替换为你要查询的数据库和表的名称。这将返回指定表的权限信息。

TABLE_PRIVILEGES 表对于数据库管理员在进行权限管理和审查时非常有用，可以帮助了解哪些用户或角色具有对特定表的访问权限。

TRIGGERS

TRIGGERS 表是 INFORMATION_SCHEMA 数据库中的一个表，它提供了数据库中所有触发器的详细信息。触发器是数据库对象，它们在指定的表上执行某些操作（如 INSERT、UPDATE 或 DELETE）时自动执行。

以下是 TRIGGERS 表中的一些关键列及其描述：

• TRIGGER_CATALOG: 触发器所属的数据库目录名称，对于 MySQL 通常是 def。
• TRIGGER_SCHEMA: 触发器所属的数据库（模式）的名称。
• TRIGGER_NAME: 触发器的名称。
• EVENT_MANIPULATION: 触发器响应的操作类型，如 INSERT、UPDATE 或 DELETE。
• EVENT_OBJECT_CATALOG: 触发器关联的表所在的目录。
• EVENT_OBJECT_SCHEMA: 触发器关联的表所属的数据库（模式）。
• EVENT_OBJECT_TABLE: 触发器关联的表的名称。
• ACTION_ORDER: 在多个触发器的情况下，定义触发器执行的顺序。
• ACTION_CONDITION: 触发器执行之前要检查的条件（如果有的话）。
• ACTION_STATEMENT: 触发器激活时执行的语句。
• ACTION_ORIENTATION: 触发器是针对 ROW（行）还是整个 STATEMENT（语句）。
• ACTION_TIMING: 触发器是在关联操作之前（BEFORE）还是之后（AFTER）执行。
• ACTION_REFERENCE_OLD_TABLE: 对于 UPDATE 或 DELETE 触发器，表示旧数据的引用。
• ACTION_REFERENCE_NEW_TABLE: 对于 INSERT 或 UPDATE 触发器，表示新数据的引用。
• ACTION_REFERENCE_OLD_ROW: 通常用于 UPDATE 或 DELETE 触发器，表示被修改或删除的旧行。
• ACTION_REFERENCE_NEW_ROW: 通常用于 INSERT 或 UPDATE 触发器，表示新插入或修改后的新行。
• CREATED: 触发器的创建时间。
• SQL_MODE: 在创建触发器时使用的 SQL 模式。
• DEFINER: 创建触发器的用户。

要查询 TRIGGERS 表，你可以使用以下 SQL 语句：

SELECT * FROM INFORMATION_SCHEMA.TRIGGERS
WHERE TRIGGER_SCHEMA = 'your_database_name';

将 your_database_name 替换为你要查询的数据库名称。这将返回指定数据库中所有触发器的详细信息。

触发器可以用于各种场景，如数据验证、数据审计、数据完整性、自动计算字段和日志记录等。它们是数据库系统中维护数据一致性和执行复杂业务逻辑的强大工具 。

USER_ATTRIBUTES

USER_ATTRIBUTES 表是 INFORMATION_SCHEMA 数据库中的一个表，从 MySQL 8.0.21 版本开始引入。这个表提供有关用户注释和用户属性的信息，这些信息来自 mysql.user 系统表。

以下是 USER_ATTRIBUTES 表中的一些关键列：

• USER: 属性列值应用的账户的用户名部分。
• HOST: 属性列值应用的账户的主机名部分。
• ATTRIBUTE: 属于 USER 和 HOST 列指定的账户的用户注释、用户属性或两者。该值以 JSON 对象表示法存储。属性显示与使用 CREATE USER 和 ALTER USER 语句设置的完全相同。

用户注释可以是任意文本，而用户属性是由一个或多个键值对组成的 JSON 对象，这些属性在创建或修改用户时通过 ATTRIBUTE 选项设置。这些属性可以包含任何有效的 JSON 对象表示法中的键值对，例如用户的手机号码、职位、国家等。

例如，要为用户设置属性，可以使用以下 SQL 语句：

CREATE USER 'username'@'host' IDENTIFIED BY 'password' ATTRIBUTE '{"fname": "firstname", "lname": "lastname", "phone": "1234567890"}';

要检索用户属性，可以使用以下查询：

SELECT ATTRIBUTE ->> '$.comment' AS Comment FROM INFORMATION_SCHEMA.USER_ATTRIBUTES WHERE USER='username' AND HOST='host';

在 MySQL 8.0.22 之前，任何人都可以访问 USER_ATTRIBUTES 表的内容。从 MySQL 8.0.22 开始，对表的访问受到限制，只有满足特定条件的用户才能访问，例如具有 CREATE USER 和 SYSTEM_USER 权限的用户。

这个表对于管理和检索用户相关的额外信息非常有用，尤其是在需要为用户存储额外数据时。

USER_PRIVILEGES

USER_PRIVILEGES 表是 INFORMATION_SCHEMA 数据库中的一个表，它提供有关全局权限的信息。这些权限是授予特定用户的，并且适用于整个 MySQL 服务器。这个表从 mysql.user 系统表中获取其值。

以下是 USER_PRIVILEGES 表中的一些关键列：

• GRANTEE: 授予权限的账户的名称，格式为 'user_name'@'host_name'。
• TABLE_CATALOG: 目录的名称，该值始终为 def。
• PRIVILEGE_TYPE: 授予的权限类型，例如 SELECT、INSERT、UPDATE、DELETE 等。
• IS_GRANTABLE: 如果用户有 GRANT OPTION 权限，则为 YES，否则为 NO。

要查询 USER_PRIVILEGES 表，你可以使用以下 SQL 语句：

SELECT * FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE GRANTEE = 'your_username' AND TABLE_CATALOG = 'def';

将 your_username 替换为你要查询的用户名。这将返回指定用户的全局权限信息。

USER_PRIVILEGES 表对于数据库管理员在进行权限管理和审查时非常有用，可以帮助了解哪些用户具有哪些全局权限。通过这个表，管理员可以确保数据库的安全性，并且可以对用户的权限进行适当的分配和限制 。

VIEWS

VIEWS 表是 INFORMATION_SCHEMA 数据库中的一个表，它提供有关数据库中定义的视图的信息。视图是基于 SQL 查询结果的虚拟表，它可以包含表的全部或部分记录。

以下是 INFORMATION_SCHEMA.VIEWS 表中的一些关键列：

• TABLE_CATALOG: 视图所属目录的名称，对于 MySQL，这个值总是 def。
• TABLE_SCHEMA: 视图所属的模式（数据库）的名称。
• TABLE_NAME: 视图的名称。
• VIEW_DEFINITION: 定义视图的 SELECT 语句。
• CHECK_OPTION: CHECK OPTION 属性的值，该值为 NONE、CASCADED 或 LOCAL。
• IS_UPDATABLE: 指示视图是否可更新的标志。如果 UPDATE、DELETE（以及类似操作）对于视图是合法的，则该标志设置为 YES。否则，该标志设置为 NO。
• DEFINER: 创建视图的用户的帐户。
• SQL_SECURITY: 视图的 SQL 安全性，值为 DEFINER 或 INVOKER。

要查询 VIEWS 表，你可以使用以下 SQL 语句：

SELECT * FROM INFORMATION_SCHEMA.VIEWS
WHERE TABLE_SCHEMA = 'your_database_name';

将 your_database_name 替换为你要查询的数据库名称。这将返回指定数据库中所有视图的详细信息。

视图可以用于多种目的，如简化复杂的 SQL 操作、提供数据的安全性、限制用户访问特定的数据行或列、以及实现数据的逻辑分组等。通过 VIEWS 表，可以快速了解数据库中视图的构成和定义，从而更好地管理和使用视图。

VIEW_ROUTINE_USAGE

VIEW_ROUTINE_USAGE 表是 INFORMATION_SCHEMA 数据库中的一个表，它提供了关于视图定义中使用的存储函数的信息。这个表不包括关于定义中使用的内置（本机）函数或可加载函数的信息。只有当你对视图和函数都有一定的权限时，你才能看到这些信息。

以下是 VIEW_ROUTINE_USAGE 表中的一些关键列：

• TABLE_CATALOG: 视图所属目录的名称，对于 MySQL 来说，这个值总是 def。
• TABLE_SCHEMA: 视图所属的模式（数据库）的名称。
• TABLE_NAME: 视图的名称。
• SPECIFIC_CATALOG: 视图定义中使用的函数所属目录的名称，这个值也总是 def。
• SPECIFIC_SCHEMA: 视图定义中使用的函数所属的模式（数据库）的名称。
• SPECIFIC_NAME: 视图定义中使用的函数的名称。

这个表对于查看和理解视图定义中使用的存储函数非常有用，尤其是在进行数据库设计和优化时。通过这个表，你可以了解视图依赖的函数，从而更好地管理和维护数据库的视图和函数。

VIEW_TABLE_USAGE

VIEW_TABLE_USAGE 表是 INFORMATION_SCHEMA 数据库中的一个表，它提供有关视图定义中使用的表和视图的信息。这个表从 MySQL 8.0.13 版本开始引入。通过这个表，用户可以查看视图所依赖的底层表或视图的详细信息。

以下是 VIEW_TABLE_USAGE 表中的一些关键列：

• VIEW_CATALOG: 视图所属目录的名称。该值始终为 def。
• VIEW_SCHEMA: 视图所属的模式（数据库）的名称。
• VIEW_NAME: 视图的名称。
• TABLE_CATALOG: 视图定义中使用的表或视图所属目录的名称。该值始终为 def。
• TABLE_SCHEMA: 视图定义中使用的表或视图所属的模式（数据库）的名称。
• TABLE_NAME: 视图定义中使用的表或视图的名称。

这个表对于数据库管理员和开发者在进行数据库设计和优化时非常有用，尤其是在需要了解视图依赖关系时。通过这个表，可以快速了解视图所依赖的表或视图，从而更好地管理和维护数据库的视图和表。

要查询 VIEW_TABLE_USAGE 表，你可以使用以下 SQL 语句：

SELECT * FROM INFORMATION_SCHEMA.VIEW_TABLE_USAGE
WHERE VIEW_SCHEMA = 'your_database_name';

将 your_database_name 替换为你要查询的数据库名称。这将返回指定数据库中所有视图所依赖的表或视图的信息。

这个表可以帮助用户理解视图的定义和它们如何与数据库中的其他表或视图相关联，从而在数据库设计和优化过程中做出更明智的决策 。