MySQL——O2. MySQL 中的系统库

performance_schema
这个数据库里主要保存 MySQL 服务器运行过程中的一些状态信息，是对 MySQL 服务器的一个性能监控。包括统计最近执行了哪些语句，在执行过程的每个阶段都花费了多长时间，内存的使用情况等等信息。
information_schema
这个数据库保存着 MySQL 服务器维护的所有其他数据库的信息，比如有哪些表、哪些视图、哪些触发器、哪些列、哪些索引。这些信息并不是真实的用户数据，而是一些描述性信息，有时候也称之为元数据。
sys
这个数据库主要是通过视图的形式把 information_schema 和 performance_schema 结合起来，可以更方便的了解 MySQL 服务器的一些性能信息。
mysql
存储了 MySQL 的用户账户和权限信息，一些存储过程、事件的定义信息，一些运行过程中产生的日志信息，一些帮助信息以及时区信息
等。

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.1 performance_schema 使用

1.1.1 检查当前数据库版本是否支持 performance_schema

performance_schema 同时被视为存储引擎。如果该引擎可用，则应该在 INFORMATION_SCHEMA.ENGINES 表或 show engines 语句的输出中可以看到它的 Support 字段值为 YES，如下所示。

performance_schema 对应的 Support 字段值为 YES，表示当前的数据库版本支持 performance_schema。但是 performance_schema 存储引擎在 MySQL 5.6 及之前的版本中默认没有启用，在 MySQL 5.7 及之后的版本中才修改为默认启用。
显式启用或关闭 performance_schema，则需要使用参数 performance_schema=ON|OFF 设置，并在 my.cnf 中进行配置。
mysqld 启动之后，通过如下语句查看 performance_schema 启用是否生效（值为 ON 表示 performance_schema 已初始化成功且可以使用了；值为 OFF 表示在启用 performance_schema 时发生某些错误，可以查看错误日志进行排查）。

1.1.2 查看 performance_schema 中的表

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

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_transaction%';
监视文件系统层调用的表。show tables like '%file%';
监视内存使用的表。show tables like '%memory%';
动态对 performance_schema 进行配置的配置表。show tables like '%setup%';

*_current 表中每个线程只保留一条记录，且一旦线程完成工作，该表中就不会再记录该线程的事件信息了。
*_history 表中记录每个线程已经执行完成的事件信息，但每个线程的事件信息只记录 10 条，再多就会被覆盖掉。
*_history_long 表中记录所有线程的事件信息，但总记录数量是 10000 行，超过会被覆盖掉。
summary 表提供所有事件的汇总信息。该组中的表以不同的方式汇总事件数据（如：按用户、按主机、按线程等汇总）。

1.1.3 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 表来得知，该表中每个线程只包含一行数据，用于显示每个线程的最新监视事件（正在做的事情）。

1.1.4 查看最近执行失败的 SQL 语句

使用代码对数据库的某些操作（如：使用 Java 的 ORM 框架操作数据库）报出语法错误，但是代码并没有记录 SQL 语句文本的功能，在 MySQL 数据库层能否查看到具体的 SQL 语句文本，看看是否哪里写错了？对于 SQL 语句的语法错误，MySQL 错误日志并不会记录。
实际上，在 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 字段（提示信息为语法错误的就是它）。

1.1.5 查看最近的事务执行信息

我们可以通过慢查询日志查询到一条语句的执行总时长，但是如果数据库中存在着一些大事务在执行过程中回滚了，或者在执行过程中异常中止，这个时候慢查询日志就爱莫能助了，这时我们可以借助 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%';

开启一个新会话用于执行事务，并模拟事务回滚：

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

回滚事务：

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

关闭会话后，事务事件当前表中的记录就消失了：

当然 performance_schema 的用途不止我们上面说到过的这些，它还能提供比如查看 SQL 语句执行阶段和进度信息、MySQL 集群下复制功能查看复制报错详情等等。

2. 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 也是唯一一个在文件系统上没有对应库表的目录和文件的系统库。

2.1 information_schema 表分类

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

2.2 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 = 包含虚拟生成列的二级索引。

3. sys 系统库

sys 系统库通常都是提供给专业的 DBA 人员排查一些特定问题使用的，其下所涉及的各项查询或多或少都会对性能有一定的影响。
sys 系统库支持 MySQL 5.6 或更高版本，不支持 MySQL 5.5.x 及以下版本。
因为 sys 系统库提供了一些代替直接访问 performance_schema 的视图，所以必须启用 performance_schema（将 performance_schema 系统参数设置为 ON），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 系统库的大部分数据收集功能。启用所有需要功能会对性能产生一定的影响，因此最好仅启用所需的配置。

3.1 sys 系统库使用

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

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

3.1.1 查看慢 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');

然后模拟一下：

3.1.2 查询表的增、删、改、查数据量和 I/O 耗时统计

select * from schema_table_statistics_with_buffer\G

除此之外，通过 sys 还可以查询查看 InnoDB 缓冲池中的热点数据、查看是否有事务锁等待、查看未使用的冗余索引、查看哪些语句使用了全表扫描等等。

4. mysql 系统库

4.1 权限系统表

MySQL 访问权限系统表，放在 mysql 库中，主要包含如下几个表：

user：包含用户账户、全局权限和其他非权限列表（安全配置字段和资源控制字段）。
db：数据库级别的权限表。该表中记录的权限信息代表用户是否可以使用这些权限来访问被授予访问的数据库下的所有对象（表或存储程序）。
tables_priv：表级别的权限表。
columns_priv：字段级别的权限表。
procs_priv：存储过程和函数权限表。
proxies_priv：代理用户权限表。
要更改权限表的内容，应该使用账号管理语句（如：CREATE USER、GRANT、REVOKE 等）来间接修改，不建议直接使用 DML 语句修改权限表。

4.2 统计信息表

持久化统计功能是通过将内存中的统计数据存储到磁盘中，使其在数据库重启时可以快速重新读入这些统计信息而不用重新执行统计，从而使得查询优化器可以利用这些持久化的统计信息准确地选择执行计划（如果没有这些持久化的统计信息，那么数据库重启之后内存中的统计信息将会丢失，下一次访问到某库某表时，需要重新计算统计信息，并且重新计算可能会因为估算值的差异导致查询计划发生变更，从而导致查询性能发生变化）。
当 innodb_stats_persistent = ON 时全局开启统计信息的持久化功能，默认是开启的：

show variables like 'innodb_stats_persistent';

如果要单独关闭某个表的持久化统计功能，则可以通过 ALTER TABLE tbl_name STATS_ PERSISTENT = 0 语句来修改。

innodb_table_stats 表提供查询与表数据相关的统计信息。

select * from innodb_table_stats where table_name = 'order_exp'\G

database_name：数据库名称。
table_name：表名、分区名或子分区名。
last_update：表示 InnoDB 上次更新统计信息行的时间。
n_rows：表中的估算数据记录行数。
clustered_index_size：主键索引的大小，以页为单位的估算数值。
sum_of_other_index_sizes：其他（非主键）索引的总大小，以页为单位的估算数值。

innodb_index_stats 表提供查询与索引相关的统计信息。

select * from innodb_index_stats where table_name = 'order_exp';

表字段含义如下：

database_name：数据库名称。
table_name：表名、分区表名、子分区表名。
index_name：索引名称。
last_update：表示 InnoDB 上次更新统计信息行的时间。
stat_name：统计信息名称，其对应的统计信息值保存在 stat_value 字段中。
stat_value：保存统计信息名称 stat_name 字段对应的统计信息值。
sample_size：stat_value 字段中提供的统计信息估计值的采样页数。
stat_description：统计信息名称 stat_name 字段中指定的统计信息的说明。

stat_name 字段一共有如下几个统计值：

size：当 stat_name 字段为 size 值时，stat_value 字段值表示索引中的总页数量。
n_leaf_pages：当 stat_name 字段为 n_leaf_pages 值时，stat_value 字段值表示索引叶子页的数量。
n_diff_pfxNN：NN 代表数字（例如 01、02 等）。当 stat_name 字段为 n_diff_pfxNN 值时，stat_value 字段值表示索引的 first column（即索引的最前索引列，从索引定义顺序的第一个列开始）列的唯一值数量。例如：当 NN 为 01 时，stat_value 字段值就表示索引的第一个列的唯一值数量；当 NN 为 02 时，stat_value 字段值就表示索引的第一个和第二个列组合的唯一值数量，依此类推。此外，在 stat_name = n_diff_pfxNN 的情况下，stat_description 字段显示一个以逗号分隔的计算索引统计信息字段的列表。

4.3 日志记录表

MySQL 的日志系统包含：普通查询日志、慢查询日志、错误日志（记录服务器启动时、运行中、停止时的错误信息）、二进制日志（记录服务器运行过程中数据变更的逻辑日志）、中继日志（记录从库 I/O 线程从主库获取的主库数据变更日志）、DDL 日志（记录 DDL 语句执行时的元数据变更信息。在 MySQL 5.7 中只支持写入文件中，在 MySQL 8.0 中支持写入 innodb_ddl_log 表中）。
在 MySQL5.7 中，只有普通查询日志、慢查询日志支持写入表中（也支持写入文件中），可以通过 log_output=TABLE 设置保存到 mysql.general_log 表和 mysql.slow_log 表中，其他日志类型在 MySQL 5.7 中只支持写入文件中。

general_log 表提供查询普通 SQL 语句的执行记录信息，用于查看客户端到底在服务器上执行了什么 SQL 语句。缺省不开启。

show variables like 'general_log';

开启：

set global log_output='TABLE'; -- 'TABLE,FILE'表示同时输出到表和文件
set global general_log=on;
show variables like 'general_log';

任意执行一个查询后：

select * from mysql.general_log\G

slow_log 表提供查询执行时间超过 long_query_time 设置值的 SQL 语句、未使用索引的语句（需要开启参数 log_queries_not_using_indexes=ON）或者管理语句（需要开启参数 log_slow_admin_statements=ON）。

4.4 复制信息表

复制信息表在从库复制主库的数据期间，用于保存从主库转发到从库的 binlog（二进制日志）事件，记录有关 relay log（中继日志）当前状态和位置的信息。

master.info 文件或者 mysql.slave_master_info 表：用于保存从库的 I/O 线程连接主库的连接状态、账号、IP 地址、端口、密码，以及 I/O 线程当前读取主库 binlog 的文件和位置信息（称为 I/O 线程信息日志）。在默认情况下，I/O 线程的连接信息和状态保存在 master.info 文件中（默认位置在 datadir 下，可以使用 master_info_file 参数指定 master.info 文件路径。注：在 MySQL 5.7.x 较新的版本以及 8.0.x 版本中该参数已经被移除）。如果需要保存在 mysql.slave_master_info 表中，则需要在服务器启动之前设置 master_info_repository=TABLE。

relay_log.info 文件或者 mysql.slave_relay_log_info 表：当从库的 I/O 线程从主库获取到最新的 binlog 事件信息后会先写入从库本地的 relay log 中，然后SQL 线程再去读取 relay log 解析并重放。relay_log.info 文件或者 mysql.slave_relay_log_info 表就是用于记录最新的 relay log 的文件和位置，以及SQL 线程当前重放的事件对应的主库 binlog 的文件和位置信息的（SQL 线程位置被称为 SQL 线程信息日志）。在默认情况下，relay log 的位置信息和 SQL 线程的位置信息保存在 relay-log.info 文件中（默认位置在 datadir 下，可以使用 relay_log_info_file 选项指定 relay-log.info 文件路径）。如果需要保存在 mysql.slave_relay_log_info 表中，则需要在服务器启动之前设置 relay_log_info_repository=TABLE。