五、MySQL 中的系统库 - 1.performance_schema - 《MySQL》

performance_schema 使用
- 启用 performance_schema
performance_schema 表的分类
performance_schema 简单配置与使用

MySQL 的 performanceschema 是运行在较低级别的用于监控 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 下的所有数据）。

performance_schema 使用

检查当前数据库版本是否支持
performance_schema 被视为存储引擎，如果该引擎可用，则应该在 INFORMATION_SCHEMA.ENGINES 表或 show engines 语句的输出中可以看到
它的 Support 字段值为 YES。

performance_schema 在 MySQL 5.6 及之前的版本中默认没有启用，在 MySQL 5.7 及之后的版本中才修改为默认启用。 :::tips

启用 performance_schema

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

show VARIABLES like 'performance_schema'

查看 performance_schema 启用是否生效(值为ON 表示 performance_schema 已初始化成功且可以使用了;值为 OFF 表示在启用 performance_schema 时发生某些错误，可以查看错误日志进行排查)。
现在，可以通过查询 INFORMATION_SCHEMA.TABLES 表中与 performance_schema 存储引擎相关的元数据，或者在 performance_schema 库下使用 show tables 语句来了解其存在哪些表。
使用 show tables 语句来查询有哪些 performance_schema 引擎表。

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 简单配置与使用

当数据库初始化完成并启动时，并非所有的 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 表提供所有事件的汇总信息。该组中的表以不同的方式汇总事件数据(如:按用户、按主机、按线程等汇总)。