MySQL8-中文参考-四十九-

MySQL8 中文参考（四十九）

原文：docs.oracle.com/javase/tutorial/reallybigindex.html

29.12.16 性能模式线程池表

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-thread-pool-tables.html

29.12.16.1 线程组状态表

29.12.16.2 线程组统计表

29.12.16.3 线程状态表

注意

此处描述的性能模式表自 MySQL 8.0.14 版本起可用。在 MySQL 8.0.14 之前，请改用相应的INFORMATION_SCHEMA表；请参阅第 28.5 节，“INFORMATION_SCHEMA 线程池表”。

以下部分描述了与线程池插件相关的性能模式表（参见第 7.6.3 节，“MySQL 企业线程池”）。它们提供有关线程池操作的信息：

  • tp_thread_group_state：关于线程池线程组状态的信息。

  • tp_thread_group_stats：线程组统计信息。

  • tp_thread_state：关于线程池线程状态的信息。

这些表中的行代表时间的快照。在tp_thread_state的情况下，线程组的所有行组成一个时间快照。因此，MySQL 服务器在生成快照时持有线程组的互斥锁。但它不会同时持有所有线程组的互斥锁，以防止针对tp_thread_state的语句阻塞整个 MySQL 服务器。

性能模式线程池表由线程池插件实现，并在加载和卸载该插件时加载和卸载（参见第 7.6.3.2 节，“线程池安装”）。表不需要特殊配置步骤。但是，表依赖于启用线程池插件。如果加载了线程池插件但未启用，则不会创建表。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-tp-thread-group-state-table.html

29.12.16.1 The tp_thread_group_state Table

注意

此处描述的性能模式表在 MySQL 8.0.14 版本中可用。在 MySQL 8.0.14 之前，请改用相应的 INFORMATION_SCHEMA 表；参见 Section 28.5.2, “The INFORMATION_SCHEMA TP_THREAD_GROUP_STATE Table”。

tp_thread_group_state 表中每个线程组都有一行。每行提供有关组的当前状态的信息。

tp_thread_group_state 表具有以下列：

  • TP_GROUP_ID

    线程组 ID。这是表中的唯一键。

  • CONSUMER THREADS

    消费者线程的数量。如果活动线程变得停滞或阻塞，最多有一个线程准备开始执行。

  • RESERVE_THREADS

    保留状态中的线程数。这意味着直到需要唤醒新线程且没有消费者线程时才会启动它们。当线程组创建的线程多于正常操作所需的线程时，大多数线程都会进入此状态。通常，线程组需要额外的线程一小段时间，然后一段时间内不再需要它们。在这种情况下，它们进入保留状态，并保持直到再次需要。它们占用一些��外的内存资源，但不占用额外的计算资源。

  • CONNECT_THREAD_COUNT

    处理或等待处理连接初始化和身份验证的线程数。每个线程组最多可以有四个连接线程；这些线程在一段不活动时间后会过期。

  • CONNECTION_COUNT

    使用此线程组的连接数。

  • QUEUED_QUERIES

    高优先级队列中等待的语句数量。

  • QUEUED_TRANSACTIONS

    低优先级队列中等待的语句数量。这些是尚未开始的事务的初始语句，因此它们也代表排队的事务。

  • STALL_LIMIT

    线程组的thread_pool_stall_limit 系统变量的值。这对于所有线程组都是相同的值。

  • PRIO_KICKUP_TIMER

    线程组的thread_pool_prio_kickup_timer 系统变量的值。这对于所有线程组都是相同的值。

  • ALGORITHM

    线程组的thread_pool_algorithm 系统变量的值。这对于所有线程组都是相同的值。

  • 线程计数

    作为线程组的一部分启动的线程数。

  • 活动线程计数

    在执行语句的活动线程数。

  • 停滞线程计数

    线程组中停滞语句的数量。停滞的语句可能正在执行，但从线程池的角度来看，它们停滞不前。长时间运行的语句很快就会进入这个类别。

  • 等待线程编号

    如果有一个线程处理线程组中语句的轮询，这指定了该线程组内的线程编号。这个线程可能正在执行语句。

  • 最老的排队

    最老的排队语句等待执行的毫秒数。

  • 线程组中的最大线程 ID

    线程组中线程的最大线程 ID。当从tp_thread_state表中选择线程时，这与MAX(TP_THREAD_NUMBER)相同。也就是说，这两个查询是等效的：

    SELECT TP_GROUP_ID, MAX_THREAD_IDS_IN_GROUP
FROM tp_thread_group_state;

SELECT TP_GROUP_ID, MAX(TP_THREAD_NUMBER)
FROM tp_thread_state GROUP BY TP_GROUP_ID;

tp_thread_group_state表具有以下索引：

  • (TP_GROUP_ID)上的唯一索引

不允许对tp_thread_group_state表进行TRUNCATE TABLE。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-tp-thread-group-stats-table.html

29.12.16.2 The tp_thread_group_stats Table

注意

此处描述的性能模式表在 MySQL 8.0.14 版本中可用。在 MySQL 8.0.14 之前，请改用相应的 INFORMATION_SCHEMA 表；请参阅第 28.5.3 节，“INFORMATION_SCHEMA TP_THREAD_GROUP_STATS 表”。

tp_thread_group_stats 表报告每个线程组的统计信息。每个组有一行。

tp_thread_group_stats 表具有以下列：

  • TP_GROUP_ID

    线程组 ID。这是表内的唯一键。

  • CONNECTIONS_STARTED

    开始的连接数量。

  • CONNECTIONS_CLOSED

    连接关闭的次数。

  • QUERIES_EXECUTED

    执行的语句数量。当语句开始执行时，此数字会递增，而不是在语句执行完成时。

  • QUERIES_QUEUED

    接收到的排队等待执行的语句数量。这不包括线程组能够立即开始执行而无需排队的语句，这可能发生在第 7.6.3.3 节，“线程池操作”中描述的条件下。

  • THREADS_STARTED

    启动的线程数量。

  • PRIO_KICKUPS

    根据 thread_pool_prio_kickup_timer 系统变量的值，已从低优先级队列移至高优先级队列的语句数量。如果此数字快速增加，请考虑增加该变量的值。快速增加的计数器意味着优先级系统未能阻止事务过早启动。对于 InnoDB，这很可能意味着由于太多并发事务而导致性能下降。

  • STALLED_QUERIES_EXECUTED

    由于执行时间超过 thread_pool_stall_limit 系统变量的值而被定义为停滞的语句数量。

  • BECOME_CONSUMER_THREAD

    已分配消费者线程角色的次数。

  • BECOME_RESERVE_THREAD

    已分配保留线程角色的次数。

  • BECOME_WAITING_THREAD

    线程被分配等待线程角色的次数。当语句被排队时，即使在正常操作中，这种情况也经常发生，因此在负载高的系统中，语句排队的情况下，这个值的快速增加是正常的。

  • WAKE_THREAD_STALL_CHECKER

    检查线程决定唤醒或创建线程以处理某些语句或处理等待线程角色的次数。

  • SLEEP_WAITS

    THD_WAIT_SLEEP等待的次数。当线程进入睡眠状态时（例如，通过调用SLEEP()函数）会发生这种情况。

  • DISK_IO_WAITS

    THD_WAIT_DISKIO等待的次数。当线程执行磁盘 I/O 时，很可能不会命中文件系统缓存。这种等待发生在缓冲池读取和写入数据到磁盘时，而不是正常的文件读取和写入时。

  • ROW_LOCK_WAITS

    THD_WAIT_ROW_LOCK等待另一个事务释放行锁的次数。

  • GLOBAL_LOCK_WAITS

    THD_WAIT_GLOBAL_LOCK等待全局锁释放的次数。

  • META_DATA_LOCK_WAITS

    THD_WAIT_META_DATA_LOCK等待元数据锁释放的次数。

  • TABLE_LOCK_WAITS

    THD_WAIT_TABLE_LOCK等待表被解锁以便语句访问的次数。

  • USER_LOCK_WAITS

    THD_WAIT_USER_LOCK等待用户线程构造的特殊锁的次数。

  • BINLOG_WAITS

    THD_WAIT_BINLOG_WAITS等待二进制日志释放的次数。

  • GROUP_COMMIT_WAITS

    THD_WAIT_GROUP_COMMIT等待的次数。当组提交必须等待其他方完成事务的一部分时会发生这种情况。

  • FSYNC_WAITS

    THD_WAIT_SYNC等待文件同步操作的次数。

tp_thread_group_stats表具有以下索引：

  • 在(TP_GROUP_ID)上的唯一索引

TRUNCATE TABLE不允许用于tp_thread_group_stats表。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-tp-thread-state-table.html

29.12.16.3 tp_thread_state 表

注意

此处描述的性能模式表可在 MySQL 8.0.14 及更高版本中使用。在 MySQL 8.0.14 之前，请改用相应的INFORMATION_SCHEMA表；参见 Section 28.5.4, “INFORMATION_SCHEMA TP_THREAD_STATE 表”。

tp_thread_state表每个由线程池创建的用于处理连接的线程都有一行。

tp_thread_state表具有以下列：

  • TP_GROUP_ID

    线程组 ID。

  • TP_THREAD_NUMBER

    线程在其线程组内的 ID。TP_GROUP_ID和TP_THREAD_NUMBER一起在表中提供唯一键。

  • PROCESS_COUNT

    该线程当前正在执行的语句所使用的 10ms 间隔。0 表示没有语句正在执行，1 表示在第一个 10ms 内，依此类推。

  • WAIT_TYPE

    线程的等待类型。NULL表示线程未被阻塞。否则，线程被thd_wait_begin()调用阻塞，值指定等待类型。tp_thread_group_stats表的*xxx*_WAIT列累积每种等待类型的计数。

    WAIT_TYPE值是描述等待类型的字符串，如下表所示。

    表 29.6 tp_thread_state 表 WAIT_TYPE 值

    等待类型 含义
    THD_WAIT_SLEEP 等待睡眠
    THD_WAIT_DISKIO 等待磁盘 IO
    THD_WAIT_ROW_LOCK 等待行锁
    THD_WAIT_GLOBAL_LOCK 等待全局锁
    THD_WAIT_META_DATA_LOCK 等待元数据锁
    THD_WAIT_TABLE_LOCK 等待表锁
    THD_WAIT_USER_LOCK 等待用户锁
    THD_WAIT_BINLOG 等待 binlog
    THD_WAIT_GROUP_COMMIT 等待组提交
    THD_WAIT_SYNC 等待 fsync
    等待类型 含义

  • TP_THREAD_TYPE

    线程的类型。此列中显示的值是CONNECTION_HANDLER_WORKER_THREAD、LISTENER_WORKER_THREAD、QUERY_WORKER_THREAD或TIMER_WORKER_THREAD之一。

    此列是在 MySQL 8.0.32 中添加的。

  • THREAD_ID

    此线程的唯一标识符。该值与性能模式threads表的THREAD_ID列中使用的值相同。

    此列是在 MySQL 8.0.32 中添加的。

tp_thread_state表具有以下索引：

  • (TP_GROUP_ID, TP_THREAD_NUMBER)上的唯一索引

TRUNCATE TABLE 不允许用于 tp_thread_state 表。

29.12.17 性能模式防火墙表

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-firewall-tables.html

29.12.17.1 firewall_groups 表

29.12.17.2 firewall_group_allowlist 表

29.12.17.3 firewall_membership 表

注意

此处描述的性能模式表在 MySQL 8.0.23 版本中可用。在 MySQL 8.0.23 之前，请改用相应的 INFORMATION_SCHEMA 表；请参阅 MySQL 企业防火墙表。

以下各节描述了与 MySQL 企业防火墙相关的性能模式表（请参阅 第 8.4.7 节，“MySQL 企业防火墙”）。它们提供有关防火墙操作的信息：

  • firewall_groups: 关于防火墙组配置文件的信息。

  • firewall_group_allowlist: 注册防火墙组配置文件的允许列表规则。

  • firewall_membership: 注册防火墙组配置文件的成员（帐户）。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-firewall-groups-table.html

29.12.17.1 防火墙组表

firewall_groups 表提供了对 MySQL 企业防火墙内存数据缓存的视图。它列出了注册的防火墙组配置文件的名称和操作模式。它与提供防火墙数据持久存储的 mysql.firewall_groups 系统表一起使用；请参阅 MySQL 企业防火墙表。

firewall_groups 表具有以下列：

  • 名称

    组配置文件名称。

  • 模式

    配置文件的当前操作模式。允许的模式值为 OFF、DETECTING、PROTECTING 和 RECORDING。有关其含义的详细信息，请参阅 防火墙概念。

  • 用户主机

    组配置文件的训练账户，在配置文件处于 RECORDING 模式时使用。数值为 NULL，或格式为 *user_name*@*host_name* 的非NULL账户：

    • 如果数值为 NULL，防火墙记录允许来自任何组成员账户的语句。

    • 如果数值为非NULL，防火墙记录仅允许来自指定账户（应为组成员）的语句。

firewall_groups 表没有索引。

不允许对 firewall_groups 表使用 TRUNCATE TABLE。

firewall_groups 表在 MySQL 8.0.23 中添加。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-firewall-group-allowlist-table.html

29.12.17.2 The firewall_group_allowlist Table

firewall_group_allowlist 表提供了对 MySQL Enterprise Firewall 内存数据缓存的视图。它列出了已注册防火墙组配置文件的允许规则。它与提供防火墙数据持久存储的 mysql.firewall_group_allowlist 系统表一起使用；请参阅 MySQL Enterprise Firewall Tables。

firewall_group_allowlist 表包含以下列：

  • NAME

    组配置文件名称。

  • RULE

    表示配置文件可接受语句模式的规范化语句。配置文件允许列表是其规则的并集。

firewall_group_allowlist 表没有索引。

TRUNCATE TABLE 不允许用于 firewall_group_allowlist 表。

firewall_group_allowlist 表在 MySQL 8.0.23 中添加。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-firewall-membership-table.html

29.12.17.3 The firewall_membership Table

firewall_membership 表提供了一个查看 MySQL Enterprise Firewall 内存数据缓存的视图。它列出了注册防火墙组个人资料的成员（账户）。它与提供防火墙数据持久存储的 mysql.firewall_membership 系统表一起使用；参见 MySQL Enterprise Firewall Tables。

firewall_membership 表有以下列：

  • GROUP_ID

    组个人资料名称。

  • MEMBER_ID

    一个属于个人资料的账户名称。

firewall_membership 表没有索引。

TRUNCATE TABLE 不允许用于 firewall_membership 表。

firewall_membership 表在 MySQL 8.0.23 中添加。

29.12.18 Performance Schema Keyring Tables

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-keyring-tables.html

29.12.18.1 The keyring_component_status Table

29.12.18.2 The keyring_keys table

以下各节描述了与 MySQL 密钥环相关的性能模式表（参见 Section 8.4.4, “The MySQL Keyring”）。它们提供有关密钥环操作的信息：

  • keyring_component_status: 关于正在使用的密钥环组件的信息。

  • keyring_keys: MySQL 密钥环中密钥的元数据。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-keyring-component-status-table.html

29.12.18.1 密钥环组件状态表

keyring_component_status 表（自 MySQL 8.0.24 起可用）提供有关正在使用的密钥环组件属性的状态信息，如果已安装密钥环组件。如果未安装密钥环组件（例如，如果未使用密钥环，或者配置为使用密钥环插件而不是密钥环组件管理密钥库），则表为空。

没有固定的属性集。每个密钥环组件可以自由定义自己的属性集。

示例 keyring_component_status 内容：

mysql> SELECT * FROM performance_schema.keyring_component_status;
+---------------------+-------------------------------------------------+
| STATUS_KEY          | STATUS_VALUE                                    |
+---------------------+-------------------------------------------------+
| Component_name      | component_keyring_file                          |
| Author              | Oracle Corporation                              |
| License             | GPL                                             |
| Implementation_name | component_keyring_file                          |
| Version             | 1.0                                             |
| Component_status    | Active                                          |
| Data_file           | /usr/local/mysql/keyring/component_keyring_file |
| Read_only           | No                                              |
+---------------------+-------------------------------------------------+

keyring_component_status 表具有以下列：

  • STATUS_KEY

    状态项名称。

  • STATUS_VALUE

    状态项值。

keyring_component_status 表没有索引。

TRUNCATE TABLE 不允许用于 keyring_component_status 表。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-keyring-keys-table.html

29.12.18.2 密钥环键表

MySQL 服务器支持一个密钥环，使内部服务器组件和插件能够安全地存储敏感信息以供以后检索。参见 第 8.4.4 节，“MySQL 密钥环”。

截至 MySQL 8.0.16，keyring_keys 表公开密钥环中密钥的元数据。密钥元数据包括密钥 ID、密钥所有者和后端密钥 ID。keyring_keys 表 不 公开任何敏感的密钥环数据，如密钥内容。

keyring_keys 表包含以下列：

  • KEY_ID

    密钥标识符。

  • KEY_OWNER

    密钥的所有者。

  • BACKEND_KEY_ID

    密钥环后端使用的密钥 ID。

keyring_keys 表没有索引。

截断表 不允许用于 keyring_keys 表。

29.12.19 性能模式克隆表

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-clone-tables.html

29.12.19.1 克隆状态表

29.12.19.2 克隆进度表

注意

这里描述的性能模式表在 MySQL 8.0.17 版本中可用。

以下部分描述了与克隆插件相关的性能模式表（参见第 7.6.7 节，“克隆插件”）。这些表提供有关克隆操作的信息。

  • clone_status: 当前或最近执行的克隆操作的状态信息。

  • clone_progress: 当前或最近执行的克隆操作的进度信息。

性能模式克隆表由克隆插件实现，并在加载和卸载该插件时加载和卸载（参见第 7.6.7.1 节，“安装克隆插件”）。表不需要特殊配置步骤。但是，表依赖于克隆插件的启用。如果加载了克隆插件但未启用，则不会创建表。

性能模式克隆插件表仅在接收端 MySQL 服务器实例上使用。数据在服务器关闭和重启时持久化。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-clone-status-table.html

29.12.19.1 克隆状态表

注意

此处描述的性能模式表自 MySQL 8.0.17 起可用。

clone_status表仅显示当前或最后执行的克隆操作的状态。该表只包含一行数据，或为空。

clone_status表包含以下列：

  • ID

    当前 MySQL 服务器实例中的唯一克隆操作标识符。

  • PID

    执行克隆操作的会话的进程列表 ID。

  • STATE

    克隆操作的当前状态。值包括Not Started、In Progress、Completed和Failed。

  • BEGIN_TIME

    克隆操作开始时的时间戳格式为'*YYYY-MM-DD hh:mm:ss*[.*fraction`*]'。

  • END_TIME

    克隆操作完成时的时间戳格式为'*YYYY-MM-DD hh:mm:ss*[.*fraction`*]'。如果操作尚未结束，则报告 NULL。

  • SOURCE

    源 MySQL 服务器地址以'HOST:PORT'格式显示。对于本地克隆操作，该列显示'LOCAL INSTANCE'。

  • DESTINATION

    正在进行克隆的目录。

  • ERROR_NO

    克隆操作失败时报告的错误编号。

  • ERROR_MESSAGE

    克隆操作失败时的错误消息字符串。

  • BINLOG_FILE

    数据被克隆到的二进制日志文件的名称。

  • BINLOG_POSITION

    数据被克隆到的二进制日志文件偏移量。

  • GTID_EXECUTED

    最后一个克隆事务的 GTID 值。

clone_status表是只读的。不允许 DDL，包括TRUNCATE TABLE。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-clone-progress-table.html

29.12.19.2 clone_progress 表

注意

此处描述的性能模式表自 MySQL 8.0.17 起可用。

clone_progress 表仅显示当前或最近执行的克隆操作的进度信息。

克隆操作的阶段包括 DROP DATA、FILE COPY、PAGE_COPY、REDO_COPY、FILE_SYNC、RESTART 和 RECOVERY。每个阶段都会生成一条记录。因此，表中只包含七行数据，或为空。

clone_progress 表具有以下列：

  • ID

    当前 MySQL 服务器实例中的唯一克隆操作标识符。

  • STAGE

    当前克隆阶段的名称。阶段包括 DROP DATA、FILE COPY、PAGE_COPY、REDO_COPY、FILE_SYNC、RESTART 和 RECOVERY。

  • STATE

    当前克隆阶段的当前状态。状态包括 Not Started、In Progress 和 Completed。

  • BEGIN_TIME

    以'*YYYY-MM-DD hh:mm:ss*[.*fraction*]'格式的时间戳，显示克隆阶段何时开始。如果阶段尚未开始，则报告 NULL。

  • END_TIME

    以'*YYYY-MM-DD hh:mm:ss*[.*fraction*]'格式的时间戳，显示克隆阶段何时完成。如果阶段尚未结束，则报告 NULL。

  • THREADS

    阶段中使用的并发线程数。

  • ESTIMATE

    当前阶段的估计数据量，以字节为单位。

  • DATA

    当前状态下传输的数据量，以字节为单位。

  • NETWORK

    当前状态下传输的网络数据量，以字节为单位。

  • DATA_SPEED

    数据传输的当前实际速度，以每秒字节计。此值可能与由clone_max_data_bandwidth定义的请求的最大数据传输速率不同。

  • NETWORK_SPEED

    当前网络传输速度，以每秒字节计。

clone_progress 表是只读的。不允许 DDL，包括TRUNCATE TABLE。

29.12.20 性能模式摘要表

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-summary-tables.html

29.12.20.1 等待事件摘要表

29.12.20.2 阶段摘要表

29.12.20.3 语句摘要表

29.12.20.4 语句直方图摘要表

29.12.20.5 事务摘要表

29.12.20.6 对象等待摘要表

29.12.20.7 文件 I/O 摘要表

29.12.20.8 表 I/O 和锁等待摘要表

29.12.20.9 套接字摘要表

29.12.20.10 内存摘要表

29.12.20.11 错误摘要表

29.12.20.12 状态变量摘要表

摘要表提供了随时间终止事件的聚合信息。此组中的表以不同方式总结事件数据。

每个摘要表都有分组列，用于确定如何对数据进行聚合，并包含聚合值的摘要列。通常，以类似方式总结事件的表具有类似的摘要列集，并且仅在用于确定如何聚合事件的分组列方面有所不同。

摘要表可以使用TRUNCATE TABLE进行截断。通常，效果是将摘要列重置为 0 或NULL，而不是删除行。这使您可以清除收集的值并重新开始聚合。例如，在进行运行时配置更改后，这可能很有用。个别摘要表部分中指出的截断行为的例外情况。

等待事件摘要

表 29.7 性能模式等待事件摘要表

表名 描述
events_waits_summary_by_account_by_event_name 每个帐户和事件名称的等待事件
events_waits_summary_by_host_by_event_name 每个主机名和事件名称的等待事件
events_waits_summary_by_instance 每个实例的等待事件
events_waits_summary_by_thread_by_event_name 每个线程和事件名称的等待事件
events_waits_summary_by_user_by_event_name 按用户名称和事件名统计等待事件
events_waits_summary_global_by_event_name 按事件名统计等待事件

阶段摘要

表 29.8 性能模式阶段事件摘要表

表名 描述
events_stages_summary_by_account_by_event_name 按账户和事件名统计阶段事件
events_stages_summary_by_host_by_event_name 按主机名和事件名统计阶段事件
events_stages_summary_by_thread_by_event_name 按线程和事件名统计阶段等待
events_stages_summary_by_user_by_event_name 按用户名称和事件名统计阶段事件
events_stages_summary_global_by_event_name 按事件名统计阶段等待

语句摘要

表 29.9 性能模式语句事件摘要表

表名 描述
events_statements_histogram_by_digest 按模式和摘要值统计语句直方图
events_statements_histogram_global 全局汇总的语句直方图
events_statements_summary_by_account_by_event_name 按账户和事件名统计语句事件
events_statements_summary_by_digest 按模式和摘要值统计语句事件
events_statements_summary_by_host_by_event_name 按主机名和事件名统计语句事件
events_statements_summary_by_program 按存储程序统计语句事件
events_statements_summary_by_thread_by_event_name 按线程和事件名统计语句事件
events_statements_summary_by_user_by_event_name 按用户名称和事件名统计语句事件
events_statements_summary_global_by_event_name 按事件名称分类的语句事件
prepared_statements_instances 准备语句实例和统计信息
表名 描述

事务摘要

表 29.10 性能模式事务事件摘要表

表名 描述
events_transactions_summary_by_account_by_event_name 按帐户和事件名称分类的事务事件
events_transactions_summary_by_host_by_event_name 按主机名和事件名称分类的事务事件
events_transactions_summary_by_thread_by_event_name 按线程和事件名称分类的事务事件
events_transactions_summary_by_user_by_event_name 按用户名和事件名称分类的事务事件
events_transactions_summary_global_by_event_name 按事件名称分类的事务事件

对象等待摘要

表 29.11 性能模式对象事件摘要表

表名 描述
objects_summary_global_by_type 对象摘要

文件 I/O 摘要

表 29.12 性能模式文件 I/O 事件摘要表

表名 描述
file_summary_by_event_name 按事件名称分类的文件事件
file_summary_by_instance 按文件实例分类的文件事件

表 I/O 和锁等待摘要

表 29.13 性能模式表 I/O 和锁等待事件摘要表

表名 描述
table_io_waits_summary_by_index_usage 按索引分类的表 I/O 等待
table_io_waits_summary_by_table 按表分类的表 I/O 等待
table_lock_waits_summary_by_table 每个表的表锁等待

套接字摘要

表 29.14 性能模式套接字事件摘要表

表名称 描述
socket_summary_by_event_name 每个事件名称的套接字等待和 I/O
socket_summary_by_instance 每个实例的套接字等待和 I/O

内存摘要

表 29.15 性能模式内存操作摘要表

表名称 描述
memory_summary_by_account_by_event_name 每个帐户和事件名称的内存操作
memory_summary_by_host_by_event_name 每个主机和事件名称的内存操作
memory_summary_by_thread_by_event_name 每个线程和事件名称的内存操作
memory_summary_by_user_by_event_name 每个用户和事件名称的内存操作
memory_summary_global_by_event_name 每个事件名称的全局内存操作

错误摘要

表 29.16 性能模式错误摘要表

表名称 描述
events_errors_summary_by_account_by_error 每个帐户和错误代码的错误
events_errors_summary_by_host_by_error 每个主机和错误代码的错误
events_errors_summary_by_thread_by_error 每个线程和错误代码的错误
events_errors_summary_by_user_by_error 每个用户和错误代码的错误
events_errors_summary_global_by_error 每个错误代码的错误

状态变量摘要

表 29.17 性能模式错误状态变量摘要表

表名称 描述
status_by_account 每个帐户的会话状态变量
status_by_host 每个主机名称的会话状态变量
status_by_user 每个用户名称的会话状态变量

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-wait-summary-tables.html

29.12.20.1 等待事件摘要表

性能模式维护表用于收集当前和最近的等待事件，并在摘要表中汇总这些信息。第 29.12.4 节，“性能模式等待事件表”描述了等待摘要的基础事件。请参阅该讨论以获取有关等待事件内容、当前和最近的等待事件表以及如何控制等待事件收集（默认情况下已禁用）的信息。

示例等待事件摘要信息：

mysql> SELECT *
       FROM performance_schema.events_waits_summary_global_by_event_name\G
...
*************************** 6\. row ***************************
    EVENT_NAME: wait/synch/mutex/sql/BINARY_LOG::LOCK_index
    COUNT_STAR: 8
SUM_TIMER_WAIT: 2119302
MIN_TIMER_WAIT: 196092
AVG_TIMER_WAIT: 264912
MAX_TIMER_WAIT: 569421
...
*************************** 9\. row ***************************
    EVENT_NAME: wait/synch/mutex/sql/hash_filo::lock
    COUNT_STAR: 69
SUM_TIMER_WAIT: 16848828
MIN_TIMER_WAIT: 0
AVG_TIMER_WAIT: 244185
MAX_TIMER_WAIT: 735345
...

每个等待事件摘要表都有一个或多个分组列，用于指示表如何聚合事件。事件名称指的是setup_instruments表中事件工具的名称：

  • events_waits_summary_by_account_by_event_name具有EVENT_NAME、USER和HOST列。每行总结了给定帐户（用户和主机组合）和事件名称的事件。

  • events_waits_summary_by_host_by_event_name具有EVENT_NAME和HOST列。每行总结了给定主机和事件名称的事件。

  • events_waits_summary_by_instance具有EVENT_NAME和OBJECT_INSTANCE_BEGIN列。每行总结了给定事件名称和对象的事件。如果一个工具用于创建多个实例，则每个实例都有一个唯一的OBJECT_INSTANCE_BEGIN值，并在此表中单独进行总结。

  • events_waits_summary_by_thread_by_event_name具有THREAD_ID和EVENT_NAME列。每行总结了给定线程和事件名称的事件。

  • events_waits_summary_by_user_by_event_name具有EVENT_NAME和USER列。每行总结了给定用户和事件名称的事件。

  • events_waits_summary_global_by_event_name具有一个EVENT_NAME列。每行总结了给定事件名称的事件。一个工具可能用于创建被检测对象的多个实例。例如，如果为每个连接创建一个互斥体的工具，则实例的数量与连接数量相同。工具的摘要行总结了所有这些实例。

每个等待事件摘要表都有这些包含聚合值的摘要列：

  • COUNT_STAR

    汇总事件的数量。此值包括所有事件，无论是定时的还是非定时的。

  • SUM_TIMER_WAIT

    汇总定时事件的总等待时间。此值仅针对定时事件计算，因为非定时事件的等待时间为 NULL。对于其他 *xxx*_TIMER_WAIT 值也是如此。

  • MIN_TIMER_WAIT

    汇总定时事件的最小等待时间。

  • AVG_TIMER_WAIT

    汇总定时事件的平均等待时间。

  • MAX_TIMER_WAIT

    汇总定时事件的最大等待时间。

等待事件汇总表具有以下索引：

  • events_waits_summary_by_account_by_event_name:

    • 主键在 (USER, HOST, EVENT_NAME)

  • events_waits_summary_by_host_by_event_name:

    • 主键在 (HOST, EVENT_NAME)

  • events_waits_summary_by_instance:

    • 主键在 (OBJECT_INSTANCE_BEGIN)

    • 在 (EVENT_NAME) 上的索引

  • events_waits_summary_by_thread_by_event_name:

    • 主键在 (THREAD_ID, EVENT_NAME)

  • events_waits_summary_by_user_by_event_name:

    • 主键在 (USER, EVENT_NAME)

  • events_waits_summary_global_by_event_name:

    • 主键在 (EVENT_NAME)

TRUNCATE TABLE 允许用于等待汇总表。它具有以下效果：

  • 对于不按帐户、主机或用户汇总的汇总表，截断会将汇总列重置为零，而不是删除行。

  • 对于按帐户、主机或用户汇总的汇总表，截断会删除没有连接的帐户、主机或用户的行，并将剩余行的汇总列重置为零。

此外，每个按帐户、主机、用户或线程汇总的等待汇总表在其依赖的连接表被截断或 events_waits_summary_global_by_event_name 被截断时会被隐式截断。有关详细信息，请参见 第 29.12.8 节，“性能模式连接表”。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-stage-summary-tables.html

29.12.20.2 阶段摘要表

性能模式维护用于收集当前和最近阶段事件的表，并在摘要表中聚合该信息。Section 29.12.5, “性能模式阶段事件表”描述了阶段摘要的基础事件。请参阅该讨论以获取有关阶段事件内容、当前和历史阶段事件表以及如何控制阶段事件收集（默认情况下已禁用）的信息。

示例阶段事件摘要信息：

mysql> SELECT *
       FROM performance_schema.events_stages_summary_global_by_event_name\G
...
*************************** 5\. row ***************************
    EVENT_NAME: stage/sql/checking permissions
    COUNT_STAR: 57
SUM_TIMER_WAIT: 26501888880
MIN_TIMER_WAIT: 7317456
AVG_TIMER_WAIT: 464945295
MAX_TIMER_WAIT: 12858936792
...
*************************** 9\. row ***************************
    EVENT_NAME: stage/sql/closing tables
    COUNT_STAR: 37
SUM_TIMER_WAIT: 662606568
MIN_TIMER_WAIT: 1593864
AVG_TIMER_WAIT: 17907891
MAX_TIMER_WAIT: 437977248
...

每个阶段摘要表都有一个或多个分组列，用于指示表如何聚合事件。事件名称指的是setup_instruments表中事件工具的名称：

  • events_stages_summary_by_account_by_event_name具有EVENT_NAME，USER和HOST列。每行总结了给定帐户（用户和主机组合）和事件名称的事件。

  • events_stages_summary_by_host_by_event_name具有EVENT_NAME和HOST列。每行总结了给定主机和事件名称的事件。

  • events_stages_summary_by_thread_by_event_name具有THREAD_ID和EVENT_NAME列。每行总结了给定线程和事件名称的事件。

  • events_stages_summary_by_user_by_event_name具有EVENT_NAME和USER列。每行总结了给定用户和事件名称的事件。

  • events_stages_summary_global_by_event_name具有一个EVENT_NAME列。每行总结了给定事件名称的事件。

每个阶段摘要表都有这些包含聚合值的摘要列：COUNT_STAR，SUM_TIMER_WAIT，MIN_TIMER_WAIT，AVG_TIMER_WAIT和MAX_TIMER_WAIT。这些列类似于等待事件摘要表中同名列的列（参见 Section 29.12.20.1, “等待事件摘要表”)，不同之处在于阶段摘要表聚合了来自events_stages_current而不是events_waits_current的事件。

阶段摘要表具有以下索引：

  • events_stages_summary_by_account_by_event_name：

    • 主键为 (USER, HOST, EVENT_NAME)

  • events_stages_summary_by_host_by_event_name：

    • 主键为 (HOST, EVENT_NAME)

  • events_stages_summary_by_thread_by_event_name：

    • 主键为 (THREAD_ID, EVENT_NAME)

  • events_stages_summary_by_user_by_event_name：

    • 主键为 (USER, EVENT_NAME)

  • events_stages_summary_global_by_event_name：

    • 主键为 (EVENT_NAME)

TRUNCATE TABLE 可用于阶段汇总表。它具有以下效果：

  • 对于不按帐户、主机或用户聚合的汇总表，截断会将汇总列重置为零，而不是删除行。

  • 对于按帐户、主机或用户聚合的汇总表，截断会删除没有连接的帐户、主机或用户的行，并将剩余行的汇总列重置为零。

此外，每个按帐户、主机、用户或线程聚合的阶段汇总表在其依赖的连接表被截断或截断 events_stages_summary_global_by_event_name 时会被隐式截断。有关详细信息，请参见 Section 29.12.8, “性能模式连接表”。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-statement-summary-tables.html

29.12.20.3 语句摘要表

Performance Schema 维护用于收集当前和最近语句事件的表，并在摘要表中聚合该信息。第 29.12.6 节，“Performance Schema 语句事件表” 描述了语句摘要的基础事件。查看该讨论以获取有关语句事件内容、当前和历史语句事件表以及如何控制语句事件收集的信息，默认情况下部分禁用。

示例语句事件摘要信息：

mysql> SELECT *
       FROM performance_schema.events_statements_summary_global_by_event_name\G
*************************** 1\. row ***************************
                 EVENT_NAME: statement/sql/select
                 COUNT_STAR: 54
             SUM_TIMER_WAIT: 38860400000
             MIN_TIMER_WAIT: 52400000
             AVG_TIMER_WAIT: 719600000
             MAX_TIMER_WAIT: 12631800000
              SUM_LOCK_TIME: 88000000
                 SUM_ERRORS: 0
               SUM_WARNINGS: 0
          SUM_ROWS_AFFECTED: 0
              SUM_ROWS_SENT: 60
          SUM_ROWS_EXAMINED: 120
SUM_CREATED_TMP_DISK_TABLES: 0
     SUM_CREATED_TMP_TABLES: 21
       SUM_SELECT_FULL_JOIN: 16
 SUM_SELECT_FULL_RANGE_JOIN: 0
           SUM_SELECT_RANGE: 0
     SUM_SELECT_RANGE_CHECK: 0
            SUM_SELECT_SCAN: 41
      SUM_SORT_MERGE_PASSES: 0
             SUM_SORT_RANGE: 0
              SUM_SORT_ROWS: 0
              SUM_SORT_SCAN: 0
          SUM_NO_INDEX_USED: 22
     SUM_NO_GOOD_INDEX_USED: 0
               SUM_CPU_TIME: 0
      MAX_CONTROLLED_MEMORY: 2028360
           MAX_TOTAL_MEMORY: 2853429
            COUNT_SECONDARY: 0
...

每个语句摘要表都有一个或多个分组列，指示表如何聚合事件。事件名称指的是setup_instruments 表中事件工具的名称：

  • events_statements_summary_by_account_by_event_name 包含 EVENT_NAME、USER 和 HOST 列。每行总结了给定帐户（用户和主机组合）和事件名称的事件。

  • events_statements_summary_by_digest 包含 SCHEMA_NAME 和 DIGEST 列。每行总结了每个模式和摘要值的事件。（DIGEST_TEXT 列包含相应的标准化语句摘要文本，但不是分组或摘要列。QUERY_SAMPLE_TEXT、QUERY_SAMPLE_SEEN 和 QUERY_SAMPLE_TIMER_WAIT 列也不是分组或摘要列；它们支持语句抽样。）

    表中的最大行数在服务器启动时自动调整大小。要明确设置此最大值，请在服务器启动时设置 performance_schema_digests_size 系统变量。

  • events_statements_summary_by_host_by_event_name 包含 EVENT_NAME 和 HOST 列。每行总结了给定主机和事件名称的事件。

  • events_statements_summary_by_program 包含 OBJECT_TYPE、OBJECT_SCHEMA 和 OBJECT_NAME 列。每行总结了给定存储程序（存储过程或函数、触发器或事件）的事件。

  • events_statements_summary_by_thread_by_event_name 包含 THREAD_ID 和 EVENT_NAME 列。每行总结了给定线程和事件名称的事件。

  • events_statements_summary_by_user_by_event_name具有EVENT_NAME和USER列。每一行总结了给定用户和事件名称的事件。

  • events_statements_summary_global_by_event_name具有一个EVENT_NAME列。每一行总结了给定事件名称的事件。

  • prepared_statements_instances具有一个OBJECT_INSTANCE_BEGIN列。每一行总结了给定准备语句的事件。

每个语句摘要表都有这些包含聚合值的摘要列（除非另有说明）：

  • COUNT_STAR、SUM_TIMER_WAIT、MIN_TIMER_WAIT、AVG_TIMER_WAIT、MAX_TIMER_WAIT

    这些列类似于等待事件摘要表中相同名称的列（参见第 29.12.20.1 节，“等待事件摘要表”），不同之处在于语句摘要表聚合了来自events_statements_current而不是events_waits_current的事件。

    prepared_statements_instances表没有这些列。

  • SUM_*xxx*

    对应于events_statements_current表中的xxx列的聚合。例如，语句摘要表中的SUM_LOCK_TIME和SUM_ERRORS列是events_statements_current表中LOCK_TIME和ERRORS列的聚合。

  • MAX_CONTROLLED_MEMORY

    报告执行过程中语句使用的最大受控内存量。

    这一列是在 MySQL 8.0.31 中添加的。

  • MAX_TOTAL_MEMORY

    报告执行过程中语句使用的最大内存量。

    这一列是在 MySQL 8.0.31 中添加的。

  • COUNT_SECONDARY

    查询在SECONDARY引擎上处理的次数。用于 MySQL HeatWave 服务和 HeatWave，其中PRIMARY引擎是InnoDB，SECONDARY引擎是 HeatWave（RAPID）。对于 MySQL 社区版服务器、MySQL 企业版服务器（本地）和没有 HeatWave 的 MySQL HeatWave 服务，查询始终在PRIMARY引擎上处理，这意味着在这些 MySQL 服务器上该值始终为 0。COUNT_SECONDARY列是在 MySQL 8.0.29 中添加的。

events_statements_summary_by_digest表具有以下额外的摘要列：

  • FIRST_SEEN，LAST_SEEN

    指示具有给定摘要值的语句何时首次看到和最近看到的时间戳。

  • QUANTILE_95：语句延迟的第 95 百分位数，单位为皮秒。这个百分位数是一个高估值，是从收集的直方图数据计算得出的。换句话说，对于给定的摘要，有 95%的语句延迟低于QUANTILE_95。

    要访问直方图数据，请使用第 29.12.20.4 节，“语句直方图摘要表”中描述的表。

  • QUANTILE_99：类似于QUANTILE_95，但针对第 99 百分位数。

  • QUANTILE_999：类似于QUANTILE_95，但针对 99.9 百分位数。

events_statements_summary_by_digest表包含以下列。这些既不是分组列也不是摘要列；它们支持语句抽样：

  • QUERY_SAMPLE_TEXT

    生成行中摘要值的样本 SQL 语句。此列使应用程序能够访问为给定摘要值而由服务器看到的实际语句。其中一个用途可能是对频繁出现的摘要相关的代表性语句运行EXPLAIN以检查执行计划。

    当QUERY_SAMPLE_TEXT列被赋值时，QUERY_SAMPLE_SEEN和QUERY_SAMPLE_TIMER_WAIT列也被赋值。

    语句显示的最大空间默认为 1024 字节。要更改此值，请在服务器启动时设置performance_schema_max_sql_text_length系统变量。（更改此值也会影响其他性能模式表中的列。请参阅第 29.10 节，“性能模式语句摘要和抽样”。）

    有关语句抽样的信息，请参阅第 29.10 节，“性能模式语句摘要和抽样”。

  • QUERY_SAMPLE_SEEN

    指示QUERY_SAMPLE_TEXT列中的语句何时被看到的时间戳。

  • QUERY_SAMPLE_TIMER_WAIT

    QUERY_SAMPLE_TEXT列中样本语句的等待时间。

events_statements_summary_by_program表具有以下额外的摘要列：

  • COUNT_STATEMENTS, SUM_STATEMENTS_WAIT, MIN_STATEMENTS_WAIT, AVG_STATEMENTS_WAIT, MAX_STATEMENTS_WAIT

    关于存储程序执行期间调用的嵌套语句的统计信息。

prepared_statements_instances 表具有以下额外的摘要列：

  • COUNT_EXECUTE, SUM_TIMER_EXECUTE, MIN_TIMER_EXECUTE, AVG_TIMER_EXECUTE, MAX_TIMER_EXECUTE

    准备语句执行的聚合统计信息。

语句摘要表具有以下索引：

  • events_transactions_summary_by_account_by_event_name:

    • 主键为 (USER, HOST, EVENT_NAME)

  • events_statements_summary_by_digest:

    • 主键为 (SCHEMA_NAME, DIGEST)

  • events_transactions_summary_by_host_by_event_name:

    • 主键为 (HOST, EVENT_NAME)

  • events_statements_summary_by_program:

    • 主键为 (OBJECT_TYPE, OBJECT_SCHEMA, OBJECT_NAME)

  • events_statements_summary_by_thread_by_event_name:

    • 主键为 (THREAD_ID, EVENT_NAME)

  • events_transactions_summary_by_user_by_event_name:

    • 主键为 (USER, EVENT_NAME)

  • events_statements_summary_global_by_event_name:

    • 主键为 (EVENT_NAME)

允许对语句摘要表执行 TRUNCATE TABLE。其效果如下：

  • 对于 events_statements_summary_by_digest，它会删除行。

  • 对于其他未按帐户、主机或用户聚合的摘要表，截断会将摘要列重置为零，而不是删除行。

  • 对于其他按帐户、主机或用户聚合的摘要表，截断会删除没有连接的帐户、主机或用户的行，并将剩余行的摘要列重置为零。

此外，按账户、主机、用户或线程汇总的每个语句摘要表都是通过截断其依赖的连接表或截断events_statements_summary_global_by_event_name而隐式截断的。详情请参见第 29.12.8 节，“性能模式连接表”。

此外，截断events_statements_summary_by_digest隐式截断events_statements_histogram_by_digest，截断events_statements_summary_global_by_event_name隐式截断events_statements_histogram_global。

语句摘要聚合规则

如果启用了statements_digest消费者，则在语句完成时将聚合到events_statements_summary_by_digest中。聚合基于为语句计算的DIGEST值。

  • 如果已存在具有刚完成语句的摘要值的events_statements_summary_by_digest行，则将该语句的统计信息聚合到该行。LAST_SEEN列将更新为当前时间。

  • 如果没有行具有刚完成语句的摘要值，并且表未满，则为该语句创建一个新行。FIRST_SEEN和LAST_SEEN列将使用当前时间进行初始化。

  • 如果没有行具有刚完成语句的语句摘要值，并且表已满，则将刚完成语句的统计信息添加到一个特殊的“全捕获”行中，该行具有DIGEST = NULL，如有必要则创建。如果创建了该行，则FIRST_SEEN和LAST_SEEN列将使用当前时间进行初始化。否则，LAST_SEEN列将使用当前时间进行更新。

具有DIGEST = NULL的行是保留的，因为性能模式表由于内存限制具有最大大小。DIGEST = NULL行允许不匹配其他行的摘要即使摘要表已满也能计数，使用一个常见的“其他”桶。此行帮助您估计摘要是否具有代表性：

  • 一个 DIGEST = NULL 行，其 COUNT_STAR 值代表所有摘要的 5%，表明摘要汇总表非常具有代表性；其他行涵盖了所见语句的 95%。

  • 一个 DIGEST = NULL 行，其 COUNT_STAR 值代表所有摘要的 50%，表明摘要汇总表并不是非常具有代表性；其他行仅涵盖了所见语句的一半。很可能数据库管理员应该增加最大表大小，以便更多在 DIGEST = NULL 行中计数的行可以使用更具体的行进行计数。默认情况下，表是自动调整大小的，但如果此大小太小，请在服务器启动时将 performance_schema_digests_size 系统变量设置为较大的值。

存储程序仪表化行为

对于在 setup_objects 表中启用了仪表化的存储程序类型，events_statements_summary_by_program 维护存储程序的统计信息如下：

  • 当对象首次在服务器中使用时，将为该对象添加一行。

  • 当对象被删除时，对象的行将被移除。

  • 统计数据在对象的行中进行聚合，随着其执行而进行。

参见 第 29.4.3 节，“事件预过滤”。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-statement-histogram-summary-tables.html

29.12.20.4 语句直方图摘要表

性能模式维护语句事件摘要表，其中包含有关语句延迟的最小、最大和平均信息（参见第 29.12.20.3 节，“语句摘要表”）。这些表允许对系统性能进行高级评估。为了允许在更细粒度级别进行评估，性能模式还收集语句延迟的直方图数据。这些直方图提供了对延迟分布的额外见解。

第 29.12.6 节，“性能模式语句事件表”描述了语句摘要基于的事件。查看该讨论以获取有关语句事件内容、当前和历史语句事件表以及如何控制语句事件收集（默认情况下部分禁用）的信息。

示例语句直方图信息：

mysql> SELECT *
       FROM performance_schema.events_statements_histogram_by_digest
       WHERE SCHEMA_NAME = 'mydb' AND DIGEST = 'bb3f69453119b2d7b3ae40673a9d4c7c'
       AND COUNT_BUCKET > 0 ORDER BY BUCKET_NUMBER\G
*************************** 1\. row ***************************
           SCHEMA_NAME: mydb
                DIGEST: bb3f69453119b2d7b3ae40673a9d4c7c
         BUCKET_NUMBER: 42
      BUCKET_TIMER_LOW: 66069344
     BUCKET_TIMER_HIGH: 69183097
          COUNT_BUCKET: 1
COUNT_BUCKET_AND_LOWER: 1
       BUCKET_QUANTILE: 0.058824
*************************** 2\. row ***************************
           SCHEMA_NAME: mydb
                DIGEST: bb3f69453119b2d7b3ae40673a9d4c7c
         BUCKET_NUMBER: 43
      BUCKET_TIMER_LOW: 69183097
     BUCKET_TIMER_HIGH: 72443596
          COUNT_BUCKET: 1
COUNT_BUCKET_AND_LOWER: 2
       BUCKET_QUANTILE: 0.117647
*************************** 3\. row ***************************
           SCHEMA_NAME: mydb
                DIGEST: bb3f69453119b2d7b3ae40673a9d4c7c
         BUCKET_NUMBER: 44
      BUCKET_TIMER_LOW: 72443596
     BUCKET_TIMER_HIGH: 75857757
          COUNT_BUCKET: 2
COUNT_BUCKET_AND_LOWER: 4
       BUCKET_QUANTILE: 0.235294
*************************** 4\. row ***************************
           SCHEMA_NAME: mydb
                DIGEST: bb3f69453119b2d7b3ae40673a9d4c7c
         BUCKET_NUMBER: 45
      BUCKET_TIMER_LOW: 75857757
     BUCKET_TIMER_HIGH: 79432823
          COUNT_BUCKET: 6
COUNT_BUCKET_AND_LOWER: 10
       BUCKET_QUANTILE: 0.625000
...

例如，在第 3 行，这些值表明 23.52%的查询在 75.86 微秒以下运行：

BUCKET_TIMER_HIGH: 75857757
  BUCKET_QUANTILE: 0.235294

在第 4 行，这些值表明 62.50%的查询在 79.44 微秒以下运行：

BUCKET_TIMER_HIGH: 79432823
  BUCKET_QUANTILE: 0.625000

每个语句直方图摘要表都有一个或多个分组列，指示表如何聚合事件：

  • events_statements_histogram_by_digest有SCHEMA_NAME、DIGEST和BUCKET_NUMBER列：

    • SCHEMA_NAME和DIGEST列在events_statements_summary_by_digest表中标识语句摘要行。

    • 具有相同SCHEMA_NAME和DIGEST值的events_statements_histogram_by_digest行构成该模式/摘要组合的直方图。

    • 在给定的直方图中，BUCKET_NUMBER列指示桶号。

  • events_statements_histogram_global有一个BUCKET_NUMBER列。该表在全局范围内汇总模式名称和摘要值的延迟，使用单个直方图。BUCKET_NUMBER列指示此全局直方图中的桶号。

直方图由N个桶组成，每一行代表一个桶，桶号由BUCKET_NUMBER列指示。桶号从 0 开始。

每个语句直方图摘要表都有这些包含聚合值的摘要列：

  • BUCKET_TIMER_LOW, BUCKET_TIMER_HIGH

    一个桶计算具有在BUCKET_TIMER_LOW和BUCKET_TIMER_HIGH之间测量的皮秒延迟的语句：

    • 第一个桶（BUCKET_NUMBER = 0）的BUCKET_TIMER_LOW值为 0。

    • 桶（BUCKET_NUMBER = k）的BUCKET_TIMER_LOW值与前一个桶（BUCKET_NUMBER = k−1）的BUCKET_TIMER_HIGH值相同

    • 最后一个桶是一个捕获所有超过直方图中前一个桶的延迟的语句的桶。

  • COUNT_BUCKET

    在从BUCKET_TIMER_LOW到BUCKET_TIMER_HIGH之间具有延迟的语句数量。

  • COUNT_BUCKET_AND_LOWER

    在从 0 到BUCKET_TIMER_HIGH之间具有延迟的语句数量。

  • BUCKET_QUANTILE

    陷入此桶或更低桶的语句比例。根据定义，此比例对应于COUNT_BUCKET_AND_LOWER / SUM(COUNT_BUCKET)，并显示为一个便利列。

语句直方图摘要表具有以下索引：

  • events_statements_histogram_by_digest:

    • 在(SCHEMA_NAME, DIGEST, BUCKET_NUMBER)上的唯一索引

  • events_statements_histogram_global:

    • 在(BUCKET_NUMBER)上的主键

允许对语句直方图摘要表进行TRUNCATE TABLE。截断将COUNT_BUCKET和COUNT_BUCKET_AND_LOWER列设置为 0。

此外，截断events_statements_summary_by_digest 隐式截断了events_statements_histogram_by_digest ，截断events_statements_summary_global_by_event_name 隐式截断了events_statements_histogram_global。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-transaction-summary-tables.html

29.12.20.5 事务摘要表

Performance Schema 维护用于收集当前和最近事务事件的表，并在摘要表中聚合该信息。第 29.12.7 节，“Performance Schema 事务表”描述了事务摘要的基础事件。请参阅该讨论以获取有关事务事件内容、当前和历史事务事件表以及如何控制事务事件收集（默认情况下已禁用）的信息。

事务事件摘要信息示例：

mysql> SELECT *
       FROM performance_schema.events_transactions_summary_global_by_event_name
       LIMIT 1\G
*************************** 1\. row ***************************
          EVENT_NAME: transaction
          COUNT_STAR: 5
      SUM_TIMER_WAIT: 19550092000
      MIN_TIMER_WAIT: 2954148000
      AVG_TIMER_WAIT: 3910018000
      MAX_TIMER_WAIT: 5486275000
    COUNT_READ_WRITE: 5
SUM_TIMER_READ_WRITE: 19550092000
MIN_TIMER_READ_WRITE: 2954148000
AVG_TIMER_READ_WRITE: 3910018000
MAX_TIMER_READ_WRITE: 5486275000
     COUNT_READ_ONLY: 0
 SUM_TIMER_READ_ONLY: 0
 MIN_TIMER_READ_ONLY: 0
 AVG_TIMER_READ_ONLY: 0
 MAX_TIMER_READ_ONLY: 0

每个事务摘要表都有一个或多个分组列，用于指示表如何聚合事件。事件名称指的是setup_instruments表中事件仪器的名称：

  • events_transactions_summary_by_account_by_event_name具有USER、HOST和EVENT_NAME列。每行总结了给定帐户（用户和主机组合）和事件名称的事件。

  • events_transactions_summary_by_host_by_event_name具有HOST和EVENT_NAME列。每行总结了给定主机和事件名称的事件。

  • events_transactions_summary_by_thread_by_event_name具有THREAD_ID和EVENT_NAME列。每行总结了给定线程和事件名称的事件。

  • events_transactions_summary_by_user_by_event_name具有USER和EVENT_NAME列。每行总结了给定用户和事件名称的事件。

  • events_transactions_summary_global_by_event_name具有一个EVENT_NAME列。每行总结了给定事件名称的事件。

每个事务摘要表都有这些包含聚合值的摘要列：

  • COUNT_STAR, SUM_TIMER_WAIT, MIN_TIMER_WAIT, AVG_TIMER_WAIT, MAX_TIMER_WAIT

    这些列类似于等待事件摘要表中同名列的列（参见第 29.12.20.1 节，“等待事件摘要表”），只是交易摘要表聚合了来自events_transactions_current而不是events_waits_current的事件。这些列总结了读写和只读事务。

  • COUNT_READ_WRITE, SUM_TIMER_READ_WRITE, MIN_TIMER_READ_WRITE, AVG_TIMER_READ_WRITE, MAX_TIMER_READ_WRITE

    这些类似于COUNT_STAR和*xxx*_TIMER_WAIT列，但仅总结了读写事务。事务访问模式指定事务是以读/写模式还是只读模式运行。

  • COUNT_READ_ONLY, SUM_TIMER_READ_ONLY, MIN_TIMER_READ_ONLY, AVG_TIMER_READ_ONLY, MAX_TIMER_READ_ONLY

    这些类似于COUNT_STAR和*xxx*_TIMER_WAIT列，但仅总结了只读事务。事务访问模式指定事务是以读/写模式还是只读模式运行。

交易摘要表具有以下索引：

  • events_transactions_summary_by_account_by_event_name:

    • 主键为(USER, HOST, EVENT_NAME)

  • events_transactions_summary_by_host_by_event_name:

    • 主键为(HOST, EVENT_NAME)

  • events_transactions_summary_by_thread_by_event_name:

    • 主键为(THREAD_ID, EVENT_NAME)

  • events_transactions_summary_by_user_by_event_name:

    • 主键为(USER, EVENT_NAME)

  • events_transactions_summary_global_by_event_name:

    • 主键为(EVENT_NAME)

TRUNCATE TABLE允许用于交易摘要表。它具有以下效果：

  • 对于未按帐户、主机或用户聚合的摘要表，截断将摘要列重置为零，而不是删除行。

  • 对于按帐户、主机或用户聚合的摘要表，截断将删除没有连接的帐户、主机或用户的行，并将剩余行的摘要列重置为零。

此外，按帐户、主机、用户或线程聚合的每个事务摘要表都会隐式地通过其依赖的连接表或events_transactions_summary_global_by_event_name的截断进行截断。详情请参见第 29.12.8 节“性能模式连接表”。

事务聚合规则

事务事件收集不考虑隔离级别、访问模式或自动提交模式。

服务器发起的所有非中止事务，包括空事务，都会进行事务事件收集。

读写事务通常比只读事务更消耗资源，因此事务摘要表包括独立的读写和只读事务的聚合列。

资源需求也可能随着事务隔离级别的不同而变化。然而，假设每台服务器只使用一个隔离级别，就不提供按隔离级别聚合的功能。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-objects-summary-global-by-type-table.html

29.12.20.6 对象等待摘要表

性能模式维护objects_summary_global_by_type表以聚合对象等待事件。

示例对象等待事件摘要信息：

mysql> SELECT * FROM performance_schema.objects_summary_global_by_type\G
...
*************************** 3\. row ***************************
   OBJECT_TYPE: TABLE
 OBJECT_SCHEMA: test
   OBJECT_NAME: t
    COUNT_STAR: 3
SUM_TIMER_WAIT: 263126976
MIN_TIMER_WAIT: 1522272
AVG_TIMER_WAIT: 87708678
MAX_TIMER_WAIT: 258428280
...
*************************** 10\. row ***************************
   OBJECT_TYPE: TABLE
 OBJECT_SCHEMA: mysql
   OBJECT_NAME: user
    COUNT_STAR: 14
SUM_TIMER_WAIT: 365567592
MIN_TIMER_WAIT: 1141704
AVG_TIMER_WAIT: 26111769
MAX_TIMER_WAIT: 334783032
...

objects_summary_global_by_type表具有这些分组列，用于指示表如何聚合事件：OBJECT_TYPE，OBJECT_SCHEMA和OBJECT_NAME。每行总结了给定对象的事件。

objects_summary_global_by_type具有与events_waits_summary_by_*xxx*表相同的摘要列。请参阅第 29.12.20.1 节，“等待事件摘要表”。

objects_summary_global_by_type表具有以下索引：

  • 主键为(OBJECT_TYPE, OBJECT_SCHEMA, OBJECT_NAME)

TRUNCATE TABLE允许用于对象摘要表。它将摘要列重置为零，而不是删除行。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-file-summary-tables.html

29.12.20.7 文件 I/O 汇总表

性能模式维护文件 I/O 汇总表，汇总有关 I/O 操作的信息。

示例文件 I/O 事件汇总信息：

mysql> SELECT * FROM performance_schema.file_summary_by_event_name\G
...
*************************** 2\. row ***************************
               EVENT_NAME: wait/io/file/sql/binlog
               COUNT_STAR: 31
           SUM_TIMER_WAIT: 8243784888
           MIN_TIMER_WAIT: 0
           AVG_TIMER_WAIT: 265928484
           MAX_TIMER_WAIT: 6490658832
...
mysql> SELECT * FROM performance_schema.file_summary_by_instance\G
...
*************************** 2\. row ***************************
                FILE_NAME: /var/mysql/share/english/errmsg.sys
               EVENT_NAME: wait/io/file/sql/ERRMSG
               EVENT_NAME: wait/io/file/sql/ERRMSG
    OBJECT_INSTANCE_BEGIN: 4686193384
               COUNT_STAR: 5
           SUM_TIMER_WAIT: 13990154448
           MIN_TIMER_WAIT: 26349624
           AVG_TIMER_WAIT: 2798030607
           MAX_TIMER_WAIT: 8150662536
...

每个文件 I/O 汇总表都有一个或多个分组列，指示表如何聚合事件。事件名称指的是setup_instruments表中事件仪器的名称：

  • file_summary_by_event_name有一个EVENT_NAME列。每行总结了给定事件名称的事件。

  • file_summary_by_instance有FILE_NAME、EVENT_NAME和OBJECT_INSTANCE_BEGIN列。每行总结了给定文件和事件名称的事件。

每个文件 I/O 汇总表都有以下包含聚合值的汇总列。一些列更通用，其值与更细粒度列的值之和相同。通过这种方式，高级别的聚合可以直接使用，无需用户定义的视图来汇总较低级别的列。

  • COUNT_STAR、SUM_TIMER_WAIT、MIN_TIMER_WAIT、AVG_TIMER_WAIT、MAX_TIMER_WAIT

    这些列汇总所有 I/O 操作。

  • COUNT_READ、SUM_TIMER_READ、MIN_TIMER_READ、AVG_TIMER_READ、MAX_TIMER_READ、SUM_NUMBER_OF_BYTES_READ

    这些列汇总所有读操作，包括FGETS、FGETC、FREAD和READ。

  • COUNT_WRITE、SUM_TIMER_WRITE、MIN_TIMER_WRITE、AVG_TIMER_WRITE、MAX_TIMER_WRITE、SUM_NUMBER_OF_BYTES_WRITE

    这些列汇总所有写操作，包括FPUTS、FPUTC、FPRINTF、VFPRINTF、FWRITE和PWRITE。

  • COUNT_MISC、SUM_TIMER_MISC、MIN_TIMER_MISC、AVG_TIMER_MISC、MAX_TIMER_MISC

    这些列汇总所有其他 I/O 操作，包括CREATE、DELETE、OPEN、CLOSE、STREAM_OPEN、STREAM_CLOSE、SEEK、TELL、FLUSH、STAT、FSTAT、CHSIZE、RENAME和SYNC。这些操作没有字节计数。

文件 I/O 汇总表具有以下索引：

  • file_summary_by_event_name:

    • 主键在(EVENT_NAME)

  • file_summary_by_instance:

    • 主键在(OBJECT_INSTANCE_BEGIN)

    • 索引在(FILE_NAME)

    • 索引在(EVENT_NAME)

TRUNCATE TABLE允许用于文件 I/O 汇总表。它将汇总列重置为零，而不是删除行。

MySQL 服务器使用多种技术来避免通过缓存从文件中读取的信息进行 I/O 操作，因此可能会出现您预期会导致 I/O 事件的语句实际上并未执行 I/O 操作。您可以通过刷新缓存或重新启动服务器来确保发生 I/O 操作以重置其状态。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-table-wait-summary-tables.html

29.12.20.8 表 I/O 和锁等待摘要表

以下部分描述了表 I/O 和锁等待摘要表：

  • 按索引使用汇总的表 I/O 等待摘要：每个索引的表 I/O 等待

  • 按表汇总的表 I/O 等待摘要：每个表的表 I/O 等待

  • 按表汇总的表锁等待摘要：每个表的表锁等待

29.12.20.8.1 按表汇总的表 I/O 等待摘要表

按表汇总的表 I/O 等待摘要表汇总了所有表 I/O 等待事件，由wait/io/table/sql/handler工具生成。按表进行分组。

按表汇总的表 I/O 等待摘要表具有以下分组列，用于指示表如何汇总事件：OBJECT_TYPE、OBJECT_SCHEMA和OBJECT_NAME。这些列的含义与events_waits_current表中的含义相同。它们标识适用于哪个表的行。

按表汇总的表 I/O 等待摘要具有以下包含汇总值的摘要列。如列描述中所示，一些列更为通用，其值与更细粒度列的值之和相同。例如，汇总所有写入的列包含聚合插入、更新和删除的相应列的总和。通过这种方式，高级别的聚合直接可用，无需用户定义的视图来汇总低级别列���

  • COUNT_STAR, SUM_TIMER_WAIT, MIN_TIMER_WAIT, AVG_TIMER_WAIT, MAX_TIMER_WAIT

    这些列汇总了所有 I/O 操作。它们与相应的*xxx*_READ和*xxx*_WRITE列的总和相同。

  • COUNT_READ, SUM_TIMER_READ, MIN_TIMER_READ, AVG_TIMER_READ, MAX_TIMER_READ

    这些列汇总了所有读操作。它们与相应的*xxx*_FETCH列的总和相同。

  • COUNT_WRITE, SUM_TIMER_WRITE, MIN_TIMER_WRITE, AVG_TIMER_WRITE, MAX_TIMER_WRITE

    这些列汇总了所有写操作。它们与相应的*xxx*_INSERT、*xxx*_UPDATE和*xxx*_DELETE列的总和��同。

  • COUNT_FETCH, SUM_TIMER_FETCH, MIN_TIMER_FETCH, AVG_TIMER_FETCH, MAX_TIMER_FETCH

    这些列汇总了所有提取操作。

  • COUNT_INSERT, SUM_TIMER_INSERT, MIN_TIMER_INSERT, AVG_TIMER_INSERT, MAX_TIMER_INSERT

    这些列汇总了所有插入操作。

  • COUNT_UPDATE, SUM_TIMER_UPDATE, MIN_TIMER_UPDATE, AVG_TIMER_UPDATE, MAX_TIMER_UPDATE

    这些列汇总了所有更新操作。

  • COUNT_DELETE, SUM_TIMER_DELETE, MIN_TIMER_DELETE, AVG_TIMER_DELETE, MAX_TIMER_DELETE

    这些列汇总了所有删除操作。

table_io_waits_summary_by_table表具有以下索引：

  • (OBJECT_TYPE, OBJECT_SCHEMA, OBJECT_NAME)上的唯一索引

TRUNCATE TABLE允许用于表 I/O 汇总表。它将汇总列重置为零，而不是删除行。截断此表还会截断table_io_waits_summary_by_index_usage表。

29.12.20.8.2 table_io_waits_summary_by_index_usage 表

table_io_waits_summary_by_index_usage表汇总了所有表索引 I/O 等待事件，由wait/io/table/sql/handler工具生成。分组是按表索引进行的。

table_io_waits_summary_by_index_usage的列几乎与table_io_waits_summary_by_table相同。唯一的区别是额外的分组列INDEX_NAME，对应于记录表 I/O 等待事件时使用的索引名称：

  • PRIMARY的值表示表 I/O 使用了主索引。

  • NULL的值表示表 I/O 未使用索引。

  • 插入计入INDEX_NAME = NULL。

table_io_waits_summary_by_index_usage 表具有这些索引：

  • 在 (OBJECT_TYPE, OBJECT_SCHEMA, OBJECT_NAME, INDEX_NAME) 上的唯一索引

对于表 I/O 摘要表，允许 TRUNCATE TABLE。它将摘要列重置为零，而不是删除行。此表也通过截断 table_io_waits_summary_by_table 表而被截断。更改表的索引结构的 DDL 操作可能会导致每个索引的统计信息被重置。

29.12.20.8.3 table_lock_waits_summary_by_table 表

table_lock_waits_summary_by_table 表聚合了所有表锁等待事件，由 wait/lock/table/sql/handler 工具生成。分组是按表进行的。

此表包含有关内部和外部锁的信息：

  • 内部锁对应于 SQL 层中的锁。目前通过调用 thr_lock() 实现。在事件行中，这些锁由 OPERATION 列区分，该列具有以下值之一：

    read normal
read with shared locks
read high priority
read no insert
write allow write
write concurrent insert
write delayed
write low priority
write normal

  • 外部锁对应于存储引擎层中的锁。目前通过调用 handler::external_lock() 实现。在事件行中，这些锁由 OPERATION 列区分，该列具有以下值之一：

    read external
write external

table_lock_waits_summary_by_table 表具有这些分组列，用于指示表如何聚合事件：OBJECT_TYPE、OBJECT_SCHEMA 和 OBJECT_NAME。这些列的含义与 events_waits_current 表中的含义相同。它们标识适用于哪个表的行。

table_lock_waits_summary_by_table 包含以下汇总列，其中包含聚合值。 如列描述中所示，某些列更一般，其值与更细粒度列的值之和相同。 例如，聚合所有锁的列包含聚合读锁和写锁的相应列之和。 通过这种方式，高级别的聚合可直接使用，无需用户定义的视图来汇总较低级别的列。

  • COUNT_STAR, SUM_TIMER_WAIT, MIN_TIMER_WAIT, AVG_TIMER_WAIT, MAX_TIMER_WAIT

    这些列聚合所有锁操作。 它们与相应的 *xxx*_READ 和 *xxx*_WRITE 列的和相同。

  • COUNT_READ, SUM_TIMER_READ, MIN_TIMER_READ, AVG_TIMER_READ, MAX_TIMER_READ

    这些列聚合所有读锁操作。 它们与相应的 *xxx*_READ_NORMAL, *xxx*_READ_WITH_SHARED_LOCKS, *xxx*_READ_HIGH_PRIORITY, 和 *xxx*_READ_NO_INSERT 列的和相同。

  • COUNT_WRITE, SUM_TIMER_WRITE, MIN_TIMER_WRITE, AVG_TIMER_WRITE, MAX_TIMER_WRITE

    这些列聚合所有写锁操作。 它们与相应的 *xxx*_WRITE_ALLOW_WRITE, *xxx*_WRITE_CONCURRENT_INSERT, *xxx*_WRITE_LOW_PRIORITY, 和 *xxx*_WRITE_NORMAL 列的和相同。

  • COUNT_READ_NORMAL, SUM_TIMER_READ_NORMAL, MIN_TIMER_READ_NORMAL, AVG_TIMER_READ_NORMAL, MAX_TIMER_READ_NORMAL

    这些列聚合内部读锁。

  • COUNT_READ_WITH_SHARED_LOCKS, SUM_TIMER_READ_WITH_SHARED_LOCKS, MIN_TIMER_READ_WITH_SHARED_LOCKS, AVG_TIMER_READ_WITH_SHARED_LOCKS, MAX_TIMER_READ_WITH_SHARED_LOCKS

    这些列聚合内部读锁。

  • COUNT_READ_HIGH_PRIORITY, SUM_TIMER_READ_HIGH_PRIORITY, MIN_TIMER_READ_HIGH_PRIORITY, AVG_TIMER_READ_HIGH_PRIORITY, MAX_TIMER_READ_HIGH_PRIORITY

    这些列聚合内部读锁。

  • COUNT_READ_NO_INSERT, SUM_TIMER_READ_NO_INSERT, MIN_TIMER_READ_NO_INSERT, AVG_TIMER_READ_NO_INSERT, MAX_TIMER_READ_NO_INSERT

    这些列聚合内部读锁。

  • COUNT_READ_EXTERNAL, SUM_TIMER_READ_EXTERNAL, MIN_TIMER_READ_EXTERNAL, AVG_TIMER_READ_EXTERNAL, MAX_TIMER_READ_EXTERNAL

    这些列聚合外部读锁。

  • COUNT_WRITE_ALLOW_WRITE, SUM_TIMER_WRITE_ALLOW_WRITE, MIN_TIMER_WRITE_ALLOW_WRITE, AVG_TIMER_WRITE_ALLOW_WRITE, MAX_TIMER_WRITE_ALLOW_WRITE

    这些列聚合内部写锁。

  • COUNT_WRITE_CONCURRENT_INSERT, SUM_TIMER_WRITE_CONCURRENT_INSERT, MIN_TIMER_WRITE_CONCURRENT_INSERT, AVG_TIMER_WRITE_CONCURRENT_INSERT, MAX_TIMER_WRITE_CONCURRENT_INSERT

    这些列聚合内部写锁。

  • COUNT_WRITE_LOW_PRIORITY, SUM_TIMER_WRITE_LOW_PRIORITY, MIN_TIMER_WRITE_LOW_PRIORITY, AVG_TIMER_WRITE_LOW_PRIORITY, MAX_TIMER_WRITE_LOW_PRIORITY

    这些列聚合了内部写锁。

  • COUNT_WRITE_NORMAL, SUM_TIMER_WRITE_NORMAL, MIN_TIMER_WRITE_NORMAL, AVG_TIMER_WRITE_NORMAL, MAX_TIMER_WRITE_NORMAL

    这些列聚合了内部写锁。

  • COUNT_WRITE_EXTERNAL, SUM_TIMER_WRITE_EXTERNAL, MIN_TIMER_WRITE_EXTERNAL, AVG_TIMER_WRITE_EXTERNAL, MAX_TIMER_WRITE_EXTERNAL

    这些列聚合了外部写锁。

table_lock_waits_summary_by_table 表具有以下索引：

  • (OBJECT_TYPE, OBJECT_SCHEMA, OBJECT_NAME) 上的唯一索引

截断表 允许用于表锁摘要表。它将摘要列重置为零，而不是删除行。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-socket-summary-tables.html

29.12.20.9 套接字汇总表

这些套接字汇总表聚合计时器和字节计数信息，用于套接字操作：

  • socket_summary_by_event_name：聚合由wait/io/socket/*工具生成的计时器和字节计数统计信息，适用于所有套接字 I/O 操作，每个套接字工具。

  • socket_summary_by_instance：聚合由wait/io/socket/*工具生成的计时器和字节计数统计信息，适用于所有套接字 I/O 操作，每个套接字实例。当连接终止时，对应于其的socket_summary_by_instance中的行将被删除。

套接字汇总表不会聚合由idle事件生成的等待，而套接字在等待来自客户端的下一个请求时。对于idle事件的聚合，使用等待事件汇总表；参见第 29.12.20.1 节，“等待事件汇总表”。

每个套接字汇总表都有一个或多个分组列，指示表如何聚合事件。事件名称指的是setup_instruments表中事件工具的名称：

  • socket_summary_by_event_name有一个EVENT_NAME列。每行汇总给定事件名称的事件。

  • socket_summary_by_instance有一个OBJECT_INSTANCE_BEGIN列。每行汇总给定对象的事件。

每个套接字汇总表都有这些包含聚合值的汇总列：

  • COUNT_STAR, SUM_TIMER_WAIT, MIN_TIMER_WAIT, AVG_TIMER_WAIT, MAX_TIMER_WAIT

    这些列聚合所有操作。

  • COUNT_READ, SUM_TIMER_READ, MIN_TIMER_READ, AVG_TIMER_READ, MAX_TIMER_READ, SUM_NUMBER_OF_BYTES_READ

    这些列聚合所有接收操作（RECV，RECVFROM和RECVMSG）。

  • COUNT_WRITE, SUM_TIMER_WRITE, MIN_TIMER_WRITE, AVG_TIMER_WRITE, MAX_TIMER_WRITE, SUM_NUMBER_OF_BYTES_WRITE

    这些列聚合所有发送操作（SEND，SENDTO和SENDMSG）。

  • COUNT_MISC, SUM_TIMER_MISC, MIN_TIMER_MISC, AVG_TIMER_MISC, MAX_TIMER_MISC

    这些列聚合所有其他套接字操作，如CONNECT，LISTEN，ACCEPT，CLOSE和SHUTDOWN。这些操作没有字节计数。

socket_summary_by_instance表还具有一个EVENT_NAME列，指示套接字的类别：client_connection、server_tcpip_socket、server_unix_socket。可以根据此列进行分组，例如将客户端活动与服务器监听套接字的活动隔离开来。

套接字摘要表具有以下索引：

  • socket_summary_by_event_name:

    • 主键为(EVENT_NAME)

  • socket_summary_by_instance:

    • 主键为(OBJECT_INSTANCE_BEGIN)

    • 索引为(EVENT_NAME)

允许对套接字摘要表执行TRUNCATE TABLE。除了events_statements_summary_by_digest之外，它将摘要列重置为零，而不是删除行。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-memory-summary-tables.html

29.12.20.10 内存摘要表

性能模式仪表盘记录内存使用情况并汇总内存使用统计信息，详细说明以下因素：

  • 使用的内存类型（各种缓存，内部缓冲区等）

  • 执行内存操作的线程，帐户，用户，主机

性能模式仪表盘记录了内存使用的以下方面。

  • 使用的内存大小

  • 操作计数

  • 低水位和高水位

内存大小有助于理解或调整服务器的内存消耗。

操作计数有助于理解或调整服务器对内存分配器施加的整体压力，这对性能有影响。一百万次分配一个字节不同于一次分配一百万字节；跟踪两种大小和计数可以揭示差异。

低水位和高水位对于检测工作负载峰值、整体���作负载稳定性和可能的内存泄漏至关重要。

内存摘要表不包含时间信息，因为内存事件没有时间。

有关收集内存使用数据的信息，请参阅内存仪表行为。

示例内存事件摘要信息：

mysql> SELECT *
       FROM performance_schema.memory_summary_global_by_event_name
       WHERE EVENT_NAME = 'memory/sql/TABLE'\G
*************************** 1\. row ***************************
                  EVENT_NAME: memory/sql/TABLE
                 COUNT_ALLOC: 1381
                  COUNT_FREE: 924
   SUM_NUMBER_OF_BYTES_ALLOC: 2059873
    SUM_NUMBER_OF_BYTES_FREE: 1407432
              LOW_COUNT_USED: 0
          CURRENT_COUNT_USED: 457
             HIGH_COUNT_USED: 461
    LOW_NUMBER_OF_BYTES_USED: 0
CURRENT_NUMBER_OF_BYTES_USED: 652441
   HIGH_NUMBER_OF_BYTES_USED: 669269

每个内存摘要表都有一个或多个分组列，指示表如何聚合事件。事件名称指的是setup_instruments表中事件仪表的名称：

每个内存摘要表都有这些包含聚合值的摘要列：

  • COUNT_ALLOC，COUNT_FREE

    内存分配和内存释放函数调用次数的聚合数。

  • SUM_NUMBER_OF_BYTES_ALLOC，SUM_NUMBER_OF_BYTES_FREE

    已分配和释放内存块的聚合大小。

  • CURRENT_COUNT_USED

    尚未释放的当前分配块的聚合数量。这是一个便利列，等于 COUNT_ALLOC - COUNT_FREE。

  • CURRENT_NUMBER_OF_BYTES_USED

    尚未释放的当前分配内存块的聚合大小。这是一个便利列，等于 SUM_NUMBER_OF_BYTES_ALLOC - SUM_NUMBER_OF_BYTES_FREE。

  • LOW_COUNT_USED，HIGH_COUNT_USED

    与CURRENT_COUNT_USED列对应的低水位和高水位标记。

  • LOW_NUMBER_OF_BYTES_USED，HIGH_NUMBER_OF_BYTES_USED

    与CURRENT_NUMBER_OF_BYTES_USED列对应的低水位和高水位标记。

内存摘要表具有以下索引：

  • memory_summary_by_account_by_event_name:

    • 主键为(USER, HOST, EVENT_NAME)

  • memory_summary_by_host_by_event_name:

    • 主键为(HOST, EVENT_NAME)

  • memory_summary_by_thread_by_event_name:

    • 主键为(THREAD_ID, EVENT_NAME)

  • memory_summary_by_user_by_event_name:

    • 主键为(USER, EVENT_NAME)

  • memory_summary_global_by_event_name:

    • 主键为(EVENT_NAME)

TRUNCATE TABLE 允许用于内存摘要表。其效果如下：

  • 一般来说，截断会重置统计数据的基线，但不会改变服务器状态。也就是说，截断内存表不会释放内存。

  • COUNT_ALLOC 和 COUNT_FREE 通过减少相同值来重置为新基线。

  • 同样，SUM_NUMBER_OF_BYTES_ALLOC 和 SUM_NUMBER_OF_BYTES_FREE 重置为新基线。

  • LOW_COUNT_USED 和 HIGH_COUNT_USED 重置为 CURRENT_COUNT_USED。

  • LOW_NUMBER_OF_BYTES_USED 和 HIGH_NUMBER_OF_BYTES_USED 重置为 CURRENT_NUMBER_OF_BYTES_USED。

此外，每个按帐户、主机、用户或线程聚合的内存摘要表在其依赖的连接表被截断或memory_summary_global_by_event_name 被截断时会被隐式截断。详情请参见第 29.12.8 节，“性能模式连接表”。

内存工具行为

内存工具在setup_instruments表中列出，并具有形式为memory/*code_area*/*instrument_name*的名称。内存工具默认启用。

以memory/performance_schema/前缀命名的工具公开了性能模式内部缓冲区分配了多少内存。memory/performance_schema/工具是内置的，始终启用，并且无法在启动时或运行时禁用。内置内存工具仅在memory_summary_global_by_event_name表中显示。

要在服务器启动时控制内存工具状态，请在您的my.cnf文件中使用以下行：

  • 启用：

    [mysqld]
performance-schema-instrument='memory/%=ON'

  • 禁用：

    [mysqld]
performance-schema-instrument='memory/%=OFF'

要在运行时控制内存工具状态，请更新setup_instruments表中相关工具的ENABLED列：

  • 启用：

    UPDATE performance_schema.setup_instruments
SET ENABLED = 'YES'
WHERE NAME LIKE 'memory/%';

  • 禁用：

    UPDATE performance_schema.setup_instruments
SET ENABLED = 'NO'
WHERE NAME LIKE 'memory/%';

对于内存工具，setup_instruments中的TIMED列被忽略，因为内存操作不计时。

当服务器中的线程执行已被工具化的内存分配时，适用以下规则：

  • 如果线程未被工具化或内存工具未启用，则分配的内存块不会被工具化。

  • 否则（即线程和工具均已启用），分配的内存块将被工具化。

对于释放，适用以下规则：

  • 如果内存分配操作已被工具化，则无论当前工具或线程启用状态如何，相应的释放操作都会被工具化。

  • 如果内存分配操作未被工具化，则无论当前工具或线程启用状态如何，相应的释放操作都不会被工具化。

对于每个线程的统计信息，适用以下规则。

当分配大小为N的工具化内存块时，性能模式将对内存摘要表列进行以下更新：

  • COUNT_ALLOC：增加 1

  • CURRENT_COUNT_USED：增加 1

  • HIGH_COUNT_USED：如果CURRENT_COUNT_USED是新的最大值，则增加

  • SUM_NUMBER_OF_BYTES_ALLOC：增加N

  • CURRENT_NUMBER_OF_BYTES_USED：增加N

  • HIGH_NUMBER_OF_BYTES_USED：如果CURRENT_NUMBER_OF_BYTES_USED是新的最大值，则增加

当工具化的内存块被释放时，性能模式将对内存摘要表列进行以下更新：

  • COUNT_FREE：增加 1

  • CURRENT_COUNT_USED：减少 1

  • LOW_COUNT_USED：如果CURRENT_COUNT_USED是新的最小值，则减少

  • SUM_NUMBER_OF_BYTES_FREE：增加N

  • CURRENT_NUMBER_OF_BYTES_USED：减少N

  • LOW_NUMBER_OF_BYTES_USED：如果CURRENT_NUMBER_OF_BYTES_USED是新的最小值，则减少

对于更高级别的聚合（全局、按账户、按用户、按主机），低水位和高水位的规则与预期相同。

  • LOW_COUNT_USED 和 LOW_NUMBER_OF_BYTES_USED 是较低的估计值。性能模式报告的值保证小于或等于运行时实际使用的内存的最低计数或大小。

  • HIGH_COUNT_USED 和 HIGH_NUMBER_OF_BYTES_USED 是较高的估计值。性能模式报告的值保证大于或等于运行时实际使用的内存的最高计数或大小。

对于除memory_summary_global_by_event_name之外的摘要表中的较低估计值，如果内存所有权在线程之间转移，则值可能为负。

这里是一个估算计算的示例；但请注意，估算实现可能会发生变化：

线程 1 在执行过程中使用的内存范围为 1MB 到 2MB，如memory_summary_by_thread_by_event_name表的 LOW_NUMBER_OF_BYTES_USED 和 HIGH_NUMBER_OF_BYTES_USED 列所报告的那样。

线程 2 在执行过程中使用的内存范围为 10MB 到 12MB，如同报告的那样。

当这两个线程属于同一用户账户时，每个账户摘要估计该账户在 11MB 到 14MB 的内存范围内。也就是说，较高级别聚合的 LOW_NUMBER_OF_BYTES_USED 是每个 LOW_NUMBER_OF_BYTES_USED 的总和（假设最坏情况）。同样，较高级别聚合的 HIGH_NUMBER_OF_BYTES_USED 是每个 HIGH_NUMBER_OF_BYTES_USED 的总和（假设最坏情况）。

11MB 是一个较低的估计值，只有当两个线程同时达到低使用标记时才会发生。

14MB 是一个较高的估计值，只有当两个线程同时达到高使用标记时才会发生。

该账户的实际内存使用量可能在 11.5MB 到 13.5MB 的范围内。

对于容量规划，报告最坏情况实际上是期望的行为，因为它展示了当会话不相关时可能发生的情况，这通常是情况。

dev.mysql.com/doc/refman/8.0/en/performance-schema-error-summary-tables.html

29.12.20.11 错误摘要表

性能模式维护了用于聚合关于服务器错误（和警告）的统计信息的摘要表。有关服务器错误的列表，请参见服务器错误消息参考。

错误信息的收集由默认启用的 error 仪器控制。不收集时间信息。

每个错误摘要表都有三列用于标识错误：

  • ERROR_NUMBER 是数字错误值。该值是唯一的。

  • ERROR_NAME 是与 ERROR_NUMBER 值对应的符号错误名称。该值是唯一的。

  • SQLSTATE 是与 ERROR_NUMBER 值对应的 SQLSTATE 值。该值不一定是唯一的。

例如，如果 ERROR_NUMBER 是 1050，ERROR_NAME 是 ER_TABLE_EXISTS_ERROR，SQLSTATE 是 42S01。

示例错误事件摘要信息：

mysql> SELECT *
       FROM performance_schema.events_errors_summary_global_by_error
       WHERE SUM_ERROR_RAISED <> 0\G
*************************** 1\. row ***************************
     ERROR_NUMBER: 1064
       ERROR_NAME: ER_PARSE_ERROR
        SQL_STATE: 42000
 SUM_ERROR_RAISED: 1
SUM_ERROR_HANDLED: 0
       FIRST_SEEN: 2016-06-28 07:34:02
        LAST_SEEN: 2016-06-28 07:34:02
*************************** 2\. row ***************************
     ERROR_NUMBER: 1146
       ERROR_NAME: ER_NO_SUCH_TABLE
        SQL_STATE: 42S02
 SUM_ERROR_RAISED: 2
SUM_ERROR_HANDLED: 0
       FIRST_SEEN: 2016-06-28 07:34:05
        LAST_SEEN: 2016-06-28 07:36:18
*************************** 3\. row ***************************
     ERROR_NUMBER: 1317
       ERROR_NAME: ER_QUERY_INTERRUPTED
        SQL_STATE: 70100
 SUM_ERROR_RAISED: 1
SUM_ERROR_HANDLED: 0
       FIRST_SEEN: 2016-06-28 11:01:49
        LAST_SEEN: 2016-06-28 11:01:49

每个错误摘要表都有一个或多个分组列，指示表如何聚合错误：

  • events_errors_summary_by_account_by_error 有 USER、HOST 和 ERROR_NUMBER 列。每行总结了给定帐户（用户和主机组合）和错误的事件。

  • events_errors_summary_by_host_by_error 有 HOST 和 ERROR_NUMBER 列。每行总结了给定主机和错误的事件。

  • events_errors_summary_by_thread_by_error 有 THREAD_ID 和 ERROR_NUMBER 列。每行总结了给定线程和错误的事件。

  • events_errors_summary_by_user_by_error 有 USER 和 ERROR_NUMBER 列。每行总结了给定用户和错误的事件。

  • events_errors_summary_global_by_error 有一个 ERROR_NUMBER 列。每行总结了给定错误的事件。

每个错误摘要表都有包含聚合值的这些摘要列：

  • SUM_ERROR_RAISED

    此列聚合错误发生的次数。

  • SUM_ERROR_HANDLED

    此列聚合了通过 SQL 异常处理程序处理的错误次数。

  • FIRST_SEEN、LAST_SEEN

    时间戳指示错误首次出现和最近出现的时间。

每个错误摘要表中的NULL行用于聚合超出仪表化错误范围的所有错误的统计信息。例如，如果 MySQL Server 错误范围从M到N，并且引发了一个不在该范围内的编号为Q的错误，则该错误将在NULL行中聚合。NULL行是具有ERROR_NUMBER=0，ERROR_NAME=NULL和SQLSTATE=NULL的行。

错误摘要表具有以下索引：

  • events_errors_summary_by_account_by_error:

    • 主键为 (USER, HOST, ERROR_NUMBER)

  • events_errors_summary_by_host_by_error:

    • 主键为 (HOST, ERROR_NUMBER)

  • events_errors_summary_by_thread_by_error:

    • 主键为 (THREAD_ID, ERROR_NUMBER)

  • events_errors_summary_by_user_by_error:

    • 主键为 (USER, ERROR_NUMBER)

  • events_errors_summary_global_by_error:

    • 主键为 (ERROR_NUMBER)

允许对错误摘要表执行TRUNCATE TABLE。它具有以下效果：

  • 对于未按帐户、主机或用户聚合的摘要表，截断将摘要列重置为零或NULL，而不是删除行。

  • 对于按帐户、主机或用户聚合的摘要表，截断将删除没有连接的帐户、主机或用户的行，并将剩余行的摘要列重置为零或NULL。

此外，通过截断依赖的连接表或截断events_errors_summary_global_by_error来隐式截断每个按帐户、主机、用户或线程聚合的错误摘要表。有关详细信息，请参见第 29.12.8 节“性能模式连接表”。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-status-variable-summary-tables.html

29.12.20.12 状态变量摘要表

Performance Schema 使状态变量信息在第 29.12.15 节“Performance Schema 状态变量表”中描述的表中可用。它还使聚合状态变量信息在此处描述的摘要表中可用。每个状态变量摘要表都有一个或多个分组列，用于指示表如何聚合状态值：

  • status_by_account具有USER，HOST和VARIABLE_NAME列，用于按帐户总结状态变量。

  • status_by_host具有HOST和VARIABLE_NAME列，用于按客户端连接的主机总结状态变量。

  • status_by_user具有USER和VARIABLE_NAME列，用于按客户端用户名称总结状态变量。

每个状态变量摘要表都有包含聚合值的此摘要列：

  • VARIABLE_VALUE

    活��和终止会话的聚合状态变量值。

状态变量摘要表具有以下索引：

这些表中“帐户”的含义类似于 MySQL 授予表中mysql系统数据库中的含义，即该术语指的是用户和主机值的组合。它们的区别在于，对于授予表，帐户的主机部分可以是模式，而对于 Performance Schema 表，主机值始终是特定的非模式主机名。

当会话终止时，会收集帐户状态。会话状态计数器将添加到全局状态计数器和相应的帐户状态计数器中。如果未收集帐户统计信息，则会话状态将添加到主机和用户状态中，如果已收集主机和用户状态。

如果分别将performance_schema_accounts_size、performance_schema_hosts_size和performance_schema_users_size系统变量设置为 0，则不会收集帐户、主机和用户统计信息。

性能模式支持以下状态变量摘要表的TRUNCATE TABLE；在所有情况下，活动会话的状态不受影响：

  • status_by_account: 将来自已终止会话的帐户状态聚合到用户和主机状态中，然后重置帐户状态。

  • status_by_host: 重置来自已终止会话的主机状态的聚合状态。

  • status_by_user: 重置来自已终止会话的用户状态。

FLUSH STATUS 将所有活动会话的会话状态添加到全局状态变量中，重置所有活动会话的状态，并重置从断开会话中聚合的帐户、主机和用户状态值。

29.12.21 性能模式杂项表

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-miscellaneous-tables.html

29.12.21.1 component_scheduler_tasks 表

29.12.21.2 error_log 表

29.12.21.3 host_cache 表

29.12.21.4 innodb_redo_log_files 表

29.12.21.5 log_status 表

29.12.21.6 performance_timers 表

29.12.21.7 processlist 表

29.12.21.8 threads 表

29.12.21.9 tls_channel_status 表

29.12.21.10 user_defined_functions 表

以下各节描述了不属于前述各节讨论的表类别的表：

  • component_scheduler_tasks: 每个计划任务的当前状态。

  • error_log: 写入错误日志的最新事件。

  • host_cache: 内部主机缓存的信息。

  • innodb_redo_log_files: InnoDB 重做日志文件的信息。

  • log_status: 用于备份目的的服务器日志信息。

  • performance_timers: 可用的事件计时器。

  • processlist: 有关服务器进程的信息。

  • threads: 有关服务器线程的信息。

  • tls_channel_status: 连接接口的 TLS 上下文属性。

  • user_defined_functions: 组件、插件或CREATE FUNCTION语句注册的可加载函数。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-component-scheduler-tasks-table.html

29.12.21.1 组件调度器任务表

component_scheduler_tasks表为每个预定任务包含一行。每行包含关于应用程序、组件和插件可以实现的任务的进行中进展的信息，可选地使用scheduler组件（参见第 7.5.5 节，“调度器组件”）。例如，audit_log服务器插件利用scheduler组件定期运行其内存缓存的刷新：

mysql> select * from performance_schema.component_scheduler_tasks\G
*************************** 1\. row ***************************
            NAME: plugin_audit_log_flush_scheduler
          STATUS: WAITING
         COMMENT: Registered by the audit log plugin. Does a periodic refresh of the audit log 
                  in-memory rules cache by calling audit_log_flush
INTERVAL_SECONDS: 100
       TIMES_RUN: 5
    TIMES_FAILED: 0 1 row in set (0.02 sec)

component_scheduler_tasks表具有以下列：

  • NAME

    在注册时提供的名称。

  • STATUS

    值为：

    • 如果任务处于活动状态并正在执行，则为RUNNING。

    • 如果任务处于空闲状态并等待后台线程接手或等待下一次运行时间到来，则为WAITING。

  • COMMENT

    由应用程序、组件或插件提供的编译时注释。在前面的示例中，MySQL 企业审计使用名为audit_log的服务器插件提供注释。

  • INTERVAL_SECONDS

    以秒为单位运行任务的时间，由应用程序、组件或插件提供。MySQL 企业审计允许您使用audit_log_flush_interval_seconds系统变量指定此值。

  • TIMES_RUN

    每次任务成功运行时递增的计数器。它会循环。

  • TIMES_FAILED

    每次任务执行失败时递增的计数器。它会循环。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-error-log-table.html

29.12.21.2 错误日志表

MySQL 服务器维护的日志之一是错误日志，用于写入诊断消息（参见 Section 7.4.2, “错误日志”）。通常，服务器将诊断写入服务器主机上的文件或系统日志服务。从 MySQL 8.0.22 开始，根据错误日志配置，服务器还可以将最近的错误事件写入性能模式error_log表。因此，授予SELECT权限给error_log表，使客户端和应用程序可以使用 SQL 查询访问错误日志内容，从而使 DBA 能够提供对日志的访问，而无需在服务器主机上允许直接文件系统访问。

error_log表支持基于其更结构化列的专注查询。它还包括错误消息的完整文本，以支持更自由形式的分析。

表实现使用固定大小的内存环形缓冲区，旧事件会根据需要自动丢弃以为新事件腾出空间。

示例error_log内容：

mysql> SELECT * FROM performance_schema.error_log\G
*************************** 1\. row ***************************
    LOGGED: 2020-08-06 09:25:00.338624
 THREAD_ID: 0
      PRIO: System
ERROR_CODE: MY-010116
 SUBSYSTEM: Server
      DATA: mysqld (mysqld 8.0.23) starting as process 96344
*************************** 2\. row ***************************
    LOGGED: 2020-08-06 09:25:00.363521
 THREAD_ID: 1
      PRIO: System
ERROR_CODE: MY-013576
 SUBSYSTEM: InnoDB
      DATA: InnoDB initialization has started.
...
*************************** 65\. row ***************************
    LOGGED: 2020-08-06 09:25:02.936146
 THREAD_ID: 0
      PRIO: Warning
ERROR_CODE: MY-010068
 SUBSYSTEM: Server
      DATA: CA certificate /var/mysql/sslinfo/cacert.pem is self signed.
...
*************************** 89\. row ***************************
    LOGGED: 2020-08-06 09:25:03.112801
 THREAD_ID: 0
      PRIO: System
ERROR_CODE: MY-013292
 SUBSYSTEM: Server
      DATA: Admin interface ready for connections, address: '127.0.0.1' port: 33062

error_log表具有以下列。如描述中所示，除了DATA列外，所有列都对应于底层错误事件结构的字段，该结构在 Section 7.4.2.3, “错误事件字段”中有描述。

  • LOGGED

    事件时间戳，精确到微秒。LOGGED对应于错误事件的time字段，尽管可能存在某些潜在差异：

    要在与错误日志文件中显示的相同时区中显示LOGGED值，请首先设置会话时区如下：

    SET @@session.time_zone = @@global.log_timestamps;

    如果log_timestamps值为UTC，并且您的系统未安装命名时区支持（参见 Section 7.1.15, “MySQL Server Time Zone Support”），请像这样设置时区：

    SET @@session.time_zone = '+00:00';

  • THREAD_ID

    MySQL 线程 ID。THREAD_ID对应于错误事件的thread字段。

    在性能模式中，error_log表中的THREAD_ID列与threads表的PROCESSLIST_ID列最相似：

    • 对于前台线程，THREAD_ID和PROCESSLIST_ID表示连接标识符。这与INFORMATION_SCHEMA PROCESSLIST表中的ID列中显示的值相同，在SHOW PROCESSLIST输出中显示的Id列中显示，并在线程内由CONNECTION_ID()函数返回。

    • 对于后台线程，THREAD_ID为 0，PROCESSLIST_ID为NULL。

    除了error_log之外，许多性能模式表都有一个名为THREAD_ID的列，但在这些表中，THREAD_ID列是性能模式内部分配的值。

  • PRIO

    事件优先级。允许的值为System、Error、Warning、Note。PRIO列基于错误事件的label字段，该字段本身基于底层数字prio字段值。

  • ERROR_CODE

    数字事件错误代码。ERROR_CODE对应于错误事件的error_code字段。

  • SUBSYSTEM

    事件发生的子系统。SUBSYSTEM对应于错误事件的subsystem字段。

  • DATA

    错误事件的文本表示。此值的格式取决于生成error_log行的日志接收组件生成的格式。例如，如果日志接收组件是log_sink_internal或log_sink_json，DATA值分别表示传统格式或 JSON 格式的错误事件。（参见 Section 7.4.2.9, “Error Log Output Format”.）

    因为错误日志可以重新配置以更改提供行给error_log表的日志接收组件，并且不同的接收组件生成不同的输出格式，所以在不同时间写入error_log表的行可能具有不同的DATA格式。

error_log表具有以下索引：

  • 在(LOGGED)上的主键

  • 在(THREAD_ID)上的索引

  • 在(PRIO)上的索引

  • 在(ERROR_CODE)上的索引

  • 在(SUBSYSTEM)上的索引

不允许对error_log表进行TRUNCATE TABLE操作。

error_log表的实现和配置

性能模式error_log表由写入表中的错误日志事件的错误日志接收组件填充，同时还写入格式化的错误事件到错误日志中。日志接收器通过性能模式支持有两个部分：

  • 日志接收组件可以在发生时将新的错误事件写入error_log表。

  • 日志接收组件可以提供用于提取先前编写的错误消息的解析器。这使得服务器实例能够读取前一个实例写入错误日志文件的消息，并将它们存储在error_log表中。前一个实例在关闭期间写入的消息可能有助于诊断关闭发生的原因。

目前，传统格式的log_sink_internal和 JSON 格式的log_sink_json接收器支持将新事件写入error_log表，并提供解析器用于读取先前编写的错误日志文件。

log_error_services系统变量控制着哪些日志组件用于错误日志记录。其值是一个管道，当发生错误事件时，按从左到右的顺序执行日志过滤器和日志接收组件。log_error_services的值与填充error_log表相关如下：

  • 在启动时，服务器检查log_error_services的值，并从中选择最左边满足以下条件的日志接收器：

    • 支持error_log表并提供解析器的接收器。

    • 如果没有，支持error_log表但不提供解析器的接收器。

    如果没有日志接收器满足这些条件，则error_log表保持为空。否则，如果接收器提供解析器并且日志配置使先前写入的错误日志文件可以被找到，则服务器使用接收器解析器读取文件的最后部分，并将其中包含的旧事件写入表中。然后，接收器会在事件发生时将新的错误事件写入表中。

  • 在运行时，如果log_error_services的值发生变化，服务器会再次检查它，这次寻找支持error_log表的最左边启用的日志接收器，无论它是否提供解析器。

    如果不存在这样的日志接收器，则不会将其他错误事件写入error_log表。否则，新配置的接收器会在事件发生时将新的错误事件写入表中。

任何影响写入错误日志的配置都会影响error_log表的内容。这包括诸如详细程度、消息抑制和消息过滤等设置。它还适用于从先前日志文件中启动时读取的信息。例如，在先前配置为低详细程度的服务器实例中未写入的消息，在当前配置为更高详细程度的实例读取文件时不会变得可用。

error_log表是一个固定大小的内存中的环形缓冲区的视图，旧事件会根据需要自动丢弃以腾出空间给新事件。如下表所示，几个状态变量提供有关进行中的error_log操作的信息。

状态变量 含义
Error_log_buffered_bytes 表中使用的字节
Error_log_buffered_events 表中存在的事件
Error_log_expired_events 从表中丢弃的事件
Error_log_latest_write 最后写入表的时间

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-host-cache-table.html

29.12.21.3 主机缓存表

MySQL 服务器维护一个内存中的主机缓存，其中包含客户端主机名和 IP 地址信息，并用于避免域名系统（DNS）查找。host_cache表公开了此缓存的内容。host_cache_size系统变量控制主机缓存的大小，以及host_cache表的大小。有关主机缓存的操作和配置信息，请参见第 7.1.12.3 节，“DNS 查找和主机缓存”。

因为host_cache表公开了主机缓存的内容，可以使用SELECT语句进行检查。这可能有助于诊断连接问题的原因。

host_cache表具有以下列：

  • IP

    以字符串形式表示连接到服务器的客户端的 IP 地址。

  • HOST

    客户端 IP 的解析 DNS 主机名，如果名称未知则为NULL。

  • HOST_VALIDATED

    客户端 IP 的 IP 到主机名到 IP DNS 解析是否成功。如果HOST_VALIDATED为YES，则HOST列用作对应于 IP 的主机名，以避免额外调用 DNS。当HOST_VALIDATED为NO时，将尝试为每个连接尝试进行 DNS 解析，直到最终以有效结果或永久错误完成。此信息使服务器能够在临时 DNS 故障期间避免缓存错误或缺失的主机名，这将永久地对客户端产生负面影响。

  • SUM_CONNECT_ERRORS

    被视为“阻塞”的连接错误数量（根据max_connect_errors系统变量进行评估）。仅计算协议握手错误，并且仅适用于通过验证的主机（HOST_VALIDATED = YES）。

    一旦给定主机的SUM_CONNECT_ERRORS达到max_connect_errors的值，来自该主机的新连接将被阻止。SUM_CONNECT_ERRORS值可以超过max_connect_errors的值，因为在主机未被阻止的情况下，可以同时发生来自主机的多个连接尝试。任何一个或全部都可能失败，独立地增加SUM_CONNECT_ERRORS，可能超过max_connect_errors的值。

    假设max_connect_errors为 200，对于给定主机的SUM_CONNECT_ERRORS为 199。如果有 10 个客户端同时尝试从该主机连接，由于SUM_CONNECT_ERRORS尚未达到 200，它们中的任何一个都不会被阻止。如果其中五个客户端发生阻止错误，对于每个客户端，SUM_CONNECT_ERRORS会增加一个，导致SUM_CONNECT_ERRORS值为 204。另外五个客户端成功连接且不被阻止，因为当它们的连接尝试开始时，SUM_CONNECT_ERRORS的值尚未达到 200。当SUM_CONNECT_ERRORS达到 200 后，从该主机发起的新连接将被阻止。

  • COUNT_HOST_BLOCKED_ERRORS

    因为SUM_CONNECT_ERRORS超过max_connect_errors系统变量值而被阻止的连接数量。

  • COUNT_NAMEINFO_TRANSIENT_ERRORS

    IP 到主机名 DNS 解析过程中的瞬时错误次数。

  • COUNT_NAMEINFO_PERMANENT_ERRORS

    IP 到主机名 DNS 解析过程中的永久错误次数。

  • COUNT_FORMAT_ERRORS

    主机名格式错误的数量。MySQL 不会对mysql.user系统表中Host列值与完全由数字组成的主机名进行匹配，例如1.2.example.com。而是使用客户端 IP 地址。关于为什么不进行这种匹配的原因，请参见 Section 8.2.4, “Specifying Account Names”。

  • COUNT_ADDRINFO_TRANSIENT_ERRORS

    主机名到 IP 反向 DNS 解析过程中出现的瞬时错误次数。

  • COUNT_ADDRINFO_PERMANENT_ERRORS

    主机名到 IP 反向 DNS 解析过程中的永久错误次数。

  • COUNT_FCRDNS_ERRORS

    前向确认反向 DNS 错误的数量。当 IP 到主机名到 IP DNS 解析产生一个与客户端原始 IP 地址不匹配的 IP 地址时，就会发生这些错误。

  • COUNT_HOST_ACL_ERRORS

    出现的错误次数，因为没有用户被允许从客户端主机连接。在这种情况下，服务器返回ER_HOST_NOT_PRIVILEGED，甚至不要求用户名或密码。

  • COUNT_NO_AUTH_PLUGIN_ERRORS

    由于请求不可用的身份验证插件而导致的错误数量。例如，如果插件从未加载或加载尝试失败，则插件可能不可用。

  • COUNT_AUTH_PLUGIN_ERRORS

    身份验证插件报告的错误数量。

    身份验证插件可以报告不同的错误代码以指示失败的根本原因。根据错误类型，将递增以下列之一：COUNT_AUTHENTICATION_ERRORS、COUNT_AUTH_PLUGIN_ERRORS、COUNT_HANDSHAKE_ERRORS。新的返回代码是现有插件 API 的可选扩展。未知或意外的插件错误计入COUNT_AUTH_PLUGIN_ERRORS列。

  • COUNT_HANDSHAKE_ERRORS

    在协议层面检测到的错误数量。

  • COUNT_PROXY_USER_ERRORS

    当代理用户 A 被代理到另一个不存在的用户 B 时检测到的错误数量。

  • COUNT_PROXY_USER_ACL_ERRORS

    当代理用户 A 被代理到另一个存在但 A 没有PROXY权限的用户 B 时检测到的错误数量。

  • COUNT_AUTHENTICATION_ERRORS

    由于身份验证失败导致的错误数量。

  • COUNT_SSL_ERRORS

    由于 SSL 问题导致的错误数量。

  • COUNT_MAX_USER_CONNECTIONS_ERRORS

    由于超出每用户连接配额而导致的错误数量。请参阅 Section 8.2.21, “Setting Account Resource Limits”。

  • COUNT_MAX_USER_CONNECTIONS_PER_HOUR_ERRORS

    由于超出每小时每用户连接配额而导致的错误数量。请参阅 Section 8.2.21, “Setting Account Resource Limits”。

  • COUNT_DEFAULT_DATABASE_ERRORS

    与默认数据库相关的错误数量。例如，数据库不存在或用户没有访问权限。

  • COUNT_INIT_CONNECT_ERRORS

    由于init_connect系统变量值中语句执行失败而导致的错误数量。

  • COUNT_LOCAL_ERRORS

    与服务器实现本地的与网络、身份验证或授权无关的错误数量。例如，内存不足情况属于此类别。

  • COUNT_UNKNOWN_ERRORS

    在此表中其他未被其他列考虑的未知错误数量。该列保留用于将来使用，以防必须报告新的错误条件，并且如果需要保留host_cache表的向后兼容性和结构。

  • FIRST_SEEN

    在IP列中看到的客户端首次连接尝试的时间戳。

  • LAST_SEEN

    在IP列中看到的客户端最近连接尝试的时间戳。

  • FIRST_ERROR_SEEN

    客户端在IP列中首次出现错误的时间戳。

  • LAST_ERROR_SEEN

    在IP列中记录客户端最近出现错误的时间戳。

host_cache表具有以下索引：

  • (IP)上的主键

  • (HOST)上的索引

对于host_cache表，允许使用TRUNCATE TABLE语句。需要对该表具有DROP权限。清空表会刷新主机缓存，具有刷新主机缓存中描述的效果。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-innodb-redo-log-files-table.html

29.12.21.4 innodb_redo_log_files表

innodb_redo_log_files表包含每个活动的InnoDB重做日志文件的一行。此表在 MySQL 8.0.30 中引入。

innodb_redo_log_files表具有以下列：

  • FILE_ID

    重做日志文件的 ID。该值对应于重做日志文件编号。

  • FILE_NAME

    重做日志文件的路径和文件名。

  • START_LSN

    重做日志文件中第一个块的日志序列号。

  • END_LSN

    最后一个块后的日志序列号在重做日志文件中。

  • SIZE_IN_BYTES

    文件中重做日志数据的大小，以字节为单位。数据大小从END_LSN到开始>START_LSN进行测量。由于文件头（2048 字节）不包括在此列报告的值中，因此磁盘上的重做日志文件大小略大。

  • IS_FULL

    重做日志文件是否已满。值为 0 表示文件中有空闲空间。值为 1 表示文件已满。

  • CONSUMER_LEVEL

    保留以供将来使用。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-log-status-table.html

29.12.21.5 log_status表

log_status表提供的信息使在线备份工具能够复制所需的日志文件，而不会在复制过程中锁定这些资源。

当查询log_status表时，服务器会阻止记录和相关的管理更改，只需足够的时间来填充表，然后释放资源。log_status表通知在线备份应该复制到源二进制日志和gtid_executed记录的哪个点，以及每个复制通道的中继日志。它还为各个存储引擎提供相关信息，例如InnoDB存储引擎的最后日志序列号（LSN）和最后一个检查点的 LSN。

log_status表具有以下列：

  • SERVER_UUID

    该服务器实例的服务器 UUID。这是只读系统变量server_uuid的生成唯一值。

  • LOCAL

    来自源的日志位置状态信息，以单个具有以下键的 JSON 对象提供：

    binary_log_file

    当前二进制日志文件的名称。

    binary_log_position

    访问log_status表时的当前二进制日志位置。

    gtid_executed

    在访问log_status表时全局服务器变量gtid_executed的当前值。此信息与binary_log_file和binary_log_position键一致。

  • REPLICATION

    一个包含以下信息的通道的 JSON 数组：

    channel_name

    复制通道的名称。默认复制通道的名称为空字符串（“”）。

    relay_log_file

    复制通道的当前中继日志文件的名称。

    relay_log_pos

    访问log_status表时的当前中继日志位置。

  • STORAGE_ENGINES

    从各个存储引擎提供的相关信息，以每个适用存储引擎的一个键的 JSON 对象。

log_status表没有索引。

访问log_status表需要BACKUP_ADMIN权限以及SELECT权限。

TRUNCATE TABLE不允许用于log_status表。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-performance-timers-table.html

29.12.21.6 The performance_timers Table

performance_timers 表显示了可用的事件计时器：

mysql> SELECT * FROM performance_schema.performance_timers;
+-------------+-----------------+------------------+----------------+
| TIMER_NAME  | TIMER_FREQUENCY | TIMER_RESOLUTION | TIMER_OVERHEAD |
+-------------+-----------------+------------------+----------------+
| CYCLE       |      2389029850 |                1 |             72 |
| NANOSECOND  |      1000000000 |                1 |            112 |
| MICROSECOND |         1000000 |                1 |            136 |
| MILLISECOND |            1036 |                1 |            168 |
| THREAD_CPU  |       339101694 |                1 |            798 |
+-------------+-----------------+------------------+----------------+

如果与特定计时器名称相关联的值为 NULL，则该计时器在您的平台上不受支持。有关事件计时发生的解释，请参见 Section 29.4.1, “Performance Schema Event Timing”。

performance_timers 表具有以下列：

  • TIMER_NAME

    计时器名称。

  • TIMER_FREQUENCY

    每秒的计时器单位数。对于循环计时器，频率通常与 CPU 速度有关。例如，在一个具有 2.4GHz 处理器的系统上，CYCLE 可能接近 2400000000。

  • TIMER_RESOLUTION

    指示计时器值增加的计时器单位数。如果计时器的分辨率为 10，则每次增加 10。

  • TIMER_OVERHEAD

    通过调用计时器 20 次进行初始化并选择最小值，性能模式确定获得给定计时器的一个计时所需的最小周期数。总开销实际上是这个值的两倍，因为在每个事件的开始和结束时，仪器会调用计时器。计时器代码仅在计时事件时调用，因此此开销不适用于非计时事件。

performance_timers 表没有索引。

TRUNCATE TABLE 不允许用于 performance_timers 表。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-processlist-table.html

29.12.21.7 进程列表表

MySQL 进程列表指示服务器内执行的一组线程当前正在执行的操作。processlist 表是进程信息的一个来源。有关此表与其他来源的比较，请参见进程信息的来源。

processlist 表可以直接查询。如果您拥有 PROCESS 权限，您可以看到所有线程，甚至属于其他用户的线程。否则（没有 PROCESS 权限），非匿名用户可以访问有关自己线程的信息，但不能访问其他用户的线程，匿名用户无法访问线程信息。

注意

如果启用了 performance_schema_show_processlist 系统变量，则 processlist 表还作为 SHOW PROCESSLIST 语句底层的替代实现的基础。有关详细信息，请参见本节后面的内容。

processlist 表包含每个服务器进程的一行：

mysql> SELECT * FROM performance_schema.processlist\G
*************************** 1\. row ***************************
     ID: 5
   USER: event_scheduler
   HOST: localhost
     DB: NULL
COMMAND: Daemon
   TIME: 137
  STATE: Waiting on empty queue
   INFO: NULL
*************************** 2\. row ***************************
     ID: 9
   USER: me
   HOST: localhost:58812
     DB: NULL
COMMAND: Sleep
   TIME: 95
  STATE:
   INFO: NULL
*************************** 3\. row ***************************
     ID: 10
   USER: me
   HOST: localhost:58834
     DB: test
COMMAND: Query
   TIME: 0
  STATE: executing
   INFO: SELECT * FROM performance_schema.processlist
...

processlist 表具有以下列：

  • ID

    连接标识符。这是在 SHOW PROCESSLIST 语句的 Id 列中显示的相同值，在性能模式 threads 表的 PROCESSLIST_ID 列中显示，并在线程内由 CONNECTION_ID() 函数返回。

  • USER

    发出语句的 MySQL 用户。system user的值指的是服务器生成的用于内部处理任务的非客户端线程，例如延迟行处理程序线程或在副本主机上使用的 I/O 或 SQL 线程。对于system user，在Host列中没有指定主机。unauthenticated user指的是已经与客户端连接关联但客户端用户尚未进行身份验证的线程。event_scheduler指的是监视计划事件的线程（参见 Section 27.4, “Using the Event Scheduler”）。

    注意

    system user的USER值与SYSTEM_USER权限是不同的。前者指的是内部线程。后者区分系统用户和常规用户帐户类别（参见 Section 8.2.11, “Account Categories”）。

  • HOST

    发出语句的客户端主机名（除了system user外，没有主机名）。对于 TCP/IP 连接，主机名以*host_name*:*client_port*格式报告，以便更容易确定哪个客户端在执行什么操作。

  • DB

    线程的默认数据库，如果没有选择任何数据库，则为NULL。

  • COMMAND

    线程代表客户端执行的命令类型，或者如果会话处于空闲状态，则为Sleep。有关线程命令的描述，请参见 Section 10.14, “Examining Server Thread (Process) Information” Information")。此列的值对应于客户端/服务器协议的COM_*xxx*命令和Com_*xxx*状态变量。参见 Section 7.1.10, “Server Status Variables”。

  • TIME

    线程在当前状态下已经持续的时间（以秒为单位）。对于副本 SQL 线程，该值是最后一个复制事件的时间戳与副本主机实际时间之间的秒数。参见 Section 19.2.3, “Replication Threads”。

  • STATE

    指示线程正在执行的操作、事件或状态。有关STATE值的描述，请参见 Section 10.14, “Examining Server Thread (Process) Information” Information")。

    大多数状态对应非常快速的操作。如果一个线程在特定状态下停留了很多秒，可能存在需要调查的问题。

  • INFO

    线程正在执行的语句，如果未执行任何语句则为NULL。该语句可能是发送到服务器的语句，或者如果该语句执行其他语句，则为最内层语句。例如，如果CALL语句执行一个正在执行SELECT语句的存储过程，则INFO值显示SELECT语句。

  • EXECUTION_ENGINE

    查询执行引擎。该值可以是PRIMARY或SECONDARY。用于 MySQL HeatWave 服务和 HeatWave，其中PRIMARY引擎是InnoDB，SECONDARY引擎是 HeatWave（RAPID）。对于 MySQL 社区版服务器、MySQL 企业版服务器（本地）以及没有 HeatWave 的 MySQL HeatWave 服务，该值始终为PRIMARY。此列在 MySQL 8.0.29 中添加。

processlist表具有以下索引：

  • 主键为(ID)

TRUNCATE TABLE不允许用于processlist表。

如前所述，如果启用了performance_schema_show_processlist系统变量，则processlist表作为其他进程信息源的替代实现的基础：

  • SHOW PROCESSLIST语句。

  • mysqladmin processlist命令（使用SHOW PROCESSLIST语句）。

默认的SHOW PROCESSLIST实现在持有全局互斥锁的同时从线程管理器中遍历活动线程。这会对性能产生负面影响，特别是在繁忙系统上。另一种SHOW PROCESSLIST实现基于性能模式processlist表。该实现从性能模式而不是线程管理器查询活动线程数据，并且不需要互斥锁。

MySQL 配置会影响processlist表的内容如下：

  • 最低要求配置：

    • MySQL 服务器必须配置并构建为启用线程仪表。这是默认情况；可以使用DISABLE_PSI_THREAD CMake选项进行控制。

    • 性能模式必须在服务器启动时启用。这是默认情况；可以使用performance_schema系统变量来控制。

    在满足该配置的情况下，performance_schema_show_processlist启用或禁用替代的SHOW PROCESSLIST实现。如果未满足最低配置要求，processlist表（因此SHOW PROCESSLIST）可能无法返回所有数据。

  • 推荐配置：

    • 为了避免一些线程被忽略：

      • 将performance_schema_max_thread_instances系统变量设置为默认值或至少设置为与max_connections系统变量一样大。

      • 将performance_schema_max_thread_classes系统变量设置为默认值。

    • 为了避免一些STATE列值为空，请将performance_schema_max_stage_classes系统变量设置为默认值。

    这些配置参数的默认值为-1，这会导致性能模式在服务器启动时自动调整它们的大小。使用指定的参数设置，processlist表（因此SHOW PROCESSLIST）会生成完整的进程信息。

前述配置参数会影响processlist表的内容。然而，对于给定的配置，processlist的内容不受performance_schema_show_processlist设置的影响。

替代的进程列表实现不适用于INFORMATION_SCHEMA的PROCESSLIST表或 MySQL 客户端/服务器协议的COM_PROCESS_INFO命令。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-threads-table.html

29.12.21.8 线程表

threads表包含每个服务器线程的一行。每行包含有关线程的信息，并指示是否为其启用了监控和历史事件记录：

mysql> SELECT * FROM performance_schema.threads\G
*************************** 1\. row ***************************
            THREAD_ID: 1
                 NAME: thread/sql/main
                 TYPE: BACKGROUND
       PROCESSLIST_ID: NULL
     PROCESSLIST_USER: NULL
     PROCESSLIST_HOST: NULL
       PROCESSLIST_DB: mysql
  PROCESSLIST_COMMAND: NULL
     PROCESSLIST_TIME: 418094
    PROCESSLIST_STATE: NULL
     PROCESSLIST_INFO: NULL
     PARENT_THREAD_ID: NULL
                 ROLE: NULL
         INSTRUMENTED: YES
              HISTORY: YES
      CONNECTION_TYPE: NULL
         THREAD_OS_ID: 5856
       RESOURCE_GROUP: SYS_default
     EXECUTION_ENGINE: PRIMARY
    CONTROLLED_MEMORY: 1456
MAX_CONTROLLED_MEMORY: 67480
         TOTAL_MEMORY: 1270430
     MAX_TOTAL_MEMORY: 1307317
     TELEMETRY_ACTIVE: NO
...

当性能模式初始化时，它基于当时存在的线程填充threads表。此后，每次服务器创建线程时都会添加新行。

新线程的INSTRUMENTED和HISTORY列值由setup_actors表的内容确定。有关如何使用setup_actors表来控制这些列的信息，请参阅 Section 29.4.6, “Pre-Filtering by Thread”.

从threads表中删除行是在线程结束时发生的。对于与客户端会话关联的线程，当会话结束时会发生删除。如果客户端启用了自动重新连接，并且会话在断开连接后重新连接，则会话将与具有不同PROCESSLIST_ID值的threads表中的新行相关联。新线程的初始INSTRUMENTED和HISTORY值可能与原始线程的值不同：setup_actors表可能已经发生了变化，如果在初始化行之后更改了原始线程的INSTRUMENTED或HISTORY值，则该更改不会传递到新线程。

您可以启用或禁用线程监控（即线程执行的事件是否被检测）和历史事件记录。要控制新前台线程的初始INSTRUMENTED和HISTORY值，请使用setup_actors表。要控制现有线程的这些方面，请设置threads表行的INSTRUMENTED和HISTORY列。（有关线程监控和历史事件记录发生条件的更多信息，请参阅INSTRUMENTED和HISTORY列的描述。）

与具有PROCESSLIST_前缀名称的threads表列进行比较，以及其他进程信息来源，请参阅进程信息来源。

重要

除了threads表之外的线程信息来源，只有当前用户具有PROCESS权限时，才会显示其他用户的线程信息。对于threads表并非如此；对于具有表的SELECT权限的任何用户，都会显示所有行。不应授予对threads表的SELECT权限的用户，不应该能够通过访问该表来查看其他用户的线程。

threads表具有以下列：

  • THREAD_ID

    唯一线程标识符。

  • 名称

    与服务器中的线程仪表代码相关联的名称。例如，thread/sql/one_connection对应于负责处理用户连接的代码中的线程函数，而thread/sql/main代表服务器的main()函数。

  • 类型

    线程类型，可以是FOREGROUND或BACKGROUND。用户连接线程是前台线程。与内部服务器活动相关的线程是后台线程。例如，内部InnoDB线程，“binlog dump”线程向副本发送信息，以及复制 I/O 和 SQL 线程。

  • PROCESSLIST_ID

    对于前台线程（与用户连接相关），这是连接标识符。这与INFORMATION_SCHEMA PROCESSLIST表的ID列中显示的值相同，在SHOW PROCESSLIST输出中显示，在线程内部由CONNECTION_ID()函数返回。

    对于后台线程（与用户连接无关），PROCESSLIST_ID为NULL，因此值不是唯一的。

  • PROCESSLIST_USER

    与前台线程关联的用户，对于后台线程为NULL。

  • PROCESSLIST_HOST

    与前台线程关联的客户端的主机名，对于后台线程为NULL。

    与INFORMATION_SCHEMA PROCESSLIST表的HOST列或SHOW PROCESSLIST输出的Host列不同，PROCESSLIST_HOST列不包括 TCP/IP 连接的端口号。要从性能模式获取此信息，请启用套接字检测（默认情况下未启用），并检查socket_instances表：

    mysql> SELECT NAME, ENABLED, TIMED
       FROM performance_schema.setup_instruments
       WHERE NAME LIKE 'wait/io/socket%';
+----------------------------------------+---------+-------+
| NAME                                   | ENABLED | TIMED |
+----------------------------------------+---------+-------+
| wait/io/socket/sql/server_tcpip_socket | NO      | NO    |
| wait/io/socket/sql/server_unix_socket  | NO      | NO    |
| wait/io/socket/sql/client_connection   | NO      | NO    |
+----------------------------------------+---------+-------+
3 rows in set (0.01 sec)

mysql> UPDATE performance_schema.setup_instruments
       SET ENABLED='YES'
       WHERE NAME LIKE 'wait/io/socket%';
Query OK, 3 rows affected (0.00 sec)
Rows matched: 3  Changed: 3  Warnings: 0

mysql> SELECT * FROM performance_schema.socket_instances\G
*************************** 1\. row ***************************
           EVENT_NAME: wait/io/socket/sql/client_connection
OBJECT_INSTANCE_BEGIN: 140612577298432
            THREAD_ID: 31
            SOCKET_ID: 53
                   IP: ::ffff:127.0.0.1
                 PORT: 55642
                STATE: ACTIVE
...

  • PROCESSLIST_DB

    线程的默认数据库，如果没有选择任何数据库，则为NULL。

  • PROCESSLIST_COMMAND

    对于前台线程，线程代表客户端执行的命令类型，如果会话空闲，则为Sleep。有关线程命令的描述，请参见 Section 10.14, “Examining Server Thread (Process) Information” Information")。此列的值对应于客户端/服务器协议的COM_*xxx*命令和Com_*xxx*状态变量。请参见 Section 7.1.10, “Server Status Variables”

    后台线程不代表客户端执行命令，因此此列可能为NULL。

  • PROCESSLIST_TIME

    线程处于当前状态的秒数。对于复制 SQL 线程，该值是最后一个复制事件的时间戳和复制主机的实际时间之间的秒数。参见 Section 19.2.3, “Replication Threads”。

  • PROCESSLIST_STATE

    表示线程正在执行的操作、事件或状态。有关PROCESSLIST_STATE值的描述，请参见 Section 10.14, “Examining Server Thread (Process) Information” Information")。如果值为NULL，则线程可能对应于空闲客户端会话或其正在执行的工作未使用阶段进行检测。

    大多数状态对应非常快速的操作。如果一个线程在某个状态停留了很多秒，可能存在需要调查的问题。

  • PROCESSLIST_INFO

    线程正在执行的语句，如果不执行任何语句，则为NULL。该语句可能是发送到服务器的语句，或者如果语句执行其他语句，则是最内部的语句。例如，如果CALL语句执行正在执行SELECT语句的存储过程，则PROCESSLIST_INFO值显示SELECT语句。

  • PARENT_THREAD_ID

    如果此线程是子线程（由另一个线程生成），则这是生成线程的THREAD_ID值。

  • ROLE

    未使用。

  • INSTRUMENTED

    是否对线程执行的事件进行仪器化。该值为YES或NO。

    • 对于前台线程，初始的INSTRUMENTED值取决于与线程关联的用户帐户是否与setup_actors表中的任何行匹配。匹配基于PROCESSLIST_USER和PROCESSLIST_HOST列的值。

      如果线程生成了子线程，则再次为为子线程创建的threads表行进行匹配。

    • 对于后台线程，默认情况下INSTRUMENTED为YES。不会查询setup_actors，因为后台线程没有关联的用户。

    • 对于任何线程，其INSTRUMENTED值可以在线程的生命周期内更改。

    要发生对线程执行的事件的监视，必须满足以下条件：

    • setup_consumers表中的thread_instrumentation消费者必须为YES。

    • threads.INSTRUMENTED列必须为YES。

    • 仅对那些在setup_instruments表中的ENABLED列设置为YES的仪器产生的线程事件进行监视。

  • HISTORY

    是否记录线程的历史事件。该值为YES或NO。

    • 对于前台线程，初始的HISTORY值取决于与线程关联的用户帐户是否与setup_actors表中的任何行匹配。匹配基于PROCESSLIST_USER和PROCESSLIST_HOST列的值。

      如果线程生成了子线程，则再次为为子线程创建的threads表行进行匹配。

    • 对于后台线程，默认情况下HISTORY为YES。不会查询setup_actors，因为后台线程没有关联的用户。

    • 对于任何线程，其HISTORY值可以在线程的生命周期内更改。

    要发生对线程的历史事件记录，必须满足以下条件：

    • 必须启用setup_consumers表中适当的与历史相关的消费者。例如，在events_waits_history和events_waits_history_long表中等待事件记录需要相应的events_waits_history和events_waits_history_long消费者为YES。

    • threads.HISTORY列必须为YES。

    • 仅对那些在setup_instruments表中ENABLED列设置为YES的仪器产生的线程事件进行记录。

  • CONNECTION_TYPE

    用于建立连接的协议，或者对于后台线程为NULL。允许的值为TCP/IP（未加密建立的 TCP/IP 连接），SSL/TLS（加密建立的 TCP/IP 连接），Socket（Unix 套接字文件连接），Named Pipe（Windows 命名管道连接）和Shared Memory（Windows 共享内存连接）。

  • THREAD_OS_ID

    如果有的话，由底层操作系统定义的线程或任务标识符：

    • 当 MySQL 线程在其生命周期内与相同的操作系统线程关联时，THREAD_OS_ID包含操作系统线程 ID。

    • 当 MySQL 线程在其生命周期内未与相同的操作系统线程关联时，THREAD_OS_ID包含NULL。这在使用线程池插件时（参见 Section 7.6.3, “MySQL Enterprise Thread Pool”）的用户会话中很常见。

    对于 Windows，THREAD_OS_ID对应于在 Process Explorer 中可见的线程 ID（technet.microsoft.com/en-us/sysinternals/bb896653.aspx）。

    对于 Linux，THREAD_OS_ID对应于gettid()函数的值。例如，可以使用perf或ps -L命令，或在proc文件系统（/proc/*[pid]*/task/*[tid]*）中公开此值。有关更多信息，请参阅perf-stat(1)，ps(1)和proc(5)手册页。

  • RESOURCE_GROUP

    资源组标签。如果当前平台或服务器配置不支持资源组，则此值为NULL（请参阅 Resource Group Restrictions）。

  • EXECUTION_ENGINE

    查询执行引擎。值为 PRIMARY 或 SECONDARY。用于 MySQL HeatWave 服务和 HeatWave，其中 PRIMARY 引擎是 InnoDB，SECONDARY 引擎是 HeatWave (RAPID)。对于 MySQL 社区版服务器、MySQL 企业版服务器（本地）和没有 HeatWave 的 MySQL HeatWave 服务，值始终为 PRIMARY。此列在 MySQL 8.0.29 版本中添加。

  • CONTROLLED_MEMORY

    线程使用的受控内存量。

    此列在 MySQL 8.0.31 版本中添加。

  • MAX_CONTROLLED_MEMORY

    线程执行期间看到的 CONTROLLED_MEMORY 的最大值。

    此列在 MySQL 8.0.31 版本中添加。

  • TOTAL_MEMORY

    线程使用的当前内存量，无论是否受控。

    此列在 MySQL 8.0.31 版本中添加。

  • MAX_TOTAL_MEMORY

    线程执行期间看到的 TOTAL_MEMORY 的最大值。

    此列在 MySQL 8.0.31 版本中添加。

  • TELEMETRY_ACTIVE

    线程是否附加了活动的遥测会话。值为 YES 或 NO。

    此列在 MySQL 8.0.33 版本中添加。

threads 表具有以下索引：

  • 在 (THREAD_ID) 上的主键

  • 在 (NAME) 上的索引

  • 在 (PROCESSLIST_ID) 上的索引

  • 在 (PROCESSLIST_USER, PROCESSLIST_HOST) 上的索引

  • 在 (PROCESSLIST_HOST) 上的索引

  • 在 (THREAD_OS_ID) 上的索引

  • 在 (RESOURCE_GROUP) 上的索引

TRUNCATE TABLE 不允许用于 threads 表。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-tls-channel-status-table.html

29.12.21.9 The tls_channel_status Table

连接接口 TLS 属性在服务器启动时设置，并可以使用ALTER INSTANCE RELOAD TLS语句在运行时进行更新。请参见 Server-Side Runtime Configuration and Monitoring for Encrypted Connections。

tls_channel_status表（自 MySQL 8.0.21 起可用）提供有关连接接口 TLS 属性的信息：

mysql> SELECT * FROM performance_schema.tls_channel_status\G
*************************** 1\. row ***************************
 CHANNEL: mysql_main
PROPERTY: Enabled
   VALUE: Yes
*************************** 2\. row ***************************
 CHANNEL: mysql_main
PROPERTY: ssl_accept_renegotiates
   VALUE: 0
*************************** 3\. row ***************************
 CHANNEL: mysql_main
PROPERTY: Ssl_accepts
   VALUE: 2
...
*************************** 29\. row ***************************
 CHANNEL: mysql_admin
PROPERTY: Enabled
   VALUE: No
*************************** 30\. row ***************************
 CHANNEL: mysql_admin
PROPERTY: ssl_accept_renegotiates
   VALUE: 0
*************************** 31\. row ***************************
 CHANNEL: mysql_admin
PROPERTY: Ssl_accepts
   VALUE: 0
...

tls_channel_status表具有以下列：

  • CHANNEL

    适用于 TLS 属性行的连接接口的名称。mysql_main和mysql_admin分别是主连接接口和管理连接接口的通道名称。有关不同接口的信息，请参见 Section 7.1.12.1, “Connection Interfaces”。

  • PROPERTY

    TLS 属性名称。Enabled属性的行指示整体接口状态，其中接口及其状态分别在CHANNEL和VALUE列中命名。其他属性名称指示特定的 TLS 属性。这些通常对应于与 TLS 相关的状态变量的名称。

  • VALUE

    TLS 属性值。

由该表公开的属性不是固定的，而是取决于每个通道实现的仪表化。

对于每个通道，具有PROPERTY值为Enabled的行指示通道是否支持加密连接，其他通道行指示 TLS 上下文属性：

  • 对于mysql_main，Enabled属性为yes或no，表示主接口是否支持加密连接。其他通道行显示主接口的 TLS 上下文属性。

    对于主接口，可以使用以下语句获取类似的状态信息：

    SHOW GLOBAL STATUS LIKE 'current_tls%';
SHOW GLOBAL STATUS LIKE 'ssl%';

  • 对于mysql_admin，如果管理接口未启用或已启用但不支持加密连接，则Enabled属性为no。如果接口已启用并支持加密连接，则Enabled为yes。

    当 Enabled 为 yes 时，如果为该接口配置了一些非默认的 TLS 参数值，则其他 mysql_admin 行仅指示管理接口 TLS 上下文的通道属性。 （如果任何 admin_tls_*xxx* 或 admin_ssl_*xxx* 系统变量设置为与其默认值不同的值，则是这种情况。）否则，管理接口使用与主接口相同的 TLS 上下文。

tls_channel_status 表没有索引。

TRUNCATE TABLE 不允许用于 tls_channel_status 表。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-user-defined-functions-table.html

29.12.21.10 user_defined_functions 表

user_defined_functions 表包含每个由组件或插件自动注册的可加载函数或由 CREATE FUNCTION 语句手动注册的函数的行。有关添加或删除表行的操作信息，请参阅 Section 7.7.1, “安装和卸载可加载函数”。

注意

user_defined_functions 表的名称源自其创立时用于现在称为可加载函数（即用户定义函数或 UDF）的函数类型的术语。

user_defined_functions 表具有以下列：

  • UDF_NAME

    SQL 语句中引用的函数名称。如果函数是由 CREATE FUNCTION 语句注册并正在卸载过程中，则值为 NULL。

  • UDF_RETURN_TYPE

    函数返回值类型。值为 int、decimal、real、char 或 row 中的一个。

  • UDF_TYPE

    函数类型。值为 function（标量）或 aggregate 中的一个。

  • UDF_LIBRARY

    包含可执行函数代码的库文件的名称。该文件位于由 plugin_dir 系统变量命名的目录中。如果函数是由组件或插件而不是由 CREATE FUNCTION 语句注册，则值为 NULL。

  • UDF_USAGE_COUNT

    当前函数使用计数。用于判断当前是否有语句访问该函数。

user_defined_functions 表具有以下索引：

  • 主键为 (UDF_NAME)

不允许对 user_defined_functions 表使用 TRUNCATE TABLE。

mysql.func 系统表还列出已安装的可加载函数，但仅列出使用 CREATE FUNCTION 安装的函数。user_defined_functions 表列出使用 CREATE FUNCTION 安装的可加载函数，以及由组件或插件自动安装的可加载函数。这种差异使得 user_defined_functions 更适合用于检查已安装的可加载函数。

29.13 性能模式选项和变量参考

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-option-variable-reference.html

表 29.18 性能模式变量参考

名称 命令行 选项文件 系统变量 状态变量 变量范围 动态
性能模式 是 是 是 全局 否
性能模式账户丢失 是 全局 否
性能模式账户大小 是 是 是 全局 否
性能模式条件类丢失 是 全局 否
性能模式条件实例丢失 是 全局 否
performance-schema-consumer-events-stages-current 是 是
performance-schema-consumer-events-stages-history 是 是
performance-schema-consumer-events-stages-history-long 是 是
performance-schema-consumer-events-statements-cpu 是 是
performance-schema-consumer-events-statements-current 是 是
performance-schema-consumer-events-statements-history 是 是
performance-schema-consumer-events-statements-history-long 是 是
performance-schema-consumer-events-transactions-current 是 是
performance-schema-consumer-events-transactions-history 是 是
performance-schema-consumer-events-transactions-history-long 是 是
performance-schema-consumer-events-waits-current 是 是
performance-schema-consumer-events-waits-history 是 是
performance-schema-consumer-events-waits-history-long 是 是
performance-schema-consumer-global-instrumentation 是 是
performance-schema-consumer-statements-digest 是 是
performance-schema-consumer-thread-instrumentation 是 是
Performance_schema_digest_lost 是 全局 否
performance_schema_digests_size 是 是 是 全局 否
performance_schema_events_stages_history_long_size 是 是 是 全局 否
performance_schema_events_stages_history_size 是 是 是 全局 否
performance_schema_events_statements_history_long_size 是 是 是 全局 否
performance_schema_events_statements_history_size 是 是 是 全局 否
performance_schema_events_transactions_history_long_size 是 是 是 全局 否
performance_schema_events_transactions_history_size 是 是 是 全局 否
performance_schema_events_waits_history_long_size 是 是 是 全局 否
performance_schema_events_waits_history_size 是 是 是 全局 否
性能模式文件类丢失 是 全局 否
性能模式文件句柄丢失 是 全局 否
性能模式文件实例丢失 是 全局 否
性能模式主机丢失 是 全局 否
性能模式主机大小 是 是 是 全局 否
性能模式仪器 是 是
性能模式锁丢失 是 全局 否
性能模式最大条件类 是 是 是 全局 否
性能模式最大条件实例数 是 是 是 全局 否
性能模式最大摘要长度 是 是 是 全局 否
性能模式最大文件类 是 是 是 全局 否
性能模式最大文件句柄数 是 是 是 全局 否
性能模式最大文件实例数 是 是 是 全局 否
性能模式最大内存类 是 是 是 全局 否
性能模式最大元数据锁数 是 是 是 全局 否
性能模式最大互斥体类 是 是 是 全局 否
性能模式最大互斥体实例数 是 是 是 全局 否
性能模式最大准备语句实例数 是 是 是 全局 否
performance_schema_max_program_instances 是 是 是 全局 否
performance_schema_max_rwlock_classes 是 是 是 全局 否
performance_schema_max_rwlock_instances 是 是 是 全局 否
performance_schema_max_socket_classes 是 是 是 全局 否
performance_schema_max_socket_instances 是 是 是 全局 否
performance_schema_max_stage_classes 是 是 是 全局 否
performance_schema_max_statement_classes 是 是 是 全局 否
performance_schema_max_statement_stack 是 是 是 全局 否
performance_schema_max_table_handles 是 是 是 全局 否
performance_schema_max_table_instances 是 是 是 全局 否
performance_schema_max_thread_classes 是 是 是 全局 否
performance_schema_max_thread_instances 是 是 是 全局 否
性能模式内存类丢失 是 全局 否
性能模式元数据锁丢失 是 全局 否
性能模式互斥类丢失 是 全局 否
性能模式互斥实例丢失 是 全局 否
性能模式嵌套语句丢失 是 全局 否
性能模式准备语句丢失 是 全局 否
性能模式程序丢失 是 全局 否
性能模式读写锁类丢失 是 全局 否
性能模式读写锁实例丢失 是 全局 否
性能模式会话连接属性丢失 是 全局 否
performance_schema_session_connect_attrs_size 是 是 是 全局 否
performance_schema_setup_actors_size 是 是 是 全局 否
performance_schema_setup_objects_size 是 是 是 全局 否
性能模式套接字类丢失 是 全局 否
性能模式套接字实例丢失 是 全局 否
性能模式阶段类丢失 是 全局 否
性能模式语句类丢失 是 全局 否
性能模式表句柄丢失 是 全局 否
性能模式表实例丢失 是 全局 否
性能模式线程类丢失 是 全局 否
性能模式线程实例丢失 是 全局 否
性能模式用户丢失 是 全局 否
performance_schema_users_size 是 是 是 全局 否
名称 命令行 选项文件 系统变量 状态变量 变量范围 动态

29.14 性能模式命令选项

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-options.html

可以在服务器启动时在命令行或选项文件中指定性能模式参数，以配置性能模式仪器和消费者。在许多情况下也可以进行运行时配置（请参见第 29.4 节“性能模式运行时配置”），但当运行时配置太晚以影响在启动过程中已��初始化的仪器时，必须使用启动配置。

可以使用以下语法在启动时配置性能模式消费者和仪器。有关更多详细信息，请参见第 29.3 节“性能模式启动配置”。

  • --performance-schema-consumer-*consumer_name*=value``

    配置性能模式消费者。setup_consumers表中的消费者名称使用下划线，但对于在启动时设置的消费者，名称中的破折号和下划线是等效的。配置单个消费者的选项将在本节后面详细介绍。

  • --performance-schema-instrument=*instrument_name*=value``

    配置性能模式仪器。名称可以作为模式给出，以配置与该模式匹配的仪器。

以下项目配置单个消费者：

  • --performance-schema-consumer-events-stages-current=value``

    配置events-stages-current消费者。

  • --performance-schema-consumer-events-stages-history=value``

    配置events-stages-history消费者。

  • --performance-schema-consumer-events-stages-history-long=value``

    配置events-stages-history-long消费者。

  • --performance-schema-consumer-events-statements-cpu=value``

    配置events-statements-cpu消费者。

  • --performance-schema-consumer-events-statements-current=value``

    配置events-statements-current消费者。

  • --performance-schema-consumer-events-statements-history=value``

    配置events-statements-history消费者。

  • --performance-schema-consumer-events-statements-history-long=value``

    配置events-statements-history-long消费者。

  • --performance-schema-consumer-events-transactions-current=value``

    配置性能模式events-transactions-current消费者。

  • --performance-schema-consumer-events-transactions-history=value``

    配置性能模式events-transactions-history消费者。

  • --performance-schema-consumer-events-transactions-history-long=value``

    配置性能模式events-transactions-history-long消费者。

  • --performance-schema-consumer-events-waits-current=value``

    配置events-waits-current消费者。

  • --performance-schema-consumer-events-waits-history=value``

    配置events-waits-history消费者。

  • --performance-schema-consumer-events-waits-history-long=value``

    配置events-waits-history-long消费者。

  • --performance-schema-consumer-global-instrumentation=value``

    配置global-instrumentation消费者。

  • --performance-schema-consumer-statements-digest=value``

    配置statements-digest消费者。

  • --performance-schema-consumer-thread-instrumentation=value``

    配置thread-instrumentation消费者。

29.15 性能模式系统变量

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-system-variables.html

性能模式实现了几个提供配置信息的系统变量：

mysql> SHOW VARIABLES LIKE 'perf%';
+----------------------------------------------------------+-------+
| Variable_name                                            | Value |
+----------------------------------------------------------+-------+
| performance_schema                                       | ON    |
| performance_schema_accounts_size                         | -1    |
| performance_schema_digests_size                          | 10000 |
| performance_schema_events_stages_history_long_size       | 10000 |
| performance_schema_events_stages_history_size            | 10    |
| performance_schema_events_statements_history_long_size   | 10000 |
| performance_schema_events_statements_history_size        | 10    |
| performance_schema_events_transactions_history_long_size | 10000 |
| performance_schema_events_transactions_history_size      | 10    |
| performance_schema_events_waits_history_long_size        | 10000 |
| performance_schema_events_waits_history_size             | 10    |
| performance_schema_hosts_size                            | -1    |
| performance_schema_max_cond_classes                      | 80    |
| performance_schema_max_cond_instances                    | -1    |
| performance_schema_max_digest_length                     | 1024  |
| performance_schema_max_file_classes                      | 50    |
| performance_schema_max_file_handles                      | 32768 |
| performance_schema_max_file_instances                    | -1    |
| performance_schema_max_index_stat                        | -1    |
| performance_schema_max_memory_classes                    | 320   |
| performance_schema_max_metadata_locks                    | -1    |
| performance_schema_max_mutex_classes                     | 350   |
| performance_schema_max_mutex_instances                   | -1    |
| performance_schema_max_prepared_statements_instances     | -1    |
| performance_schema_max_program_instances                 | -1    |
| performance_schema_max_rwlock_classes                    | 40    |
| performance_schema_max_rwlock_instances                  | -1    |
| performance_schema_max_socket_classes                    | 10    |
| performance_schema_max_socket_instances                  | -1    |
| performance_schema_max_sql_text_length                   | 1024  |
| performance_schema_max_stage_classes                     | 150   |
| performance_schema_max_statement_classes                 | 192   |
| performance_schema_max_statement_stack                   | 10    |
| performance_schema_max_table_handles                     | -1    |
| performance_schema_max_table_instances                   | -1    |
| performance_schema_max_table_lock_stat                   | -1    |
| performance_schema_max_thread_classes                    | 50    |
| performance_schema_max_thread_instances                  | -1    |
| performance_schema_session_connect_attrs_size            | 512   |
| performance_schema_setup_actors_size                     | -1    |
| performance_schema_setup_objects_size                    | -1    |
| performance_schema_users_size                            | -1    |
+----------------------------------------------------------+-------+

可以在命令行或选项文件中设置性能模式系统变量，并且许多变量可以在运行时设置。请参见第 29.13 节，“性能模式选项和变量参考”。

如果未显式设置，性能模式会在服务器启动时自动调整几个参数的值。更多信息，请参见第 29.3 节，“性能模式启动配置”。

性能模式系统变量具有以下含义：

  • performance_schema

    命令行格式 --performance-schema[={OFF&#124;ON}]
    系统变量 performance_schema
    范围 全局
    动态 否
    SET_VAR提示适用 否
    类型 布尔值
    默认值 ON

    此变量的值为ON或OFF，表示性能模式是否已启用。默认情况下，该值为ON。在服务器启动时，您可以指定此变量不带值或带ON或 1 的值来启用它，或者带OFF或 0 的值来禁用它。

    即使性能模式被禁用，它仍会继续填充global_variables、session_variables、global_status和session_status表。这是必要的，以便从这些表中获取SHOW VARIABLES和SHOW STATUS语句的结果。性能模式在禁用时也会填充一些复制表。

  • performance_schema_accounts_size

    命令行格式 --performance-schema-accounts-size=#
    系统变量 performance_schema_accounts_size
    范围 全局
    动态 否
    SET_VAR 提示适用 否
    类型 整数
    默认值 -1（表示自动缩放；不要分配此文字值）
    最小值 -1（表示自动缩放；不要分配此文字值）
    最大值 1048576

    accounts表中的行数。如果此变量为 0，则性能模式不会在accounts表中维护连接统计信息，也不会在status_by_account表中维护状态变量信息。

  • performance_schema_digests_size

    命令行格式 --performance-schema-digests-size=#
    系统变量 performance_schema_digests_size
    范围 全局
    Dynamic No
    SET_VAR 提示适用 否
    类型 整数
    Default Value -1（表示自动调整大小；不要分配此文字值）
    最小值 -1（表示自动缩放；不要分配此文字值）
    最大值 1048576

    events_statements_summary_by_digest表中的最大行数。如果超过此最大值，以至于无法对摘要进行检测，则性能模式会增加Performance_schema_digest_lost状态变量。

    有关语句摘要的更多信息，请参见第 29.10 节，“性能模式语句摘要和抽样”。

  • performance_schema_error_size

    命令行格式 --performance-schema-error-size=#
    系统变量 performance_schema_error_size
    范围 全局
    动态 否
    SET_VAR 提示适用 否
    类型 整数
    Default Value 服务器错误代码的数量
    最小值 0
    最大值 1048576

    被检测的服务器错误代码的数量。默认值是实际的服务器错误代码数量。虽然该值可以设置为从 0 到其最大值的任何值，但预期用法是将其设置为默认值（以检测所有错误）或 0（不检测任何错误）。

    错误信息在摘要表中汇总；请参阅第 29.12.20.11 节，“错误摘要表”。如果发生未被检测的错误，该事件的信息将被汇总到每个摘要表的NULL行中；也就是说，到具有ERROR_NUMBER=0、ERROR_NAME=NULL和SQLSTATE=NULL的行。

  • performance_schema_events_stages_history_long_size

    命令行格式 --performance-schema-events-stages-history-long-size=#
    系统变量 performance_schema_events_stages_history_long_size
    范围 全局
    动态 否
    SET_VAR 提示适用 否
    类型 整数
    默认值 -1（表示自动调整大小；不要分配此文字值）
    最小值 -1（表示自动缩放；不要分配此文字值）
    最大值 1048576

    events_stages_history_long 表中的行数。

  • performance_schema_events_stages_history_size

    命令行格式 --performance-schema-events-stages-history-size=#
    系统变量 performance_schema_events_stages_history_size
    范围 全局
    动态 否
    SET_VAR 提示适用 否
    类型 整数
    默认值 -1（表示自动调整大小；不要分配此文字值）
    最小值 -1（表示自动缩放；不要分配此文字值）
    最大值 1024

    每个线程在events_stages_history表中的行数。

  • performance_schema_events_statements_history_long_size

    命令行格式 --performance-schema-events-statements-history-long-size=#
    系统变量 performance_schema_events_statements_history_long_size
    范围 全局
    动态 否
    SET_VAR 提示适用 否
    类型 整数
    默认值 -1（表示自动调整大小；不要分配此文字值）
    最小值 -1（表示自动缩放；不要分配此文字值）
    最大值 1048576

    events_statements_history_long 表中的行数��

  • performance_schema_events_statements_history_size

    命令行格式 --performance-schema-events-statements-history-size=#
    系统变量 performance_schema_events_statements_history_size
    范围 全局
    动态 否
    SET_VAR 提示适用 否
    类型 整数
    默认值 -1（表示自动调整大小；不要分配此文字值）
    最小值 -1（表示自动缩放；不要分配此文字值）
    最大值 1024

    events_statements_history 表中每个线程的行数。

  • performance_schema_events_transactions_history_long_size

    命令行格式 --performance-schema-events-transactions-history-long-size=#
    系统变量 performance_schema_events_transactions_history_long_size
    范围 全局
    动态 否
    SET_VAR 提示适用 否
    类型 整数
    默认值 -1（表示自动调整大小；不要分配此文字值）
    最小值 -1（表示自动缩放；不要分配此文字值）
    最大值 1048576

    events_transactions_history_long 表中的行数。

  • performance_schema_events_transactions_history_size

    命令行格式 --performance-schema-events-transactions-history-size=#
    系统变量 performance_schema_events_transactions_history_size
    范围 全局
    动态 否
    SET_VAR 提示适用 否
    类型 整数
    默认值 -1（表示自动调整大小；不要分配此文字值）
    最小值 -1（表示自动缩放；不要分配此文字值）
    最大值 1024

    在events_transactions_history表中每个线程的行数。

  • performance_schema_events_waits_history_long_size

    命令行格式 --performance-schema-events-waits-history-long-size=#
    系统变量 performance_schema_events_waits_history_long_size
    范围 全局
    动态 否
    SET_VAR 提示适用 否
    类型 整数
    默认值 -1（表示自动调整大小；不要分配此文字值）
    最小值 -1（表示自动缩放；不要分配此文字值）
    最大值 1048576

    在events_waits_history_long表中的行数。

  • performance_schema_events_waits_history_size

    命令行格式 --performance-schema-events-waits-history-size=#
    系统变量 performance_schema_events_waits_history_size
    范围 全局
    动态 否
    SET_VAR 提示适用 否
    类型 整数
    默认值 -1（表示自动调整大小；不要分配此文字值）
    最小值 -1（表示自动缩放；不要分配此文字值）
    最大值 1024

    在events_waits_history表中每个线程的行数。

  • performance_schema_hosts_size

    命令行格式 --performance-schema-hosts-size=#
    系统变量 performance_schema_hosts_size
    范围 全局
    动态 否
    SET_VAR 提示适用 否
    类型 整数
    默认值 -1（表示自动缩放；不要分配此文字值）
    最小值 -1（表示自动缩放；不要分配此文字值）
    最大值 1048576

    hosts 表中的行数。如果此变量为 0，则性能模式不会在 hosts 表中维护连接统计信息，也不会在 status_by_host 表中维护状态变量信息。

  • performance_schema_max_cond_classes

    命令行格式 --performance-schema-max-cond-classes=#
    系统变量 performance_schema_max_cond_classes
    作用域 全局
    动态 否
    SET_VAR 提示适用 否
    类型 整数
    默认值（≥ 8.0.27） 150
    默认值（≥ 8.0.13, ≤ 8.0.26） 100
    默认值（≤ 8.0.12） 80
    最小值 0
    最大值（≥ 8.0.12） 1024
    最大值（8.0.11） 256

    条件仪器的最大数量。有关如何设置和使用此变量的信息，请参见 第 29.7 节，“性能模式状态监控”。

  • performance_schema_max_cond_instances

    命令行格式 --performance-schema-max-cond-instances=#
    系统变量 performance_schema_max_cond_instances
    作用域 全局
    动态 否
    SET_VAR 提示适用 否
    类型 整数
    默认值 -1（表示自动缩放；不要赋予此字面值）
    最小值 -1（表示自动缩放；不要赋予此字面��）
    最大值 1048576

    仪器化条件对象的最大数量。有关如何设置和使用此变量的信息，请参见 第 29.7 节，“性能模式状态监控”。

  • performance_schema_max_digest_length

    命令行格式 --performance-schema-max-digest-length=#
    系统变量 performance_schema_max_digest_length
    作用域 全局
    动态 否
    SET_VAR 提示适用 否
    类型 整数
    默认值 1024
    最小值 0
    最大值 1048576
    单位 字节

    在性能模式中，每个语句用于计算规范语句摘要值的内存保留的最大字节数。此变量与max_digest_length有关；请参阅第 7.1.8 节，“服务器系统变量”中对该变量的描述。

    有关语句摘要的更多信息，包括有关内存使用的考虑，请参阅第 29.10 节，“性能模式语句摘要和采样”。

  • performance_schema_max_digest_sample_age

    命令行格式 --performance-schema-max-digest-sample-age=#
    系统变量 performance_schema_max_digest_sample_age
    范围 全局
    动态 是
    SET_VAR提示适用 否
    类型 整数
    默认值 60
    最小值 0
    最大值 1048576
    单位 秒

    此变量影响events_statements_summary_by_digest表的语句采样。当插入新的表行时，生成行摘要值的语句将存储为与摘要相关联的当前样本语句。此后，当服务器看到具有相同摘要值的其他语句时，它会确定是否使用新语句替换当前样本语句（即是否重新采样）。重新采样策略基于当前样本语句和新语句的比较等待时间，以及可选的当前样本语句的年龄：

    • 基于等待时间的重新采样：如果新语句的等待时间大于当前样本语句的等待时间，则新语句将成为当前样本语句。

    • 基于年龄的重新采样：如果performance_schema_max_digest_sample_age系统变量的值大于零，并且当前样本语句的年龄超过该时间（以秒为单位），则当前语句被视为“太旧”，新语句将替换它。即使新语句的等待时间小于当前样本语句的等待时间，也会发生这种情况。

    有关语句采样的信息，请参阅第 29.10 节，“性能模式语句摘要和采样”。

  • performance_schema_max_file_classes

    命令行格式 --performance-schema-max-file-classes=#
    系统变量 performance_schema_max_file_classes
    范围 全局
    动态 否
    SET_VAR 提示适用 否
    类型 整数
    默认值 80
    最小值 0
    最大值 (≥ 8.0.12) 1024
    最大值 (8.0.11) 256

    文件工具的最大数量。有关如何设置和使用此变量的信息，请参见 第 29.7 节，“性能模式状态监控”。

  • performance_schema_max_file_handles

    命令行格式 --performance-schema-max-file-handles=#
    系统变量 performance_schema_max_file_handles
    范围 全局
    动态 否
    SET_VAR 提示适用 否
    类型 整数
    默认值 32768
    最小值 0
    最大值 1048576

    打开文件对象的最大数量。有关如何设置和使用此变量的信息，请参见 第 29.7 节，“性能模式状态监控”。

    performance_schema_max_file_handles 的值应大于 open_files_limit 的值：open_files_limit 影响服务器支持的最大打开文件句柄数，而 performance_schema_max_file_handles 影响可以被检测的这些文件句柄的数量。

  • performance_schema_max_file_instances

    命令行格式 --performance-schema-max-file-instances=#
    系统变量 performance_schema_max_file_instances
    范围 全局
    动态 否
    SET_VAR 提示适用 否
    类型 整数
    默认值 -1（表示自动缩放；不要分配此文字值）
    最小值 -1（表示自动缩放；不要分配此文字值）
    最大值 1048576

    文件对象的受检测最大数量。有关如何设置和使用此变量的信息，请参见第 29.7 节，“性能模式状态监控”。

  • performance_schema_max_index_stat

    命令行格式 --performance-schema-max-index-stat=#
    系统变量 performance_schema_max_index_stat
    范围 全局
    动态 否
    SET_VAR 提示适用 否
    类型 整数
    默认值 -1（表示自动调整大小；不要分配此字面值）
    最小值 -1（表示自动缩放；不要分配此字面值）
    最大值 1048576

    Performance Schema 维护统计信息的最大索引数。如果超过此最大值，导致索引统计丢失，Performance Schema 会增加Performance_schema_index_stat_lost状态变量。默认值是使用performance_schema_max_table_instances的值进行自动调整。

  • performance_schema_max_memory_classes

    命令行格式 --performance-schema-max-memory-classes=#
    系统变量 performance_schema_max_memory_classes
    范围 全局
    动态 否
    SET_VAR 提示适用 否
    类型 整数
    默认值 450
    最小值 0
    最大值 1024

    内存工具的最大数量。有关如何设置和使用此变量的信息，请参见第 29.7 节，“性能模式状态监控”。

  • performance_schema_max_metadata_locks

    命令行格式 --performance-schema-max-metadata-locks=#
    系统变量 performance_schema_max_metadata_locks
    范围 全局
    动态 否
    SET_VAR 提示适用 否
    类型 整数
    默认值 -1（表示自动缩放；不要分配此字面值）
    最小值 -1（表示自动缩放；不要分配此字面值）
    最大值 10485760

    元数据锁仪器的最大数量。此值控制metadata_locks表的大小。如果超过此最大值，以至于无法对元数据锁进行仪器化，则性能模式会增加Performance_schema_metadata_lock_lost状态变量。

  • performance_schema_max_mutex_classes

    命令行格式 --performance-schema-max-mutex-classes=#
    系统变量 performance_schema_max_mutex_classes
    范围 全局
    动态 否
    SET_VAR 提示适用 否
    类型 整数
    默认值 (≥ 8.0.27) 350
    默认值 (≥ 8.0.12, ≤ 8.0.26) 300
    默认值 (8.0.11) 250
    最小值 0
    最大值 (≥ 8.0.12) 1024
    最大值 (8.0.11) 256

    互斥锁仪器的最大数量。有关如何设置和使用此变量的信息，请参见第 29.7 节，“性能模式状态监控”。

  • performance_schema_max_mutex_instances

    命令行格式 --performance-schema-max-mutex-instances=#
    系统变量 performance_schema_max_mutex_instances
    范围 全局
    动态 否
    SET_VAR 提示适用 否
    类型 整数
    默认值 -1 (表示自动缩放；不要分配此文字值)
    最小值 -1 (表示自动缩放；不要分配此文字值)
    最大值 104857600

    仪器化互斥对象的最大数量。有关如何设置和使用此变量的信息，请参见第 29.7 节，“性能模式状态监控”。

  • performance_schema_max_prepared_statements_instances

    命令行格式 --performance-schema-max-prepared-statements-instances=#
    系统变量 performance_schema_max_prepared_statements_instances
    范围 全局
    动态 否
    SET_VAR 提示适用 否
    类型 整数
    默认值 -1 (表示自动缩放；不要分配此文字值)
    最小值 -1 (表示自动缩放；不要分配此文字值)
    最大值 4194304

    prepared_statements_instances 表中的最大行数。如果超过此最大值，使得无法对准备语句进行仪器化，性能模式会增加 Performance_schema_prepared_statements_lost 状态变量。有关如何设置和使用此变量的信息，请参见第 29.7 节，“性能模式状态监控”。

    此变量的默认值是基于 max_prepared_stmt_count 系统变量的值自动调整的。

  • performance_schema_max_rwlock_classes

    命令行格式 --performance-schema-max-rwlock-classes=#
    系统变量 performance_schema_max_rwlock_classes
    范围 全局
    动态 否
    SET_VAR 提示适用 否
    类型 整数
    默认值 (≥ 8.0.12) 100
    默认值 (8.0.11) 60
    最小值 0
    最大值 (≥ 8.0.12) 1024
    最大值 (8.0.11) 256

    最大的 rwlock 仪器数量。有关如何设置和使用此变量的信息，请参见第 29.7 节，“性能模式状态监控”。

  • performance_schema_max_program_instances

    命令行格式 --performance-schema-max-program-instances=#
    系统变量 performance_schema_max_program_instances
    范围 全局
    动态 否
    SET_VAR 提示适用 否
    类型 整数
    默认值 -1 (表示自动缩放；不要分配此文字值)
    最小值 -1 (表示自动缩放；不要分配此文字值)
    最大值 1048576

    存储程序的最大数量，性能模式维护统计信息。如果超过此最大值，性能模式会增加Performance_schema_program_lost状态变量。有关如何设置和使用此变量的信息，请参见第 29.7 节，“性能模式状态监控”。

  • performance_schema_max_rwlock_instances

    命令行格式 --performance-schema-max-rwlock-instances=#
    系统变量 performance_schema_max_rwlock_instances
    作用范围 全局
    动态 否
    SET_VAR 提示适用 否
    类型 整数
    默认值 -1（表示自动调整大小；不要分配此字面值）
    最小值 -1（表示自动调整大小；不要分配此字面值）
    最大值 104857600

    最大锁对象数量。有关如何设置和使用此变量的信息，请参见第 29.7 节，“性能模式状态监控”。

  • performance_schema_max_socket_classes

    命令行格式 --performance-schema-max-socket-classes=#
    系统变量 performance_schema_max_socket_classes
    作用范围 全局
    动态 否
    SET_VAR 提示适用 否
    类型 整数
    默认值 10
    最小值 0
    最大值（≥ 8.0.12） 1024
    最大值（8.0.11） 256

    最大套接字工具数量。有关如何设置和使用此变量的信息，请参见第 29.7 节，“性能模式状态监控”。

  • performance_schema_max_socket_instances

    命令行格式 --performance-schema-max-socket-instances=#
    系统变量 performance_schema_max_socket_instances
    作用范围 全局
    动态 否
    SET_VAR 提示适用 否
    类型 整数
    默认值 -1（表示自动调整大小；不要分配此字面值）
    最小值 -1（表示自动缩放；不要赋予此文字值）
    最大值 1048576

    受监视的套接字对象的最大数量。有关如何设置和使用此变量的信息，请参见 第 29.7 节“性能模式状态监视”。

  • performance_schema_max_sql_text_length

    命令行格式 --performance-schema-max-sql-text-length=#
    系统变量 performance_schema_max_sql_text_length
    范围 全局
    动态 否
    SET_VAR 提示适用 否
    类型 整数
    默认值 1024
    最小值 0
    最大值 1048576
    单位 字节

    用于存储 SQL 语句的最大字节数。该值适用于以下列所需的存储空间：

    • events_statements_current、events_statements_history 和 events_statements_history_long 语句事件表的 SQL_TEXT 列。

    • events_statements_summary_by_digest 摘要表的 QUERY_SAMPLE_TEXT 列。

    超过 performance_schema_max_sql_text_length 的任何字节都将被丢弃，并不会出现在列中。只有在那么多初始字节之后有所不同的语句在列中是无法区分的。

    减小 performance_schema_max_sql_text_length 值会减少内存使用，但会导致更多语句在仅在结尾处���所不同时无法区分。增加该值会增加内存使用，但允许区分更长的语句。

  • performance_schema_max_stage_classes

    命令行格式 --performance-schema-max-stage-classes=#
    系统变量 performance_schema_max_stage_classes
    范围 全局
    动态 否
    SET_VAR 提示适用 否
    类型 整数
    默认值（≥ 8.0.13） 175
    默认值（≤ 8.0.12） 150
    最小值 0
    最大值（≥ 8.0.12） 1024
    最大值（8.0.11） 256

    阶段仪器的最大数量。有关如何设置和使用此变量的信息，请参见第 29.7 节“性能模式状态监控”。

  • performance_schema_max_statement_classes

    命令行格式 --performance-schema-max-statement-classes=#
    系统变量 performance_schema_max_statement_classes
    范围 全局
    动态 否
    SET_VAR 提示适用 否
    类型 整数
    最小值 0
    最大值 256

    语句仪器的最大数量。有关如何设置和使用此变量的信息，请参见第 29.7 节“性能模式状态监控”。

    默认值是在服务器构建时根据客户端/服务器协议中的命令数量和服务器支持的 SQL 语句类型数量计算的。

    除非将其设置为 0 以禁用所有语句仪表化并保存与之关联的所有内存，否则不应更改此变量。将变量设置为非默认值没有任何好处；特别是，大于默认值的值会导致分配更多的内存。

  • performance_schema_max_statement_stack

    命令行格式 --performance-schema-max-statement-stack=#
    系统变量 performance_schema_max_statement_stack
    范围 全局
    动态 否
    SET_VAR 提示适用 否
    类型 整数
    默认值 10
    最小值 1
    最大值 256

    Performance Schema 维护统计信息的最大嵌套存储过程调用深度。当超过此最大值时，Performance Schema 会为执行的每个存储过程语句递增Performance_schema_nested_statement_lost状态变量。

  • performance_schema_max_table_handles

    命令行格式 --performance-schema-max-table-handles=#
    系统变量 performance_schema_max_table_handles
    范围 全局
    动态 否
    SET_VAR提示适用 否
    类型 整数
    默认值 -1（表示自动缩放；不要分配此文字值）
    最小值 -1（表示自动缩放；不要分配此文字值）
    最大值 1048576

    最大打开表对象数量。此值控制table_handles表的大小。如果超过此最大值，导致无法对表句柄进行仪表化，性能模式会增加Performance_schema_table_handles_lost状态变量。有关如何设置和使用此变量的信息，请参见第 29.7 节，“性能模式状态监控”。

  • performance_schema_max_table_instances

    命令行格式 --performance-schema-max-table-instances=#
    系统变量 performance_schema_max_table_instances
    范围 全局
    动态 否
    SET_VAR提示适用 否
    类型 整数
    默认值 -1（表示自动缩放；不要分配此文字值）
    最小值 -1（表示自动缩放；不要分配此文字值）
    最大值 1048576

    最大仪表化表对象数量。有关如何设置和使用此变量的信息，请参见第 29.7 节，“性能模式状态监控”。

  • performance_schema_max_table_lock_stat

    命令行格式 --performance-schema-max-table-lock-stat=#
    系统变量 performance_schema_max_table_lock_stat
    范围 全局
    动态 否
    SET_VAR提示适用 否
    类型 整数
    默认值 -1（表示自动调整大小；不要分配此文字值）
    最小值 -1（表示自动缩放；不要分配此文字值）
    最大值 1048576

    性能模式维护锁统计信息的表的最大数量。如果超过了这个最大值，导致表锁统计信息丢失，性能模式会增加Performance_schema_table_lock_stat_lost状态变量。

  • performance_schema_max_thread_classes

    命令行格式 --performance-schema-max-thread-classes=#
    系统变量 performance_schema_max_thread_classes
    范围 全局
    动态 否
    SET_VAR提示适用 否
    类型 整数
    默认值 100
    最小值 0
    最大值（≥ 8.0.12） 1024
    最大值（8.0.11） 256

    线程仪器的最大数量。有关如何设置和使用此变量的信息，请参见第 29.7 节“性能模式状态监控”。

  • performance_schema_max_thread_instances

    命令行格式 --performance-schema-max-thread-instances=#
    系统变量 performance_schema_max_thread_instances
    范围 全局
    动态 否
    SET_VAR提示适用 否
    类型 整数
    默认值 -1（表示自动调整大小；不要分配此文字值）
    最小值 -1（表示自动缩放；不要分配此文字值）
    最大值 1048576

    最大仪器化线程对象的数量。该值控制了threads表的大小。如果超过了这个最大值，导致无法对线程进行仪器化，性能模式会增加Performance_schema_thread_instances_lost状态变量。有关如何设置和使用此变量的信息，请参见第 29.7 节“性能模式状态监控”。

    max_connections系统变量影响服务器中可以运行的线程数量。performance_schema_max_thread_instances影响可以对这些运行线程进行仪器化的数量。

    variables_by_thread 和 status_by_thread 表仅包含关于前台线程的系统和状态变量信息。如果性能模式未对所有线程进行仪表化，此表将缺少一些行。在这种情况下，Performance_schema_thread_instances_lost 状态变量大于零。

  • performance_schema_session_connect_attrs_size

    命令行格式 --performance-schema-session-connect-attrs-size=#
    系统变量 performance_schema_session_connect_attrs_size
    范围 全局
    动态 否
    SET_VAR 提示适用 否
    类型 整数
    默认值 -1（表示自动调整大小；不要分配此文字值）
    最小值 -1（表示自动调整大小；不要分配此文字值）
    最大值 1048576
    单位 字节

    每个线程预分配的内存量，用于保存连接属性键值对。如果客户端发送的连接属性数据的总大小大于此数量，则性能模式会截断属性数据，增加 Performance_schema_session_connect_attrs_lost 状态变量，并在错误日志中写入一条消息指示发生了截断，如果 log_error_verbosity 系统变量大于 1。如果属性缓冲区有足够的空间，还会向会话属性添加一个 _truncated 属性，其中包含丢失的字节数，这样性能模式就可以在连接属性表中公��每个连接的截断信息。这样就可以在不必检查错误日志的情况下检查这些信息。

    performance_schema_session_connect_attrs_size 的默认值在服务器启动时自动调整大小。这个值可能很小，所以如果发生截断（Performance_schema_session_connect_attrs_lost 变为非零），您可能希望将 performance_schema_session_connect_attrs_size 明确设置为较大的值。

    尽管performance_schema_session_connect_attrs_size的最大允许值为 1MB，但有效最大值为 64KB，因为服务器对其接受的连接属性数据的总大小施加了 64KB 的限制。如果客户端尝试发送超过 64KB 的属性数据，服务器将拒绝连接。更多信息，请参见第 29.12.9 节，“性能模式连接属性表”。

  • performance_schema_setup_actors_size

    命令行格式 --performance-schema-setup-actors-size=#
    系统变量 performance_schema_setup_actors_size
    范围 全局
    动态 否
    SET_VAR提示适用 否
    类型 整数
    默认值 -1（表示自动缩放；不要分配此文字值）
    最小值 -1（表示自动调整大小；不要分配此文字值）
    最大值 1048576

    setup_actors表中的行数。

  • performance_schema_setup_objects_size

    命令行格式 --performance-schema-setup-objects-size=#
    系统变量 performance_schema_setup_objects_size
    范围 全局
    动态 否
    SET_VAR提示适用 否
    类型 整数
    默认值 -1（表示自动缩放；不要分配此文字值）
    最小值 -1（表示自动缩放；不要分配此文字值）
    最大值 1048576

    setup_objects表中的行数。

  • performance_schema_show_processlist

    命令行格式 --performance-schema-show-processlist[={OFF&#124;ON}]
    引入版本 8.0.22
    已弃用 8.0.35
    系统变量 performance_schema_show_processlist
    范围 全局
    动态 是
    SET_VAR提示适用 否
    类型 布尔
    默认值 OFF

    SHOW PROCESSLIST语句通过从所有活动线程收集线程数据提供进程信息。performance_schema_show_processlist变量确定要使用哪种SHOW PROCESSLIST实现：

    • 默认实现在持有全局互斥锁的同时，从线程管理器中遍历活动线程。这对于繁忙系统会产生负面的性能后果。

    • 另一种SHOW PROCESSLIST实现基于性能模式processlist表。该实现从性能模式而不是线程管理器查询活动线程数据，并且不需要互斥锁。

    要启用替代实现，请启用performance_schema_show_processlist系统变量。为确保默认和替代实现提供相同的信息，必须满足某些配置要求；参见第 29.12.21.7 节，“The processlist Table”。

  • performance_schema_users_size

    命令行格式 --performance-schema-users-size=#
    系统变量 `performance_schema_users_size``
    范围 全局
    动态 否
    SET_VAR提示适用 否
    类型 整数
    默认值 -1（表示自动缩放；不要分配此文字值）
    最小值 -1（表示自动缩放；不要分配此文字值）
    最大值 1048576

    users表中的行数。如果此变量为 0，则性能模式不会在users表中维护连接统计信息，也不会在status_by_user表中维护状态变量信息。

29.16 性能模式状态变量

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-status-variables.html

性能模式实现了几个状态变量，提供有关由于内存限制而无法加载或创建的仪器化信息：

mysql> SHOW STATUS LIKE 'perf%';
+-------------------------------------------+-------+
| Variable_name                             | Value |
+-------------------------------------------+-------+
| Performance_schema_accounts_lost          | 0     |
| Performance_schema_cond_classes_lost      | 0     |
| Performance_schema_cond_instances_lost    | 0     |
| Performance_schema_file_classes_lost      | 0     |
| Performance_schema_file_handles_lost      | 0     |
| Performance_schema_file_instances_lost    | 0     |
| Performance_schema_hosts_lost             | 0     |
| Performance_schema_locker_lost            | 0     |
| Performance_schema_mutex_classes_lost     | 0     |
| Performance_schema_mutex_instances_lost   | 0     |
| Performance_schema_rwlock_classes_lost    | 0     |
| Performance_schema_rwlock_instances_lost  | 0     |
| Performance_schema_socket_classes_lost    | 0     |
| Performance_schema_socket_instances_lost  | 0     |
| Performance_schema_stage_classes_lost     | 0     |
| Performance_schema_statement_classes_lost | 0     |
| Performance_schema_table_handles_lost     | 0     |
| Performance_schema_table_instances_lost   | 0     |
| Performance_schema_thread_classes_lost    | 0     |
| Performance_schema_thread_instances_lost  | 0     |
| Performance_schema_users_lost             | 0     |
+-------------------------------------------+-------+

有关使用这些变量检查性能模式状态的信息，请参见第 29.7 节“性能模式状态监控”。

性能模式状态变量具有以下含义：

  • Performance_schema_accounts_lost

    由于表已满，无法将行添加到accounts表中的次数。

  • Performance_schema_cond_classes_lost

    无法加载多少个条件仪器。

  • Performance_schema_cond_instances_lost

    无法创建多少个条件仪器实例。

  • Performance_schema_digest_lost

    无法在events_statements_summary_by_digest表中对摘要实例进行仪器化的次数。如果performance_schema_digests_size的值太小，则此值可能为非零。

  • Performance_schema_file_classes_lost

    无法加载多少个文件仪器。

  • Performance_schema_file_handles_lost

    无法打开多少个文件仪器实例。

  • Performance_schema_file_instances_lost

    无法创建多少个文件仪器实例。

  • Performance_schema_hosts_lost

    由于表已满，无法将行添加到hosts表中的次数。

  • Performance_schema_index_stat_lost

    丢失了多少个统计信息的索引。如果performance_schema_max_index_stat的值太小，则此值可能为非零。

  • Performance_schema_locker_lost

    由于以下条件，有多少事件“丢失”或未记录：

    • 事件是递归的（例如，等待 A 导致等待 B，导致等待 C）。

    • 嵌套事件堆栈的深度超过了实现所施加的限制。

    Performance Schema 记录的事件不是递归的，因此此变量应始终为 0。

  • Performance_schema_memory_classes_lost

    无法加载内存工具的次数。

  • Performance_schema_metadata_lock_lost

    在metadata_locks表中无法对元数据锁进行仪器化的数量。如果performance_schema_max_metadata_locks的值太小，则可能不为零。

  • Performance_schema_mutex_classes_lost

    有多少互斥锁工具无法加载。

  • Performance_schema_mutex_instances_lost

    有多少互斥锁工具实例无法创建。

  • Performance_schema_nested_statement_lost

    丢失统计信息的存储程序语句的数量。如果performance_schema_max_statement_stack的值太小，则可能不为零。

  • Performance_schema_prepared_statements_lost

    在prepared_statements_instances表中无法对准备语句进行仪器化的数量。如果performance_schema_max_prepared_statements_instances的值太小，则可能不为零��

  • Performance_schema_program_lost

    丢失统计信息的存储程序的数量。如果performance_schema_max_program_instances的值太小，则可能不为零。

  • Performance_schema_rwlock_classes_lost

    无法加载多少个 rwlock 仪器。

  • Performance_schema_rwlock_instances_lost

    无法创建多少个 rwlock 仪器实例。

  • Performance_schema_session_connect_attrs_longest_seen

    除了性能模式针对performance_schema_session_connect_attrs_size系统变量的值执行的连接属性大小限制检查外，服务器还执行了一个初步检查，对接受的连接属性数据的总大小施加了 64KB 的限制。如果客户端尝试发送超过 64KB 的属性数据，服务器将拒绝连接。否则，服务器将认为属性缓冲区有效，并跟踪最长缓冲区的大小，存储在Performance_schema_session_connect_attrs_longest_seen状态变量中。如果此值大于performance_schema_session_connect_attrs_size，DBA 可能希望增加后者的值，或者调查哪些客户端正在发送大量属性数据。

    关于连接属性的更多信息，请参见第 29.12.9 节，“性能模式连接属性表”。

  • Performance_schema_session_connect_attrs_lost

    发生连接属性截断的连接数。对于给定的连接，如果客户端发送的连接属性键值对的总大小大于performance_schema_session_connect_attrs_size系统变量允许的保留存储空间，性能模式将截断属性数据并增加Performance_schema_session_connect_attrs_lost。如果此值不为零，则可能希望将performance_schema_session_connect_attrs_size设置为较大的值。

    关于连接属性的更多信息，请参见第 29.12.9 节，“性能模式连接属性表”。

  • Performance_schema_socket_classes_lost

    有多少套接字工具无法加载。

  • Performance_schema_socket_instances_lost

    有多少套接字工具实例无法创建。

  • Performance_schema_stage_classes_lost

    有多少阶段工具无法加载。

  • Performance_schema_statement_classes_lost

    有多少语句工具无法加载。

  • Performance_schema_table_handles_lost

    有多少表工具实例无法打开。如果performance_schema_max_table_handles的值太小，则可能不为零。

  • Performance_schema_table_instances_lost

    有多少表工具实例无法创建。

  • Performance_schema_table_lock_stat_lost

    丢失锁统计信息的表数。如果performance_schema_max_table_lock_stat的值太小，则可能不为零。

  • Performance_schema_thread_classes_lost

    有多少线程工具无法加载。

  • Performance_schema_thread_instances_lost

    无法在threads表中对线程实例进行仪器化的次数。如果performance_schema_max_thread_instances的值太小，则可能不为零。

  • Performance_schema_users_lost

    由于表已满，无法将行添加到users表中的次数。

29.17 性能模式内存分配模型

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-memory-model.html

性能模式使用此内存分配模型：

  • 可能在服务器启动时分配内存。

  • 可能在服务器运行期间分配额外的内存。

  • 永远不要在服务器运行期间释放内存（尽管它可能被回收）。

  • 在关闭时释放所有使用的内存。

结果是放宽内存约束，以便性能模式可以在较少的配置下使用，并减少内存占用量，使消耗随服务器负载而扩展。内存使用取决于实际观察到的负载，而不是估计的负载或明确配置的负载。

几个性能模式大小参数是自动缩放的，除非您想要在内存分配上建立明确的限制，否则无需显式配置：

performance_schema_accounts_size
performance_schema_hosts_size
performance_schema_max_cond_instances
performance_schema_max_file_instances
performance_schema_max_index_stat
performance_schema_max_metadata_locks
performance_schema_max_mutex_instances
performance_schema_max_prepared_statements_instances
performance_schema_max_program_instances
performance_schema_max_rwlock_instances
performance_schema_max_socket_instances
performance_schema_max_table_handles
performance_schema_max_table_instances
performance_schema_max_table_lock_stat
performance_schema_max_thread_instances
performance_schema_users_size

对于自动缩放的参数，配置如下：

  • 当值设置为-1（默认值）时，参数会自动缩放：

    • 相应的内部缓冲区最初为空，不会分配任何内存。

    • 当性能模式收集数据时，内存会在相应的缓冲区中分配。缓冲区大小是无限的，并且可能随着负载而增长。

  • 当值设置为 0 时：

    • 相应的内部缓冲区最初为空，不会分配任何内存。

  • 当值设置为N > 0 时：

    • 相应的内部缓冲区最初为空，不会分配任何内存。

    • 当性能模式收集数据时，内存会在相应的缓冲区中分配，直到缓冲区大小达到N。

    • 一旦缓冲区大小达到N，就不会再分配更多内存。性能模式为此缓冲区收集的数据将丢失，并且任何相应的“丢失实例”计数器都会递增。

要查看性能模式使用了多少内存，请检查为此目的设计的工具。性能模式在内部分配内存，并将每个缓冲区与专用工具相关联，以便可以将内存消耗跟踪到各个缓冲区。以memory/performance_schema/为前缀命名的工具公开了为这些内部缓冲区分配了多少内存。这些缓冲区是全局的，因此这些工具仅在memory_summary_global_by_event_name表中显示，并不在其他memory_summary_by_*xxx*_by_event_name表中显示。

此查询显示与内存工具相关的信息：

SELECT * FROM performance_schema.memory_summary_global_by_event_name
WHERE EVENT_NAME LIKE 'memory/performance_schema/%';

29.18 性能模式和插件

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-and-plugins.html

使用UNINSTALL PLUGIN命令移除插件不会影响已经收集的插件中的代码信息。即使稍后卸载插件，执行插件加载时花费的时间仍然会被计算在内。相关的事件信息，包括聚合信息，仍然可以在performance_schema数据库表中读取。有关插件安装和移除的更多信息，请参见第 29.7 节，“性能模式状态监控”。

实现插件代码的插件开发者应该记录其插装特性，以便加载插件的人能够考虑其需求。例如，第三方存储引擎应该在文档中说明引擎需要多少内存用于互斥锁和其他插装。

29.19 使用性能模式诊断问题

译文：dev.mysql.com/doc/refman/8.0/en/performance-schema-examples.html

29.19.1 使用性能模式进行查询分析

29.19.2 获取父事件信息

性能模式是帮助数据库管理员通过进行实际测量而不是“猜测”来进行性能调优的工具。本节演示了使用性能模式进行此目的的一些方法。这里的讨论依赖于事件过滤的使用，该过滤在 Section 29.4.2, “性能模式事件过滤”中有描述。

以下示例提供了一种方法，您可以使用该方法分析可重复的问题，例如调查性能瓶颈。首先，您应该有一个性能被认为“太慢”并需要优化的可重复用例，并且应该启用所有仪器（完全不进行预过滤）。

  1. 运行用例。

  2. 使用性能模式表，分析性能问题的根本原因。这种分析在很大程度上依赖于后过滤。

  3. 对于已排除的问题领域，禁用相应的仪器。例如，如果分析显示问题与特定存储引擎中的文件 I/O 无关，则禁用该引擎的文件 I/O 仪器。然后截断历史和摘要表以删除先前收集的事件。

  4. 重复步骤 1 中的过程。

    随着每次迭代，性能模式输出，特别是events_waits_history_long表，包含的由于不重要的仪器引起的“噪音”越来越少，而且由于该表具有固定大小，包含的与手头问题分析相关的数据越来越多。

    随着每次迭代，调查应该越来越接近问题的根本原因，因为“信号/噪音”比例改善，使分析变得更容易。

  5. 一旦确定了性能瓶颈的根本原因，采取适当的纠正措施，例如：

    • 调整服务器参数（缓存大小、内存等）。

    • 通过不同方式编写查询来调整查询，

    • 调整数据库架构（表、索引等）。

    • 调整代码（仅适用于存储引擎或服务器开发人员）。

  6. 重新从步骤 1 开始，以查看对性能的更改产生的影响。

mutex_instances.LOCKED_BY_THREAD_ID 和 rwlock_instances.WRITE_LOCKED_BY_THREAD_ID 列对于调查性能瓶颈或死锁非常重要。这是通过性能模式仪器实现的：

  1. 假设线程 1 因等待互斥锁而被阻塞。

  2. 您可以确定线程正在等待什么：

    SELECT * FROM performance_schema.events_waits_current
WHERE THREAD_ID = *thread_1*;

    查询结果显示线程正在等待互斥锁 A，位于events_waits_current.OBJECT_INSTANCE_BEGIN。

  3. 你可以确定哪个线程正在持有互斥锁 A：

    SELECT * FROM performance_schema.mutex_instances
WHERE OBJECT_INSTANCE_BEGIN = *mutex_A*;

    查询结果显示线程 2 正在持有互斥锁 A，如mutex_instances.LOCKED_BY_THREAD_ID中所示。

  4. 你可以看到线程 2 在做什么：

    SELECT * FROM performance_schema.events_waits_current
WHERE THREAD_ID = *thread_2*;

29.19.1 使用性能模式进行查询分析

译文：dev.mysql.com/doc/refman/8.0/en/performance-schema-query-profiling.html

以下示例演示了如何使用性能模式语句事件和阶段事件检索与SHOW PROFILES和SHOW PROFILE语句提供的性能信息类似的数据。

setup_actors表可用于通过主机、用户或帐户限制历史事件的收集，以减少运行时开销和历史表中收集的数据量。示例的第一步显示了如何将历史事件的收集限制为特定用户。

性能模式以皮秒（万亿分之一秒）显示事件计时器信息，以将时间数据标准化为标准单位。在以下示例中，TIMER_WAIT值除以 1000000000000 以以秒为单位显示数据。值还被截断为 6 位小数以以与SHOW PROFILES和SHOW PROFILE语句相同的格式显示数据。

  1. 将历史事件的收集限制为运行查询的用户。默认情况下，setup_actors配置为允许监视和历史事件收集所有前台线程：

    mysql> SELECT * FROM performance_schema.setup_actors;
+------+------+------+---------+---------+
| HOST | USER | ROLE | ENABLED | HISTORY |
+------+------+------+---------+---------+
| %    | %    | %    | YES     | YES     |
+------+------+------+---------+---------+

    更新setup_actors表中的默认行，禁用所有前台线程的历史事件收集和监视，并插入一个新行，以启用运行查询的用户的监视和历史事件收集：

    mysql> UPDATE performance_schema.setup_actors
       SET ENABLED = 'NO', HISTORY = 'NO'
       WHERE HOST = '%' AND USER = '%';

mysql> INSERT INTO performance_schema.setup_actors
       (HOST,USER,ROLE,ENABLED,HISTORY)
       VALUES('localhost','test_user','%','YES','YES');

    setup_actors表中的数据现在应类似于以下内容：

    mysql> SELECT * FROM performance_schema.setup_actors;
+-----------+-----------+------+---------+---------+
| HOST      | USER      | ROLE | ENABLED | HISTORY |
+-----------+-----------+------+---------+---------+
| %         | %         | %    | NO      | NO      |
| localhost | test_user | %    | YES     | YES     |
+-----------+-----------+------+---------+---------+

  2. 确保通过更新setup_instruments表启用语句和阶段仪器。一些仪器可能已默认启用。

    mysql> UPDATE performance_schema.setup_instruments
       SET ENABLED = 'YES', TIMED = 'YES'
       WHERE NAME LIKE '%statement/%';

mysql> UPDATE performance_schema.setup_instruments
       SET ENABLED = 'YES', TIMED = 'YES'
       WHERE NAME LIKE '%stage/%';

  3. 确保events_statements_*和events_stages_*消费者已启用。一些消费者可能已默认启用。

    mysql> UPDATE performance_schema.setup_consumers
       SET ENABLED = 'YES'
       WHERE NAME LIKE '%events_statements_%';

mysql> UPDATE performance_schema.setup_consumers
       SET ENABLED = 'YES'
       WHERE NAME LIKE '%events_stages_%';

  4. 在您正在监视的用户帐户下，运行要分析的语句。例如：

    mysql> SELECT * FROM employees.employees WHERE emp_no = 10001;
+--------+------------+------------+-----------+--------+------------+
| emp_no | birth_date | first_name | last_name | gender | hire_date |
+--------+------------+------------+-----------+--------+------------+
|  10001 | 1953-09-02 | Georgi     | Facello   | M      | 1986-06-26 |
+--------+------------+------------+-----------+--------+------------+

  5. 通过查询events_statements_history_long表来识别语句的EVENT_ID。这一步类似于运行SHOW PROFILES来识别Query_ID。以下查询产生类似于SHOW PROFILES的输出：

    mysql> SELECT EVENT_ID, TRUNCATE(TIMER_WAIT/1000000000000,6) as Duration, SQL_TEXT
       FROM performance_schema.events_statements_history_long WHERE SQL_TEXT like '%10001%';
+----------+----------+--------------------------------------------------------+
| event_id | duration | sql_text                                               |
+----------+----------+--------------------------------------------------------+
|       31 | 0.028310 | SELECT * FROM employees.employees WHERE emp_no = 10001 |
+----------+----------+--------------------------------------------------------+

  6. 查询events_stages_history_long表以检索语句的阶段事件。阶段通过事件嵌套与语句相关联。每个阶段事件记录都有一个包含父语句的EVENT_ID的NESTING_EVENT_ID列。

    mysql> SELECT event_name AS Stage, TRUNCATE(TIMER_WAIT/1000000000000,6) AS Duration
       FROM performance_schema.events_stages_history_long WHERE NESTING_EVENT_ID=31;
+--------------------------------+----------+
| Stage                          | Duration |
+--------------------------------+----------+
| stage/sql/starting             | 0.000080 |
| stage/sql/checking permissions | 0.000005 |
| stage/sql/Opening tables       | 0.027759 |
| stage/sql/init                 | 0.000052 |
| stage/sql/System lock          | 0.000009 |
| stage/sql/optimizing           | 0.000006 |
| stage/sql/statistics           | 0.000082 |
| stage/sql/preparing            | 0.000008 |
| stage/sql/executing            | 0.000000 |
| stage/sql/Sending data         | 0.000017 |
| stage/sql/end                  | 0.000001 |
| stage/sql/query end            | 0.000004 |
| stage/sql/closing tables       | 0.000006 |
| stage/sql/freeing items        | 0.000272 |
| stage/sql/cleaning up          | 0.000001 |
+--------------------------------+----------+

29.19.2 获取父事件信息

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-obtaining-parent-events.html

data_locks 表显示持有和请求的数据锁。该表的行具有THREAD_ID列，指示拥有锁的会话的线程 ID，以及EVENT_ID列，指示导致锁的性能模式事件。(THREAD_ID, EVENT_ID)值的元组在其他性能模式表中隐式标识父事件：

  • events_waits_*xxx* 表中的父等待事件

  • events_stages_*xxx* 表中的父阶段事件

  • events_statements_*xxx* 表中的父语句事件

  • events_transactions_current 表中的父事务事件

要获取有关父事件的详细信息，请将THREAD_ID和EVENT_ID列与适当的父事件表中同名列进行连接。关系基于嵌套集数据模型，因此连接具有几个子句。给定由parent和child表示的父表和子表，连接如下所示：

WHERE
  parent.THREAD_ID = child.THREAD_ID        /* 1 */
  AND parent.EVENT_ID < child.EVENT_ID      /* 2 */
  AND (
    child.EVENT_ID <= parent.END_EVENT_ID   /* 3a */
    OR parent.END_EVENT_ID IS NULL          /* 3b */
  )

连接的条件是：

  1. 父事件和子事件在同一线程中。

  2. 子事件在父事件之后开始，因此其EVENT_ID值大于父事件的值。

  3. 父事件已经完成或仍在运行。

要查找锁信息，data_locks 是包含子事件的表。

data_locks 表仅显示现有锁定，因此关于哪个表包含父事件的考虑如下：

  • 对于事务，唯一的选择是events_transactions_current。如果事务已完成，则可能在事务历史表中，但锁已经消失。

  • 对于语句，一切取决于获取锁的语句是否是已经完成的事务中的语句（使用events_statements_history）还是语句仍在运行（使用events_statements_current）。

  • 对于阶段，逻辑与语句类似；使用events_stages_history或events_stages_current。

  • 对于等待，逻辑与语句类似；使用events_waits_history或events_waits_current。然而，记录的等待太多，导致引起锁定的等待很可能已经从历史表中消失。

等待、阶段和语句事件很快就会从历史中消失。如果很久之前执行的语句获取了锁但仍在打开的事务中，可能无法找到该语句，但可以找到事务。

这就是为什么嵌套集数据模型更适合定位父事件。在父/子关系（数据锁 -> 父等待 -> 父阶段 -> 父事务）中跟随链接时，当中间节点已经从历史表中消失时，效果不佳。

以下场景说明了如何找到在其中获取锁的语句的父事务：

会话 A：

[1] START TRANSACTION;
[2] SELECT * FROM t1 WHERE pk = 1;
[3] SELECT 'Hello, world';

会话 B：

SELECT ...
FROM performance_schema.events_transactions_current AS parent
  INNER JOIN performance_schema.data_locks AS child
WHERE
  parent.THREAD_ID = child.THREAD_ID
  AND parent.EVENT_ID < child.EVENT_ID
  AND (
    child.EVENT_ID <= parent.END_EVENT_ID
    OR parent.END_EVENT_ID IS NULL
  );

会话 B 的查询应该显示语句 [2] 拥有记录中 pk=1 的数据锁。

如果会话 A 执行更多语句，[2] 将从历史表中消失。

查询应该显示从 [1] 开始的事务，无论执行了多少语句、阶段或等待。

要查看更多数据，还可以使用events_*xxx*_history_long表，除了事务，假设服务器中没有运行其他查询（以便保留历史记录）。

29.20 关于 Performance Schema 的限制

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-restrictions.html

Performance Schema 避免使用互斥锁来收集或生成数据，因此无法保证一致性，结果有时可能不正确。performance_schema 表中的事件值是不确定性的且不可重复的。

如果您将事件信息保存在另一个表中，则不应假定原始事件稍后仍然可用。例如，如果您从 performance_schema 表中选择事件到临时表中，打算稍后将该表与原始表连接，可能会找不到匹配项。

mysqldump 和 BACKUP DATABASE 会忽略 performance_schema 数据库中的表。

performance_schema 数据库中的表无法使用 LOCK TABLES 进行锁定，除了 setup_*xxx* 表。

performance_schema 数据库中的表无法被索引。

performance_schema 数据库中的表不会被复制。

计时器的类型可能因平台而异。performance_timers 表显示了可用的事件计时器。如果给定计时器名称在此表中的值为 NULL，则表示该计时器在您的平台上不受支持。

适用于存储引擎的工具可能并未为所有存储引擎实现。每个第三方引擎的工具化是引擎维护者的责任。

第三十章 MySQL sys 模式

原文：dev.mysql.com/doc/refman/8.0/en/sys-schema.html

目录

30.1 使用 sys 模式的先决条件

30.2 使用 sys 模式

30.3 sys 模式的进度报告

30.4 sys 模式对象参考

30.4.1 sys 模式对象索引

30.4.2 sys 模式的表和触发器

30.4.3 sys 模式的视图

30.4.4 sys 模式的存储过程

30.4.5 sys 模式的存储函数

MySQL 8.0 包括sys模式，这是一组对象，帮助 DBA 和开发人员解释 Performance Schema 收集的数据。sys模式对象可用于典型的调优和诊断用例。此模式中的对象包括：

  • 将 Performance Schema 数据汇总为更易理解形式的视图。

  • 执行操作，如 Performance Schema 配置和生成诊断报告的存储过程。

  • 查询 Performance Schema 配置并提供格式化服务的存储函数。

对于新安装，如果您使用带有--initialize或--initialize-insecure选项的mysqld进行数据目录初始化，默认情况下会安装sys模式。如果不需要这个模式，您可以在初始化后手动删除sys模式。

如果存在一个没有version视图的sys模式，则 MySQL 升级过程会产生错误，假设缺少此视图表示用户创建了sys模式。在这种情况下，要升级，请先删除或重命名现有的sys模式。

sys模式对象的DEFINER为'mysql.sys'@'localhost'。使用专用的mysql.sys帐户可以避免如果 DBA 重命名或删除root帐户而导致的问题。

30.1 使用 sys 模式的先决条件

原文：dev.mysql.com/doc/refman/8.0/en/sys-schema-prerequisites.html

在使用sys模式之前，必须满足本节中描述的先决条件。

因为sys模式提供了访问性能模式的另一种方式，所以性能模式必须启用才能使sys模式正常工作。请参阅第 29.3 节“性能模式启动配置”。

要完全访问sys模式，用户必须具有以下权限：

  • 对所有sys表和视图进行SELECT操作

  • 对所有sys存储过程和函数进行EXECUTE操作

  • 如果要对其进行更改，则对sys_config表进行INSERT和UPDATE操作

  • 对于某些sys模式存储过程和函数，还需要额外的权限，如其描述中所述（例如，ps_setup_save()过程")过程）

还必须具有底层对象的权限，这些对象是sys模式对象的基础：

  • 对由sys模式对象访问的任何性能模式表进行SELECT操作，并且对使用sys模式对象更新的任何表进行UPDATE操作

  • 对INFORMATION_SCHEMA中的INNODB_BUFFER_PAGE表进行PROCESS操作

必须启用某些性能模式工具和消费者，并且（对于工具）必须定时以充分利用sys模式的功能：

  • 所有wait工具

  • 所有stage工具

  • 所有statement工具

  • *xxx*_current和*xxx*_history_long消费者适用于所有事件

你可以使用sys模式本身来启用所有额外的工具和消费者：

CALL sys.ps_setup_enable_instrument('wait');
CALL sys.ps_setup_enable_instrument('stage');
CALL sys.ps_setup_enable_instrument('statement');
CALL sys.ps_setup_enable_consumer('current');
CALL sys.ps_setup_enable_consumer('history_long');

注意

对于sys模式的许多用途，默认的性能模式已足以进行数据收集。启用所有上述提到的仪器和消费者会对性能产生影响，因此最好只启用您需要的额外配置。另外，请记住，如果您启用了额外的配置，可以轻松地像这样恢复默认配置：

CALL sys.ps_setup_reset_to_default(TRUE);

30.2 使用 sys 模式

原文：dev.mysql.com/doc/refman/8.0/en/sys-schema-usage.html

您可以将 sys 模式设置为默认模式，以便引用其对象时无需使用模式名称限定：

mysql> USE sys;
Database changed
mysql> SELECT * FROM version;
+-------------+---------------+
| sys_version | mysql_version |
+-------------+---------------+
| 2.1.1       | 8.0.26-debug  |
+-------------+---------------+

（version 视图显示 sys 模式和 MySQL 服务器版本。）

要在默认情况下访问 sys 模式对象（或者只是明确），请使用模式名称限定对象引用：

mysql> SELECT * FROM sys.version;
+-------------+---------------+
| sys_version | mysql_version |
+-------------+---------------+
| 2.1.1       | 8.0.26-debug  |
+-------------+---------------+

sys 模式包含许多以不同方式总结性能模式表的视图。其中大多数视图都是成对出现的，其中一对的名称与另一对成员的名称相同，只是前面有一个 x$ 前缀。例如，host_summary_by_file_io 视图按主机分组总结文件 I/O，并显示从皮秒转换为更易读值（带单位）的延迟；

mysql> SELECT * FROM sys.host_summary_by_file_io;
+------------+-------+------------+
| host       | ios   | io_latency |
+------------+-------+------------+
| localhost  | 67570 | 5.38 s     |
| background |  3468 | 4.18 s     |
+------------+-------+------------+

x$host_summary_by_file_io 视图总结相同数据，但显示未格式化的皮秒延迟：

mysql> SELECT * FROM sys.x$host_summary_by_file_io;
+------------+-------+---------------+
| host       | ios   | io_latency    |
+------------+-------+---------------+
| localhost  | 67574 | 5380678125144 |
| background |  3474 | 4758696829416 |
+------------+-------+---------------+

没有 x$ 前缀的视图旨在提供更用户友好且更易于人类阅读的输出。带有 x$ 前缀的视图显示相同值的原始形式，更适用于其他对数据执行自己处理的工具。有关非 x$ 和 x$ 视图之间差异的更多信息，请参阅 第 30.4.3 节“sys 模式视图”。

要检查 sys 模式对象定义，请使用适当的 SHOW 语句或 INFORMATION_SCHEMA 查询。例如，要检查 session 视图和 format_bytes() 函数") 函数的定义，请使用以下语句：

mysql> SHOW CREATE VIEW sys.session;
mysql> SHOW CREATE FUNCTION sys.format_bytes;

然而，这些语句以相对未格式化的形式显示定义。要查看具有更易读格式的对象定义，请访问 MySQL 源分发中 scripts/sys_schema 下找到的各个 .sql 文件。在 MySQL 8.0.18 之前，这些源代码是在一个单独的分发中维护的，可以从 sys 模式开发网站 github.com/mysql/mysql-sys 获取。

无论是mysqldump还是mysqlpump默认情况下都不会转储sys模式。要生成一个转储文件，请在命令行上明确命名sys模式，使用以下任一命令：

mysqldump --databases --routines sys > sys_dump.sql
mysqlpump sys > sys_dump.sql

要从转储文件重新安装模式，请使用以下命令：

mysql < sys_dump.sql

30.3 sys Schema 进度报告

原文：dev.mysql.com/doc/refman/8.0/en/sys-schema-progress-reporting.html

以下sys模式视图为长时间运行的事务提供进度报告：

processlist
session
x$processlist
x$session

假设所需的仪器和消费者已启用，则这些视图的progress列显示支持进度报告的阶段已完成工作的百分比。

阶段进度报告要求启用events_stages_current消费者，以及需要进度信息的仪器。目前支持进度报告的阶段的仪器有：

stage/sql/Copying to tmp table
stage/innodb/alter table (end)
stage/innodb/alter table (flush)
stage/innodb/alter table (insert)
stage/innodb/alter table (log apply index)
stage/innodb/alter table (log apply table)
stage/innodb/alter table (merge sort)
stage/innodb/alter table (read PK and internal sort)
stage/innodb/buffer pool load

对于不支持估计和已完成工作报告的阶段，或者如果所需的仪器或消费者未启用，则progress列为NULL。

30.4 sys 模式对象参考

原文：dev.mysql.com/doc/refman/8.0/en/sys-schema-reference.html

30.4.1 sys 模式对象索引

30.4.2 sys 模式的表和触发器

30.4.3 sys 模式的视图

30.4.4 sys 模式的存储过程

30.4.5 sys 模式的存储函数

sys模式包括表和触发器、视图以及存储过程和函数。以下部分详细介绍了这些对象。

30.4.1 sys 模式对象索引

原文：dev.mysql.com/doc/refman/8.0/en/sys-schema-object-index.html

下表列出了sys模式对象，并提供了每个对象的简短描述。

表 30.1 sys 模式表和触发器

表或触发器名称 描述
sys_config sys 模式配置选项表
sys_config_insert_set_user sys_config 插入触发器
sys_config_update_set_user sys_config 更新触发器

表 30.2 sys 模式视图

视图名称 描述 已弃用
host_summary, x$host_summary 按主机分组的语句活动、文件 I/O 和连接
host_summary_by_file_io, x$host_summary_by_file_io 按主机分组的文件 I/O
host_summary_by_file_io_type, x$host_summary_by_file_io_type 按主机和事件类型分组的文件 I/O
host_summary_by_stages, x$host_summary_by_stages 按主机分组的语句阶段
host_summary_by_statement_latency, x$host_summary_by_statement_latency 按主机分组的语句统计信息
host_summary_by_statement_type, x$host_summary_by_statement_type 按主机和语句分组的执行语句
innodb_buffer_stats_by_schema, x$innodb_buffer_stats_by_schema 按模式分组的 InnoDB 缓冲区信息
innodb_buffer_stats_by_table, x$innodb_buffer_stats_by_table 按模式和表分组的 InnoDB 缓冲区信息
innodb_lock_waits, x$innodb_lock_waits InnoDB 锁信息
io_by_thread_by_latency, x$io_by_thread_by_latency 按线程分组的 I/O 消费者
io_global_by_file_by_bytes, x$io_global_by_file_by_bytes 按文件和字节分组的全局 I/O 消费者
io_global_by_file_by_latency, x$io_global_by_file_by_latency 按文��和延迟分组的全局 I/O 消费者
io_global_by_wait_by_bytes, x$io_global_by_wait_by_bytes 按字节分组的全局 I/O 消费者
io_global_by_wait_by_latency, x$io_global_by_wait_by_latency 按延迟分组的全局 I/O 消费者
latest_file_io, x$latest_file_io 最近的 I/O，按文件和线程分组
memory_by_host_by_current_bytes, x$memory_by_host_by_current_bytes 按主机分组的内存使用
memory_by_thread_by_current_bytes, x$memory_by_thread_by_current_bytes 按线程分组的内存使用
memory_by_user_by_current_bytes, x$memory_by_user_by_current_bytes 按用户分组的内存使用
memory_global_by_current_bytes, x$memory_global_by_current_bytes 按分配类型分组的内存使用
memory_global_total, x$memory_global_total 总内存使用
metrics 服务器指标
processlist, x$processlist 进程列表信息
ps_check_lost_instrumentation 已丢失仪器的变量
schema_auto_increment_columns AUTO_INCREMENT 列信息
schema_index_statistics, x$schema_index_statistics 索引统计信息
schema_object_overview 每个模式中对象的类型
schema_redundant_indexes 重复或冗余索引
schema_table_lock_waits, x$schema_table_lock_waits 等待元数据锁的会话
schema_table_statistics, x$schema_table_statistics 表统计信息
schema_table_statistics_with_buffer, x$schema_table_statistics_with_buffer 表统计信息，包括 InnoDB 缓冲池统计信息
schema_tables_with_full_table_scans, x$schema_tables_with_full_table_scans 使用全表扫描访问的表
schema_unused_indexes 未被使用的索引
session, x$session 用户会话的进程列表信息
session_ssl_status 连接 SSL 信息
statement_analysis, x$statement_analysis 语句聚合统计信息
statements_with_errors_or_warnings, x$statements_with_errors_or_warnings 产生错误或警告的语句
statements_with_full_table_scans, x$statements_with_full_table_scans 执行全表扫描的语句
statements_with_runtimes_in_95th_percentile, x$statements_with_runtimes_in_95th_percentile 平均运行时间最长的语句
statements_with_sorting, x$statements_with_sorting 执行排序操作的语句
statements_with_temp_tables, x$statements_with_temp_tables 使用临时表的语句
user_summary, x$user_summary 用户语��和连接活动
user_summary_by_file_io, x$user_summary_by_file_io 按用户分组的文件 I/O
user_summary_by_file_io_type, x$user_summary_by_file_io_type 按用户和事件分组的文件 I/O
user_summary_by_stages, x$user_summary_by_stages 按用户分组的阶段事件
user_summary_by_statement_latency, x$user_summary_by_statement_latency 按用户分组的语句统计信息
user_summary_by_statement_type, x$user_summary_by_statement_type 按用户和语句分组的执行语句
version 当前 sys 模式和 MySQL 服务器版本 8.0.18
wait_classes_global_by_avg_latency, x$wait_classes_global_by_avg_latency 按事件类别分组的等待类别平均延迟
wait_classes_global_by_latency, x$wait_classes_global_by_latency 按事件类别分组的等待类别总延迟
waits_by_host_by_latency, x$waits_by_host_by_latency 按主机和事件分组的等待事件
waits_by_user_by_latency, x$waits_by_user_by_latency 按用户和事件分组的等待事件
waits_global_by_latency, x$waits_global_by_latency 按事件分组的等待事件
x$ps_digest_95th_percentile_by_avg_us 95th-percentile 视图的辅助视图
x$ps_digest_avg_latency_distribution 95th-percentile 视图的辅助视图
x$ps_schema_table_statistics_io 表统计视图的辅助视图
x$schema_flattened_keys schema_redundant_indexes 的辅助视图
视图名称 描述 已弃用

表 30.3 sys 模式存储过程

过程名称 描述
create_synonym_db() 过程") 为模式创建同义词
diagnostics() 过程") 收集系统诊断信息
execute_prepared_stmt() 过程") 执行准备好的语句
ps_setup_disable_background_threads() 过程") 禁用后台线程仪器
ps_setup_disable_consumer() 过程") 禁用消费者
ps_setup_disable_instrument() 过程") 禁用仪器
ps_setup_disable_thread() 过程") 禁用线程的仪器
ps_setup_enable_background_threads() 过程") 启用后台线程仪器
ps_setup_enable_consumer() 过程") 启用消费者
ps_setup_enable_instrument() 过程") 启用仪器
ps_setup_enable_thread() 过程") 为线程启用仪器
ps_setup_reload_saved() 过程") 重新加载保存的性能模式配置
ps_setup_reset_to_default() 过程") 重置保存的性能模式配置
ps_setup_save() 过程") 保存性能模式配置
ps_setup_show_disabled() 过程") 显示已禁用的性能模式配置
ps_setup_show_disabled_consumers() 过程") 显示已禁用的性能模式消费者
ps_setup_show_disabled_instruments() 过程") 显示已禁用的性能模式工具
ps_setup_show_enabled() 过程") 显示已启用的性能模式配置
ps_setup_show_enabled_consumers() 过程") 显示已启用的性能模式消费者
ps_setup_show_enabled_instruments() 过程") 显示已启用的性能模式工具
ps_statement_avg_latency_histogram() 过程") 显示语句延迟直方图
ps_trace_statement_digest() 过程") 跟踪摘要的性能模式仪器
ps_trace_thread() 过程") 为线程转储性能模式数据
ps_truncate_all_tables() 过程") 截断性能模式摘要表
statement_performance_analyzer() 过程") 报告在服务器上运行的语句
table_exists() 过程") 检查表是否存在
过程名称 描述

表 30.4 sys 模式存储函数

函数名称 描述 已弃用
extract_schema_from_file_name() Function") 从文件名中提取模式名部分
extract_table_from_file_name() Function") 从文件名中提取表名部分
format_bytes() Function") 将字节计数转换为带单位的值 8.0.16
format_path() Function") 用符号系统变量名替换路径名中的目录
format_statement() Function") 将长语句截断为固定长度
format_time() Function") 将皮秒时间转换为带单位的值 8.0.16
list_add() Function") 向列表添加项目
list_drop() Function") 从列表中移除项目
ps_is_account_enabled() Function") 是否启用帐户的性能模式仪表
ps_is_consumer_enabled() Function") 是否启用性能模式消费者
ps_is_instrument_default_enabled() Function") 是否默认启用性能模式仪表
ps_is_instrument_default_timed() Function") 是否默认启用性能模式计时仪表
ps_is_thread_instrumented() Function") 是否启用连接 ID 的性能模式仪表
ps_thread_account() Function") 与性能模式线程 ID 关联的帐户
ps_thread_id() Function") 与连接 ID 关联的性能模式线程 ID 8.0.16
ps_thread_stack() Function") 连接 ID 的事件信息
ps_thread_trx_info() Function") 线程 ID 的事务信息
quote_identifier() Function") 将字符串引用为标识符
sys_get_config() Function") 系统模式配置选项值
version_major() 函数") MySQL 服务器主要版本号
version_minor() 函数") MySQL 服务器次要版本号
version_patch() 函数") MySQL 服务器补丁发布版本号
函数名称 描述 已弃用
posted @ 2024-06-23 16:27  绝不原创的飞龙  阅读(6)  评论(0)  编辑  收藏  举报