Mysql- (三)

1.3. MySQL 中的系统库

1.3.1. 系统库简介

以下系统库的介绍，主要是扩展大家的知识面，因为系统库中的数据很重要， 没有对 MySQL 有全面通盘的了解，不宜去操作其下的数据，而且对系统库的管 理维护是是 DBA 的职责。
MySQL 有几个系统数据库，这几个数据库包含了 MySQL 服务器运行过程中 所需的一些信息以及一些运行状态信息，我们现在稍微了解一下。
performance_schema
这个数据库里主要保存 MySQL 服务器运行过程中的一些状态信息，算是对 MySQL 服务器的一个性能监控。包括统计最近执行了哪些语句，在执行过程的每 个阶段都花费了多长时间，内存的使用情况等等信息。
sys
这个数据库主要是通过视图的形式把 information_schema 和 performance_schema 结合起来，让程序员可以更方便的了解 MySQL 服务器的一 些性能信息。
information_schema
这个数据库保存着 MySQL 服务器维护的所有其他数据库的信息，比如有哪 些表、哪些视图、哪些触发器、哪些列、哪些索引。这些信息并不是真实的用户 数据，而是一些描述性信息，有时候也称之为元数据。
mysql
这个数据库核心，它存储了 MySQL 的用户账户和权限信息，一些存储过程、 事件的定义信息，一些运行过程中产生的日志信息，一些帮助信息以及时区信息 等。

1.3.2. performance_schema

1.3.2.1. 什么是 performance_schema

MySQL 的 performance_schema 是运行在较低级别的用于监控 MySQL Server 运行过程中的资源消耗、资源等待等情况的一个功能特性，它具有以下特点。

• performance_schema 提供了一种在数据库运行时实时检查 Server 内部执 行情况的方法。performance_schema 数据库中的表使用 performance_schema 存 储引擎。该数据库主要关注数据库运行过程中的性能相关数据。
• performance_schema 通过监视 Server 的事件来实现监视其内部执行情况， “事件”就是在 Server 内部活动中所做的任何事情以及对应的时间消耗，利用这 些信息来判断 Server 中的相关资源被消耗在哪里。一般来说，事件可以是函数调 用、操作系统的等待、SQL 语句执行的阶段[如 SQL 语句执行过程中的 parsing（解 析）或 sorting（排序）阶段]或者整个 SQL 语句的集合。采集事件可以方便地提 供 Server 中的相关存储引擎对磁盘文件、表 I/O、表锁等资源的同步调用信息。
• 当前活跃事件、历史事件和事件摘要相关表中记录的信息，能提供某个 事件的执行次数、使用时长，进而可用于分析与某个特定线程、特定对象（如 mutex 或 file）相关联的活动。
• performance_schema 存储引擎使用 Server 源代码中的“检测点”来实现 事件数据的收集。对于 performance_schema 实现机制本身的代码没有相关的单 独线程来检测，这与其他功能（如复制或事件计划程序）不同。

收集到的事件数据被存储在 performance_schema 数据库的表中。对于这些 表可以使用 SELECT 语句查询，也可以使用 SQL 语句更新 performance_schema 数 据库中的表记录（比如动态修改 performance_schema 的以“setup_”开头的配 置表，但要注意，配置表的更改会立即生效，这会影响数据收集）。

• performance_schema 的表中数据不会持久化存储在磁盘中，而是保存在 内存中，一旦服务器重启，这些数据就会丢失（包括配置表在内的整个 performance_schema 下的所有数据）。

1.3.2.2. performance_schema 使用

通过上面介绍，相信你对于什么是 performance_schema 这个问题了解得更 清晰了。下面开始介绍 performance_schema 的使用。
检查当前数据库版本是否支持
performance_schema 被视为存储引擎，如果该引擎可用，则应该在 INFORMATION_SCHEMA.ENGINES 表或 show engines 语句的输出中可以看到 它的 Support 字段值为 YES，如下所示。

当我们看到 performance_schema 对应的 Support 字段值为 YES 时，就表示当 前的数据库版本是支持 performance_schema 的。但确认了数据库实例支持 performance_schema 存储引擎就可以使用了吗？NO，很遗憾， performance_schema 在 MySQL 5.6 及之前的版本中默认没有启用，在 MySQL 5.7 及之后的版本中才修改为默认启用。

启用 performance_schema 如果要显式启用或关闭 performance_schema，则需要使用参数 performance_schema=ON|OFF 来设置，并在 my.cnf 中进行配置。注意:该参数为 只读参数，需要在实例启动之前设置才生效

mysqld 启动之后，通过如下语句查看 performance_schema 启用是否生效（值 为 ON 表示 performance_schema 已初始化成功且可以使用了；值为 OFF 表示在 启用 performance_schema 时发生某些错误，可以查看错误日志进行排查）。

现在，可以通过查询 INFORMATION_SCHEMA.TABLES 表中与 performance_schema 存储引擎相关的元数据，或者在 performance_schema 库下 使用 show tables 语句来了解其存在哪些表。
使用 show tables 语句来查询有哪些 performance_schema 引擎表。


现在，我们知道了在当前版本中，performance_schema 库下一共有 87 个表， 那么这些表都用于存放什么数据呢？我们如何使用它们来查询数据呢？先 来看看这些表是如何分类的。
performance_schema 表的分类
performance_schema 库下的表可以按照监视的不同维度进行分组，例如： 按照不同的数据库对象进行分组、按照不同的事件类型进行分组，或者按照事件 类型分组之后，再进一步按照账号、主机、程序、线程、用户等进行细分。
下面介绍按照事件类型分组记录性能事件数据的表。

• 语句事件记录表：记录语句事件信息的表，包括： events_statements_current（当前语句事件表）、events_statements_history（历 史语句事件表）、events_statements_history_long（长语句历史事件表）以及一 些 summary 表（聚合后的摘要表）。其中，summary 表还可以根据账号（account）、 主机（host）、程序（program）、线程（thread）、用户（user）和全局（global） 再进行细分。
  show tables like ‘events_statement%’;
  
• 等待事件记录表：与语句事件记录表类似。
  show tables like ‘events_wait%’;
  
• 阶段事件记录表：记录语句执行阶段事件的表，与语句事件记录表类似。
  show tables like ‘events_stage%’;
  
• 事务事件记录表：记录与事务相关的事件的表，与语句事件记录表类似。
  show tables like ‘events_transaction%’;
  • 监视文件系统层调用的表：
  show tables like ‘%file%’;
  • 监视内存使用的表：
  show tables like ‘%memory%’;
  • 动态对 performance_schema 进行配置的配置表：
  show tables like ‘%setup%’;
  现在，我们已经大概知道了 performance_schema 中主要表的分类，但如何 使用这些表来提供性能事件数据呢？
  performance_schema

简单配置与使用 当数据库初始化完成并启动时，并非所有的 instruments（在采集配置项的 配置表中，每一项都有一个开关字段，或为 YES，或为 NO）和 consumers（与采 集配置项类似，也有一个对应的事件类型保存表配置项，为 YES 表示对应的表保 存性能数据，为 NO 表示对应的表不保存性能数据）都启用了，所以默认不会收 集所有的事件。

可能你想检测的事件并没有打开，需要进行设置。可以使用如下两条语句打 开对应的 instruments 和 consumers，我们以配置监测等待事件数据为例进行说明。

打开等待事件的采集器配置项开关，需要修改 setup_instruments 配置表中 对应的采集器配置项。
update setup_instruments set enabled=‘yes’,timed=‘yes’ where name like ‘wait%’;

打开等待事件的保存表配置项开关，修改 setup_consumers 配置表中对应的 配置项。
update setup_consumers set enabled=‘yes’ where name like ‘wait%’;

配置好之后，我们就可以查看 Server 当前正在做什么了。可以通过查询 events_waits_current 表来得知，该表中每个线程只包含一行数据，用于显示每个 线程的最新监视事件（正在做的事情）。

_current 表中每个线程只保留一条记录，且一旦线程完成工作，该表中就 不会再记录该线程的事件信息了。_history 表中记录每个线程已经执行完成的事 件信息，但每个线程的事件信息只记录 10 条，再多就会被覆盖掉。*_history_long 表中记录所有线程的事件信息，但总记录数量是 10000 行，超过会被覆盖掉。
summary 表提供所有事件的汇总信息。该组中的表以不同的方式汇总事件数 据（如：按用户、按主机、按线程等汇总）。
查看最近执行失败的 SQL 语句
使用代码对数据库的某些操作（比如：使用 Java 的 ORM 框架操作数据库） 报出语法错误，但是代码并没有记录 SQL 语句文本的功能，在 MySQL 数据库层 能否查看到具体的 SQL 语句文本，看看是否哪里写错了？这个时候，大多数人首 先想到的就是去查看错误日志。很遗憾，对于 SQL 语句的语法错误，错误日志并 不会记录。

实际上，在 performance_schema 的语句事件记录表中针对每一条语句的执 行状态都记录了较为详细的信息，例如：events_statements_表和 events_statements_summary_by_digest 表（events_statements_表记录了语句所有 的执行错误信息，而 events_statements_summary_by_digest 表只记录了语句在执 行过程中发生错误的语句记录统计信息，不记录具体的错误类型，例如：不记录 语法错误类的信息）。下面看看如何使用这两个表查询语句发生错误的语句信息。

首先，我们模拟一条语法错误的 SQL 语句，使用 events_statements_history_long 表或者 events_statements_history 表查询发生语 法错误的 SQL 语句：

然后，查询 events_statements_history 表中错误号为 1064 的记录 select * from events_statements_history where mysql_errno=1064\G

不知道错误号是多少，可以查询发生错误次数不为 0 的语句记录，在里边找 到 SQL_TEXT 和 MESSAGE_TEXT 字段（提示信息为语法错误的就是它）。

查看最近的事务执行信息
我们可以通过慢查询日志查询到一条语句的执行总时长，但是如果数据库中 存在着一些大事务在执行过程中回滚了，或者在执行过程中异常中止，这个时候 慢查询日志就爱莫能助了，这时我们可以借助 performance_schema 的 events_transactions_*表来查看与事务相关的记录，在这些表中详细记录了是否 有事务被回滚、活跃（长时间未提交的事务也属于活跃事务）或已提交等信息。
首先需要进行配置启用，事务事件默认并未启用
update setup_instruments set enabled=‘yes’,timed=‘yes’ where name like ‘transaction%’;
update setup_consumers set enabled=‘yes’ where name like ‘%transaction%’;

开启一个新会话（会话 2）用于执行事务，并模拟事务回滚。

查询活跃事务，活跃事务表示当前正在执行的事务事件，需要从 events_transactions_current 表中查询。

会话 2 中回滚事务：

查询事务事件当前表和事务事件历史记录表，可以看到在两表中都记录了一 行事务事件信息，线程ID为49的线程执行了一个事务，事务状态为ROLLED BACK。

但是当我们关闭会话 2 以后，事务事件当前表中的记录就消失了。

小结
当然 performance_schema 的用途不止我们上面说到过的这些，它还能提供 比如查看 SQL 语句执行阶段和进度信息、MySQL 集群下复制功能查看复制报错 详情等等，更多的功能请大家自行挖掘，并欢迎大家以文章的形式发表在大家共 有的 VIP 论坛 http://bbs.xiangxueketang.cn/article/article 上。

1.3.3. sys 系统库

1.3.3.1. sys 使用须知

sys 系统库通常都是提供给专业的 DBA 人员排查一些特定问题使用的，其下 所涉及的各项查询或多或少都会对性能有一定的影响。所以这个库的配置、触发 器等等我们都不做学习。
同时在使用上：
sys 系统库支持 MySQL 5.6 或更高版本，不支持 MySQL 5.5.x 及以下版本。 因为 sys 系统库提供了一些代替直接访问 performance_schema 的视图，所 以必须启用 performance_schema（将 performance_schema 系统参数设置为 ON）， sys 系统库的大部分功能才能正常使用。

同时要完全访问 sys 系统库，用户必须具有以下数据库的管理员权限。
如果要充分使用 sys 系统库的功能，则必须启用某些 performance_schema 的功能。当然 sys 系统库本身已经提供了启用所有需要的功能的存储过程，比如：
启用所有的 wait instruments：
CALL sys.ps_setup_enable_instrument(‘wait’);

启用所有事件类型的 current 表： CALL sys.ps_setup_enable_consumer(‘current’); 注意：performance_schema 的默认配置就可以满足 sys 系统库的大部分数据 收集功能。启用所有需要功能会对性能产生一定的影响，因此最好仅启用所需的 配置。

1.3.3.2. sys 系统库使用

如果使用了 USE 语句切换默认数据库，那么就可以直接使用 sys 系统库下的 视图进行查询，就像查询某个库下的表一样操作。也可以使用 b_name.view_name、 db_name.procedure_name、db_name.func_name 等方式，在不指定默认数据库的 情况下访问 sys 系统库中的对象（这叫作名称限定对象引用）。

在 sys 系统库下包含很多视图，它们以各种方式对 performance_schema 表 进行聚合计算展示。这些视图大部分是成对出现的，两个视图名称相同，但有一 个视图是带“x$”前缀的，例如：hos{t}_{s}ummar{y}_b{y}_{f}il{e}_{i}o和x$host_summary_by_file_io，代表按照主机进行汇总统计的文件 I/O 性能数据， 两个视图访问的数据源是相同的，但是在创建视图的语句中，不带“x$”前缀的视图显示的是相关数值经过单位换算后的数据（单位是毫秒、秒、分钟、小时、天等），带“x$”前缀的视图显示的是原始的数据（单位是皮秒）。

查看慢 SQL 语句慢在哪里
如果我们频繁地在慢查询日志中发现某个语句执行缓慢，且在表结构、索引 结构、统计信息中都无法找出原因时，则可以利用 sys 系统库中的撒手锏： sys.session 视图结合 performance_schema 的等待事件来找出症结所在。那么 session 视图有什么用呢？使用它可以查看当前用户会话的进程列表信息，看看 当前进程到底再干什么，注意，这个视图在 MySQL 5.7.9 中才出现。
首先需要启用与等待事件相关功能：

call sys.ps_setup_enable_instrument(‘wait’);
call sys.ps_setup_enable_consumer(‘wait’);
然后模拟一下：


查询表的增、删、改、查数据量和 I/O 耗时统计
select * from schema_table_statistics_with_buffer\G

小结 除此之外，通过 sys 还可以查询查看 InnoDB 缓冲池中的热点数据、查看是 否有事务锁等待、查看未使用的，冗余索引、查看哪些语句使用了全表扫描等等。 更多的功能请大家自行挖掘，并欢迎大家以文章的形式发表在大家共有的 VIP 论坛 http://bbs.xiangxueketang.cn/article/article 上。

1.3.4. information_schema

1.3.4.1. 什么是 information_schema

information_schema 提供了对数据库元数据、统计信息以及有关 MySQL Server 信息的访问（例如：数据库名或表名、字段的数据类型和访问权限等）。 该库中保存的信息也可以称为 MySQL 的数据字典或系统目录。
在每个MySQL 实例中都有一个独立的information_schema，用来存储MySQL 实例中所有其他数据库的基本信息。information_schema 库下包含多个只读表（非 持久表），所以在磁盘中的数据目录下没有对应的关联文件，且不能对这些表设 置触发器。虽然在查询时可以使用 USE 语句将默认数据库设置为 information_schema，但该库下的所有表是只读的，不能执行 INSERT、UPDATE、 DELETE 等数据变更操作。
针对 information_schema 下的表的查询操作可以替代一些 SHOW 查询语句 （例如：SHOW DATABASES、SHOW TABLES 等）。

注意：根据 MySQL 版本的不同，表的个数和存放是有所不同的。在 MySQL 5.6 版本中总共有 59 个表，在 MySQL 5.7 版本中，该 schema 下总共有 61 个表，

在 MySQL 8.0 版本中，该 schema 下的数据字典表（包含部分原 Memory 引 擎临时表）都迁移到了 mysql schema 下，且在 mysql schema 下这些数据字典表 被隐藏，无法直接访问，需要通过 information_schema 下的同名表进行访问。

information_schema 下的所有表使用的都是 Memory 和 InnoDB 存储引擎， 且都是临时表，不是持久表，在数据库重启之后这些数据会丢失。在 MySQL 的 4 个系统库中，information_schema 也是唯一一个在文件系统上没有对应库表的 目录和文件的系统库。

1.3.4.2. information_schema 表分类

Server 层的统计信息字典表

（1）COLUMNS
• 提供查询表中的列（字段）信息。
（2）KEY_COLUMN_USAGE
• 提供查询哪些索引列存在约束条件。
该表中的信息包含主键、唯一索引、外键等约束信息，例如：所在的库 表列名、引用的库表列名等。该表中的信息与 TABLE_CONSTRAINTS 表中记录的 信息有些类似，但 TABLE_CONSTRAINTS 表中没有记录约束引用的库表列信息，
而 KEY_COLUMN_USAGE 表中却记录了 TABLE_CONSTRAINTS 表中所没有的约束类 型。
（3）REFERENTIAL_CONSTRAINTS
• 提供查询关于外键约束的一些信息。
（4）STATISTICS • 提供查询关于索引的一些统计信息，一个索引对应一行记录。
（5）TABLE_CONSTRAINTS
• 提供查询与表相关的约束信息。
（6）FILES
• 提供查询与 MySQL 的数据表空间文件相关的信息。
（7）ENGINES
• 提供查询 MySQL Server 支持的引擎相关信息。
（8）TABLESPACES
• 提供查询关于活跃表空间的相关信息（主要记录的是 NDB 存储引擎的表 空间信息）。
• 注意：该表不提供有关 InnoDB 存储引擎的表空间信息。对于 InnoDB 表 空间的元数据信息，请查询 INNODB_SYS_TABLESPACES 表和 INNODB_SYS_DATAFILES 表。另外，从 MySQL 5.7.8 开始， INFORMATION_SCHEMA.FILES 表也提供查询 InnoDB 表空间的元数据信息。
（9）SCHEMATA
• 提供查询 MySQL Server 中的数据库列表信息，一个 schema 就代表一个 数据库。
Server 层的表级别对象字典表
（1）VIEWS
• 提供查询数据库中的视图相关信息。查询该表的账户需要拥有 show view 权限。
（2）TRIGGERS
• 提供查询关于某个数据库下的触发器相关信息。
（3）TABLES
• 提供查询与数据库内的表相关的基本信息。
（4）ROUTINES
• 提供查询关于存储过程和存储函数的信息（不包括用户自定义函数）。 该表中的信息与 mysql.proc 中记录的信息相对应（如果该表中有值的话）。
（5）PARTITIONS
• 提供查询关于分区表的信息。
（6）EVENTS
• 提供查询与计划任务事件相关的信息。
（7）PARAMETERS
• 提供有关存储过程和函数的参数信息，以及有关存储函数的返回值信息。 这些参数信息与 mysql.proc 表中的 param_list 列记录的内容类似。
Server 层的混杂信息字典表
（1）GLOBAL_STATUS、GLOBAL_VARIABLES、SESSION_STATUS、 SESSION_VARIABLES
• 提供查询全局、会话级别的状态变量与系统变量信息。
（2）OPTIMIZER_TRACE • 提供优化程序跟踪功能产生的信息。
• 跟踪功能默认是关闭的，使用 optimizer_trace 系统变量启用跟踪功能。 如果开启该功能，则每个会话只能跟踪它自己执行的语句，不能看到其他会话执 行的语句，且每个会话只能记录最后一条跟踪的 SQL 语句。
（3）PLUGINS
• 提供查询关于 MySQL Server 支持哪些插件的信息。
（4）PROCESSLIST
• 提供查询一些关于线程运行过程中的状态信息。
（5）PROFILING
• 提供查询关于语句性能分析的信息。其记录内容对应于 SHOW PROFILES 和 SHOW PROFILE 语句产生的信息。该表只有在会话变量 profiling=1 时才会记录 语句性能分析信息，否则该表不记录。
• 注意：从 MySQL 5.7.2 开始，此表不再推荐使用，在未来的 MySQL 版本 中删除，改用 Performance Schema 代替。
（6）CHARACTER_SETS
• 提供查询 MySQL Server 支持的可用字符集。
（7）COLLATIONS
• 提供查询 MySQL Server 支持的可用校对规则。
（8）COLLATION_CHARACTER_SET_APPLICABILITY
• 提供查询 MySQL Server 中哪种字符集适用于什么校对规则。查询结果集 相当于从 SHOW COLLATION 获得的结果集的前两个字段值。目前并没有发现该表 有太大的作用。
（9）COLUMN_PRIVILEGES • 提供查询关于列（字段）的权限信息，表中的内容来自 mysql.column_priv 列权限表（需要针对一个表的列单独授权之后才会有内容）。
（10）SCHEMA_PRIVILEGES • 提供查询关于库级别的权限信息，每种类型的库级别权限记录一行信息， 该表中的信息来自 mysql.db 表。
（11）TABLE_PRIVILEGES
• 提供查询关于表级别的权限信息，该表中的内容来自 mysql.tables_priv 表。
（12）USER_PRIVILEGES • 提供查询全局权限的信息，该表中的信息来自 mysql.user 表。
10.2.4 InnoDB 层的系统字典表
（1）INNODB_SYS_DATAFILES
• 提供查询 InnoDB 所有表空间类型文件的元数据（内部使用的表空间 ID 和表空间文件的路径信息），包括独立表空间、常规表空间、系统表空间、临时 表空间和 undo 空间（如果开启了独立 undo 空间的话）。
• 该表中的信息等同于 InnoDB 数据字典内部 SYS_DATAFILES 表的信息。
（2）INNODB_SYS_VIRTUAL
• 提供查询有关 InnoDB 虚拟生成列和与之关联的列的元数据信息，等同于 InnoDB 数据字典内部 SYS_VIRTUAL 表的信息。该表中展示的行信息是与虚拟生 成列相关联列的每个列的信息。 （3）INNODB_SYS_INDEXES
• 提供查询有关 InnoDB 索引的元数据信息，等同于 InnoDB 数据字典内部 SYS_INDEXES 表中的信息。
（4）INNODB_SYS_TABLES
• 提供查询有关 InnoDB 表的元数据信息，等同于 InnoDB 数据字典内部 SYS_TABLES 表的信息。
（5）INNODB_SYS_FIELDS
• 提供查询有关 InnoDB 索引键列（字段）的元数据信息，等同于 InnoDB 数据字典内部 SYS_FIELDS 表的信息。
（6）INNODB_SYS_TABLESPACES
• 提供查询有关 InnoDB 独立表空间和普通表空间的元数据信息（也包含了 全文索引表空间），等同于 InnoDB 数据字典内部 SYS_TABLESPACES 表的信息。
（7）INNODB_SYS_FOREIGN_COLS
• 提供查询有关 InnoDB 外键列的状态信息，等同于 InnoDB 数据字典内部 SYS_FOREIGN_COLS 表的信息。
（8）INNODB_SYS_COLUMNS • 提供查询有关 InnoDB 表列的元数据信息，等同于 InnoDB 数据字典内部 SYS_COLUMNS 表的信息。
（9）INNODB_SYS_FOREIGN • 提供查询有关 InnoDB 外键的元数据信息，等同于 InnoDB 数据字典内部 SYS_FOREIGN 表的信息。
（10）INNODB_SYS_TABLESTATS • 提供查询有关 InnoDB 表的较低级别的状态信息视图。 MySQL 优化器会 使用这些统计信息数据来计算并确定在查询 InnoDB 表时要使用哪个索引。这些
信息保存在内存中的数据结构中，与存储在磁盘上的数据无对应关系。在 InnoDB 内部也无对应的系统表。
InnoDB 层的锁、事务、统计信息字典表
（1）INNODB_LOCKS
• 提供查询 InnoDB 引擎中事务正在请求的且同时被其他事务阻塞的锁信 息（即没有发生不同事务之间锁等待的锁信息，在这里是查看不到的。例如，当 只有一个事务时，无法查看到该事务所加的锁信息）。该表中的内容可用于诊断 高并发下的锁争用信息。
（2）INNODB_TRX
• 提供查询当前在 InnoDB 引擎中执行的每个事务（不包括只读事务）的信 息，包括事务是否正在等待锁、事务什么时间点开始，以及事务正在执行的 SQL 语句文本信息等（如果有 SQL 语句的话）。
（3）INNODB_BUFFER_PAGE_LRU
• 提供查询缓冲池中的页面信息。与 INNODB_BUFFER_PAGE 表不同， INNODB_BUFFER_PAGE_LRU表保存有关InnoDB缓冲池中的页如何进入LRU链表， 以及在缓冲池不够用时确定需要从中逐出哪些页的信息。
（4）INNODB_LOCK_WAITS
• 提供查询 InnoDB 事务的锁等待信息。如果查询该表为空，则表示无锁等 待信息；如果查询该表中有记录，则说明存在锁等待，表中的每一行记录表示一 个锁等待关系。在一个锁等待关系中包含：一个等待锁（即，正在请求获得锁） 的事务及其正在等待的锁等信息、一个持有锁（这里指的是发生锁等待事务正在 请求的锁）的事务及其所持有的锁等信息。
（5）INNODB_TEMP_TABLE_INFO
• 提供查询有关在 InnoDB 实例中当前处于活动状态的用户（只对已建立连 接的用户有效，断开的用户连接对应的临时表会被自动删除）创建的 InnoDB 临 时表的信息。它不提供查询优化器使用的内部 InnoDB 临时表的信息。该表在首 次查询时创建。
（6）INNODB_BUFFER_PAGE
• 提供查询关于缓冲池中的页相关信息。
（7）INNODB_METRICS
• 提供查询 InnoDB 更为详细的性能信息，是对 InnoDB 的 performance_schema 的补充。通过对该表的查询，可用于检查 InnoDB 的整体健 康状况，也可用于诊断性能瓶颈、资源短缺和应用程序的问题等。
（8）INNODB_BUFFER_POOL_STATS
• 提供查询一些 InnoDB 缓冲池中的状态信息，该表中记录的信息与 SHOW ENGINEINNODB STATUS 语句输出的缓冲池统计部分信息类似。另外，InnoDB 缓 冲池的一些状态变量也提供了部分相同的值.
InnoDB 层的全文索引字典表
（1）INNODB_FT_CONFIG
（2）INNODB_FT_BEING_DELETED
（3）INNODB_FT_DELETED
（4）INNODB_FT_DEFAULT_STOPWORD
（5）INNODB_FT_INDEX_TABLE
InnoDB 层的压缩相关字典表
（1）INNODB_CMP 和 INNODB_CMP_RESET
• 这两个表中的数据包含了与压缩的 InnoDB 表页有关的操作状态信息。表 中记录的数据为测量数据库中的 InnoDB 表压缩的有效性提供参考。
（2）INNODB_CMP_PER_INDEX 和 INNODB_CMP_PER_INDEX_RESET
• 这两个表中记录了与 InnoDB 压缩表数据和索引相关的操作状态信息，对 数据库、表、索引的每个组合使用不同的统计信息，以便为评估特定表的压缩性 能和实用性提供参考数据。
（3）INNODB_CMPMEM 和 INNODB_CMPMEM_RESET
• 这两个表中记录了 InnoDB 缓冲池中压缩页的状态信息，为测量数据库中 InnoDB 表压缩的有效性提供参考。

1.3.4.3. information_schema 应用

查看索引列的信息
INNODB_SYS_FIELDS 表提供查询有关 InnoDB 索引列（字段）的元数据信息， 等同于 InnoDB 数据字典中 SYS_FIELDS 表的信息。
INNODB_SYS_INDEXES 表提供查询有关 InnoDB 索引的元数据信息，等同于 InnoDB 数据字典内部 SYS_INDEXES 表中的信息。
INNODB_SYS_TABLES 表提供查询有关 InnoDB 表的元数据信息，等同于 InnoDB 数据字典中 SYS_TABLES 表的信息。 假设需要查询 mysqladv 库下的 InnoDB 表 order_exp 的索引列名称、组成和 索引列顺序等相关信息。

则可以使用如下 SQL 语句进行查询
select t.name as d_t_name,i.name as i_name ,i.type as i_type,i.N_FIELDS as i_column_numbers,f.name as i_column_name,f.pos as i_position from INNODB_SYS_TABLES as t join INNODB_SYS_INDEXES as i on t.TABLE_ID=i.TABLE_ID left join INNODB_SYS_FIELDS as f on i.INDEX_ID=f.INDEX_ID where t.name=‘mysqladv/order_exp’;

结果中的列都很好理解，唯一需要解释的是 i_type(INNODB_SYS_INDEXES.type)，它是表示索引类型的数字 ID，0 =二级索引、 1=集群索引、2 =唯一索引、3 =主键索引、32 =全文索引、64 =空间索引、128 = 包含虚拟生成列的二级索引。