MySQL8-中文参考-一百零七-

布客飞龙
69 阅读1小时+

MySQL8 中文参考（一百零七）

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

29.10 性能模式语句摘要和采样

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

MySQL 服务器能够维护语句摘要信息。摘要过程将每个 SQL 语句转换为规范化形式（语句摘要），并从规范化结果计算一个 SHA-256 哈希值（摘要哈希值）。规范化允许类似的语句被分组和总结，以公开关于服务器正在执行的语句类型及其频率的信息。对于每个摘要，存储生成该摘要的代表性语句作为样本。本节描述了语句摘要和采样的发生方式以及它们的用途。

无论性能模式是否可用，解析器都会进行摘要处理，以便其他功能如 MySQL 企业防火墙和查询重写插件可以访问语句摘要。

  • 语句摘要概念

  • 性能模式中的语句摘要

  • 语句摘要内存使用

  • 语句采样

语句摘要概念

当解析器接收到一个 SQL 语句时，如果需要该摘要，则会计算一个语句摘要，如果以下任一条件为真，则为真：

  • 启用了性能模式摘要工具

  • 启用了 MySQL 企业防火墙

  • 启用了查询重写插件

解析器还被 STATEMENT_DIGEST_TEXT() 和 STATEMENT_DIGEST() 函数使用，应用程序可以调用这些函数从 SQL 语句中计算规范化语句摘要和摘要哈希值。

max_digest_length 系统变量的值确定了每个会话用于计算规范化语句摘要的最大字节数。一旦在摘要计算过程中使用了这么多空间，就会发生截断：从解析语句中收集的标记不再被收集或计入其摘要值。只有在解析标记之后的那么多字节之后才有所不同的语句会产生相同的规范化语句摘要，并且如果进行比较或用于摘要统计，则被视为相同。

警告

将max_digest_length系统变量设置为零会禁用摘要生成，这也会禁用需要摘要的服务器功能。

计算规范化语句后，从中计算 SHA-256 哈希值。此外：

  • 如果启用了 MySQL 企业防火墙，则会调用它，并且计算的摘要对其可用。

  • 如果启用了任何查询重写插件，则会调用它，并且语句摘要和摘要值对其可用。

  • 如果性能模式启用了摘要仪器，它会复制规范化的语句摘要，为其分配最多performance_schema_max_digest_length字节。因此，如果performance_schema_max_digest_length小于max_digest_length，则复制相对于原始文本被截断。规范化的语句摘要的副本存储在适当的性能模式表中，以及从原始规范化语句计算的 SHA-256 哈希值。 （如果性能模式相对于原始文本截断其规范化语句摘要的副本，则不会重新计算 SHA-256 哈希值。）

语句规范化将语句文本转换为更标准化的摘要字符串表示形式，保留一般语句结构同时删除不影响结构的信息：

  • 保留对象标识符，如数据库和表名。

  • 文本值被转换为参数标记。规范化的语句不保留名称、密码、日期等信息。

  • 注释被移除，空格被调整。

考虑这些语句：

SELECT * FROM orders WHERE customer_id=10 AND quantity>20
SELECT * FROM orders WHERE customer_id = 20 AND quantity > 100

为了规范化这些语句，解析器将数据值替换为?并调整空格。两个语句产生相同的规范化形式，因此被认为是“相同的”：

SELECT * FROM orders WHERE customer_id = ? AND quantity > ?

规范化的语句包含较少信息，但仍代表原始语句。其他类似的具有不同数据值的语句具有相同的规范化形式。

现在考虑这些语句：

SELECT * FROM customers WHERE customer_id = 1000
SELECT * FROM orders WHERE customer_id = 1000

在这种情况下，规范化的语句不同，因为对象标识符不同：

SELECT * FROM customers WHERE customer_id = ?
SELECT * FROM orders WHERE customer_id = ?

如果规范化产生的语句超过摘要缓冲区中可用的空间（由max_digest_length确定），则会发生截断，并且文本以“...”结尾。只有在“...”后面部分不同的长规范化语句被视为相同。考虑这些语句：

SELECT * FROM mytable WHERE cola = 10 AND colb = 20
SELECT * FROM mytable WHERE cola = 10 AND colc = 20

如果截断恰好发生在AND之后，则这两个语句具有相同的规范化形式：

SELECT * FROM mytable WHERE cola = ? AND ...

在这种情况下，第二列名称的差异被忽略，两个语句被视为相同。

性能模式中的语句摘要

在性能模式中，语句摘要涉及以下元素：

  • setup_consumers 表中的 statements_digest 消费者控制性能模式是否维护摘要信息。参见 语句摘要消费者。

  • 语句事件表（events_statements_current，events_statements_history 和 events_statements_history_long）具有用于存储规范语句摘要和相应摘要 SHA-256 哈希值的列：

    • DIGEST_TEXT 是规范语句摘要的文本。这是原始规范语句的副本，计算到最大 max_digest_length 字节，根据需要进一步截断为 performance_schema_max_digest_length 字节。

    • DIGEST 是从原始规范语句计算得出的摘要 SHA-256 哈希值。

    参见 第 29.12.6 节，“性能模式语句事件表”。

  • events_statements_summary_by_digest 摘要表提供了聚合的语句摘要信息。该表按 SCHEMA_NAME 和 DIGEST 组合对语句信息进行聚合。性能模式使用 SHA-256 哈希值进行聚合，因为它们计算速度快，并且具有有利的统计分布，可以最小化碰撞。参见 第 29.12.20.3 节，“语句摘要表”。

一些性能表具有一个列，用于存储计算摘要的原始 SQL 语句：

  • events_statements_current，events_statements_history 和 events_statements_history_long 语句事件表的 SQL_TEXT 列。

  • events_statements_summary_by_digest 摘要表的 QUERY_SAMPLE_TEXT 列。

默认情况下，语句显示的最大空间为 1024 字节。要更改此值，请在服务器启动时设置 performance_schema_max_sql_text_length 系统变量。更改会影响所有上述列所需的存储空间。

performance_schema_max_digest_length 系统变量确定性能模式中用于摘要值存储的每个语句的最大字节数。然而，由于语句元素（如关键字和文字值）的内部编码，语句摘要的显示长度可能长于可用缓冲区大小。因此，从语句事件表的 DIGEST_TEXT 列中选择的值可能会超过 performance_schema_max_digest_length 的值。

events_statements_summary_by_digest 摘要表提供了服务器执行的语句的概要。它显示了应用程序执行的语句类型和频率。应用程序开发人员可以将此信息与表中的其他信息一起使用，评估应用程序的性能特征。例如，显示等待时间、锁定时间或索引使用的表列可能突出显示效率低下的查询类型。这使开发人员了解应用程序哪些部分需要关注。

events_statements_summary_by_digest 摘要表具有固定大小。默认情况下，性能模式在启动时估计要使用的大小。要明确指定表大小，请在服务器启动时设置 performance_schema_digests_size 系统变量。如果表变满，性能模式将具有 SCHEMA_NAME 和 DIGEST 值不匹配现有表中值的语句分组到一个特殊行中，该行的 SCHEMA_NAME 和 DIGEST 设置为 NULL。这允许计算所有语句。但是，如果特殊行占执行的语句的显著百分比，可能需要通过增加 performance_schema_digests_size 来增加摘要表大小。

语句摘要内存使用

对于生成仅在结尾处有所不同的非常长语句的应用程序，增加max_digest_length可以计算出区分否则会聚合到相同摘要的语句的摘要。相反，减少max_digest_length会导致服务器将更少的内存用于摘要存储，但增加较长语句聚合到相同摘要的可能性。管理员应牢记，较大的值会导致相应增加的内存需求，特别是对于涉及大量同时会话的工作负载（服务器为每个会话分配max_digest_length字节）。

如前所述，由解析器计算的规范化语句摘要受限于最多max_digest_length字节，而性能模式中存储的规范化语句摘要使用performance_schema_max_digest_length字节。关于max_digest_length和performance_schema_max_digest_length的相对值，以下内存使用考虑适用：

  • 如果max_digest_length小于performance_schema_max_digest_length：

    • 除了性能模式之外的服务器功能使用占用最多max_digest_length字节的规范化语句摘要。

    • 性能模式不会进一步截断存储的规范化语句摘要，但为每个摘要分配比max_digest_length字节更多的内存，这是不必要的。

  • 如果max_digest_length等于performance_schema_max_digest_length：

    • 除了性能模式之外的服务器功能使用占用最多max_digest_length字节的规范化语句摘要。

    • 性能模式不会进一步截断存储的规范化语句摘要，并为每个摘要分配与max_digest_length字节相同的内存。

  • 如果max_digest_length大于performance_schema_max_digest_length：

    • Performance Schema 之外的服务器功能使用占用max_digest_length字节的规范语句摘要。

    • Performance Schema 进一步截断其存储的规范语句摘要，并为每个摘要分配少于max_digest_length字节的内存。

因为 Performance Schema 语句事件表可能存储许多摘要，所以将performance_schema_max_digest_length设置为小于max_digest_length使管理员能够平衡这些因素：

  • 在 Performance Schema 之外的服务器功能需要长规范语句摘要

  • 许多并发会话，每个会话分配摘要计算内存

  • 在存储许多语句摘要时，需要限制 Performance Schema 语句事件表的内存消耗

performance_schema_max_digest_length设置不是每个会话，而是每个语句，一个会话可以在events_statements_history表中存储多个语句。在此表中的典型语句数量为每个会话 10 个，因此每个会话仅针对此表消耗了performance_schema_max_digest_length值所示的内存的 10 倍。

此外，全局收集了许多语句（和摘要），最显著的是在events_statements_history_long表中。在这里，存储的N语句消耗了N倍于performance_schema_max_digest_length值所示内存的内存。

要评估用于 SQL 语句存储和摘要计算的内存量，请使用SHOW ENGINE PERFORMANCE_SCHEMA STATUS语句，或监视这些指标：

mysql> SELECT NAME
       FROM performance_schema.setup_instruments
       WHERE NAME LIKE '%.sqltext';
+------------------------------------------------------------------+
| NAME                                                             |
+------------------------------------------------------------------+
| memory/performance_schema/events_statements_history.sqltext      |
| memory/performance_schema/events_statements_current.sqltext      |
| memory/performance_schema/events_statements_history_long.sqltext |
+------------------------------------------------------------------+

mysql> SELECT NAME
       FROM performance_schema.setup_instruments
       WHERE NAME LIKE 'memory/performance_schema/%.tokens';
+----------------------------------------------------------------------+
| NAME                                                                 |
+----------------------------------------------------------------------+
| memory/performance_schema/events_statements_history.tokens           |
| memory/performance_schema/events_statements_current.tokens           |
| memory/performance_schema/events_statements_summary_by_digest.tokens |
| memory/performance_schema/events_statements_history_long.tokens      |
+----------------------------------------------------------------------+

语句抽样

性能模式使用语句取样来收集在events_statements_summary_by_digest表中生成每个摘要值的代表性语句。这些列存储样本语句信息：QUERY_SAMPLE_TEXT（语句的文本），QUERY_SAMPLE_SEEN（语句被看到的时间）和QUERY_SAMPLE_TIMER_WAIT（语句等待或执行时间）。每次选择样本语句时，性能模式都会更新这三列。

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

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

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

默认情况下，performance_schema_max_digest_sample_age为 60 秒（1 分钟）。要更改样本语句由于年龄而“过期”的速度，增加或减少该值。要禁用基于年龄的重新取样策略的部分，请将performance_schema_max_digest_sample_age设置为 0。

29.11 性能模式通用表特性

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

performance_schema数据库的名称是小写的，其中的表名也是小写的。查询应该以小写指定名称。

performance_schema数据库中的许多表是只读的，不能被修改：

mysql> TRUNCATE TABLE performance_schema.setup_instruments;
ERROR 1683 (HY000): Invalid performance_schema usage.

一些设置表具有可以修改以影响性能模式操作的列；有些还允许插入或删除行。允许截断以清除收集的事件，因此可以在包含这些类型信息的表上使用TRUNCATE TABLE，例如以events_waits_为前缀命名的表。

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

权限与其他数据库和表相同：

  • 要从performance_schema表中检索，您必须具有SELECT权限。

  • 要更改可以修改的列，您必须具有UPDATE权限。

  • 要截断可以截断的表，您必须具有DROP权限。

因为性能模式表只适用于有限的一组特权，尝试使用GRANT ALL作为在数据库或表级别授予权限的简写会导致错误：

mysql> GRANT ALL ON performance_schema.*
       TO 'u1'@'localhost';
ERROR 1044 (42000): Access denied for user 'root'@'localhost'
to database 'performance_schema'
mysql> GRANT ALL ON performance_schema.setup_instruments
       TO 'u2'@'localhost';
ERROR 1044 (42000): Access denied for user 'root'@'localhost'
to database 'performance_schema'

相反，授予确切所需的权限：

mysql> GRANT SELECT ON performance_schema.*
       TO 'u1'@'localhost';
Query OK, 0 rows affected (0.03 sec)

mysql> GRANT SELECT, UPDATE ON performance_schema.setup_instruments
       TO 'u2'@'localhost';
Query OK, 0 rows affected (0.02 sec)

29.12 性能模式表描述

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

29.12.1 性能模式表参考

29.12.2 性能模式设置表

29.12.3 性能模式实例表

29.12.4 性能模式等待事件表

29.12.5 性能模式阶段事件表

29.12.6 性能模式语句事件表

29.12.7 性能模式事务表

29.12.8 性能模式连接表

29.12.9 性能模式连接属性表

29.12.10 性能模式用户定义变量表

29.12.11 性能模式复制表

29.12.12 性能模式 NDB 集群表

29.12.13 性能模式锁表

29.12.14 性能模式系统变量表

29.12.15 性能模式状态变量表

29.12.16 性能模式线程池表

29.12.17 性能模式防火墙表

29.12.18 性能模式密钥环表

29.12.19 性能模式克隆表

29.12.20 性能模式摘要表

29.12.21 性能模式杂项表

performance_schema 数据库中的表可以分为以下几类：

  • 设置表。这些表用于配置和显示监控特性。

  • 当前事件表。events_waits_current 表包含每个线程的最新事件。其他类似的表包含不同层次事件的当前事件：events_stages_current 用于阶段事件，events_statements_current 用于语句事件，以及events_transactions_current 用于事务事件。

  • 历史表。这些表与当前事件表具有相同的结构，但包含更多行。例如，对于等待事件，events_waits_history 表包含每个线程的最新 10 个事件。events_waits_history_long 包含最近的 10,000 个事件。其他类似的表存在于阶段、语句和事务历史中。

    要更改历史表的大小，请在服务器启动时设置适当的系统变量。例如，要设置等待事件历史表的大小，请设置performance_schema_events_waits_history_size 和performance_schema_events_waits_history_long_size。

  • 汇总表。这些表包含对事件组进行聚合的信息，包括已从历史表中丢弃的事件。

  • 实例表。这些表记录了被检测对象的类型。当服务器使用被检测对象时，会产生一个事件。这些表提供事件名称、解释说明或状态信息。

  • 杂项表。这些表不属于任何其他表组。

29.12.1 性能模式表参考

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

以下表格总结了所有可用的性能模式表。更详细的信息，请参阅各个表的描述。

表 29.1 性能模式表

表名描述引入版本
accounts每个客户端账户的连接统计
binary_log_transaction_compression_stats二进制日志事务压缩8.0.20
clone_progress克隆操作进度8.0.17
clone_status克隆操作状态8.0.17
component_scheduler_tasks计划任务的状态8.0.34
cond_instances同步对象实例
data_lock_waits数据锁等待关系
data_locks持有和请求的数据锁
error_log服务器错误日志最近条目8.0.22
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每个错误代码的错误
events_stages_current当前阶段事件
events_stages_history每个线程的最近阶段事件
events_stages_history_long最近的整体阶段事件
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每个事件名称的阶段等待
events_statements_current当前语句事件
events_statements_histogram_by_digest每个模式和摘要值的语句直方图
events_statements_histogram_global全局汇总的语句直方图
events_statements_history每个线程的最近语句事件
events_statements_history_long最近的整体语句事件
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每个事件名称的语句事件
events_transactions_current当前事务事件
events_transactions_history每个线程的最近事务事件
events_transactions_history_long最近的所有事务事件
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每个事件名称的事务事件
events_waits_current当前等待事件
events_waits_history每个线程的最近等待事件
events_waits_history_long最近的所有等待事件
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按事件名称的等待事件
file_instances文件实例
file_summary_by_event_name按事件名称的文件事件
file_summary_by_instance按文件实例的文件事件
firewall_group_allowlist组配置允许列表的防火墙内存数据8.0.23
firewall_groups组配置的防火墙内存数据8.0.23
firewall_membership组配置成员的防火墙内存数据8.0.23
global_status全局状态变量
global_variables全局系统变量
host_cache内部主机缓存的信息
hosts每个客户端主机名称的连接统计
keyring_component_status已安装密钥环组件的状态信息8.0.24
keyring_keys密钥环键的元数据8.0.16
log_status用于备份目的的服务器日志信息
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按事件名称全局内存操作
metadata_locks元数据锁和锁请求
mutex_instances互斥同步对象实例
ndb_sync_excluded_objects无法同步的 NDB 对象8.0.21
ndb_sync_pending_objects等待同步的 NDB 对象8.0.21
objects_summary_global_by_type对象摘要
performance_timers可用的事件计时器
persisted_variablesmysqld-auto.cnf 文件的内容
prepared_statements_instances准备语句实例和统计信息
processlist进程列表信息8.0.22
replication_applier_configuration复制应用程序在副本上的配置参数
replication_applier_filters当前副本上的通道特定复制过滤器
replication_applier_global_filters当前副本上的全局复制过滤器
replication_applier_status复制应用程序在副本上的当前状态
replication_applier_status_by_coordinatorSQL 或协调器线程应用程序状态
replication_applier_status_by_worker工作线程应用程序状态
replication_asynchronous_connection_failover异步连接故障转移机制的源列表8.0.22
replication_asynchronous_connection_failover_managed异步连接故障转移机制的受控源列表8.0.23
replication_connection_configuration连接到源的配置参数
replication_connection_status与源的当前连接状态
replication_group_communication_information复制组配置选项8.0.27
replication_group_member_stats复制组成员统计信息
replication_group_members复制组成员网络和状态
rwlock_instances锁同步对象实例
session_account_connect_attrs当前会话的连接属性
session_connect_attrs所有会话的连接属性
session_status当前会话的状态变量
session_variables当前会话的系统变量
setup_actors如何为新前台线程初始化监视
setup_consumers可存储事件信息的消费者
setup_instruments可收集事件的已标记对象类别
setup_objects应监视的对象
setup_threads已标记线程名称和属性
socket_instances活动连接实例
socket_summary_by_event_name按事件名称的套接字等待和 I/O
socket_summary_by_instance按实例的套接字等待和 I/O
status_by_account每个账户的会话状态变量
status_by_host每个主机名的会话状态变量
status_by_thread每个会话的会话状态变量
status_by_user每个用户名的会话状态变量
table_handles表锁和锁请求
table_io_waits_summary_by_index_usage按索引使用情况的表 I/O 等待
table_io_waits_summary_by_table按表的表 I/O 等待
table_lock_waits_summary_by_table按表的表锁等待
threads服务器线程信息
tls_channel_status每个连接接口的 TLS 状态8.0.21
tp_thread_group_state线程池线程组状态8.0.14
tp_thread_group_stats线程池线程组统计信息8.0.14
tp_thread_state线程池线程信息8.0.14
user_defined_functions注册的可加载函数
user_variables_by_thread每个线程的用户定义变量
users每个客户端用户名的连接统计
variables_by_thread每个会话的会话系统变量
variables_info最近设置的系统变量
表名描述引入版本

29.12.2 性能模式设置表

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

29.12.2.1 设置演员表

29.12.2.2 设置消费者表

29.12.2.3 设置仪器表

29.12.2.4 设置对象表

29.12.2.5 设置线程表

设置表提供有关当前仪表化的信息，并允许更改监视配置。因此，如果您拥有UPDATE权限，则可以更改这些表中的某些列。

使用表而不是单个变量来存储设置信息，在修改性能模式配置方面提供了高度的灵活性。例如，您可以使用标准 SQL 语法的单个语句进行多个同时配置更改。

可用的设置表包括：

  • setup_actors：如何为新的前台线程初始化监视

  • setup_consumers：可以发送和存储事件信息的目的地

  • setup_instruments：可以收集事件的被检测对象的类别

  • setup_objects：应该监视哪些对象

  • setup_threads：被检测线程的名称和属性

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

29.12.2.1 设置 _actors 表

setup_actors表包含确定是否为新的前台服务器线程（与客户端连接关联的线程）启用监视和历史事件记录的信息。默认情况下，此表的最大大小为 100 行。要更改表大小，请在服务器启动时修改performance_schema_setup_actors_size系统变量。

对于每个新的前台线程，性能模式将线程的用户和主机与setup_actors表的行进行匹配。如果该表中的行匹配，则使用其ENABLED和HISTORY列值来设置线程的threads行的INSTRUMENTED和HISTORY列，分别。这使得可以根据主机、用户或帐户（用户和主机组合）有选择地应用仪器化和历史事件记录。如果没有匹配，则线程的INSTRUMENTED和HISTORY列设置为NO。

对于后台线程，没有关联的用户。INSTRUMENTED和HISTORY默认为YES，并且不会查询setup_actors。

setup_actors表的初始内容匹配任何用户和主机组合，因此默认情况下为所有前台线程启用监视和历史事件收集：

mysql> SELECT * FROM performance_schema.setup_actors;
+------+------+------+---------+---------+
| HOST | USER | ROLE | ENABLED | HISTORY |
+------+------+------+---------+---------+
| %    | %    | %    | YES     | YES     |
+------+------+------+---------+---------+

有关如何使用setup_actors表影响事件监视的信息，请参见第 29.4.6 节，“按线程进行预过滤”。

对setup_actors表的修改仅影响在修改后创建的前台线程，而不影响现有线程。要影响现有线程，请修改threads表行的INSTRUMENTED和HISTORY列。

setup_actors表具有以下列：

  • 主机

    主机名。这应该是一个字面名称，或者'%'表示“任何主机”。

  • 用户

    用户名。这应该是一个字面名称，或者'%'表示“任何用户”。

  • 角色

    未使用。

  • 启用

    是否为与行匹配的前台线程启用仪表化。该值为YES或NO。

  • HISTORY

    是否记录与行匹配的前台线程的历史事件。该值为YES或NO。

setup_actors表具有以下索引：

  • 主键为(HOST, USER, ROLE)

允许对setup_actors表执行TRUNCATE TABLE语句。它会删除行。

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

29.12.2.2 The setup_consumers Table

setup_consumers 表列出了可以存储事件信息并启用的消费者类型：

mysql> SELECT * FROM performance_schema.setup_consumers;
+----------------------------------+---------+
| NAME                             | ENABLED |
+----------------------------------+---------+
| events_stages_current            | NO      |
| events_stages_history            | NO      |
| events_stages_history_long       | NO      |
| events_statements_current        | YES     |
| events_statements_history        | YES     |
| events_statements_history_long   | NO      |
| events_transactions_current      | YES     |
| events_transactions_history      | YES     |
| events_transactions_history_long | NO      |
| events_waits_current             | NO      |
| events_waits_history             | NO      |
| events_waits_history_long        | NO      |
| global_instrumentation           | YES     |
| thread_instrumentation           | YES     |
| statements_digest                | YES     |
+----------------------------------+---------+

setup_consumers 表中的消费者设置形成了从高级到低级的层次结构。有关启用不同消费者的影响的详细信息，请参见 Section 29.4.7, “Pre-Filtering by Consumer”。

对 setup_consumers 表的修改立即影响监视。

setup_consumers 表具有以下列：

  • NAME

    消费者名称。

  • ENABLED

    指示消费者是否已启用。值为 YES 或 NO。此列可修改。如果禁用消费者，则服务器不会花时间将事件信息添加到其中。

setup_consumers 表具有以下索引：

  • 主键为 (NAME)

不允许对 setup_consumers 表执行 TRUNCATE TABLE。

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

29.12.2.3 setup_instruments 表

setup_instruments 表列出了可以收集事件的被检测对象的类别：

mysql> SELECT * FROM performance_schema.setup_instruments\G
*************************** 1\. row ***************************
         NAME: wait/synch/mutex/pfs/LOCK_pfs_share_list
      ENABLED: NO
        TIMED: NO
   PROPERTIES: singleton
        FLAGS: NULL
   VOLATILITY: 1
DOCUMENTATION: Components can provide their own performance_schema tables. 
This lock protects the list of such tables definitions.
...
*************************** 410\. row ***************************
         NAME: stage/sql/executing
      ENABLED: NO
        TIMED: NO
   PROPERTIES:
        FLAGS: NULL
   VOLATILITY: 0
DOCUMENTATION: NULL
...
*************************** 733\. row ***************************
         NAME: statement/abstract/Query
      ENABLED: YES
        TIMED: YES
   PROPERTIES: mutable
        FLAGS: NULL
   VOLATILITY: 0
DOCUMENTATION: SQL query just received from the network. 
At this point, the real statement type is unknown, the type 
will be refined after SQL parsing.
...
*************************** 737\. row ***************************
         NAME: memory/performance_schema/mutex_instances
      ENABLED: YES
        TIMED: NULL
   PROPERTIES: global_statistics
        FLAGS:
   VOLATILITY: 1
DOCUMENTATION: Memory used for table performance_schema.mutex_instances
...
*************************** 823\. row ***************************
         NAME: memory/sql/Prepared_statement::infrastructure
      ENABLED: YES
        TIMED: NULL
   PROPERTIES: controlled_by_default
        FLAGS: controlled
   VOLATILITY: 0
DOCUMENTATION: Map infrastructure for prepared statements per session.
...

源代码中添加的每个仪器都为 setup_instruments 表提供一行，即使未执行仪器化代码。当启用并执行仪器时，将创建仪器化实例，这些实例在 *xxx*_instances 表中可见，例如 file_instances 或 rwlock_instances。

大多数 setup_instruments 行的修改立即影响监视。对于某些仪器，修改仅在服务器启动时生效；在运行时更改它们没有影响。这主要影响服务器中的互斥体、条件和读写锁，尽管可能还有其他仪器也是如此。

欲了解有关 setup_instruments 表在事件过滤中的作用的更多信息，请参阅 Section 29.4.3, “Event Pre-Filtering”。

setup_instruments 表包含以下列：

  • NAME

    仪器名称。仪器名称可能有多个部分并形成层次结构，如 Section 29.6, “Performance Schema Instrument Naming Conventions” 中所讨论的。从执行仪器产生的事件具有从仪器 NAME 值中获取的 EVENT_NAME 值。（事件实际上没有“名称”，但这提供了一种将事件与仪器关联的方式。）

  • ENABLED

    仪器是否启用。值为 YES 或 NO。禁用的仪器不会产生事件。此列可修改，尽管对于已创建的仪器设置 ENABLED 没有影响。

  • TIMED

    仪器是否计时。值为 YES、NO 或 NULL。此列可修改，尽管对于已创建的仪器设置 TIMED 没有影响。

    TIMED 值为 NULL 表示该仪器不支持计时。例如，内存操作不计时，因此其 TIMED 列为 NULL。

    为支持计时的仪器设置TIMED为NULL没有效果，为不支持计时的仪器设置TIMED为非NULL也没有效果。

    如果启用的仪器没有计时，那么仪器代码是启用的，但计时器不是。由仪器产生的事件的TIMER_START、TIMER_END和TIMER_WAIT计时器值为NULL。这反过来导致在汇总表中计算总和、最小值、最大值和平均时间值时忽略这些值。

  • PROPERTIES

    仪器属性。此列使用SET数据类型，因此每个仪器可以设置以下列表中的多个标志：

    • controlled_by_default: 默认情况下为该仪器收集内存。

    • global_statistics: 该仪器仅生成全局摘要。较细级别的摘要不可用，例如每个线程、账户、用户或主机。例如，大多数内存仪器仅生成全局摘要。

    • mutable: 该仪器可以“变异”为更具体的仪器。此属性仅适用于语句仪器。

    • progress: 该仪器能够报告进度数据。此属性仅适用于阶段仪器。

    • singleton: 该仪器具有单个实例。例如，服务器中的大多数全局互斥锁都是单例的，因此相应的仪器也是如此。

    • user: 该仪器与用户工作量直接相关（与系统工作量相反）。其中一个这样的仪器是wait/io/socket/sql/client_connection。

  • FLAGS

    仪器的内存是否受控。

    该标志仅支持非全局内存仪器，并且可以设置或取消设置。例如：

     SQL> UPDATE PERFORMANCE_SCHEMA.SETUP_INTRUMENTS SET FLAGS="controlled" WHERE NAME='memory/sql/NET::buff';

    注意

    尝试在非内存仪器或全局内存仪器上设置FLAGS = controlled会静默失败。

  • VOLATILITY

    仪器的不稳定性。不稳定性值从低到高。这些值对应于mysql/psi/psi_base.h头文件中定义的PSI_VOLATILITY_*xxx*常量：

    #define PSI_VOLATILITY_UNKNOWN 0
#define PSI_VOLATILITY_PERMANENT 1
#define PSI_VOLATILITY_PROVISIONING 2
#define PSI_VOLATILITY_DDL 3
#define PSI_VOLATILITY_CACHE 4
#define PSI_VOLATILITY_SESSION 5
#define PSI_VOLATILITY_TRANSACTION 6
#define PSI_VOLATILITY_QUERY 7
#define PSI_VOLATILITY_INTRA_QUERY 8

    VOLATILITY列纯粹是信息性的，为用户（以及性能模式代码）提供有关仪器运行时行为的一些提示。

    具有低不稳定性指数（PERMANENT = 1）的仪器在服务器启动时创建一次，并且在正常服务器操作期间永远不会被销毁或重新创建。它们仅在服务器关闭时被销毁。

    例如，wait/synch/mutex/pfs/LOCK_pfs_share_list互斥锁被定义为具有不变性为 1，这意味着它只创建一次。仪器本身可能产生的开销（即互斥锁初始化）对于这个仪器没有影响。运行时开销仅在锁定或解锁互斥锁时发生。

    具有较高不稳定性指数（例如，SESSION = 5）的仪器为每个用户会话创建和销毁。例如，wait/synch/mutex/sql/THD::LOCK_query_plan互斥锁在每次会话连接时创建，并在会话断开时销毁。

    这个互斥体对性能模式的开销更为敏感，因为开销不仅来自于锁定和解锁的仪器化，还来自于更频繁执行的互斥体创建和销毁的仪器化。

    另一个不稳定性的方面涉及ENABLED列的更新实际上是否产生某种效果：

    • 对ENABLED的更新会影响随后创建的被仪器化对象，但不会影响已经创建的仪器。

    • 更“不稳定”的仪器会更快地使用setup_instruments表中的新设置。

    例如，此语句不会影响现有会话的LOCK_query_plan互斥体，但会影响在更新后创建的新会话：

    UPDATE performance_schema.setup_instruments
SET ENABLED=*value*
WHERE NAME = 'wait/synch/mutex/sql/THD::LOCK_query_plan';

    这个语句实际上根本没有任何效果：

    UPDATE performance_schema.setup_instruments
SET ENABLED=*value*
WHERE NAME = 'wait/synch/mutex/pfs/LOCK_pfs_share_list';

    这个互斥体是永久的，在更新执行之前已经创建。互斥体永远不会再次创建，因此setup_instruments中的ENABLED值永远不会被使用。要启用或禁用此互斥体，请改用mutex_instances表。

  • DOCUMENTATION

    描述仪器目的的字符串。如果没有可用的描述，则值为NULL。

setup_instruments表具有以下索引：

  • 主键为(NAME)

不允许对setup_instruments表进行TRUNCATE TABLE。

截至 MySQL 8.0.27，为了辅助监控和故障排除，性能模式仪器化用于将被仪器化线程的名称导出到操作系统。这使得能够显示线程名称的实用程序（如调试器和 Unix ps命令）能够显示不同的mysqld线程名称，而不是“mysqld”。此功能仅在 Linux、macOS 和 Windows 上受支持。

假设mysqld正在运行在一个支持此调用语法的ps版本的系统上：

ps -C mysqld H -o "pid tid cmd comm"

在不将线程名称导出到操作系统的情况下，该命令显示类似于这样的输出，其中大多数COMMAND值为mysqld：

 PID   TID CMD                         COMMAND
 1377  1377 /usr/sbin/mysqld            mysqld
 1377  1528 /usr/sbin/mysqld            mysqld
 1377  1529 /usr/sbin/mysqld            mysqld
 1377  1530 /usr/sbin/mysqld            mysqld
 1377  1531 /usr/sbin/mysqld            mysqld
 1377  1534 /usr/sbin/mysqld            mysqld
 1377  1535 /usr/sbin/mysqld            mysqld
 1377  1588 /usr/sbin/mysqld            xpl_worker1
 1377  1589 /usr/sbin/mysqld            xpl_worker0
 1377  1590 /usr/sbin/mysqld            mysqld
 1377  1594 /usr/sbin/mysqld            mysqld
 1377  1595 /usr/sbin/mysqld            mysqld

将线程名称导出到操作系统后，输出看起来像这样，线程的名称类似于它们的仪器名称：

 PID   TID CMD                         COMMAND
27668 27668 /usr/sbin/mysqld            mysqld
27668 27671 /usr/sbin/mysqld            ib_io_ibuf
27668 27672 /usr/sbin/mysqld            ib_io_log
27668 27673 /usr/sbin/mysqld            ib_io_rd-1
27668 27674 /usr/sbin/mysqld            ib_io_rd-2
27668 27677 /usr/sbin/mysqld            ib_io_wr-1
27668 27678 /usr/sbin/mysqld            ib_io_wr-2
27668 27699 /usr/sbin/mysqld            xpl_worker-2
27668 27700 /usr/sbin/mysqld            xpl_accept-1
27668 27710 /usr/sbin/mysqld            evt_sched
27668 27711 /usr/sbin/mysqld            sig_handler
27668 27933 /usr/sbin/mysqld            connection

同一类中的不同线程实例被编号以提供可行的不同名称。由于名称长度受到可能大量连接的限制，连接被简单命名为connection。

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

29.12.2.4 setup_objects表

setup_objects表控制着性能模式监视特定对象的行为。默认情况下，该表的最大大小为 100 行。要更改表的大小，请在服务器启动时修改performance_schema_setup_objects_size系统变量。

初始的setup_objects内容如下：

mysql> SELECT * FROM performance_schema.setup_objects;
+-------------+--------------------+-------------+---------+-------+
| OBJECT_TYPE | OBJECT_SCHEMA      | OBJECT_NAME | ENABLED | TIMED |
+-------------+--------------------+-------------+---------+-------+
| EVENT       | mysql              | %           | NO      | NO    |
| EVENT       | performance_schema | %           | NO      | NO    |
| EVENT       | information_schema | %           | NO      | NO    |
| EVENT       | %                  | %           | YES     | YES   |
| FUNCTION    | mysql              | %           | NO      | NO    |
| FUNCTION    | performance_schema | %           | NO      | NO    |
| FUNCTION    | information_schema | %           | NO      | NO    |
| FUNCTION    | %                  | %           | YES     | YES   |
| PROCEDURE   | mysql              | %           | NO      | NO    |
| PROCEDURE   | performance_schema | %           | NO      | NO    |
| PROCEDURE   | information_schema | %           | NO      | NO    |
| PROCEDURE   | %                  | %           | YES     | YES   |
| TABLE       | mysql              | %           | NO      | NO    |
| TABLE       | performance_schema | %           | NO      | NO    |
| TABLE       | information_schema | %           | NO      | NO    |
| TABLE       | %                  | %           | YES     | YES   |
| TRIGGER     | mysql              | %           | NO      | NO    |
| TRIGGER     | performance_schema | %           | NO      | NO    |
| TRIGGER     | information_schema | %           | NO      | NO    |
| TRIGGER     | %                  | %           | YES     | YES   |
+-------------+--------------------+-------------+---------+-------+

对setup_objects表的修改会立即影响对象监视。

对于setup_objects中列出的对象类型，性能模式使用该表来监视它们。对象匹配基于OBJECT_SCHEMA和OBJECT_NAME列。没有匹配的对象不会被监视。

默认对象配置的效果是对除了mysql、INFORMATION_SCHEMA和performance_schema数据库之外的所有表进行仪器化。（无论setup_objects的内容如何，INFORMATION_SCHEMA数据库中的表都不会被仪器化；information_schema.%的行只是明确了这一默认设置。）

当性能模式在setup_objects中查找匹配时，它首先尝试找到更具体的匹配。例如，对于表db1.t1，它会先查找'db1'和't1'的匹配，然后是'db1'和'%'，最后是'%'和'%'。匹配发生的顺序很重要，因为不同的匹配setup_objects行可能具有不同的ENABLED和TIMED值。

用户具有对表的INSERT或DELETE权限可以向setup_objects中插入或删除行。对于现有行，只有具有对表的UPDATE权限的用户可以修改ENABLED和TIMED列。

有关setup_objects表在事件过滤中的作用的更多信息，请参见 Section 29.4.3, “Event Pre-Filtering”。

setup_objects表具有以下列：

  • OBJECT_TYPE

    要检测的对象类型。值为'EVENT'（事件调度器事件）、'FUNCTION'（存储函数）、'PROCEDURE'（存储过程）、'TABLE'（基本表）或'TRIGGER'（触发器）。

    TABLE过滤影响表 I/O 事件（wait/io/table/sql/handler工具）和表锁事件（wait/lock/table/sql/handler工具）。

  • OBJECT_SCHEMA

    包含对象的模式。这应该是一个字面名称，或者'%'表示“任何模式”。

  • OBJECT_NAME

    被检测对象的名称。这应该是一个字面名称，或者'%'表示“任何对象”。

  • ENABLED

    对象的事件是否被检测。值为YES或NO。此列可以修改。

  • TIMED

    对象的事件是否被计时。此列可以修改。

setup_objects表具有以下索引：

  • 在(OBJECT_TYPE, OBJECT_SCHEMA, OBJECT_NAME)上的索引。

允许对setup_objects表进行TRUNCATE TABLE。它会删除行。

dev.mysql.com/doc/refman/8.0/en/performance-schema-setup-threads-table.html

29.12.2.5 The setup_threads Table

setup_threads 表列出了被检测的线程类。它公开了线程类的名称和属性：

mysql> SELECT * FROM performance_schema.setup_threads\G
*************************** 1\. row ***************************
         NAME: thread/performance_schema/setup
      ENABLED: YES
      HISTORY: YES
   PROPERTIES: singleton
   VOLATILITY: 0
DOCUMENTATION: NULL
...
*************************** 4\. row ***************************
         NAME: thread/sql/main
      ENABLED: YES
      HISTORY: YES
   PROPERTIES: singleton
   VOLATILITY: 0
DOCUMENTATION: NULL
*************************** 5\. row ***************************
         NAME: thread/sql/one_connection
      ENABLED: YES
      HISTORY: YES
   PROPERTIES: user
   VOLATILITY: 0
DOCUMENTATION: NULL
...
*************************** 10\. row ***************************
         NAME: thread/sql/event_scheduler
      ENABLED: YES
      HISTORY: YES
   PROPERTIES: singleton
   VOLATILITY: 0
DOCUMENTATION: NULL

setup_threads 表具有以下列：

  • NAME

    仪器名称。线程仪器以thread开头（例如，thread/sql/parser_service或thread/performance_schema/setup）。

  • ENABLED

    仪器是否启用。值为YES或NO。此列可以修改，尽管对于已经运行的线程设置ENABLED没有效果。

    对于后台线程，设置ENABLED值控制随后为此仪器创建的线程是否在threads 表中列出时将INSTRUMENTED设置为YES或NO。对于前台线程，此列没有效果；setup_actors 表优先。

  • HISTORY

    是否记录仪器的历史事件。值为YES或NO。此列可以修改，尽管对于已经运行的线程设置HISTORY没有效果。

    对于后台线程，设置HISTORY值控制随后为此仪器创建的线程是否在threads 表中列出时将HISTORY设置为YES或NO。对于前台线程，此列没有效果；setup_actors 表优先。

  • PROPERTIES

    仪器属性。此列使用SET数据类型，因此可以为每个仪器设置以下列表中的多个标志：

    • singleton：该仪器具有单个实例。例如，thread/sql/main仪器只有一个线程。

    • user：该仪器与用户工作负载直接相关（而不是系统工作负载）。例如，执行用户会话的线程（如thread/sql/one_connection）具有user属性，以区分它们与系统线程。

  • VOLATILITY

    仪器的波动性。此列与setup_instruments 表中的含义相同。请参阅 Section 29.12.2.3, “The setup_instruments Table”。

  • DOCUMENTATION

    描述仪器目的的字符串。如果没有可用的描述，则值为NULL。

setup_threads表具有以下索引：

  • 主键为(NAME)

不允许对setup_threads表执行TRUNCATE TABLE操作。

29.12.3 性能模式实例表

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

29.12.3.1 条件实例表

29.12.3.2 文件实例表

29.12.3.3 互斥实例表

29.12.3.4 读写锁实例表

29.12.3.5 套接字实例表

实例表记录了被检测的对象类型。它们提供事件名称和解释说明或状态信息：

  • cond_instances：条件同步对象实例

  • file_instances：文件实例

  • mutex_instances：互斥同步对象实例

  • rwlock_instances：锁同步对象实例

  • socket_instances：活动连接实例

这些表列出了被检测的同步对象、文件和连接。同步对象有三种类型：cond、mutex 和 rwlock。每个实例表都有一个 EVENT_NAME 或 NAME 列，用于指示与每行关联的仪器。仪器名称可能有多个部分，并形成一个层次结构，如 第 29.6 节，“性能模式仪器命名约定” 中所讨论的。

mutex_instances.LOCKED_BY_THREAD_ID 和 rwlock_instances.WRITE_LOCKED_BY_THREAD_ID 列对于调查性能瓶颈或死锁非常重要。有关如何使用它们进行此目的的示例，请参见 第 29.19 节，“使用性能模式诊断问题”

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

29.12.3.1 cond_instances 表

cond_instances 表列出了服务器执行时性能模式看到的所有条件。条件是代码中使用的同步机制，用于发出特定事件已发生的信号，以便等待此条件的线程可以恢复工作。

当一个线程在等待某些事件发生时，条件名称表明了线程在等待什么，但没有直接的方法可以告诉是哪个其他线程或哪些线程导致了条件的发生。

cond_instances 表具有以下列：

  • NAME

    与条件相关联的工具名称。

  • OBJECT_INSTANCE_BEGIN

    工具化条件在内存中的地址。

cond_instances 表具有以下索引：

  • 在 (OBJECT_INSTANCE_BEGIN) 上的主键

  • 在 (NAME) 上的索引

TRUNCATE TABLE 不允许用于 cond_instances 表。

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

29.12.3.2 文件实例表

当执行文件 I/O 仪表化时，file_instances 表列出了性能模式看到的所有文件。如果磁盘上的文件从未被打开过，则不会显示在 file_instances 表中。当从磁盘中删除文件时，它也会从 file_instances 表中删除。

file_instances 表包含以下列：

  • FILE_NAME

    文件名。

  • EVENT_NAME

    与文件关联的仪器名称。

  • OPEN_COUNT

    文件上的打开句柄计数。如果文件被打开然后关闭，它被打开了 1 次，但 OPEN_COUNT 是 0。要列出服务器当前打开的所有文件，请使用 WHERE OPEN_COUNT > 0。

file_instances 表包含以下索引：

  • 主键 (FILE_NAME)

  • (EVENT_NAME) 上的索引

TRUNCATE TABLE 不允许用于 file_instances 表。

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

29.12.3.3 mutex_instances 表

mutex_instances 表列出了服务器执行时性能模式看到的所有互斥锁。互斥锁是代码中用于强制只有一个线程可以访问某些共享资源的同步机制。该资源被互斥锁“保护”。

当两个在服务器中执行的线程（例如，两个用户会话同时执行查询）需要访问相同的资源（文件、缓冲区或某些数据），这两个线程相互竞争，因此第一个查询获得互斥锁的线程会导致另一个查询等待，直到第一个完成并解锁互斥锁。

在持有互斥锁时执行的工作被称为“临界区”，多个查询以串行方式（一次一个）执行此临界区，这可能是一个潜在的瓶颈。

mutex_instances 表具有以下列：

  • NAME

    与互斥锁关联的仪器名称。

  • OBJECT_INSTANCE_BEGIN

    仪器化互斥锁在内存中的地址。

  • LOCKED_BY_THREAD_ID

    当一个线程当前持有一个互斥锁时，LOCKED_BY_THREAD_ID 是锁定线程的 THREAD_ID，否则为 NULL。

mutex_instances 表具有以下索引：

  • 主键为 (OBJECT_INSTANCE_BEGIN)

  • 索引为 (NAME)

  • 索引为 (LOCKED_BY_THREAD_ID)

TRUNCATE TABLE 不允许用于 mutex_instances 表。

对于代码中仪器化的每个互斥锁，性能模式提供以下信息。

  • setup_instruments 表列出了仪器点的名称，带有前缀 wait/synch/mutex/。

  • 当一些代码创建一个互斥锁时，会向 mutex_instances 表添加一行。OBJECT_INSTANCE_BEGIN 列是一个唯一标识互斥锁的属性。

  • 当一个线程尝试锁定一个互斥锁时，events_waits_current 表显示了一个针对该线程的行，指示它正在等待一个互斥锁（在 EVENT_NAME 列中），并指示正在等待的互斥锁是哪个（在 OBJECT_INSTANCE_BEGIN 列中）。

  • 当一个线程成功锁定一个互斥锁时：

    • events_waits_current显示互斥锁上的等待已完成（在TIMER_END和TIMER_WAIT列中）

    • 完成的等待事件被添加到events_waits_history和events_waits_history_long表中

    • mutex_instances显示该互斥锁现在由该线程拥有（在THREAD_ID列中）。

  • 当线程解锁互斥锁时，mutex_instances显示该互斥锁现在没有所有者（THREAD_ID列为NULL）。

  • 当互斥锁对象被销毁时，相应的行从mutex_instances中移除。

通过对上述两个表执行查询，监控应用程序或数据库管理员可以检测涉及互斥锁的线程之间的瓶颈或死锁：

  • events_waits_current，查看线程正在等待哪个互斥锁

  • mutex_instances，查看哪个其他线程当前拥有互斥锁

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

29.12.3.4 rwlock_instances表

rwlock_instances表列出了在服务器执行时性能模式看到的所有 rwlock（读写锁）实例。rwlock是代码中使用的同步机制，用于强制在给定时间内的线程可以按照某些规则访问一些共享资源。资源被称为由rwlock“保护”。访问可以是共享的（许多线程可以同时拥有读锁），独占的（一次只有一个线程可以拥有写锁），或共享-独占的（一个线程可以拥有写锁，同时允许其他线程进行不一致的读取）。共享-独占访问又称为sxlock，可优化并发性并改善读写工作负载的可伸缩性。

根据请求锁的线程数量以及请求的锁的性质，访问可以以共享模式、独占模式、共享-独占模式或根本不授予访问，等待其他线程先完成。

rwlock_instances表具有以下列：

  • NAME

    与锁相关联的工具名称。

  • OBJECT_INSTANCE_BEGIN

    工具锁在内存中的地址。

  • WRITE_LOCKED_BY_THREAD_ID

    当一个线程当前以独占（写）模式锁定一个rwlock时，WRITE_LOCKED_BY_THREAD_ID是锁定线程的THREAD_ID，否则为NULL。

  • READ_LOCKED_BY_COUNT

    当一个线程当前以共享（读）模式锁定一个rwlock时，READ_LOCKED_BY_COUNT会增加 1。这只是一个计数器，因此不能直接用来找出哪个线程持有读锁，但可以用来查看rwlock上是否存在读争用，以及当前有多少读者活跃。

rwlock_instances表具有以下索引：

  • 主键为(OBJECT_INSTANCE_BEGIN)

  • 索引为(NAME)

  • 索引为(WRITE_LOCKED_BY_THREAD_ID)

TRUNCATE TABLE不允许用于rwlock_instances表。

通过对以下两个表执行查询，监控应用程序或 DBA 可以检测到涉及锁的线程之间的一些瓶颈或死锁：

  • events_waits_current，查看线程正在等待哪个rwlock

  • rwlock_instances，查看当前拥有rwlock的其他线程。

存在一个限制：rwlock_instances 只能用于识别持有写锁的线程，而不能识别持有读锁的线程。

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

29.12.3.5 The socket_instances Table

socket_instances表提供了 MySQL 服务器的活动连接的实时快照。该表每个 TCP/IP 或 Unix 套接字文件连接包含一行。此表中可用的信息提供了服务器的活动连接的实时快照。（有关套接字摘要表的其他信息，请参见第 29.12.20.9 节“套接字摘要表”）。

mysql> SELECT * FROM performance_schema.socket_instances\G
*************************** 1\. row ***************************
           EVENT_NAME: wait/io/socket/sql/server_unix_socket
OBJECT_INSTANCE_BEGIN: 4316619408
            THREAD_ID: 1
            SOCKET_ID: 16
                   IP:
                 PORT: 0
                STATE: ACTIVE
*************************** 2\. row ***************************
           EVENT_NAME: wait/io/socket/sql/client_connection
OBJECT_INSTANCE_BEGIN: 4316644608
            THREAD_ID: 21
            SOCKET_ID: 39
                   IP: 127.0.0.1
                 PORT: 55233
                STATE: ACTIVE
*************************** 3\. row ***************************
           EVENT_NAME: wait/io/socket/sql/server_tcpip_socket
OBJECT_INSTANCE_BEGIN: 4316699040
            THREAD_ID: 1
            SOCKET_ID: 14
                   IP: 0.0.0.0
                 PORT: 50603
                STATE: ACTIVE

Socket 工具的名称形式为wait/io/socket/sql/*socket_type*，使用方式如下：

  1. 服务器为其支持的每种网络协议都有一个监听套接字。与 TCP/IP 或 Unix 套接字文件连接的监听套接字相关联的工具具有server_tcpip_socket或server_unix_socket的*socket_type*值。

  2. 当监听套接字检测到连接时，服务器将连接转移到由单独线程管理的新套接字。新连接线程的工具具有client_connection的*socket_type*值。

  3. 当连接终止时，对应的socket_instances表中的行将被删除。

socket_instances表具有以下列：

  • EVENT_NAME

    产生事件的wait/io/socket/*工具的名称。这是setup_instruments表中的一个NAME值。工具名称可能由多个部分组成，形成一个层次结构，如第 29.6 节“性能模式工具命名约定”中所讨论的那样。

  • OBJECT_INSTANCE_BEGIN

    此列唯一标识套接字。该值是内存中对象的地址。

  • THREAD_ID

    服务器分配的内部线程标识符。每个套接字由单个线程管理，因此每个套接字可以映射到一个线程，该线程可以映射到一个服务器进程。

  • SOCKET_ID

    分配给套接字的内部文件句柄。

  • IP

    客户端 IP 地址。该值可以是 IPv4 或 IPv6 地址，或者为空以指示 Unix 套接字文件连接。

  • PORT

    TCP/IP 端口号，范围从 0 到 65535。

  • STATE

    套接字状态，要么是 IDLE，要么是 ACTIVE。活动套接字的等待时间使用相应的套接字工具进行跟踪。空闲套接字的等待时间使用 idle 工具进行跟踪。

    如果套接字正在等待来自客户端的请求，则套接字处于空闲状态。当套接字变为空闲时，跟踪套接字的 socket_instances 表中的事件行从 ACTIVE 状态切换到 IDLE。EVENT_NAME 值仍为 wait/io/socket/*，但工具的计时被暂停。相反，在 events_waits_current 表中生成一个 EVENT_NAME 值为 idle 的事件。

    当接收到下一个请求时，idle 事件终止，套接字实例从 IDLE 切换到 ACTIVE，套接字工具的计时恢复。

socket_instances 表具有以下索引：

  • 在 (OBJECT_INSTANCE_BEGIN) 上建立主键

  • 在 (THREAD_ID) 上建立索引

  • 在 (SOCKET_ID) 上建立索引

  • 在 (IP, PORT) 上建立索引

不允许对 socket_instances 表使用 TRUNCATE TABLE。

IP:PORT 列组合值标识连接。此组合值在 events_waits_*xxx* 表的 OBJECT_NAME 列中使用，用于标识套接字事件的连接来源：

  • 对于 Unix 域监听器套接字 (server_unix_socket)，端口为 0，IP 为 ''。

  • 对通过 Unix 域监听器 (client_connection) 的客户端连接，端口为 0，IP 为 ''。

  • 对于 TCP/IP 服务器监听器套接字 (server_tcpip_socket)，端口始终是主端口（例如，3306），IP 始终是 0.0.0.0。

  • 对通过 TCP/IP 监听器 (client_connection) 的客户端连接，端口是服务器分配的任何端口，但绝不是 0。IP 是发起主机的 IP (127.0.0.1 或 ::1 为本地主机)

29.12.4 性能模式等待事件表

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

29.12.4.1 events_waits_current 表

29.12.4.2 events_waits_history 表

29.12.4.3 events_waits_history_long 表

性能模式工具记录等待事件，这些事件需要时间。在事件层次结构中，等待事件嵌套在阶段事件中，阶段事件嵌套在语句事件中，语句事件嵌套在事务事件中。

这些表存储等待事件：

  • events_waits_current：每个线程的当前等待事件。

  • events_waits_history：每个线程最近结束的等待事件。

  • events_waits_history_long：全局最近结束的等待事件（跨所有线程）。

以下各节描述了等待事件表。还有汇总信息关于等待事件的摘要表；请参阅第 29.12.20.1 节，“等待事件摘要表”。

有关三个等待事件表之间关系的更多信息，请参阅第 29.9 节，“当前和历史事件的性能模式表”。

配置等待事件收集

要控制是否收集等待事件，请设置相关工具和消费者的状态：

  • setup_instruments表包含以wait开头的工具名称。使用这些工具来启用或禁用单个等待事件类的收集。

  • setup_consumers表包含与当前和历史等待事件表名称对应的消费者值。使用这些消费者来过滤等待事件的收集。

一些等待工具默认启用；其他则禁用。例如：

mysql> SELECT NAME, ENABLED, TIMED
       FROM performance_schema.setup_instruments
       WHERE NAME LIKE 'wait/io/file/innodb%';
+-------------------------------------------------+---------+-------+
| NAME                                            | ENABLED | TIMED |
+-------------------------------------------------+---------+-------+
| wait/io/file/innodb/innodb_tablespace_open_file | YES     | YES   |
| wait/io/file/innodb/innodb_data_file            | YES     | YES   |
| wait/io/file/innodb/innodb_log_file             | YES     | YES   |
| wait/io/file/innodb/innodb_temp_file            | YES     | YES   |
| wait/io/file/innodb/innodb_arch_file            | YES     | YES   |
| wait/io/file/innodb/innodb_clone_file           | YES     | YES   |
+-------------------------------------------------+---------+-------+
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    |
+----------------------------------------+---------+-------+

等待消费者默认情况下处于禁用状态：

mysql> SELECT *
       FROM performance_schema.setup_consumers
       WHERE NAME LIKE 'events_waits%';
+---------------------------+---------+
| NAME                      | ENABLED |
+---------------------------+---------+
| events_waits_current      | NO      |
| events_waits_history      | NO      |
| events_waits_history_long | NO      |
+---------------------------+---------+

要在服务器启动时控制等待事件的收集，请在您的my.cnf文件中使用以下行：

  • 启用：

    [mysqld]
performance-schema-instrument='wait/%=ON'
performance-schema-consumer-events-waits-current=ON
performance-schema-consumer-events-waits-history=ON
performance-schema-consumer-events-waits-history-long=ON

  • 禁用：

    [mysqld]
performance-schema-instrument='wait/%=OFF'
performance-schema-consumer-events-waits-current=OFF
performance-schema-consumer-events-waits-history=OFF
performance-schema-consumer-events-waits-history-long=OFF

要在运行时控制等待事件收集，请更新setup_instruments和setup_consumers表：

  • 启用：

    UPDATE performance_schema.setup_instruments
SET ENABLED = 'YES', TIMED = 'YES'
WHERE NAME LIKE 'wait/%';

UPDATE performance_schema.setup_consumers
SET ENABLED = 'YES'
WHERE NAME LIKE 'events_waits%';

  • 禁用：

    UPDATE performance_schema.setup_instruments
SET ENABLED = 'NO', TIMED = 'NO'
WHERE NAME LIKE 'wait/%';

UPDATE performance_schema.setup_consumers
SET ENABLED = 'NO'
WHERE NAME LIKE 'events_waits%';

要仅收集特定的等待事件，请仅启用相应的等待工具。要仅为特定的等待事件表收集等待事件，请启用等待工具，但仅启用与所需表对应的等待消费者。

有关配置事件收集的更多信息，请参阅第 29.3 节，“性能模式启动配置”和第 29.4 节，“性能模式运行时配置”。

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

29.12.4.1 events_waits_current 表

events_waits_current 表包含当前的等待事件。该表为每个线程存储一行，显示线程最近监视等待事件的当前状态，因此没有用于配置表大小的系统变量。

在包含等待事件行的表中，events_waits_current 是最基本的。其他包含等待事件行的表从当前事件中逻辑派生。例如，events_waits_history 和 events_waits_history_long 表是最近已结束的等待事件的集合，每个线程和全局跨所有线程的最大行数。

有关三个等待事件表之间关系的更多信息，请参见 Section 29.9, “Performance Schema Tables for Current and Historical Events”。

有关配置是否收集等待事件的信息，请参见 Section 29.12.4, “Performance Schema Wait Event Tables”。

events_waits_current 表具有以下列：

  • THREAD_ID, EVENT_ID

    与事件相关联的线程以及事件开始时的线程当前事件编号。THREAD_ID 和 EVENT_ID 值一起唯一标识行。没有两行具有相同的值对。

  • END_EVENT_ID

    当事件开始时，此列设置为 NULL，并在事件结束时更新为线程当前事件编号。

  • EVENT_NAME

    产生事件的工具的名称。这是来自 setup_instruments 表的 NAME 值。工具名称可能有多个部分并形成层次结构，如 Section 29.6, “Performance Schema Instrument Naming Conventions” 中所讨论的。

  • SOURCE

    包含产生事件的有仪器代码的源文件的名称和仪器发生的文件中的行号。这使您可以检查源代码以确定涉及的确切代码。例如，如果互斥锁或锁被阻塞，您可以检查发生这种情况的上下文。

  • TIMER_START，TIMER_END，TIMER_WAIT

    事件的时间信息。这些值的单位是皮秒（万亿分之一秒）。TIMER_START和TIMER_END值表示事件计时开始和结束的时间。TIMER_WAIT是事件经过的时间（持续时间）。

    如果事件尚未完成，TIMER_END是当前计时器值，TIMER_WAIT是到目前为止经过的时间（TIMER_END − TIMER_START）。

    如果事件来自具有TIMED = NO的工具，将不会收集时间信息，TIMER_START，TIMER_END和TIMER_WAIT都为NULL。

    有关以皮秒为事件时间单位和影响时间值的因素的讨论，请参阅 Section 29.4.1, “Performance Schema Event Timing”。

  • SPINS

    对于互斥锁，自旋轮数。如果值为NULL，则代码不使用自旋轮数或自旋未被记录。

  • OBJECT_SCHEMA，OBJECT_NAME，OBJECT_TYPE，OBJECT_INSTANCE_BEGIN

    这些列标识了“被操作的”对象。具体含义取决于对象类型。

    对于一个同步对象（cond，mutex，rwlock）：

    • OBJECT_SCHEMA，OBJECT_NAME和OBJECT_TYPE为NULL。

    • OBJECT_INSTANCE_BEGIN是内存中同步对象的地址。

    对于文件 I/O 对象：

    • OBJECT_SCHEMA为NULL。

    • OBJECT_NAME是文件名。

    • OBJECT_TYPE为FILE。

    • OBJECT_INSTANCE_BEGIN是内存中的地址。

    对于套接字对象：

    • OBJECT_NAME是套接字的IP:PORT值。

    • OBJECT_INSTANCE_BEGIN是内存中的地址。

    对于表 I/O 对象：

    • OBJECT_SCHEMA是包含表的模式的名称。

    • OBJECT_NAME是表名。

    • 对于持久基表的OBJECT_TYPE为TABLE或临时表的OBJECT_TYPE为TEMPORARY TABLE。

    • OBJECT_INSTANCE_BEGIN是内存中的地址。

    OBJECT_INSTANCE_BEGIN值本身没有意义，除非不同的值表示不同的对象。OBJECT_INSTANCE_BEGIN可用于调试。例如，可以与GROUP BY OBJECT_INSTANCE_BEGIN一起使用，以查看对 1,000 个互斥锁（保护 1,000 个页面或数据块）的负载是否均匀分布或只是击中了一些瓶颈。如果在日志文件或其他调试或性能工具中看到相同的对象地址，这可以帮助您与其他信息源进行关联。

  • INDEX_NAME

    使用的索引名称。PRIMARY表示表的主索引。NULL表示未使用索引。

  • NESTING_EVENT_ID

    此事件嵌套在其中的事件的EVENT_ID值。

  • NESTING_EVENT_TYPE

    嵌套事件类型。值为TRANSACTION，STATEMENT，STAGE或WAIT。

  • OPERATION

    执行的操作类型，例如lock，read或write。

  • NUMBER_OF_BYTES

    操作读取或写入的字节数。对于表 I/O 等待（wait/io/table/sql/handler工具的事件），NUMBER_OF_BYTES表示行数。如果值大于 1，则该事件是批量 I/O 操作。以下讨论描述了独占单行报告和反映批量 I/O 的报告之间的区别。

    MySQL 使用嵌套循环实现连接。性能模式仪表化的工作是为连接中的每个表提供行数和累积执行时间。假设执行以下形式的连接查询，使用表连接顺序为t1，t2，t3：

    SELECT ... FROM t1 JOIN t2 ON ... JOIN t3 ON ...

    表“扇出”是在连接处理过程中添加表后行数增加或减少的情况。如果表t3的扇出大于 1，则大部分行提取操作是针对该表的。假设连接从t1提取 10 行，从t2每行t1提取 20 行，从t3每行t2提取 30 行。使用单行报告，总仪表化操作数为：

    10 + (10 * 20) + (10 * 20 * 30) = 6210

    通过按扫描（即从t1和t2的唯一组合）对其进行聚合，可以显著减少仪表化操作的数量。使用批量 I/O 报告，性能模式为内部表t3的每次扫描产生一个事件，而不是每行，仪表化行操作数量减少为：

    10 + (10 * 20) + (10 * 20) = 410

    这是 93%的减少，说明批量报告策略通过减少报告调用的数量显著减少了表 I/O 的性能模式开销。权衡是事件定时的准确性较低。与每行报告中的单行操作的时间不同，批量 I/O 的时间包括用于操作的时间，例如连接缓冲，聚合和将行返回给客户端的时间。

    要发生批量 I/O 报告，必须满足以下条件：

    • 查询执行访问查询块的最内部表（对于单表查询，该表计为最内部）

    • 查询执行不会从表中请求单行（因此，例如，eq_ref访问会阻止批量报告的使用）

    • 查询执行不会评估包含表访问的子查询的表

  • FLAGS

    保留供将来使用。

events_waits_current表具有以下索引：

  • 主键为（THREAD_ID，EVENT_ID）

允许对events_waits_current表进行TRUNCATE TABLE。它会删除行。

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

29.12.4.2 事件等待历史表

events_waits_history表包含每个线程已结束的*N*个最近的等待事件。直到等待事件结束后才将其添加到表中。当表包含给定线程的最大行数时，当为该线程添加新行时，最旧的线程行将被丢弃。当线程结束时，其所有行都将被丢弃。

性能模式在服务器启动期间自动调整*N*的值。要显式设置每个线程的行数，请在服务器启动时设置performance_schema_events_waits_history_size系统变量。

events_waits_history表具有与events_waits_current相同的列和索引。请参阅第 29.12.4.1 节，“事件等待当前表”。

TRUNCATE TABLE允许用于events_waits_history表。它会删除行。

有关三个等待事件表之间关系的更多信息，请参阅第 29.9 节，“当前和历史事件的性能模式表”。

有关配置是否收集等待事件的信息，请参阅第 29.12.4 节，“性能模式等待事件表”。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-events-waits-history-long-table.html

29.12.4.3 events_waits_history_long 表

events_waits_history_long表包含全局结束的*N*最近的等待事件，跨所有线程。等待事件直到结束后才会添加到表中。当表变满时，无论哪个线程生成了新行，最旧的行都会在添加新行时被丢弃。

性能模式在服务器启动期间自动调整*N*的值。要显式设置表大小，请在服务器启动时设置performance_schema_events_waits_history_long_size系统变量。

events_waits_history_long表与events_waits_current表具有相同的列。请参阅第 29.12.4.1 节，“events_waits_current 表”。与events_waits_current不同，events_waits_history_long没有索引。

TRUNCATE TABLE允许用于events_waits_history_long表。它会删除行。

有关三个等待事件表之间关系的更多信息，请参阅第 29.9 节，“当前和历史事件的性能模式表”。

关于配置是否收集等待事件的信息，请参阅第 29.12.4 节，“性能模式等待事件表”。

29.12.5 性能模式阶段事件表

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

29.12.5.1 events_stages_current 表

29.12.5.2 events_stages_history 表

29.12.5.3 events_stages_history_long 表

Performance Schema 仪器阶段，这些是语句执行过程中的步骤，例如解析语句、打开表或执行filesort操作。阶段对应于由 SHOW PROCESSLIST 显示的线程状态，或者在信息模式 PROCESSLIST 表中可见的状态。阶段在状态值更改时开始和结束。

在事件层次结构中，等待事件嵌套在阶段事件中，阶段事件嵌套在语句事件中，语句事件嵌套在事务事件中。

这些表存储阶段事件：

  • events_stages_current：每个线程的当前阶段事件。

  • events_stages_history：每个线程已结束的最近阶段事件。

  • events_stages_history_long：全局已结束的最近阶段事件（跨所有线程）。

以下各节描述了阶段事件表。还有汇总信息的摘要表，汇总了有关阶段事件的信息；请参见 第 29.12.20.2 节，“阶段摘要表”。

有关三个阶段事件表之间关系的更多信息，请参见 第 29.9 节，“当前和历史事件的性能模式表”。

  • 配置阶段事件收集

  • 阶段事件进度信息

配置阶段事件收集

要控制是否收集阶段事件，请设置相关仪器和消费者的状态：

  • setup_instruments 包含以stage开头的仪器。使用这些仪器来启用或禁用单个阶段事件类的收集。

  • setup_consumers表包含与当前和历史阶段事件表名称对应的消费者值。使用这些消费者来过滤阶段事件的收集。

除了提供语句进度信息的仪器外，阶段仪器默认情况下是禁用的。例如：

mysql> SELECT NAME, ENABLED, TIMED
       FROM performance_schema.setup_instruments
       WHERE NAME RLIKE 'stage/sql/[a-c]';
+----------------------------------------------------+---------+-------+
| NAME                                               | ENABLED | TIMED |
+----------------------------------------------------+---------+-------+
| stage/sql/After create                             | NO      | NO    |
| stage/sql/allocating local table                   | NO      | NO    |
| stage/sql/altering table                           | NO      | NO    |
| stage/sql/committing alter table to storage engine | NO      | NO    |
| stage/sql/Changing master                          | NO      | NO    |
| stage/sql/Checking master version                  | NO      | NO    |
| stage/sql/checking permissions                     | NO      | NO    |
| stage/sql/cleaning up                              | NO      | NO    |
| stage/sql/closing tables                           | NO      | NO    |
| stage/sql/Connecting to master                     | NO      | NO    |
| stage/sql/converting HEAP to MyISAM                | NO      | NO    |
| stage/sql/Copying to group table                   | NO      | NO    |
| stage/sql/Copying to tmp table                     | NO      | NO    |
| stage/sql/copy to tmp table                        | NO      | NO    |
| stage/sql/Creating sort index                      | NO      | NO    |
| stage/sql/creating table                           | NO      | NO    |
| stage/sql/Creating tmp table                       | NO      | NO    |
+----------------------------------------------------+---------+-------+

默认情况下启用并计时提供语句进度信息的阶段事件仪器：

mysql> SELECT NAME, ENABLED, TIMED
       FROM performance_schema.setup_instruments
       WHERE ENABLED='YES' AND NAME LIKE "stage/%";
+------------------------------------------------------+---------+-------+
| NAME                                                 | ENABLED | TIMED |
+------------------------------------------------------+---------+-------+
| stage/sql/copy to tmp table                          | YES     | YES   |
| stage/sql/Applying batch of row changes (write)      | YES     | YES   |
| stage/sql/Applying batch of row changes (update)     | YES     | YES   |
| stage/sql/Applying batch of row changes (delete)     | YES     | YES   |
| stage/innodb/alter table (end)                       | YES     | YES   |
| stage/innodb/alter table (flush)                     | YES     | YES   |
| stage/innodb/alter table (insert)                    | YES     | YES   |
| stage/innodb/alter table (log apply index)           | YES     | YES   |
| stage/innodb/alter table (log apply table)           | YES     | YES   |
| stage/innodb/alter table (merge sort)                | YES     | YES   |
| stage/innodb/alter table (read PK and internal sort) | YES     | YES   |
| stage/innodb/buffer pool load                        | YES     | YES   |
| stage/innodb/clone (file copy)                       | YES     | YES   |
| stage/innodb/clone (redo copy)                       | YES     | YES   |
| stage/innodb/clone (page copy)                       | YES     | YES   |
+------------------------------------------------------+---------+-------+

阶段消费者默认情况下是禁用的：

mysql> SELECT *
       FROM performance_schema.setup_consumers
       WHERE NAME LIKE 'events_stages%';
+----------------------------+---------+
| NAME                       | ENABLED |
+----------------------------+---------+
| events_stages_current      | NO      |
| events_stages_history      | NO      |
| events_stages_history_long | NO      |
+----------------------------+---------+

要在服务器启动时控制阶段事件收集，请在您的my.cnf文件中使用以下行：

  • 启用：

    [mysqld]
performance-schema-instrument='stage/%=ON'
performance-schema-consumer-events-stages-current=ON
performance-schema-consumer-events-stages-history=ON
performance-schema-consumer-events-stages-history-long=ON

  • 禁用：

    [mysqld]
performance-schema-instrument='stage/%=OFF'
performance-schema-consumer-events-stages-current=OFF
performance-schema-consumer-events-stages-history=OFF
performance-schema-consumer-events-stages-history-long=OFF

要在运行时控制阶段事件收集，请更新setup_instruments和setup_consumers表：

  • 启用：

    UPDATE performance_schema.setup_instruments
SET ENABLED = 'YES', TIMED = 'YES'
WHERE NAME LIKE 'stage/%';

UPDATE performance_schema.setup_consumers
SET ENABLED = 'YES'
WHERE NAME LIKE 'events_stages%';

  • 禁用：

    UPDATE performance_schema.setup_instruments
SET ENABLED = 'NO', TIMED = 'NO'
WHERE NAME LIKE 'stage/%';

UPDATE performance_schema.setup_consumers
SET ENABLED = 'NO'
WHERE NAME LIKE 'events_stages%';

仅收集特定阶段事件，只需启用相应的阶段仪器。要仅为特定阶段事件表收集阶段事件，请启用阶段仪器，但仅启用与所需表对应的阶段消费者。

有关配置事件收集的其他信息，请参见第 29.3 节，“Performance Schema 启动配置”和第 29.4 节，“Performance Schema 运行时配置”。

阶段事件进度信息

Performance Schema 阶段事件表包含两列，这两列一起为每行提供阶段进度指示器：

  • WORK_COMPLETED：阶段完成的工作单元数量

  • WORK_ESTIMATED：阶段预期的工作单元数量

如果没有为仪器提供进度信息，则每列均为NULL。如果可用，信息的解释完全取决于仪器实现。Performance Schema 表提供了存储进度数据的容器，但不对度量本身的语义做任何假设：

  • “工作单元”是一个整数度量，随着执行时间的增加而增加，例如处理的字节数、行数、文件数或表数。对于特定仪器的“工作单元”的定义由提供数据的仪器代码确定。

  • WORK_COMPLETED值可以根据被仪器化的代码一次或多次增加一个单位。

  • WORK_ESTIMATED值可以在阶段期间更改，具体取决于被仪器化的代码。

用于阶段事件进度指示器的仪器可以实现以下任何行为：

  • 无进度仪器

    这是最典型的情况，即没有提供进度数据。WORK_COMPLETED和WORK_ESTIMATED列都为NULL。

  • 无限进度仪器

    只有WORK_COMPLETED列是有意义的。WORK_ESTIMATED列没有提供任何数据，显示为 0。

    通过查询监视会话的events_stages_current表，监视应用程序可以报告到目前为止完成了多少工作，但无法报告阶段是否接近完成。目前没有类似这样的阶段被仪器化。

  • 有界进度仪器

    WORK_COMPLETED和WORK_ESTIMATED列都是有意义的。

    这种类型的进度指示器适用于具有定义完成标准的操作，例如后面描述的表复制工具。通过查询监视会话的events_stages_current表，监视应用程序可以报告到目前为止完成了多少工作，并且可以通过计算WORK_COMPLETED / WORK_ESTIMATED比率来报告阶段的整体完成百分比。

stage/sql/copy to tmp table工具展示了进度指示器的工作原理。在执行ALTER TABLE语句期间，会使用stage/sql/copy to tmp table阶段，这个阶段的执行时间可能会很长，取决于要复制的数据大小。

表复制任务有一个定义的终止条件（所有行都已复制），stage/sql/copy to tmp table阶段被设计为提供有界的进度信息：使用的工作单元是复制的行数，WORK_COMPLETED和WORK_ESTIMATED都是有意义的，它们的比率表示任务完成的百分比。

要启用该仪器和相关的消费者，请执行以下语句：

UPDATE performance_schema.setup_instruments
SET ENABLED='YES'
WHERE NAME='stage/sql/copy to tmp table';

UPDATE performance_schema.setup_consumers
SET ENABLED='YES'
WHERE NAME LIKE 'events_stages_%';

要查看正在进行的ALTER TABLE语句的进度，请从events_stages_current表中进行选择。

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

29.12.5.1 events_stages_current 表

events_stages_current表包含当前阶段事件。该表为每个线程存储一行，显示线程最近监视的阶段事件的当前状态，因此没有用于配置表大小的系统变量。

包含阶段事件行的表中，events_stages_current是最基本的。其他包含阶段事件行的表是从当前事件逻辑推导出来的。例如，events_stages_history和events_stages_history_long表是最近已结束的阶段事件的集合，每个线程和全局跨所有线程的最大行数。

有关三个阶段事件表之间关系的更多信息，请参见第 29.9 节“当前和历史事件的性能模式表”。

有关配置是否收集阶段事件的信息，请参见第 29.12.5 节“性能模式阶段事件表”。

events_stages_current表具有以下列：

  • THREAD_ID，EVENT_ID

    与事件相关联的线程以及事件开始时的线程当前事件编号。THREAD_ID和EVENT_ID值一起唯一标识行。没有两行具有相同的值对。

  • END_EVENT_ID

    当事件开始时，此列设置为NULL，并在事件结束时更新为线程当前事件编号。

  • EVENT_NAME

    产生事件的仪器名称。这是setup_instruments表中的一个NAME值。仪器名称可能由多个部分组成，形成一个层次结构，如第 29.6 节“性能模式仪器命名约定”所讨论的那样。

  • SOURCE

    包含产生事件的被检测代码的源文件名和文件中发生检测的行号。这使您可以检查源代码以确定涉及的确切代码。

  • TIMER_START、TIMER_END、TIMER_WAIT

    事件的时间信息。这些值的单位为皮秒（万亿分之一秒）。TIMER_START和TIMER_END值表示事件计时开始和结束的时间。TIMER_WAIT是事件经过的时间（持续时间）。

    如果事件尚未完成，TIMER_END是当前计时器值，TIMER_WAIT是到目前为止经过的时间（TIMER_END − TIMER_START）。

    如果事件是由TIMED = NO的工具产生的，则不会收集时间信息，TIMER_START、TIMER_END和TIMER_WAIT都为NULL。

    有关皮秒作为事件时间单位以及影响时间值的因素的讨论，请参阅第 29.4.1 节，“性能模式事件定时”。

  • WORK_COMPLETED、WORK_ESTIMATED

    这些列提供阶段进度信息，用于生成此类信息的工具。WORK_COMPLETED指示已完成的阶段工作单元数，WORK_ESTIMATED指示阶段预期的工作单元数。有关更多信息，请参阅阶段事件进度信息。

  • NESTING_EVENT_ID

    此事件嵌套在其中的事件的EVENT_ID值。阶段事件的嵌套事件通常是语句事件。

  • NESTING_EVENT_TYPE

    嵌套事件类型。其值为TRANSACTION、STATEMENT、STAGE或WAIT。

events_stages_current表具有以下索引：

  • 主键为(THREAD_ID, EVENT_ID)

TRUNCATE TABLE允许用于events_stages_current表。它会删除行。

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

29.12.5.2 events_stages_history 表

events_stages_history 表包含每个线程中最近结束的 N 个阶段事件。阶段事件直到结束后才会添加到表中。当表中包含给定线程的最大行数时，当为该线程添加新行时，最旧的线程行将被丢弃。当线程结束时，其所有行都将被丢弃。

在服务器启动期间，性能模式会自动调整 N 的值。要显式设置每个线程的行数，请在服务器启动时设置 performance_schema_events_stages_history_size 系统变量。

events_stages_history 表具有与 events_stages_current 相同的列和索引。请参阅 Section 29.12.5.1, “events_stages_current 表”。

允许对 events_stages_history 表执行 TRUNCATE TABLE。它会删除行。

有关三个阶段事件表之间关系的更多信息，请参阅 Section 29.9, “当前和历史事件的性能模式表”。

有关配置是否收集阶段事件的信息，请参阅 Section 29.12.5, “性能模式阶段事件表”。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-events-stages-history-long-table.html

29.12.5.3 events_stages_history_long 表

events_stages_history_long表包含全局结束的*N*最近的阶段事件，跨所有线程。直到阶段事件结束后才将其添加到表中。当表已满时，添加新行时会丢弃最旧的行，无论哪个线程生成了这两行。

性能模式在服务器启动期间自动调整*N*的值。要显式设置表大小，请在服务器启动时设置performance_schema_events_stages_history_long_size系统变量。

events_stages_history_long表与events_stages_current表具有相同的列。请参阅第 29.12.5.1 节，“events_stages_current 表”。与events_stages_current表不同，events_stages_history_long表没有索引。

TRUNCATE TABLE允许用于events_stages_history_long表。它会删除行。

有关三个阶段事件表之间关系的更多信息，请参阅第 29.9 节，“当前和历史事件的性能模式表”。

关于配置是否收集阶段事件的信息，请参阅第 29.12.5 节，“性能模式阶段事件表”。

29.12.6 性能模式语句事件表

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

29.12.6.1 events_statements_current 表

29.12.6.2 events_statements_history 表

29.12.6.3 events_statements_history_long 表

29.12.6.4 prepared_statements_instances 表

性能模式仪器语句执行。语句事件发生在事件层次结构的高级别。在事件层次结构中，等待事件嵌套在阶段事件中，阶段事件嵌套在语句事件中，语句事件嵌套在事务事件中。

这些表存储语句事件：

  • events_statements_current: 每个线程的当前语句事件。

  • events_statements_history: 最近每个线程结束的语句事件。

  • events_statements_history_long: 最近全局结束的语句事件（跨所有线程）。

  • prepared_statements_instances: 准备语句实例和统计信息

以下各节描述了语句事件表。还有汇总信息关于语句事件的表；请参阅 第 29.12.20.3 节，“语句汇总表”。

有关三个 events_statements_*xxx* 事件表之间关系的更多信息，请参阅 第 29.9 节，“当前和历史事件的性能模式表”。

  • 配置语句事件收集

  • 语句监控

配置语句事件收集

要控制是否收集语句事件，请设置相关仪器和消费者的状态：

  • setup_instruments表包含以statement开头的工具名称。使用这些工具来启用或禁用单个语句事件类的收集。

  • setup_consumers表包含与当前和历史语句事件表名称以及语句摘要消费者对应的消费者值。使用这些消费者来过滤语句事件和语句摘要的收集。

语句工具默认启用，并且默认启用events_statements_current、events_statements_history和statements_digest语句消费者：

mysql> SELECT NAME, ENABLED, TIMED
       FROM performance_schema.setup_instruments
       WHERE NAME LIKE 'statement/%';
+---------------------------------------------+---------+-------+
| NAME                                        | ENABLED | TIMED |
+---------------------------------------------+---------+-------+
| statement/sql/select                        | YES     | YES   |
| statement/sql/create_table                  | YES     | YES   |
| statement/sql/create_index                  | YES     | YES   |
...
| statement/sp/stmt                           | YES     | YES   |
| statement/sp/set                            | YES     | YES   |
| statement/sp/set_trigger_field              | YES     | YES   |
| statement/scheduler/event                   | YES     | YES   |
| statement/com/Sleep                         | YES     | YES   |
| statement/com/Quit                          | YES     | YES   |
| statement/com/Init DB                       | YES     | YES   |
...
| statement/abstract/Query                    | YES     | YES   |
| statement/abstract/new_packet               | YES     | YES   |
| statement/abstract/relay_log                | YES     | YES   |
+---------------------------------------------+---------+-------+

mysql> SELECT *
       FROM performance_schema.setup_consumers
       WHERE NAME LIKE '%statements%';
+--------------------------------+---------+
| NAME                           | ENABLED |
+--------------------------------+---------+
| events_statements_current      | YES     |
| events_statements_history      | YES     |
| events_statements_history_long | NO      |
| statements_digest              | YES     |
+--------------------------------+---------+

要在服务器启动时控制语句事件收集，请在您的my.cnf文件中使用以下行：

  • 启用：

    [mysqld]
performance-schema-instrument='statement/%=ON'
performance-schema-consumer-events-statements-current=ON
performance-schema-consumer-events-statements-history=ON
performance-schema-consumer-events-statements-history-long=ON
performance-schema-consumer-statements-digest=ON

  • 禁用：

    [mysqld]
performance-schema-instrument='statement/%=OFF'
performance-schema-consumer-events-statements-current=OFF
performance-schema-consumer-events-statements-history=OFF
performance-schema-consumer-events-statements-history-long=OFF
performance-schema-consumer-statements-digest=OFF

要在运行时控制语句事件收集，请更新setup_instruments和setup_consumers表：

  • 启用：

    UPDATE performance_schema.setup_instruments
SET ENABLED = 'YES', TIMED = 'YES'
WHERE NAME LIKE 'statement/%';

UPDATE performance_schema.setup_consumers
SET ENABLED = 'YES'
WHERE NAME LIKE '%statements%';

  • 禁用：

    UPDATE performance_schema.setup_instruments
SET ENABLED = 'NO', TIMED = 'NO'
WHERE NAME LIKE 'statement/%';

UPDATE performance_schema.setup_consumers
SET ENABLED = 'NO'
WHERE NAME LIKE '%statements%';

仅启用相应的语句工具以收集特定语句事件。要仅为特定语句事件表收集语句事件，请启用语句工具，但仅启用与所需表对应的语句消费者。

有关配置事件收集的其他信息，请参见第 29.3 节，“性能模式启动配置”和第 29.4 节，“性能模式运行时配置”。

语句监控

语句监控从服务器看到线程请求活动的时刻开始，直到所有活动停止的时刻结束。通常，这意味着从服务器收到客户端的第一个数据包到服务器完成发送响应的时间。存储程序中的语句与其他语句一样进行监视。

当性能模式工具请求（服务器命令或 SQL 语句）时，它使用从更一般（或“抽象”）到更具体的阶段逐渐进行的工具名称，直到到达最终工具名称。

最终工具名称对应于服务器命令和 SQL 语句：

  • 服务器命令对应于mysql_com.h头文件中定义的COM_*xxx* codes，并在sql/sql_parse.cc中进行处理。例如COM_PING和COM_QUIT。命令的工具具有以statement/com开头的名称，例如statement/com/Ping和statement/com/Quit。

  • SQL 语句以文本形式表示，例如DELETE FROM t1或SELECT * FROM t2。SQL 语句的仪器名称以statement/sql开头，例如statement/sql/delete和statement/sql/select。

一些最终的仪器名称是特定于错误处理的：

  • statement/com/Error用于处理服务器接收到的超出带外的消息。它可用于检测服务器不理解的客户端发送的命令。这可能有助于识别配置错误或使用比服务器更近期的 MySQL 版本的客户端，或者试图攻击服务器的客户端。

  • statement/sql/error用于处理无法解析的 SQL 语句。它可用于检测客户端发送的格式错误的查询。无法解析的查询与解析但在执行过程中由于错误而失败的查询不同。例如，SELECT * FROM是格式错误的，将使用statement/sql/error仪器。相比之下，SELECT *解析但由于No tables used错误而失败。在这种情况下，将使用statement/sql/select，并且语句事件包含信息以指示错误的性质。

请求可以从这些来源中获取：

  • 作为客户端发送的命令或语句请求，该请求以数据包形式发送

  • 作为从副本的中继日志中读取的语句字符串

  • 作为事件来自事件调度程序

对于请求的详细信息最初是未知的，性能模式会根据请求的来源从抽象到具体的仪器名称进行顺序处理。

对于从客户端接收的请求：

  1. 当服务器在套接字级别检测到新数据包时，将以statement/abstract/new_packet的抽象仪器名称开始一个新语句。

  2. 当服务器读取数据包编号时，它会更多地了解收到的请求类型，并且性能模式会细化仪器名称。例如，如果请求是一个COM_PING数据包，则仪器名称变为statement/com/Ping，这是最终名称。如果请求是一个COM_QUERY数据包，则已知它对应于一个 SQL 语句，但不知道具体的语句类型。在这种情况下，仪器从一个抽象名称更改为一个更具体但仍然抽象的名称，statement/abstract/Query，并且请求需要进一步分类。

  3. 如果请求是一个语句，语句文本将被读取并传递给解析器。解析后，确切的语句类型就会知道。例如，如果请求是一个INSERT语句，性能模式会将仪器名称从statement/abstract/Query细化为statement/sql/insert，这是最终名称。

对于从副本的中继日志中读取的请求作为语句：

  1. 中继日志中的语句以文本形式存储并按此方式读取。没有网络协议，因此不使用statement/abstract/new_packet工具。相反，初始工具是statement/abstract/relay_log。

  2. 当语句被解析时，确切的语句类型是已知的。例如，如果请求是一个INSERT语句，性能模式将从statement/abstract/Query细化工具名称为statement/sql/insert，这是最终名称。

上述描述仅适用于基于语句的复制。对于基于行的复制，作为处理行更改的副本上的表 I/O 可以被检测，但中继日志中的行事件不会显示为离散语句。

对于从事件调度程序接收的请求：

事件执行使用名称statement/scheduler/event进行检测。这是最终名称。

在事件体内执行的语句使用statement/sql/*名称进行检测，而不使用任何前置的抽象工具。事件是一个存储过程，并且存储过程在执行之前在内存中预编译。因此，在运行时没有解析，每个语句的类型在执行时已知。

在事件体内执行的语句是子语句。例如，如果一个事件执行了一个INSERT语句，那么事件本身的执行是父级，使用statement/scheduler/event进行检测，而INSERT是子级，使用statement/sql/insert进行检测。父子关系存在于不同的被检测操作之间。这与在单个被检测操作内发生的从抽象到最终工具名称的细化顺序不同。

要收集语句的统计信息，仅启用单个语句类型所使用的最终statement/sql/*工具是不够的。还必须启用抽象的statement/abstract/*工具。这通常不是问题，因为所有语句工具默认都是启用的。然而，选择性启用或禁用语句工具的应用程序必须考虑到禁用抽象工具也会禁用对单个语句工具的统计信息收集。例如，要收集INSERT语句的统计信息，必须启用statement/sql/insert，还必须启用statement/abstract/new_packet和statement/abstract/Query。同样，要对复制语句进行检测，必须启用statement/abstract/relay_log。

对于statement/abstract/Query等抽象工具，不会对其进行统计汇总，因为最终语句名称中从未将语句分类为抽象工具。

avatar
文章
阅读
粉丝