25.8 性能模式原子和分子事件
对于表 I/O 事件，通常有两行 events_waits_current，而不是一行。例如，行提取可能会产生如下行：
Row# EVENT_NAME TIMER_START TIMER_END---- ---------- ----------- --------- 1 wait/io/file/myisam/dfile 10001 10002 2 wait/io/table/sql/handler 10000 NULL行提取导致文件读取。在示例中，表 I/O 提取事件在文件 I/O 事件之前开始但尚未完成（其TIMER_END值为 NULL）。文件 I/O 事件 “嵌套”在表 I/O 事件中。
这是因为，与其他“原子”等待事件（例如互斥锁或文件 I/O）不同，表 I/O 事件是 “分子”事件并包含（重叠）其他事件。在events_waits_current中，表 I/O 事件通常有两行：
- 一行表示最近的表 I/O 等待事件
- 一行表示任何类型的最新等待事件
通常，但不总是，“任何类型的”等待事件不同于表 I/O 事件。随着每个附属事件的完成，它会从 中消失 events_waits_current。此时，直到下一个辅助事件开始，表 I/O 等待也是任何类型的最近等待。
25.9 当前和历史事件的性能模式表
对于等待、阶段、语句和事务事件，Performance Schema 可以监视和存储当前事件。此外，当事件结束时，Performance Schema 可以将它们存储在历史表中。对于每种事件类型，Performance Schema 使用三个表来存储当前和历史事件。这些表具有以下形式的名称，其中 xxx表示事件类型（waits、stages、 statements、transactions）：
events_xxx_current：“当前事件”表存储每个线程的当前监控事件（每个线程一行）。events_xxx_history：“最近历史”表存储每个线程结束的最近事件（最多每个线程的最大行数）。events_xxx_history_long：“ long history ”表存储全局结束的最新事件（跨所有线程，最多每个表的最大行数）。
每种事件类型的_current表每个线程包含一行，因此没有用于配置其最大大小的系统变量。性能模式自动调整历史表的大小，或者可以在服务器启动时使用特定于表的系统变量显式配置大小，如描述各个历史表的部分所示。典型的 autosized 值是表的每个线程 10 行， _history表的总行数为 10,000 行 _history_long。
对于每种事件类型，_current、 _history和_history_long 表具有相同的列。
这些_current表格显示了服务器内当前正在发生的事情。当前事件结束时，将从其_current表中删除。
_history和 _history_long表显示最近发生的事情 。当历史表变满时，旧事件被丢弃，因为新事件被添加。_history行以不同的方式从和表中过期， _history_long 因为这些表有不同的用途：
_history旨在调查单个线程，独立于全局服务器负载。_history_long旨在全局调查服务器，而不是每个线程。
两种历史表的区别与数据保留策略有关。首次看到事件时，两个表都包含相同的数据。但是，每个表中的数据会随着时间的推移以不同的方式过期，因此数据可能会在每个表中保留更长或更短的时间：
- 对于
_history，当表包含给定线程的最大行数时，当为该线程添加新行时，最旧的线程行将被丢弃。 - 对于
_history_long，当表变满时，添加新行时最旧的行将被丢弃，无论哪个线程生成任一行。
当一个线程结束时，它的所有行都会从表中丢弃， _history但不会从 _history_long表中丢弃。
以下示例说明了在两种类型的历史表中添加和丢弃事件的方式的差异。这些原则同样适用于所有事件类型。该示例基于以下假设：
- 性能模式配置为在表中每个线程保留 10 行，在
_history表中总共保留 10,000 行_history_long。 - 线程 A 每秒生成 1 个事件。
线程 B 每秒生成 100 个事件。
- 没有其他线程正在运行。
执行 5 秒后：
- A 和 B 分别产生了 5 个和 500 个事件。
_historyA 包含 5 行，B 包含 10 行。由于每个线程的存储限制为 10 行，因此 A 没有丢弃任何行，而 B 丢弃了 490 行。_history_longA 包含 5 行，B 包含 500 行。由于该表的最大大小为 10,000 行，因此两个线程都没有丢弃任何行。
执行 5 分钟（300 秒）后：
- A 和 B 分别产生了 300 和 30,000 个事件。
_historyA 包含 10 行，B 包含 10 行。由于每个线程的存储限制为 10 行，因此 A 已丢弃 290 行，而 B 已丢弃 29,990 行。A 的行包括最长 10 秒的数据，而B 的行包含最多只有 0.1 秒的数据。_history_long包含 10,000 行。因为 A 和 B 每秒一起生成 101 个事件，所以该表包含最多大约 10,000/101 = 99 秒的数据，其中混合了来自 B 和 A 的大约 100 到 1 的行。
25.10 性能模式语句摘要
MySQL 服务器能够维护语句摘要信息。摘要过程将每个 SQL 语句转换为规范化形式（语句摘要），并根据规范化结果计算 MD5 哈希值（摘要哈希值）。规范化允许对相似的语句进行分组和汇总，以公开有关服务器正在执行的语句类型及其发生频率的信息。本节介绍语句摘要是如何发生的以及它如何有用。
无论性能模式是否可用，解析器都会进行摘要，以便其他服务器组件（例如 MySQL Enterprise Firewall 和查询重写插件）可以访问语句摘要。
声明文摘一般概念
当解析器收到一条 SQL 语句时，如果需要该摘要，它会计算一个语句摘要，如果以下任何条件为真，则该摘要为真：
- 性能模式摘要检测已启用
- MySQL 企业防火墙已启用
- 启用查询重写插件
max_digest_length系统变量值确定每个会话可用于计算规范化语句摘要的最大字节数 。一旦在摘要计算期间使用了该空间量，就会发生截断：不再收集已解析语句中的其他标记或计算其摘要值。仅在解析令牌的那么多字节之后才不同的语句产生相同的规范化语句摘要，并且如果比较或聚合摘要统计信息，则认为它们是相同的。
警告
将max_digest_length 系统变量设置为零会禁用摘要生成，这也会禁用需要摘要的服务器功能。
在计算出规范化语句后，会从中计算出一个 MD5 哈希值。此外：
- 如果启用了 MySQL Enterprise Firewall，则会调用它并且计算的摘要可供它使用。
- 如果启用了任何查询重写插件，则会调用它，并且可以使用语句摘要和摘要值。
- 如果 Performance Schema 启用了摘要检测，它会制作规范化语句摘要的副本，为其分配最大 performance_schema_max_digest_length 字节数。因此，如果 performance_schema_max_digest_length 小于 max_digest_length，则副本相对于原件被截断。规范化语句摘要的副本与从原始规范化语句计算的 MD5 哈希值一起存储在适当的性能模式表中。（如果性能模式相对于原始数据截断了规范化语句摘要的副本，它不会重新计算 MD5 哈希值。）
语句规范化将语句文本转换为更标准化的摘要字符串表示，该表示保留一般语句结构，同时删除结构不重要的信息：
- 保留对象标识符，例如数据库和表名。
- 文字值被转换为参数标记。规范化语句不保留姓名、密码、日期等信息。
- 删除注释并调整空格。
考虑这些陈述：
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 ...
在这种情况下，第二列名称的差异将丢失，并且两个语句被认为是相同的。
性能模式中的语句摘要
在性能模式中，语句摘要涉及以下元素：
- 表中的
statements_digest消费者 setup_consumers控制性能模式是否维护摘要信息。请参阅 声明摘要消费者。 - 语句事件表（events_statements_current、 events_statements_history和 events_statements_history_long）具有用于存储规范化语句摘要和相应摘要 MD5 哈希值的列：
DIGEST_TEXT是规范化语句摘要的文本。这是计算到最大 max_digest_length 字节的原始规范化语句的副本，根据需要进一步截断为 performance_schema_max_digest_length 字节。DIGEST是从原始规范化语句计算的摘要 MD5 哈希值。
- 摘要 events_statements_summary_by_digest 表提供汇总的语句摘要信息。此表汇总了每个语句
SCHEMA_NAME和DIGEST组合语句的信息。Performance Schema 使用 MD5 哈希值进行聚合，因为它们计算速度快，并且具有可最大限度减少冲突的有利统计分布。请参阅 第 25.12.15.3 节，“语句汇总表”。
语句事件表还有一个 SQL_TEXT包含原始 SQL 语句的列。默认情况下，可用于语句显示的最大空间为 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 会估计启动时使用的大小。要明确指定表大小，请 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：
- 性能模式以外的服务器组件使用规范化的语句摘要，最多占用 max_digest_length 字节。
- 性能模式进一步截断它存储的规范化语句摘要，并且分配的内存少于 max_digest_length每个摘要的字节数。
由于 Performance Schema 语句事件表可能存储许多摘要，设置 performance_schema_max_digest_length 小于max_digest_length 使管理员能够平衡这些因素：
- 需要为性能模式之外的服务器组件提供长的规范化语句摘要
- 许多并发会话，每个会话分配摘要计算内存
- 存储许多语句摘要时需要限制性能模式语句事件表的内存消耗
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 |
+----------------------------------------------------------------------+
25.11 性能模式通用表特征
数据库的名称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 表，所以尝试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)
25.12 性能模式表说明
25.12.1 性能模式表参考
下表总结了所有可用的性能模式表。有关更多详细信息，请参阅各个表的说明。
| 表名 | 描述 | 已弃用 |
| 每个客户帐户的连接统计信息 | ||
| 同步对象实例 | ||
| 当前阶段事件 | ||
| 每个线程的最新阶段事件 | ||
| 总体上最近的舞台活动 | ||
| 每个帐户和事件名称的阶段事件 | ||
| 每个主机名和事件名称的阶段事件 | ||
| 每个线程和事件名称的阶段等待 | ||
| 每个用户名和事件名称的阶段事件 | ||
| 每个事件名称的阶段等待 | ||
| 当前声明事件 | ||
| 每个线程最近的语句事件 | ||
| 总体上最近的声明事件 | ||
| 每个账户的报表事件和事件名称 | ||
| 每个模式和摘要值的语句事件 | ||
| 每个主机名和事件名称的语句事件 | ||
| 每个存储程序的语句事件 | ||
| 每个线程的语句事件和事件名称 | ||
| 每个用户名和事件名称的语句事件 | ||
| 每个事件名称的语句事件 | ||
| 当前交易事件 | ||
| 每个线程最近的事务事件 | ||
| 总体上最近的交易事件 | ||
| 每个账户的交易事件和事件名称 | ||
| 每个主机名和事件名的事务事件 | ||
| 每个线程的事务事件和事件名称 | ||
| 每个用户名和事件名的事务事件 | ||
| 每个事件名称的事务事件 | ||
| 当前等待事件 | ||
| 每个线程最近的等待事件 | ||
| 总体上最近的等待事件 | ||
| 每个帐户和事件名称的等待事件 | ||
| 每个主机名和事件名等待事件 | ||
| 每个实例的等待事件 | ||
| 每个线程的等待事件和事件名称 | ||
| 每个用户名和事件名等待事件 | ||
| 每个事件名称的等待事件 | ||
| 文件实例 | ||
| 每个事件名称的文件事件 | ||
| 每个文件实例的文件事件 | ||
| 全局状态变量 | ||
| 全局系统变量 | ||
| 来自内部主机缓存的信息 | ||
| 每个客户端主机名的连接统计信息 | ||
| 每个帐户和事件名称的内存操作 | ||
| 每个主机和事件名称的内存操作 | ||
| 每个线程和事件名称的内存操作 | ||
| 每个用户和事件名称的内存操作 | ||
| 每个事件名称的全局内存操作 | ||
| 元数据锁和锁请求 | ||
| 互斥同步对象实例 | ||
| 对象摘要 | ||
| 哪些事件计时器可用 | ||
| 准备好的语句实例和统计信息 | ||
| 副本上的复制应用程序的配置参数 | ||
| 副本上复制应用程序的当前状态 | ||
| SQL 或协调线程应用程序状态 | ||
| 工作线程应用程序状态 | ||
| 连接源的配置参数 | ||
| 与源的连接的当前状态 | ||
| 复制组成员统计 | ||
| 复制组成员网络和状态 | ||
| 锁定同步对象实例 | ||
| 当前会话的每个连接属性 | ||
| 所有会话的连接属性 | ||
| 当前会话的状态变量 | ||
| 当前会话的系统变量 | ||
| 如何初始化对新前台线程的监控 | ||
| 可以存储事件信息的消费者 | ||
| 可以为其收集事件的检测对象的类别 | ||
| 应该监控哪些对象 | ||
| 当前选择的事件计时器 | 5.7.21 | |
| 活动连接实例 | ||
| 每个事件名称的套接字等待和 I/O | ||
| 每个实例的套接字等待和 I/O | ||
| 每个帐户的会话状态变量 | ||
| 每个主机名的会话状态变量 | ||
| 每个会话的会话状态变量 | ||
| 每个用户名的会话状态变量 | ||
| 表锁和锁请求 | ||
| 每个索引的表 I/O 等待 | ||
| 每个表的表 I/O 等待 | ||
| 每个表的表锁等待 | ||
| 有关服务器线程的信息 | ||
| 每个线程的用户定义变量 | ||
| 每个客户端用户名的连接统计信息 | ||
| 每个会话的会话系统变量 |
25.12.2 性能模式设置表
25.12.2.1 setup_actors 表
该setup_actors表包含确定是否为新的前台服务器线程（与客户端连接关联的线程）启用监视和历史事件日志记录的信息。默认情况下，此表的最大大小为 100 行。要更改表大小，请 performance_schema_setup_actors_size 在服务器启动时修改系统变量。
对于每个新的前台线程，Performance Schema 将线程的用户和主机与表中的行进行匹配 setup_actors。如果该表中的一行匹配，则其值ENABLED和 HISTORY列值分别用于设置 线程 的 表行INSTRUMENTED的列。这使得检测和历史事件日志可以有选择地按主机、用户或帐户（用户和主机组合）应用。如果不匹配，则线程的 和 列设置为。 HISTORYthreadsINSTRUMENTEDHISTORYNO
对于后台线程，没有关联的用户。 INSTRUMENTED并且默认情况下 HISTORY 不被咨询。 YESsetup_actors
表的初始内容 setup_actors匹配任何用户和主机组合，因此默认为所有前台线程启用监控和历史事件收集：
mysql> SELECT * FROM performance_schema.setup_actors;
+------+------+------+---------+---------+
| HOST | USER | ROLE | ENABLED | HISTORY |
+------+------+------+---------+---------+
| % | % | % | YES | YES |
+------+------+------+---------+---------+
有关如何使用该 setup_actors表来影响事件监视的信息，请参阅 第 25.4.6 节，“按线程进行预过滤”。
对setup_actors 表的修改仅影响在修改之后创建的前台线程，而不影响现有线程。要影响现有线程，请修改表行的INSTRUMENTED和 HISTORY列 threads。
该setup_actors表具有以下列：
HOST
主机名。这应该是一个字面名称，或者 '%'表示“任何主机”。”
USER
用户名。这应该是一个字面名称，或 '%'表示“任何用户”。”
ROLE
没用过。
ENABLED
是否为该行匹配的前台线程启用检测。值为YES或 NO。
HISTORY
是否记录该行匹配的前台线程的历史事件。值为YES或 NO。
TRUNCATE TABLE表允许setup_actors。它删除行。
25.12.2.2 setup_consumers 表
该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 | NO |
| events_transactions_history | NO |
| 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形成了从高到低的层次结构。有关启用不同消费者的效果的详细信息，请参阅第 25.4.7 节，“消费者预过滤”。
对 setup_consumers表格的修改会立即影响监控。
该setup_consumers表具有以下列：
NAME
消费者名称。
ENABLED
消费者是否启用。值为 YES或NO。可以修改此列。如果禁用消费者，服务器不会花时间向其添加事件信息。
TRUNCATE TABLE不允许用于该setup_consumers表。
25.12.2.3 setup_instruments 表
该setup_instruments表列出了可以为其收集事件的检测对象的类别：
mysql> SELECT * FROM performance_schema.setup_instruments;
+---------------------------------------------------+---------+-------+
| NAME | ENABLED | TIMED |
+---------------------------------------------------+---------+-------+
...
| stage/sql/end | NO | NO |
| stage/sql/executing | NO | NO |
| stage/sql/init | NO | NO |
| stage/sql/insert | NO | NO |
...
| statement/sql/load | YES | YES |
| statement/sql/grant | YES | YES |
| statement/sql/check | YES | YES |
| statement/sql/flush | YES | YES |
...
| wait/synch/mutex/sql/LOCK_global_read_lock | YES | YES |
| wait/synch/mutex/sql/LOCK_global_system_variables | YES | YES |
| wait/synch/mutex/sql/LOCK_lock_db | YES | YES |
| wait/synch/mutex/sql/LOCK_manager | YES | YES |
...
| wait/synch/rwlock/sql/LOCK_grant | YES | YES |
| wait/synch/rwlock/sql/LOGGER::LOCK_logger | YES | YES |
| wait/synch/rwlock/sql/LOCK_sys_init_connect | YES | YES |
| wait/synch/rwlock/sql/LOCK_sys_init_slave | YES | YES |
...
| wait/io/file/sql/binlog | YES | YES |
| wait/io/file/sql/binlog_index | YES | YES |
| wait/io/file/sql/casetest | YES | YES |
| wait/io/file/sql/dbopt | YES | YES |
...
添加到源代码的每个工具都会为setup_instruments表提供一行，即使未执行已检测的代码也是如此。启用和执行仪器时，会创建已检测的实例，这些实例在 xxx_instances 表中可见，例如file_instances或 rwlock_instances。
对大多数 setup_instruments行的修改会立即影响监控。对于某些仪器，修改仅在服务器启动时生效；在运行时更改它们无效。这主要影响服务器中的互斥体、条件和 rwlocks，尽管可能有其他工具是这样的。
有关 setup_instruments表在事件过滤中的作用的更多信息，请参阅 第 25.4.3 节，“事件预过滤”。
该setup_instruments表具有以下列：
NAME
仪器名称。仪器名称可能有多个部分并形成层次结构，如 第 25.6 节“性能模式仪器命名约定”中所述。执行工具产生的事件具有 EVENT_NAME取自工具值的NAME值。（事件并没有真正的“名称”，但这提供了一种将事件与乐器相关联的方法。）
ENABLED
仪器是否启用。值为 YES或NO。禁用的仪器不会产生任何事件。此列可以修改，但设置ENABLED对已创建的仪器无效。
TIMED
仪器是否定时。值为 YES或NO。此列可以修改，但设置 TIMED对已创建的仪器无效。
对于内存工具， 由于内存操作没有计时，因此忽略 了TIMED in 列。setup_instruments
如果启用的仪器未计时，则启用仪器代码，但不启用计时器。仪器产生的事件具有NULL、 TIMER_START和 TIMER_ENDtimer TIMER_WAIT值。这反过来会导致在计算汇总表中的总和、最小、最大和平均时间值时忽略这些值。
TRUNCATE TABLE不允许用于该setup_instruments表。
25.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，Performance Schema 使用该表来了解如何监视它们。对象匹配基于OBJECT_SCHEMA和 OBJECT_NAME列。没有匹配的对象不被监控。
默认对象配置的效果是检测除 、 和 数据库中的所有表之外的 mysql所有 INFORMATION_SCHEMA表 performance_schema。（INFORMATION_SCHEMA无论 的内容如何，都不会检测数据库中的 表setup_objects； 的行 information_schema.%只是使此默认值显式。）
当 Performance Schema 检查 中的匹配项时 setup_objects，它会首先尝试查找更具体的匹配项。例如，对于 table ，它会查找anddb1.t1的匹配项 ，然后查找 and ，然后查找 and 。匹配发生的顺序很重要，因为不同的匹配 行可以有不同的和 值。 'db1''t1''db1''%''%''%'setup_objectsENABLEDTIMED
行可以由对表具有或 权限setup_objects的用户 插入或删除 。对于现有行，只有和 列可以由具有表权限的用户修改。 INSERTDELETEENABLEDTIMEDUPDATE
有关 setup_objects表在事件过滤中的作用的更多信息，请参阅 第 25.4.3 节，“事件预过滤”。
该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
对象的事件是否定时。值为 YES或NO。可以修改此列。
TRUNCATE TABLE表允许setup_objects。它删除行。
25.12.2.5 setup_timers 表
该setup_timers表显示了当前选择的事件计时器：
mysql> SELECT * FROM performance_schema.setup_timers;
+-------------+-------------+
| NAME | TIMER_NAME |
+-------------+-------------+
| idle | MICROSECOND |
| wait | CYCLE |
| stage | NANOSECOND |
| statement | NANOSECOND |
| transaction | NANOSECOND |
+-------------+-------------+
笔记
从 MySQL 5.7.21 开始，Performance Schema setup_timers表已被弃用，并在 MySQL 8.0 中被删除，表中的 TICKS行也是 如此performance_timers。
setup_timers.TIMER_NAME可以更改 该值以选择不同的计时器。该值可以是 performance_timers.TIMER_NAME列中的任何值。有关事件计时如何发生的说明，请参阅 第 25.4.1 节，“性能模式事件计时”。
对setup_timers 表格的修改会立即影响监控。已经在进行中的事件可以使用原始计时器作为开始时间，使用新计时器作为结束时间。为避免在更改计时器后出现不可预测的结果，请使用 TRUNCATE TABLE重置 Performance Schema 统计信息。
该setup_timers表具有以下列：
NAME
计时器用于的仪器类型。
TIMER_NAME
适用于仪器类型的计时器。可以修改此列。
TRUNCATE TABLE不允许用于该setup_timers表。
设置表提供有关当前仪器的信息并允许更改监控配置。因此，如果您有UPDATE 权限，可以更改这些表中的某些列。
使用表而不是单个变量来获取设置信息，为修改性能模式配置提供了高度的灵活性。例如，您可以使用具有标准 SQL 语法的单个语句来同时进行多个配置更改。
这些设置表可用：
- setup_actors: 如何初始化对新前台线程的监控
- setup_consumers: 可以发送和存储事件信息的目的地
- setup_instruments：可以为其收集事件的检测对象的类
- setup_objects: 应该监控哪些对象
- setup_timers：当前事件计时器
25.12.3 性能模式实例表
25.12.3.1 cond_instances 表
该cond_instances表列出了服务器执行时 Performance Schema 看到的所有条件。条件是代码中使用的一种同步机制，用于发出特定事件已发生的信号，以便等待此条件的线程可以恢复工作。
当一个线程正在等待某事发生时，条件名称指示线程正在等待什么，但没有直接的方法来判断哪些其他线程导致条件发生。
该cond_instances表具有以下列：
NAME
与条件关联的仪器名称。
OBJECT_INSTANCE_BEGIN
检测条件在内存中的地址。
TRUNCATE TABLE不允许用于该cond_instances表。
25.12.3.2 file_instances 表
该file_instances表列出了执行文件 I/O 检测时性能模式看到的所有文件。如果磁盘上的文件从未打开过，则它不在 file_instances. 当一个文件从磁盘中删除时，它也会从 file_instances表中删除。
该file_instances表具有以下列：
FILE_NAME
文件名。
EVENT_NAME
与文件关联的仪器名称。
OPEN_COUNT
文件上打开句柄的计数。如果一个文件被打开然后关闭，它被打开了 1 次，但 OPEN_COUNT为 0。要列出服务器当前打开的所有文件，请使用WHERE OPEN_COUNT > 0.
TRUNCATE TABLE不允许用于该file_instances表。
25.12.3.3 mutex_instances 表
该mutex_instances表列出了服务器执行时 Performance Schema 看到的所有互斥锁。互斥锁是代码中使用的一种同步机制，用于强制在给定时间只有一个线程可以访问某些公共资源。资源被互斥体 “保护” 。
当服务器中执行的两个线程（例如，同时执行查询的两个用户会话）确实需要访问相同的资源（文件、缓冲区或某些数据）时，这两个线程相互竞争，因此第一个获取互斥锁锁定的查询会导致另一个查询等到第一个查询完成并解锁互斥锁。
持有互斥锁时执行的工作被称为 “临界区”，并且多个查询确实以序列化的方式（一次一个）执行该临界区，这是一个潜在的瓶颈。
该mutex_instances表具有以下列：
NAME
与互斥锁关联的仪器名称。
OBJECT_INSTANCE_BEGIN
已检测互斥体在内存中的地址。
LOCKED_BY_THREAD_ID
当一个线程当前有一个互斥锁被锁定时， LOCKED_BY_THREAD_ID是 THREAD_ID锁定线程的，否则是NULL。
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列中）。
- events_waits_current 显示对互斥体的等待已完成（在
- 当线程解锁互斥锁时， mutex_instances显示互斥锁现在没有所有者（
THREAD_ID列是NULL）。 - 当一个互斥对象被销毁时，相应的行会从mutex_instances.
通过对以下两个表执行查询，监控应用程序或 DBA 可以检测涉及互斥锁的线程之间的瓶颈或死锁：
- events_waits_current, 查看线程正在等待什么互斥锁
- mutex_instances, 查看当前哪个其他线程拥有互斥锁
25.12.3.4 rwlock_instances 表
该rwlock_instances表列出了服务器执行时 Performance Schema 看到的所有rwlock（读写锁）实例。Anrwlock是代码中使用的一种同步机制，用于强制线程在给定时间可以按照某些规则访问某些公共资源。该资源被称为 “受保护”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，并查看当前有多少阅读器处于活动状态。
TRUNCATE TABLE不允许用于该rwlock_instances表。
通过对以下两个表执行查询，监控应用程序或 DBA 可能会检测到涉及锁的线程之间的一些瓶颈或死锁：
- events_waits_current, 查看
rwlock线程在等待 什么 - rwlock_instances, 查看哪个其他线程当前拥有一个
rwlock
有一个限制： rwlock_instances只能用于识别持有写锁的线程，不能用于识别持有读锁的线程。
25.12.3.5 socket_instances 表
该socket_instances表提供了与 MySQL 服务器的活动连接的实时快照。该表包含每个 TCP/IP 或 Unix 套接字文件连接一行。此表中的可用信息提供了与服务器的活动连接的实时快照。（套接字摘要表中提供了其他信息，包括网络活动，例如套接字操作和发送和接收的字节数；请参阅 第 25.12.15.8 节，“套接字摘要表”）。
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
套接字工具具有形式的名称， 并像这样使用： wait/io/socket/sql/socket_type
- 服务器为它支持的每个网络协议都有一个侦听套接字。与 TCP/IP 或 Unix 套接字文件连接的侦听套接字关联的工具分别具有或
socket_type值。server_tcpip_socketserver_unix_socket - 当侦听套接字检测到连接时，服务器会将连接转移到由单独线程管理的新套接字。新连接线程的工具的
socket_type值为client_connection。 - 当一个连接终止时， socket_instances 与之对应的行被删除。
该socket_instances表具有以下列：
EVENT_NAME
wait/io/socket/* 产生事件 的工具的名称。这是表中的 NAME值 setup_instruments。仪器名称可能有多个部分并形成层次结构，如 第 25.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，并且套接字仪器的计时恢复。
TRUNCATE TABLE不允许用于该socket_instances表。
列IP:PORT组合值标识连接。此组合值用于表的OBJECT_NAME列中 ，以标识套接字事件来自的连接： events_waits_xxx
- 对于 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（127.0.0.1::1
实例表记录了检测的对象类型。它们提供事件名称和解释性说明或状态信息：
- cond_instances: 条件同步对象实例
- file_instances: 文件实例
- mutex_instances: Mutex 同步对象实例
- rwlock_instances: 锁定同步对象实例
- socket_instances: 活动连接实例
这些表列出了检测的同步对象、文件和连接。有三种类型的同步对象：cond、mutex和 rwlock。每个实例表都有一个 EVENT_NAME或NAME列来指示与每一行关联的工具。仪器名称可能有多个部分并形成层次结构，如第 25.6 节“性能模式仪器命名约定”中所述。
和 列对于调查性能瓶颈或死锁非常重要mutex_instances.LOCKED_BY_THREAD_ID。 rwlock_instances.WRITE_LOCKED_BY_THREAD_ID有关如何将它们用于此目的的示例，请参阅第 25.19 节，“使用性能模式诊断问题”
25.12.4 性能模式等待事件表
25.12.4.1 events_waits_current 表
25.12.4.1 events_waits_current 表
该events_waits_current表包含当前等待事件。该表为每个线程存储一行，显示线程最近监视的等待事件的当前状态，因此没有用于配置表大小的系统变量。
在包含等待事件行的表中， events_waits_current是最基本的。包含等待事件行的其他表在逻辑上是从当前事件派生的。例如， events_waits_history和 events_waits_history_long表是最近结束的等待事件的集合，分别达到每个线程和全局所有线程的最大行数。
有关三个等待事件表之间关系的更多信息，请参阅 第 25.9 节，“当前和历史事件的性能模式表”。
有关配置是否收集等待事件的信息，请参阅第 25.12.4 节，“性能模式等待事件表”。
该events_waits_current表具有以下列：
THREAD_ID,EVENT_ID
事件启动时与事件关联的线程和线程当前事件编号。THREAD_ID和 EVENT_ID值一起唯一标识该行。 没有两行具有相同的一对值。
END_EVENT_ID
此列设置为NULL事件何时开始，并在事件结束时更新为线程当前事件编号。
EVENT_NAME
产生事件的工具的名称。这是表中的NAME值 setup_instruments。仪器名称可能有多个部分并形成层次结构，如 第 25.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。
有关以皮秒为单位的事件时间和影响时间值的因素的讨论，请参阅 第 25.4.1 节，“性能模式事件计时”。
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持久基表或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 使用嵌套循环实现来执行连接。Performance Schema 检测的工作是提供连接中每个表的行数和累积执行时间。t1假设使用, t2, 的表连接顺序执行以下形式的连接查询 t3：
SELECT ... FROM t1 JOIN t2 ON ... JOIN t3 ON ...
表“扇出”是在连接处理期间添加表所增加或减少的行数。如果 table 的 fanoutt3大于 1，则大多数 row-fetch 操作都针对该 table。假设连接访问表的 10 行 ， 每行t120 行，表 的每行 30 行 。对于单行报告，检测操作的总数为： t2t1t3t2
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
保留供将来使用。
TRUNCATE TABLE表允许events_waits_current。它删除行。
25.12.4.2 events_waits_history 表
25.12.4.2 events_waits_history 表
该events_waits_history表包含N每个线程最近结束的等待事件。等待事件在结束之前不会添加到表中。当表包含给定线程的最大行数时，当为该线程添加新行时，最旧的线程行将被丢弃。当一个线程结束时，它的所有行都被丢弃。
性能模式 N在服务器启动期间自动调整 的值。要显式设置每个线程的行数，请 performance_schema_events_waits_history_size 在服务器启动时设置系统变量。
该events_waits_history表具有与 相同的列 events_waits_current。请参阅 第 25.12.4.1 节，“events_waits_current 表”。
TRUNCATE TABLE表允许events_waits_history。它删除行。
有关三个等待事件表之间关系的更多信息，请参阅 第 25.9 节，“当前和历史事件的性能模式表”。
有关配置是否收集等待事件的信息，请参阅第 25.12.4 节，“性能模式等待事件表”。
25.12.4.3 events_waits_history_long 表
25.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。请参阅 第 25.12.4.1 节，“events_waits_current 表”。
TRUNCATE TABLE表允许events_waits_history_long 。它删除行。
有关三个等待事件表之间关系的更多信息，请参阅 第 25.9 节，“当前和历史事件的性能模式表”。
有关配置是否收集等待事件的信息，请参阅第 25.12.4 节，“性能模式等待事件表”。
性能模式仪器等待，这是需要时间的事件。在事件层次结构中，等待事件嵌套在阶段事件中，阶段事件嵌套在语句事件中，又嵌套在事务事件中。
这些表存储等待事件：
- events_waits_current：每个线程的当前等待事件。
- events_waits_history：每个线程结束的最近等待事件。
- events_waits_history_long：最近全局结束的等待事件（跨所有线程）。
以下部分描述了等待事件表。还有汇总表，汇总有关等待事件的信息；请参阅 第 25.12.15.1 节，“等待事件汇总表”。
有关三个等待事件表之间关系的更多信息，请参阅 第 25.9 节，“当前和历史事件的性能模式表”。
要控制是否收集等待事件，请设置相关仪器和消费者的状态：
- 该setup_instruments表包含名称以 开头的仪器
wait。使用这些工具来启用或禁用单个等待事件类的收集。 - 该setup_consumers表包含名称对应于当前和历史等待事件表名称的消费者值。使用这些消费者过滤等待事件的集合。
一些等待工具默认启用；其他人被禁用。例如：
mysql> SELECT * FROM performance_schema.setup_instruments
WHERE NAME LIKE 'wait/io/file/innodb%';+--------------------------------------+---------+-------+
| NAME | ENABLED | TIMED |
+--------------------------------------+---------+-------+
| 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 |
+--------------------------------------+---------+-------+
mysql> SELECT *
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=TIMED= - WHERE
- UPDATE
performance_schema.setup_consumers - SET
ENABLED=
WHERE NAME LIKE 'events_waits%';
- 禁用：
- UPDATE
performance_schema.setup_instruments - SET
ENABLED=TIMED= - WHERE
- UPDATE
performance_schema.setup_consumers - SET
ENABLED=
WHERE NAME LIKE 'events_waits%';
要仅收集特定的等待事件，请仅启用相应的等待工具。要仅收集特定等待事件表的等待事件，请启用等待工具，但仅启用与所需表相对应的等待消费者。
该setup_timers表包含一行，其NAME值为 wait表示等待事件计时的单位。默认单位是CYCLE：
mysql> SELECT *
FROM performance_schema.setup_timers WHERE NAME = 'wait';+------+------------+
| NAME | TIMER_NAME |
+------+------------+
| wait | CYCLE |
+------+------------+
要更改计时单位，请修改 TIMER_NAME值：
UPDATE performance_schema.setup_timers
SET TIMER_NAME = 'NANOSECOND'
WHERE NAME = 'wait';
有关配置事件收集的其他信息，请参阅第 25.3 节，“性能模式启动配置”和第 25.4 节，“性能模式运行时配置”。
25.12.5 性能模式阶段事件表
25.12.5.1 events_stages_current 表
25.12.5.1 events_stages_current 表
该events_stages_current表包含当前阶段事件。该表为每个线程存储一行，显示线程最近监控的阶段事件的当前状态，因此没有用于配置表大小的系统变量。
在包含舞台事件行的表中， events_stages_current是最基本的。包含舞台事件行的其他表在逻辑上是从当前事件派生的。例如， events_stages_history和 events_stages_history_long表是最近结束的阶段事件的集合，分别达到每个线程和全局所有线程的最大行数。
有关三个阶段事件表之间关系的更多信息，请参阅 第 25.9 节，“当前和历史事件的性能模式表”。
有关配置是否收集阶段事件的信息，请参阅第 25.12.5 节，“性能模式阶段事件表”。
该events_stages_current表具有以下列：
THREAD_ID,EVENT_ID
事件启动时与事件关联的线程和线程当前事件编号。THREAD_ID和 EVENT_ID值一起唯一标识该行。 没有两行具有相同的一对值。
END_EVENT_ID
此列设置为NULL事件何时开始，并在事件结束时更新为线程当前事件编号。
EVENT_NAME
产生事件的工具的名称。这是表中的NAME值 setup_instruments。仪器名称可能有多个部分并形成层次结构，如 第 25.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。
有关以皮秒为单位的事件时间和影响时间值的因素的讨论，请参阅 第 25.4.1 节，“性能模式事件计时”。
WORK_COMPLETED,WORK_ESTIMATED
这些列提供阶段进度信息，用于已实施以生成此类信息的工具。WORK_COMPLETED指示该阶段已完成多少工作单元，并 WORK_ESTIMATED指示该阶段预期有多少工作单元。有关详细信息，请参阅舞台活动进度信息。
NESTING_EVENT_ID
EVENT_ID嵌套此事件的事件 的值。阶段事件的嵌套事件通常是语句事件。
NESTING_EVENT_TYPE
嵌套事件类型。值为 TRANSACTION、 STATEMENT、STAGE或 WAIT。
TRUNCATE TABLE表允许events_stages_current。它删除行。
25.12.5.2 events_stages_history 表
25.12.5.2 events_stages_history 表
该events_stages_history表包含N每个线程已结束的最新阶段事件。舞台事件在结束之前不会添加到表格中。当表包含给定线程的最大行数时，当为该线程添加新行时，最旧的线程行将被丢弃。当一个线程结束时，它的所有行都被丢弃。
性能模式 N在服务器启动期间自动调整 的值。要显式设置每个线程的行数，请 performance_schema_events_stages_history_size 在服务器启动时设置系统变量。
该events_stages_history表具有与 相同的列 events_stages_current。请参阅 第 25.12.5.1 节，“events_stages_current 表”。
TRUNCATE TABLE表允许events_stages_history。它删除行。
有关三个阶段事件表之间关系的更多信息，请参阅 第 25.9 节，“当前和历史事件的性能模式表”。
有关配置是否收集阶段事件的信息，请参阅第 25.12.5 节，“性能模式阶段事件表”。
25.12.5.3 events_stages_history_long 表
25.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。请参阅 第 25.12.5.1 节，“events_stages_current 表”。
TRUNCATE TABLE表允许events_stages_history_long 。它删除行。
有关三个阶段事件表之间关系的更多信息，请参阅 第 25.9 节，“当前和历史事件的性能模式表”。
有关配置是否收集阶段事件的信息，请参阅第 25.12.5 节，“性能模式阶段事件表”。
性能模式检测阶段，即语句执行过程中的步骤，例如解析语句、打开表或执行 filesort操作。阶段对应于表中显示SHOW PROCESSLIST或可见 的线程状态INFORMATION_SCHEMA.PROCESSLIST 。当状态值发生变化时，阶段开始和结束。
在事件层次结构中，等待事件嵌套在阶段事件中，阶段事件嵌套在语句事件中，又嵌套在事务事件中。
这些表存储阶段事件：
- events_stages_current：每个线程的当前阶段事件。
- events_stages_history：每个线程结束的最新阶段事件。
- events_stages_history_long：已在全球范围内结束的最新阶段事件（跨所有线程）。
以下部分描述了舞台事件表。还有汇总有关舞台事件的信息的汇总表；请参阅 第 25.12.15.2 节，“阶段汇总表”。
有关三个阶段事件表之间关系的更多信息，请参阅 第 25.9 节，“当前和历史事件的性能模式表”。
要控制是否收集舞台事件，请设置相关仪器和消费者的状态：
- 该setup_instruments表包含名称以 开头的仪器
stage。使用这些工具来启用或禁用单个舞台事件类的收集。 - 该setup_consumers表包含名称对应于当前和历史阶段事件表名称的消费者值。使用这些消费者来过滤阶段事件的集合。
除了那些提供语句进度信息的工具外，舞台工具默认禁用。例如：
mysql> SELECT *
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/checking privileges on cached query | NO | NO |
| stage/sql/checking query cache for query | 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 *
FROM performance_schema.setup_instruments WHERE ENABLED='YES' AND NAME LIKE "stage/%";+------------------------------------------------------+---------+-------+
| NAME | ENABLED | TIMED |
+------------------------------------------------------+---------+-------+
| stage/sql/copy to tmp table | 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 |
+------------------------------------------------------+---------+-------+
默认情况下禁用阶段消费者：
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=TIMED= - WHERE
- UPDATE
performance_schema.setup_consumers - SET
ENABLED=
WHERE NAME LIKE 'events_stages%';
- 禁用：
- UPDATE
performance_schema.setup_instruments - SET
ENABLED=TIMED= - WHERE
- UPDATE
performance_schema.setup_consumers - SET
ENABLED=
WHERE NAME LIKE 'events_stages%';
要仅收集特定的舞台事件，请仅启用相应的舞台乐器。要仅为特定舞台事件表收集舞台事件，请启用舞台工具，但仅启用与所需表相对应的舞台消费者。
该setup_timers表包含一行，其NAME值为 stage表示舞台事件计时的单位。默认单位是NANOSECOND：
mysql> SELECT *
FROM performance_schema.setup_timers WHERE NAME = 'stage';+-------+------------+
| NAME | TIMER_NAME |
+-------+------------+
| stage | NANOSECOND |
+-------+------------+
要更改计时单位，请修改 TIMER_NAME值：
UPDATE performance_schema.setup_timers
SET TIMER_NAME = 'MICROSECOND'
WHERE NAME = 'stage';
有关配置事件收集的其他信息，请参阅第 25.3 节，“性能模式启动配置”和第 25.4 节，“性能模式运行时配置”。
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表中选择。
25.12.6.1 events_statements_current 表
该events_statements_current 表包含当前语句事件。该表为每个线程存储一行，显示线程最近监控的语句事件的当前状态，因此没有用于配置表大小的系统变量。
在包含语句事件行的表中， events_statements_current是最基本的。包含语句事件行的其他表在逻辑上是从当前事件派生的。例如， events_statements_history和 events_statements_history_long 表是最近结束的语句事件的集合，分别达到每个线程和全局所有线程的最大行数。
有关三个事件表 之间关系的更多信息 ，请参阅第 25.9 节，“当前和历史事件的性能模式表”。 events_statements_xxx
有关配置是否收集语句事件的信息，请参阅 第 25.12.6 节，“性能模式语句事件表”。
该events_statements_current 表具有以下列：
THREAD_ID,EVENT_ID
事件启动时与事件关联的线程和线程当前事件编号。THREAD_ID和 EVENT_ID值一起唯一标识该行。 没有两行具有相同的一对值。
END_EVENT_ID
此列设置为NULL事件何时开始，并在事件结束时更新为线程当前事件编号。
EVENT_NAME
从中收集事件的工具的名称。这是表中的NAME值setup_instruments。仪器名称可能有多个部分并形成层次结构，如 第 25.6 节“性能模式仪器命名约定”中所述。
对于 SQL 语句，该EVENT_NAME 值最初是statement/com/Query 直到语句被解析，然后更改为更合适的值，如 第 25.12.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。
有关以皮秒为单位的事件时间和影响时间值的因素的讨论，请参阅 第 25.4.1 节，“性能模式事件计时”。
LOCK_TIME
等待表锁所花费的时间。此值以微秒为单位计算，但标准化为皮秒，以便与其他性能模式计时器进行比较。
SQL_TEXT
SQL 语句的文本。对于不与 SQL 语句关联的命令，值为 NULL。
默认情况下，可用于语句显示的最大空间为 1024 字节。要更改此值，请 performance_schema_max_sql_text_length 在服务器启动时设置系统变量。
DIGEST
该语句将 MD5 值摘要为 32 个十六进制字符的字符串，或者NULL如果 statements_digest消费者是 no. 有关语句摘要的更多信息，请参阅 第 25.10 节，“性能模式语句摘要”。
DIGEST_TEXT
规范化的语句摘要文本，或者 NULL如果 statements_digest消费者是 no. 有关语句摘要的更多信息，请参阅 第 25.10 节，“性能模式语句摘要”。
系统变量确定每个会话可用于存储摘要值的 performance_schema_max_digest_length 最大字节数。但是，由于在摘要缓冲区中对语句元素（例如关键字和文字值）进行了编码，语句摘要的显示长度可能会比可用缓冲区大小长。因此，从 DIGEST_TEXT语句事件表列中选择的值可能会超过该 performance_schema_max_digest_length 值。
CURRENT_SCHEMA
语句的默认数据库（ NULL如果没有）。
OBJECT_SCHEMA,OBJECT_NAME,OBJECT_TYPE
对于嵌套语句（存储程序），这些列包含有关父语句的信息。否则他们是NULL。
OBJECT_INSTANCE_BEGIN
此列标识语句。该值是内存中对象的地址。
MYSQL_ERRNO
语句错误号，来自语句诊断区域。
RETURNED_SQLSTATE
语句 SQLSTATE 值，来自语句诊断区域。
MESSAGE_TEXT
来自语句诊断区域的语句错误消息。
ERRORS
语句是否发生错误。00 如果 SQLSTATE 值以(completion) 或01(warning)开头，则该值为 0 。值为 1 是 SQLSTATE 值是其他任何值。
WARNINGS
来自语句诊断区域的警告数。
ROWS_AFFECTED
受语句影响的行数。有关“影响”含义的描述，请参见 mysql_affected_rows()。
ROWS_SENT
语句返回的行数。
ROWS_EXAMINED
服务器层检查的行数（不包括存储引擎内部的任何处理）。
CREATED_TMP_DISK_TABLES
与 Created_tmp_disk_tables 状态变量类似，但特定于语句。
CREATED_TMP_TABLES
与 Created_tmp_tables 状态变量类似，但特定于语句。
SELECT_FULL_JOIN
与 Select_full_join状态变量类似，但特定于语句。
SELECT_FULL_RANGE_JOIN
与 Select_full_range_join 状态变量类似，但特定于语句。
SELECT_RANGE
与Select_range 状态变量类似，但特定于语句。
SELECT_RANGE_CHECK
与 Select_range_check 状态变量类似，但特定于语句。
SELECT_SCAN
与Select_scan 状态变量类似，但特定于语句。
SORT_MERGE_PASSES
与 Sort_merge_passes状态变量类似，但特定于语句。
SORT_RANGE
与Sort_range 状态变量类似，但特定于语句。
SORT_ROWS
与Sort_rows 状态变量类似，但特定于语句。
SORT_SCAN
与Sort_scan 状态变量类似，但特定于语句。
NO_INDEX_USED
如果语句在不使用索引的情况下执行表扫描，则为 1，否则为 0。
NO_GOOD_INDEX_USED
如果服务器没有找到用于该语句的好的索引，则为 1，否则为 0。有关其他信息，请参阅第 8.8.2 节，“解释输出格式”中的值的 输出 Extra列的描述。 EXPLAINRange checked for each record
NESTING_EVENT_ID,NESTING_EVENT_TYPE,NESTING_EVENT_LEVEL
这三列与其他列一起使用，为顶级（未嵌套）语句和嵌套语句（在存储程序中执行）提供如下信息。
对于顶级语句：
OBJECT_TYPE = NULLOBJECT_SCHEMA = NULLOBJECT_NAME = NULLNESTING_EVENT_ID = NULLNESTING_EVENT_TYPE = NULLNESTING_LEVEL = 0对于嵌套语句：
OBJECT_TYPE = the parent statement object typeOBJECT_SCHEMA = the parent statement object schemaOBJECT_NAME = the parent statement object nameNESTING_EVENT_ID = the parent statement EVENT_IDNESTING_EVENT_TYPE = 'STATEMENT'NESTING_LEVEL = the parent statement NESTING_LEVEL plus oneTRUNCATE TABLE表允许events_statements_current 。它删除行。
25.12.6.2 events_statements_history 表
该events_statements_history 表包含N每个线程已结束的最新语句事件。语句事件在它们结束之前不会添加到表中。当表包含给定线程的最大行数时，当为该线程添加新行时，最旧的线程行将被丢弃。当一个线程结束时，它的所有行都被丢弃。
性能模式 N在服务器启动期间自动调整 的值。要显式设置每个线程的行数，请 performance_schema_events_statements_history_size 在服务器启动时设置系统变量。
该events_statements_history 表具有与 相同的列 events_statements_current。请参阅 第 25.12.6.1 节，“events_statements_current 表”。
TRUNCATE TABLE表允许events_statements_history 。它删除行。
有关三个事件表 之间关系的更多信息 ，请参阅第 25.9 节，“当前和历史事件的性能模式表”。 events_statements_xxx
有关配置是否收集语句事件的信息，请参阅 第 25.12.6 节，“性能模式语句事件表”。
25.12.6.3 events_statements_history_long 表
该 events_statements_history_long 表包含N在所有线程中全局结束的最新语句事件。语句事件在它们结束之前不会添加到表中。当表变满时，添加新行时最旧的行将被丢弃，无论哪个线程生成任一行。
的值N在服务器启动时自动调整大小。要显式设置表大小，请 performance_schema_events_statements_history_long_size 在服务器启动时设置系统变量。
该 events_statements_history_long 表具有与 相同的列 events_statements_current。请参阅 第 25.12.6.1 节，“events_statements_current 表”。
TRUNCATE TABLE表允许 events_statements_history_long 。它删除行。
有关三个事件表 之间关系的更多信息 ，请参阅第 25.9 节，“当前和历史事件的性能模式表”。 events_statements_xxx
有关配置是否收集语句事件的信息，请参阅 第 25.12.6 节，“性能模式语句事件表”。
25.12.6.4prepared_statements_instances 表
Performance Schema 为prepared statements 提供了工具，有两个协议：
- 二进制协议。这通过 MySQL C API 访问并映射到底层服务器命令，如下表所示。
| C API 函数 | 对应的服务器命令 |
|
| |
|
| |
|
|
- 文本协议。这是使用 SQL 语句访问的，并映射到底层服务器命令，如下表所示。
| SQL 语句 | 对应的服务器命令 |
|
| |
|
| |
|
|
Performance Schema 准备好的语句检测涵盖了这两种协议。以下讨论涉及服务器命令，而不是 C API 函数或 SQL 语句。
表中提供了有关准备好的语句的信息 prepared_statements_instances 。该表可以检查服务器中使用的准备好的语句，并提供有关它们的汇总统计信息。要控制此表的大小，请 performance_schema_max_prepared_statements_instances 在服务器启动时设置系统变量。
准备好的语句信息的收集取决于下表中显示的语句工具。这些仪器默认启用。要修改它们，请更新 setup_instruments表。
| 乐器 | 服务器命令 |
|
|
|
|
|
|
|
|
|
|
|
|
Performance Schema 管理 prepared_statements_instances 表的内容如下：
- 报表准备
COM_STMT_PREPAREor 命令在服务器中创建 一个SQLCOM_PREPARE准备好的语句。如果语句成功检测，则将新行添加到 prepared_statements_instances 表中。如果无法检测该语句， Performance_schema_prepared_statements_lost 则增加状态变量。
- 准备好的语句执行
为检测的预准备语句实例 执行COM_STMT_EXECUTEor 命令会更新相应的 表行。 SQLCOM_PREPAREprepared_statements_instances
- 准备好的语句解除分配
为检测的预准备语句实例 执行COM_STMT_CLOSEor 命令会删除相应的 表行。为了避免资源泄漏，即使前面描述的准备好的语句工具被禁用，也会发生删除。 SQLCOM_DEALLOCATE_PREPAREprepared_statements_instances
该prepared_statements_instances 表具有以下列：
OBJECT_INSTANCE_BEGIN
已检测的预准备语句在内存中的地址。
STATEMENT_ID
服务器分配的内部语句 ID。文本和二进制协议都使用语句 ID。
STATEMENT_NAME
对于二进制协议，此列为 NULL. 对于文本协议，此列是用户分配的外部语句名称。例如，对于下面的 SQL 语句，准备好的语句的名称是stmt：
PREPARE stmt FROM 'SELECT 1';
SQL_TEXT
准备好的语句文本，带有? 占位符标记。
OWNER_THREAD_ID,OWNER_EVENT_ID
这些列指示创建预准备语句的事件。
OWNER_OBJECT_TYPE,OWNER_OBJECT_SCHEMA,OWNER_OBJECT_NAME
对于客户端会话创建的准备好的语句，这些列是NULL. 对于存储程序创建的准备好的语句，这些列指向存储程序。一个典型的用户错误是忘记释放准备好的语句。这些列可用于查找泄漏准备好的语句的存储程序：
SELECT
OWNER_OBJECT_TYPE, OWNER_OBJECT_SCHEMA, OWNER_OBJECT_NAME, STATEMENT_NAME, SQL_TEXTFROM performance_schema.prepared_statements_instances
WHERE OWNER_OBJECT_TYPE IS NOT NULL;
TIMER_PREPARE
执行语句准备本身所花费的时间。
COUNT_REPREPARE
该语句在内部重新准备的次数（请参阅第 8.10.4 节，“准备好的语句和存储程序的缓存”）。重新准备的时间统计信息不可用，因为它被计为语句执行的一部分，而不是单独的操作。
COUNT_EXECUTE,SUM_TIMER_EXECUTE,MIN_TIMER_EXECUTE,AVG_TIMER_EXECUTE,MAX_TIMER_EXECUTE
准备好的语句执行的聚合统计信息。
SUM_xxx
其余 列与语句摘要表相同（请参阅 第 25.12.15.3 节，“语句摘要表”）。 SUM_xxx
TRUNCATE TABLE重置表的统计列 prepared_statements_instances 。
25.12.7 性能模式事务表
25.12.7.1 events_transactions_current 表
25.12.7.1 events_transactions_current 表
该events_transactions_current 表包含当前事务事件。该表为每个线程存储一行，显示线程最近监控的事务事件的当前状态，因此没有用于配置表大小的系统变量。例如：
mysql> SELECT *
FROM performance_schema.events_transactions_current LIMIT 1\G*************************** 1. row ***************************
THREAD_ID: 26
EVENT_ID: 7
END_EVENT_ID: NULL
EVENT_NAME: transaction
STATE: ACTIVE
TRX_ID: NULL
GTID: 3E11FA47-71CA-11E1-9E33-C80AA9429562:56
XID: NULL
XA_STATE: NULL
SOURCE: transaction.cc:150
TIMER_START: 420833537900000
TIMER_END: NULL
TIMER_WAIT: NULL
ACCESS_MODE: READ WRITE
ISOLATION_LEVEL: REPEATABLE READ
AUTOCOMMIT: NO
NUMBER_OF_SAVEPOINTS: 0
NUMBER_OF_ROLLBACK_TO_SAVEPOINT: 0
NUMBER_OF_RELEASE_SAVEPOINT: 0
OBJECT_INSTANCE_BEGIN: NULL
NESTING_EVENT_ID: 6
NESTING_EVENT_TYPE: STATEMENT
在包含事务事件行的表中， events_transactions_current是最基本的。包含事务事件行的其他表在逻辑上是从当前事件派生的。例如， events_transactions_history和 events_transactions_history_long 表是最近结束的事务事件的集合，分别达到每个线程和全局所有线程的最大行数。
有关三个事务事件表之间关系的更多信息，请参阅 第 25.9 节，“当前和历史事件的性能模式表”。
有关配置是否收集事务事件的信息，请参阅 第 25.12.7 节，“性能模式事务表”。
该events_transactions_current 表具有以下列：
THREAD_ID,EVENT_ID
事件启动时与事件关联的线程和线程当前事件编号。THREAD_ID和 EVENT_ID值一起唯一标识该行。 没有两行具有相同的一对值。
END_EVENT_ID
此列设置为NULL事件何时开始，并在事件结束时更新为线程当前事件编号。
EVENT_NAME
从中收集事件的工具的名称。这是表中的NAME值setup_instruments。仪器名称可能有多个部分并形成层次结构，如 第 25.6 节“性能模式仪器命名约定”中所述。
STATE
当前交易状态。该值是 ACTIVE(after START TRANSACTIONor BEGIN)、 COMMITTED(after COMMIT) 或ROLLED BACK(after ROLLBACK)。
TRX_ID
没用过。
GTID
GTID 列包含 的值 gtid_next，该值可以是ANONYMOUS、 AUTOMATIC或使用格式的 GTID 之一UUID:NUMBER。对于使用 的事务 gtid_next=AUTOMATIC（所有普通客户端事务），GTID 列会在事务提交并分配实际 GTID 时更改。如果gtid_mode 是ON或 ON_PERMISSIVE，则 GTID 列更改为事务的 GTID。如果gtid_mode 是OFF或 OFF_PERMISSIVE，则 GTID 列更改为ANONYMOUS。
XID_FORMAT_ID,XID_GTRID, 和XID_BQUAL
XA 事务标识符的元素。它们具有第 13.3.7.1 节，“XA 事务 SQL 语句”中描述的格式。
XA_STATE
XA 事务的状态。值为 ACTIVE(after XA START)、IDLE(after XA END)、PREPARED(after XA PREPARE)、ROLLED BACK(after XA ROLLBACK) 或COMMITTED (after XA COMMIT)。
events_transactions_current 在副本上，同一个 XA 事务可以在不同线程上以不同状态 出现在 表中。这是因为在 XA 事务准备好之后，它立即与复制应用程序线程分离，并且可以由副本上的任何线程提交或回滚。该 events_transactions_current 表显示线程上最近监视的事务事件的当前状态，并且在线程空闲时不更新此状态。所以 XA 交易仍然可以显示在 PREPARED原始应用程序线程的状态，在它被另一个线程处理之后。要积极识别仍处于 PREPARED状态且需要恢复的 XA 事务，请使用 XA RECOVER语句而不是 Performance Schema 事务表。
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。
有关以皮秒为单位的事件时间和影响时间值的因素的讨论，请参阅 第 25.4.1 节，“性能模式事件计时”。
ACCESS_MODE
事务访问模式。值为READ WRITE或READ ONLY。
ISOLATION_LEVEL
事务隔离级别。值为 REPEATABLE READ、 READ COMMITTED、 READ UNCOMMITTED或 SERIALIZABLE。
AUTOCOMMIT
事务开始时是否启用自动提交模式。
NUMBER_OF_SAVEPOINTS,NUMBER_OF_ROLLBACK_TO_SAVEPOINT,NUMBER_OF_RELEASE_SAVEPOINT
事务期间发出的 、 和 语句 SAVEPOINT的 ROLLBACK TO SAVEPOINT数量 。RELEASE SAVEPOINT
OBJECT_INSTANCE_BEGIN
没用过。
NESTING_EVENT_ID
EVENT_ID嵌套此事件的事件 的值。
NESTING_EVENT_TYPE
嵌套事件类型。值为 TRANSACTION、 STATEMENT、STAGE或 WAIT。（TRANSACTION 不出现，因为事务不能嵌套。）
TRUNCATE TABLE表允许events_transactions_current 。它删除行。
25.12.7.2 events_transactions_history 表
25.12.7.2 events_transactions_history 表
该events_transactions_history 表包含N每个线程已结束的最新事务事件。事务事件在结束之前不会添加到表中。当表包含给定线程的最大行数时，当为该线程添加新行时，最旧的线程行将被丢弃。当一个线程结束时，它的所有行都被丢弃。
性能模式 N在服务器启动期间自动调整 的值。要显式设置每个线程的行数，请 performance_schema_events_transactions_history_size 在服务器启动时设置系统变量。
该events_transactions_history 表具有与 相同的列 events_transactions_current。请参阅 第 25.12.7.1 节，“events_transactions_current 表”。
TRUNCATE TABLE表允许events_transactions_history 。它删除行。
有关三个事务事件表之间关系的更多信息，请参阅 第 25.9 节，“当前和历史事件的性能模式表”。
有关配置是否收集事务事件的信息，请参阅 第 25.12.7 节，“性能模式事务表”。
25.12.7.3 events_transactions_history_long 表
25.12.7.3 events_transactions_history_long 表
该 events_transactions_history_long 表包含N在所有线程中全局结束的最新事务事件。事务事件在结束之前不会添加到表中。当表变满时，添加新行时最旧的行将被丢弃，无论哪个线程生成任一行。
性能模式自动调整 的值 N在服务器启动时自动调整大小。要显式设置表大小，请 performance_schema_events_transactions_history_long_size 在服务器启动时设置系统变量。
该 events_transactions_history_long 表具有与 相同的列 events_transactions_current。请参阅 第 25.12.7.1 节，“events_transactions_current 表”。
TRUNCATE TABLE表允许 events_transactions_history_long 。它删除行。
有关三个事务事件表之间关系的更多信息，请参阅 第 25.9 节，“当前和历史事件的性能模式表”。
有关配置是否收集事务事件的信息，请参阅 第 25.12.7 节，“性能模式事务表”。
性能模式检测交易。在事件层次结构中，等待事件嵌套在阶段事件中，阶段事件嵌套在语句事件中，又嵌套在事务事件中。
这些表存储事务事件：
- events_transactions_current：每个线程的当前事务事件。
- events_transactions_history：每个线程结束的最新事务事件。
- events_transactions_history_long: 已在全球范围内结束的最新事务事件（跨所有线程）。
以下部分描述了事务事件表。还有汇总表，汇总有关事务事件的信息；请参阅 第 25.12.15.4 节，“事务汇总表”。
有关三个事务事件表之间关系的更多信息，请参阅 第 25.9 节，“当前和历史事件的性能模式表”。
要控制是否收集交易事件，请设置相关工具和消费者的状态：
- 该setup_instruments表包含一个名为 的工具
transaction。使用此工具来启用或禁用单个事务事件类的收集。 - 该setup_consumers表包含名称对应于当前和历史事务事件表名称的消费者值。使用这些消费者来过滤事务事件的集合。
默认情况下transaction禁用仪器和交易消费者：
mysql> SELECT *
FROM performance_schema.setup_instruments WHERE NAME = 'transaction';+-------------+---------+-------+
| NAME | ENABLED | TIMED |
+-------------+---------+-------+
| transaction | NO | NO |
+-------------+---------+-------+
mysql> SELECT *
FROM performance_schema.setup_consumers WHERE NAME LIKE 'events_transactions%';+----------------------------------+---------+
| NAME | ENABLED |
+----------------------------------+---------+
| events_transactions_current | NO |
| events_transactions_history | NO |
| events_transactions_history_long | NO |
+----------------------------------+---------+
要在服务器启动时控制事务事件收集，请在my.cnf文件中使用如下行：
- 使能够：
- [mysqld]
- performance-schema-instrument='transaction=ON'
- performance-schema-consumer-events-transactions-current=ON
- performance-schema-consumer-events-transactions-history=ON
performance-schema-consumer-events-transactions-history-long=ON
- 禁用：
- [mysqld]
- performance-schema-instrument='transaction=OFF'
- performance-schema-consumer-events-transactions-current=OFF
- performance-schema-consumer-events-transactions-history=OFF
performance-schema-consumer-events-transactions-history-long=OFF
To control transaction event collection at runtime, update the setup_instruments and setup_consumers tables:
- Enable:
- UPDATE
performance_schema.setup_instruments - SET
ENABLED=TIMED= - WHERE
- UPDATE
performance_schema.setup_consumers - SET
ENABLED=
WHERE NAME LIKE 'events_transactions%';
- Disable:
- UPDATE
performance_schema.setup_instruments - SET
ENABLED=TIMED= - WHERE
- UPDATE
performance_schema.setup_consumers - SET
ENABLED=
WHERE NAME LIKE 'events_transactions%';
To collect transaction events only for specific transaction event tables, enable the transaction instrument but only the transaction consumers corresponding to the desired tables.
The setup_timers table contains a row with a NAME value of transaction that indicates the unit for transaction event timing. The default unit is NANOSECOND:
mysql> SELECT *
FROM performance_schema.setup_timers WHERE NAME = 'transaction';+-------------+------------+
| NAME | TIMER_NAME |
+-------------+------------+
| transaction | NANOSECOND |
+-------------+------------+
To change the timing unit, modify the TIMER_NAME value:
UPDATE performance_schema.setup_timers
SET TIMER_NAME = 'MICROSECOND'
WHERE NAME = 'transaction';
有关配置事件收集的其他信息，请参阅第 25.3 节，“性能模式启动配置”和第 25.4 节，“性能模式运行时配置”。
在 MySQL 服务器中，事务以这些语句显式开始：
START TRANSACTION | BEGIN | XA START | XA BEGIN
事务也隐式开始。例如， autocommit启用系统变量时，每个语句的开头都会启动一个新事务。
禁用时autocommit，已提交事务之后的第一条语句标志着新事务的开始。在提交之前，后续语句是事务的一部分。
事务以这些语句显式结束：
COMMIT | ROLLBACK | XA COMMIT | XA ROLLBACK
通过执行 DDL 语句、锁定语句和服务器管理语句，事务也会隐式结束。
在以下讨论中，对 的引用 START TRANSACTION也适用于 BEGIN、 XA START和 XA BEGIN。同样，对 和 的引用 COMMIT分别 ROLLBACK适用于XA COMMIT和 XA ROLLBACK。
Performance Schema 定义了与服务器类似的事务边界。事务事件的开始和结束与服务器中相应的状态转换紧密匹配：
- 对于显式启动的事务，事务事件在 START TRANSACTION语句处理期间开始。
- 对于隐式启动的事务，事务事件从前一个事务结束后使用事务引擎的第一条语句开始。
- 对于任何事务，无论是显式结束还是隐式结束，事务事件都会在服务器在处理 COMMIT或 期间转换出活动事务状态时结束ROLLBACK。
这种方法有一些微妙的含义：
- 性能模式中的事务事件不完全包括与相应START TRANSACTION的 COMMIT、、或 ROLLBACK 语句关联的语句事件。事务事件和这些语句之间有少量的时间重叠。
- 使用非事务引擎的语句对连接的事务状态没有影响。对于隐式事务，事务事件从使用事务引擎的第一条语句开始。这意味着仅在非事务表上运行的语句将被忽略，即使在 START TRANSACTION.
为了说明，请考虑以下场景：
1. SET autocommit = OFF;2. CREATE TABLE t1 (a INT) ENGINE = InnoDB;3. START TRANSACTION; -- Transaction 1 START4. INSERT INTO t1 VALUES (1), (2), (3);5. CREATE TABLE t2 (a INT) ENGINE = MyISAM; -- Transaction 1 COMMIT -- (implicit; DDL forces commit)6. INSERT INTO t2 VALUES (1), (2), (3); -- Update nontransactional table7. UPDATE t2 SET a = a + 1; -- ... and again8. INSERT INTO t1 VALUES (4), (5), (6); -- Write to transactional table -- Transaction 2 START (implicit)9. COMMIT; -- Transaction 2 COMMIT从服务器的角度来看，事务 1 在t2创建表时结束。事务 2 在访问事务表之前不会启动，尽管对非事务表进行了干预更新。
从性能模式的角度来看，事务 2 在服务器转换为活动事务状态时启动。语句 6 和 7 不包含在 Transaction 2 的边界内，这与服务器将事务写入二进制日志的方式是一致的。
三个属性定义事务：
- 访问模式（只读、读写）
- 隔离级别（SERIALIZABLE、 REPEATABLE READ等）
- 隐式（autocommit 启用）或显式（autocommit禁用）
为了降低事务检测的复杂性并确保收集的事务数据提供完整、有意义的结果，所有事务都独立于访问模式、隔离级别或自动提交模式进行检测。
要有选择地检查事务历史，请使用事务事件表中的属性列： ACCESS_MODE、 ISOLATION_LEVEL和 AUTOCOMMIT。
可以通过各种方式降低事务检测的成本，例如根据用户、帐户、主机或线程（客户端连接）启用或禁用事务检测。
事务事件的父事件是发起事务的事件。对于显式启动的事务，这包括START TRANSACTIONand COMMIT AND CHAIN语句。对于隐式启动的事务，它是前一个事务结束后使用事务引擎的第一条语句。
通常，事务是事务期间启动的所有事件的顶级父级，包括显式结束事务的语句，例如 COMMIT和 ROLLBACK。异常是隐式结束事务的语句，例如 DDL 语句，在这种情况下，必须在执行新语句之前提交当前事务。
事务和存储的程序事件相关如下：
- 存储过程
存储过程独立于事务运行。存储过程可以在事务中启动，事务可以在存储过程中启动或结束。如果从事务中调用，存储过程可以执行强制提交父事务然后启动新事务的语句。
如果存储过程在事务中启动，则该事务是存储过程事件的父级。
如果事务由存储过程启动，则存储过程是事务事件的父级。
- 存储函数
存储函数被限制导致显式或隐式提交或回滚。存储的函数事件可以驻留在父事务事件中。
- 触发器
触发器作为访问与其关联的表的语句的一部分而激活，因此触发器事件的父级始终是激活它的语句。
触发器不能发出导致事务显式或隐式提交或回滚的语句。
- 预定活动
计划事件主体中语句的执行发生在新连接中。在父事务中嵌套计划事件不适用。
Savepoint 语句被记录为单独的语句事件。事务事件包括用于 、 和 的单独计数器 SAVEPOINT， ROLLBACK TO SAVEPOINT以及 RELEASE SAVEPOINT在事务期间发出的语句。
事务中发生的错误和警告记录在语句事件中，但不记录在相应的事务事件中。这包括特定于事务的错误和警告，例如非事务表的回滚或 GTID 一致性错误。
数据库中的表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。
- 汇总表。这些表包含聚合事件组的信息，包括那些已从历史表中丢弃的事件。
- 实例表。这些表记录了检测的对象类型。检测对象在被服务器使用时会产生一个事件。这些表提供事件名称和解释性说明或状态信息。
- 各种表。这些不属于任何其他表组。
25.12.8 性能模式连接表
25.12.8.1 账户表
该accounts表包含已连接到 MySQL 服务器的每个帐户的一行。对于每个帐户，该表计算当前连接数和总连接数。表大小在服务器启动时自动调整大小。要显式设置表大小，请 performance_schema_accounts_size 在服务器启动时设置系统变量。要禁用帐户统计信息，请将此变量设置为 0。
该accounts表具有以下列。有关 Performance Schema 如何维护此 table 中的行的描述，包括 的效果 TRUNCATE TABLE，请参阅 第 25.12.8 节，“Performance Schema Connection Tables”。
USER
连接的客户端用户名。这 NULL适用于内部线程，或用于身份验证失败的用户会话。
HOST
客户端连接的主机。这 NULL适用于内部线程，或用于身份验证失败的用户会话。
CURRENT_CONNECTIONS
帐户的当前连接数。
TOTAL_CONNECTIONS
帐户的连接总数。
25.12.8.2 主机表
该hosts表包含客户端连接到 MySQL 服务器的每个主机的一行。对于每个主机名，该表计算当前连接数和总连接数。表大小在服务器启动时自动调整大小。要显式设置表大小，请 performance_schema_hosts_size 在服务器启动时设置系统变量。要禁用主机统计信息，请将此变量设置为 0。
该hosts表具有以下列。有关 Performance Schema 如何维护此 table 中的行的描述，包括 的效果 TRUNCATE TABLE，请参阅 第 25.12.8 节，“Performance Schema Connection Tables”。
HOST
客户端连接的主机。这 NULL适用于内部线程，或用于身份验证失败的用户会话。
CURRENT_CONNECTIONS
主机的当前连接数。
TOTAL_CONNECTIONS
主机的连接总数。
25.12.8.3 用户表
该users表包含已连接到 MySQL 服务器的每个用户的一行。对于每个用户名，该表计算当前连接数和总连接数。表大小在服务器启动时自动调整大小。要显式设置表大小，请 performance_schema_users_size 在服务器启动时设置系统变量。要禁用用户统计，请将此变量设置为 0。
该users表具有以下列。有关 Performance Schema 如何维护此 table 中的行的描述，包括 的效果 TRUNCATE TABLE，请参阅 第 25.12.8 节，“Performance Schema Connection Tables”。
USER
连接的客户端用户名。这 NULL适用于内部线程，或用于身份验证失败的用户会话。
CURRENT_CONNECTIONS
用户的当前连接数。
TOTAL_CONNECTIONS
用户的连接总数。
当客户端连接到 MySQL 服务器时，它会使用特定的用户名和特定的主机进行连接。Performance Schema 提供有关这些连接的统计信息，使用这些表按帐户（用户和主机组合）以及按用户名和主机名分别跟踪它们：
连接表中“帐户”的含义与系统数据库中 MySQL 授权表中的含义相似 mysql，从某种意义上说，该术语指的是用户值和主机值的组合。它们的不同之处在于，对于授权表，帐户的主机部分可以是模式，而对于性能模式表，主机值始终是特定的非模式主机名。
每个连接表都有CURRENT_CONNECTIONS 和列来跟踪每个“跟踪值”TOTAL_CONNECTIONS的当前连接数和连接总数，其统计信息基于该“跟踪值”。这些表的不同之处在于它们用于跟踪值的内容。该 表具有 和列来跟踪每个用户和主机组合的连接。和 表有一个 和 列，分别用于跟踪每个用户名和主机名的连接。 accountsUSERHOSTusershostsUSERHOST
性能模式还计算内部线程和未能通过身份验证的用户会话的线程，使用的行 USER和HOST列值为NULL.
假设名为user1和 的客户端分别从和user2连接一次 。性能模式跟踪连接如下： hostahostb
- 该accounts表有四行，用于
user1/hosta、user1/hostb、user2/hosta和user2/hostb帐户值，每行计算每个帐户一个连接。 - 该hosts表有两行， for
hosta和hostb，每行计算每个主机名的两个连接。 - 该users表有两行， for
user1和user2，每行计算每个用户名的两个连接。
当客户端连接时，Performance Schema 使用适用于每个表的跟踪值来确定每个连接表中的哪一行适用。如果没有这样的行，则添加一个。CURRENT_CONNECTIONS然后 Performance Schema 将该行中的和 TOTAL_CONNECTIONS列 增加一 。
当客户端断开连接时，Performance SchemaCURRENT_CONNECTIONS将行中的列减一并保持该TOTAL_CONNECTIONS列不变。
TRUNCATE TABLE允许用于连接表。它有以下效果：
- 删除当前没有连接的帐户、主机或用户的行（带有 的行
CURRENT_CONNECTIONS = 0）。 - 未删除的行被重置为仅计算当前连接数：对于带有 的行
CURRENT_CONNECTIONS > 0，TOTAL_CONNECTIONS被重置为CURRENT_CONNECTIONS。 - 依赖于连接表的汇总表被隐式截断，如本节后面所述。
性能模式维护汇总表，按帐户、主机或用户汇总各种事件类型的连接统计信息。这些表的名称中有 _summary_by_account、 _summary_by_host或 _summary_by_user。要识别它们，请使用以下查询：
mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = 'performance_schema' AND TABLE_NAME REGEXP '_summary_by_(account|host|user)' ORDER BY TABLE_NAME;+------------------------------------------------------+
| TABLE_NAME |
+------------------------------------------------------+
| events_stages_summary_by_account_by_event_name |
| events_stages_summary_by_host_by_event_name |
| events_stages_summary_by_user_by_event_name |
| events_statements_summary_by_account_by_event_name |
| events_statements_summary_by_host_by_event_name |
| events_statements_summary_by_user_by_event_name |
| events_transactions_summary_by_account_by_event_name |
| events_transactions_summary_by_host_by_event_name |
| events_transactions_summary_by_user_by_event_name |
| events_waits_summary_by_account_by_event_name |
| events_waits_summary_by_host_by_event_name |
| events_waits_summary_by_user_by_event_name |
| memory_summary_by_account_by_event_name |
| memory_summary_by_host_by_event_name |
| memory_summary_by_user_by_event_name |
+------------------------------------------------------+
有关各个连接汇总表的详细信息，请参阅描述汇总事件类型表的部分：
- 等待事件摘要： 第 25.12.15.1 节，“等待事件摘要表”
- 阶段事件摘要： 第 25.12.15.2 节，“阶段摘要表”
- 语句事件摘要： 第 25.12.15.3 节，“语句摘要表”
- 事务事件摘要： 第 25.12.15.4 节，“事务摘要表”
- 内存事件摘要： 第 25.12.15.9 节，“内存摘要表”
TRUNCATE TABLE允许用于连接汇总表。它会删除没有连接的帐户、主机或用户的行，并将剩余行的摘要列重置为零。此外，每个按帐户、主机、用户或线程聚合的汇总表都会通过截断它所依赖的连接表来隐式截断。下表描述了连接表截断和隐式截断表之间的关系。
| 截断连接表 | 隐式截断汇总表 |
|
| 名称包含的表 |
|
| 名称包含 |
|
| 名称包含 |
截断_summary_global汇总表也会隐式地截断其对应的连接和线程汇总表。例如，截断 events_waits_summary_global_by_event_name 隐式截断按帐户、主机、用户或线程聚合的等待事件汇总表。
25.12.9 性能模式连接属性表
25.12.9.1 session_account_connect_attrs 表
25.12.9.1 session_account_connect_attrs 表
应用程序可以提供键值连接属性以在连接时传递给服务器。有关公共属性的描述，请参阅 第 25.12.9 节，“性能模式连接属性表”。
该session_account_connect_attrs 表仅包含当前会话以及与会话帐户关联的其他会话的连接属性。要查看所有会话的连接属性，请使用该session_connect_attrs表。
该session_account_connect_attrs 表具有以下列：
PROCESSLIST_ID
会话的连接标识符。
ATTR_NAME
属性名称。
ATTR_VALUE
属性值。
ORDINAL_POSITION
将属性添加到连接属性集中的顺序。
TRUNCATE TABLE不允许用于该 session_account_connect_attrs 表。
25.12.9.2 session_connect_attrs 表
25.12.9.2 session_connect_attrs 表
应用程序可以提供键值连接属性以在连接时传递给服务器。有关公共属性的描述，请参阅 第 25.12.9 节，“性能模式连接属性表”。
该session_connect_attrs表包含所有会话的连接属性。要仅查看当前会话以及与会话帐户关联的其他会话的连接属性，请使用该 session_account_connect_attrs 表。
该session_connect_attrs表具有以下列：
PROCESSLIST_ID
会话的连接标识符。
ATTR_NAME
属性名称。
ATTR_VALUE
属性值。
ORDINAL_POSITION
将属性添加到连接属性集中的顺序。
TRUNCATE TABLE不允许用于该session_connect_attrs 表。
连接属性是应用程序可以在连接时传递给服务器的键值对。对于基于 libmysqlclient客户端库实现的 C API 的应用程序， mysql_options()和 mysql_options4()函数定义连接属性集。其他 MySQL 连接器可能会提供自己的属性定义方法。
这些性能模式表公开属性信息：
- session_account_connect_attrs：当前会话的连接属性，以及与会话帐户关联的其他会话
- session_connect_attrs：所有会话的连接属性
以下划线 ( ) 开头的属性名称_保留供内部使用，不应由应用程序创建。该约定允许 MySQL 引入新属性而不会与应用程序属性冲突，并使应用程序能够定义自己的不与内部属性冲突的属性。
给定连接中可见的连接属性集因平台、用于建立连接的 MySQL 连接器或客户端程序等因素而异。
客户端库设置这些libmysqlclient属性：
_client_name：客户端名称（libmysql用于客户端库）。_client_version：客户端库版本。_os: 操作系统（例如Linux,Win64）。_pid: 客户端进程 ID。_platform：机器平台（例如，x86_64）。_thread：客户端线程 ID（仅限 Windows）。
其他 MySQL 连接器可以定义自己的连接属性。
MySQL Connector/J 定义了这些属性：
_client_license：连接器许可证类型。_runtime_vendor：Java 运行时环境 (JRE) 供应商。_runtime_version：Java 运行时环境 (JRE) 版本。
MySQL Connector/NET 定义了这些属性：
_client_version：客户端库版本。_os: 操作系统（例如Linux,Win64）。_pid: 客户端进程 ID。_platform：机器平台（例如，x86_64）。_program_name: 客户名称。_thread：客户端线程 ID（仅限 Windows）。
PHP 定义的属性取决于它的编译方式：
- 编译使用
libmysqlclient：标准libmysqlclient属性，如前所述。 - 编译使用
mysqlnd：仅_client_name属性，值为mysqlnd。
许多 MySQL 客户端程序设置一个program_name 属性值等于客户端名称。例如， mysqladmin和mysqldump分别 设置program_name为 mysqladmin和mysqldump。
一些 MySQL 客户端程序定义了额外的属性：
- mysqlbinlog：
_client_role:binary_log_listener
- 副本连接：
program_name:mysqld_client_role:binary_log_listener_client_replication_channel_name：频道名称。
- FEDERATED存储引擎连接：
program_name:mysqld_client_role:federated_storage
从客户端传输到服务器的连接属性数据的数量是有限制的：
- 客户端在连接时间之前施加的固定限制。
- 服务器在连接时施加的固定限制。
- 性能模式在连接时施加的可配置限制。
对于使用 C API 发起的连接， libmysqlclient库对客户端连接属性数据的聚合大小施加了 64KB 的限制：调用 mysql_options()该限制会导致超出此限制产生 CR_INVALID_PARAMETER_NO错误。其他 MySQL 连接器可能会对可以将多少连接属性数据传输到服务器施加自己的客户端限制。
在服务器端，对连接属性数据进行这些大小检查：
- 服务器对其可以接受的连接属性数据的聚合大小施加了 64KB 的限制。如果客户端尝试发送超过 64KB 的属性数据，服务器将拒绝连接。
- performance_schema_session_connect_attrs_size 对于接受的连接，性能模式会根据系统变量 的值检查聚合属性大小 。如果属性大小超过此值，则会发生以下操作：
- 性能模式截断属性数据并递增 Performance_schema_session_connect_attrs_lost 状态变量，该变量指示发生属性截断的连接数。
- log_error_verbosity 如果系统变量大于 1 ，Performance Schema 会向错误日志写入一条消息 ：
[Warning] Connection attributes of length N were truncated25.12.10 性能模式用户定义的变量表
性能模式提供了一个 user_variables_by_thread公开用户定义变量的表。这些是在特定会话中定义的变量，并@ 在名称前包含一个字符；请参阅 第 9.4 节，“用户定义的变量”。
该user_variables_by_thread表具有以下列：
THREAD_ID
定义变量的会话的线程标识符。
VARIABLE_NAME
变量名，没有前导@ 字符。
VARIABLE_VALUE
变量值。
TRUNCATE TABLE不允许用于该user_variables_by_thread 表。
25.12.11 性能模式复制表
25.12.11.1 复制连接配置表
此表显示副本用于连接到源的配置参数。存储在表中的参数可以在运行时使用 CHANGE MASTER TO语句更改，如列描述中所示。
与 replication_connection_status 表相比， replication_connection_configuration 更改频率较低。它包含定义副本如何连接到源并在连接期间保持不变的 replication_connection_status 值，而包含在连接期间更改的值。
该 replication_connection_configuration 表具有以下列。列描述指示了CHANGE MASTER TO 从中获取列值的相应选项，本节后面给出的表格显示了 replication_connection_configuration 列和SHOW SLAVE STATUS 列之间的对应关系。
CHANNEL_NAME
此行显示的复制通道。总是有一个默认的复制通道，并且可以添加更多的复制通道。有关详细信息，请参阅 第 16.2.2 节，“复制通道”。（CHANGE MASTER TO选项 FOR CHANNEL：）
HOST
副本连接到的复制源服务器。（CHANGE MASTER TO选项 MASTER_HOST：）
PORT
用于连接复制源服务器的端口。（CHANGE MASTER TO选项 MASTER_PORT：）
USER
用于连接到复制源服务器的帐户的用户名。（CHANGE MASTER TO选项MASTER_USER：）
NETWORK_INTERFACE
副本绑定到的网络接口（如果有）。（CHANGE MASTER TO选项 MASTER_BIND：）
AUTO_POSITION
1 如果正在使用自动定位；否则为 0。（CHANGE MASTER TO选项 MASTER_AUTO_POSITION：）
SSL_ALLOWED,SSL_CA_FILE,SSL_CA_PATH,SSL_CERTIFICATE,SSL_CIPHER,SSL_KEY,SSL_VERIFY_SERVER_CERTIFICATE,SSL_CRL_FILE,SSL_CRL_PATH
这些列显示副本用于连接到复制源服务器的 SSL 参数（如果有）。
SSL_ALLOWED有这些值：
-
Yes如果允许与源的 SSL 连接No如果不允许 SSL 连接到源Ignored如果允许 SSL 连接但副本未启用 SSL 支持
CHANGE MASTER TO其他 SSL 列的选项：MASTER_SSL_CA, MASTER_SSL_CAPATH, MASTER_SSL_CERT, MASTER_SSL_CIPHER, MASTER_SSL_CRL, MASTER_SSL_CRLPATH, MASTER_SSL_KEY, MASTER_SSL_VERIFY_SERVER_CERT.
CONNECTION_RETRY_INTERVAL
连接重试之间的秒数。（CHANGE MASTER TO选项 MASTER_CONNECT_RETRY：）
CONNECTION_RETRY_COUNT
在连接丢失的情况下，副本可以尝试重新连接到源的次数。（CHANGE MASTER TO选项 MASTER_RETRY_COUNT：）
HEARTBEAT_INTERVAL
副本上的复制心跳间隔，以秒为单位。（CHANGE MASTER TO选项 MASTER_HEARTBEAT_PERIOD：）
TLS_VERSION
源上使用的 TLS 版本。有关 TLS 版本信息，请参阅 第 6.3.2 节，“加密连接 TLS 协议和密码”。（CHANGE MASTER TO选项 MASTER_TLS_VERSION：）
此列是在 MySQL 5.7.10 中添加的。
TRUNCATE TABLE不允许用于该 replication_connection_configuration 表。
下表显示了 replication_connection_configuration 列和SHOW SLAVE STATUS 列之间的对应关系。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 没有任何 |
|
|
|
25.12.11.2 复制连接状态表
相比 replication_connection_configuration 表， replication_connection_status 变化更频繁。它包含在连接期间更改的值，而 replication_connection_configuration 包含定义副本如何连接到源并且在连接期间保持不变的值。
该replication_connection_status 表具有以下列：
CHANNEL_NAME
此行显示的复制通道。总是有一个默认的复制通道，并且可以添加更多的复制通道。有关详细信息，请参阅 第 16.2.2 节，“复制通道”。
GROUP_NAME
如果此服务器是某个组的成员，则显示该服务器所属的组的名称。
SOURCE_UUID
server_uuid来自源 的价值。
THREAD_ID
I/O 线程 ID。
SERVICE_STATE
ON（线程存在并且处于活动或空闲状态），OFF（线程不再存在），或CONNECTING（线程存在并且正在连接到源）。
RECEIVED_TRANSACTION_SET
与此副本接收的所有事务相对应的全局事务 ID (GTID) 集。如果 GTID 未使用，则为空。有关更多信息，请参阅 GTID 集。
LAST_ERROR_NUMBER,LAST_ERROR_MESSAGE
导致 I/O 线程停止的最新错误的错误编号和错误消息。错误号 0 和空字符串的消息表示“没有错误。”如果该 LAST_ERROR_MESSAGE值不为空，则错误值也会出现在副本的错误日志中。
发布RESET MASTER或 RESET SLAVE重置这些列中显示的值。
LAST_ERROR_TIMESTAMP
YYMMDD hh:mm:ss 显示最近一次 I/O 错误发生 时间的时间戳格式。
LAST_HEARTBEAT_TIMESTAMP
格式的时间戳YYMMDD hh:mm:ss ，显示副本何时收到最新的心跳信号。
COUNT_RECEIVED_HEARTBEATS
自上次重新启动或重置或发出CHANGE MASTER TO语句以来，副本收到的心跳信号总数。
TRUNCATE TABLE不允许用于该 replication_connection_status 表。
下表显示了 replication_connection_status 列和SHOW SLAVE STATUS 列之间的对应关系。
|
|
|
|
|
|
|
| 没有任何 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
25.12.11.3 复制应用程序配置表
此表显示了影响副本应用的事务的配置参数。存储在表中的参数可以在运行时使用 CHANGE MASTER TO语句更改，如列描述中所示。
该 replication_applier_configuration 表具有以下列：
CHANNEL_NAME
此行显示的复制通道。总是有一个默认的复制通道，并且可以添加更多的复制通道。有关详细信息，请参阅 第 16.2.2 节，“复制通道”。
DESIRED_DELAY
副本必须落后于源的秒数。（CHANGE MASTER TO选项 MASTER_DELAY：）
TRUNCATE TABLE不允许用于该 replication_applier_configuration 表。
下表显示了 replication_applier_configuration 列和SHOW SLAVE STATUS列之间的对应关系。
|
|
|
|
|
|
25.12.11.4 复制应用程序状态表
此表显示副本上当前的一般事务执行状态。该表提供了有关事务应用程序状态的一般方面的信息，这些信息并不特定于所涉及的任何线程。表中提供了线程特定的状态信息 replication_applier_status_by_coordinator （ replication_applier_status_by_worker 如果副本是多线程的）。
该replication_applier_status 表具有以下列：
CHANNEL_NAME
此行显示的复制通道。总是有一个默认的复制通道，并且可以添加更多的复制通道。有关详细信息，请参阅 第 16.2.2 节，“复制通道”。
SERVICE_STATE
显示ON复制通道的应用程序线程何时处于活动或空闲状态，OFF 表示应用程序线程未处于活动状态。
REMAINING_DELAY
如果副本在源应用事件后等待 DESIRED_DELAY秒数过去，则此字段包含剩余的延迟秒数。在其他时候，这个字段是 NULL。（ DESIRED_DELAY值存储在 replication_applier_configuration 表中。）
COUNT_TRANSACTIONS_RETRIES
显示由于复制 SQL 线程未能应用事务而进行的重试次数。给定事务的最大重试次数由 slave_transaction_retries 系统变量设置。
TRUNCATE TABLE不允许用于该 replication_applier_status表。
下表显示了 replication_applier_status 列和SHOW SLAVE STATUS 列之间的对应关系。
|
|
|
|
| 没有任何 |
|
|
|
25.12.11.5 replication_applier_status_by_coordinator 表
25.12.11.5 replication_applier_status_by_coordinator 表
对于多线程副本，副本使用多个工作线程和一个协调线程来管理它们，该表显示了协调线程的状态。对于单线程副本，此表为空。对于多线程副本，该 replication_applier_status_by_worker 表显示工作线程的状态。
该 replication_applier_status_by_coordinator 表具有以下列：
CHANNEL_NAME
此行显示的复制通道。总是有一个默认的复制通道，并且可以添加更多的复制通道。有关详细信息，请参阅 第 16.2.2 节，“复制通道”。
THREAD_ID
SQL/协调器线程 ID。
SERVICE_STATE
ON（线程存在并且处于活动或空闲状态）或OFF（线程不再存在）。
LAST_ERROR_NUMBER,LAST_ERROR_MESSAGE
导致 SQL/协调器线程停止的最新错误的错误号和错误消息。错误号 0 和空字符串消息表示“没有错误”。如果该 LAST_ERROR_MESSAGE值不为空，则错误值也会出现在副本的错误日志中。
发布RESET MASTER或 RESET SLAVE重置这些列中显示的值。
LAST_ERROR_NUMBER和 列 中显示的所有错误代码和消息 LAST_ERROR_MESSAGE对应于 服务器错误消息参考中列出的错误值。
LAST_ERROR_TIMESTAMP
YYMMDD hh:mm:ss 显示最近一次 SQL/协调器错误发生 时间的时间戳格式。
TRUNCATE TABLE不允许用于该 replication_applier_status_by_coordinator 表。
下表显示了 replication_applier_status_by_coordinator 列和SHOW SLAVE STATUS 列之间的对应关系。
|
|
|
|
| 没有任何 |
|
|
|
|
|
|
|
|
|
|
|
|
25.12.11.6 replication_applier_status_by_worker 表
25.12.11.6 replication_applier_status_by_worker 表
如果副本不是多线程的，则此表显示应用程序线程的状态。否则，副本使用多个工作线程和一个协调线程来管理它们，并且该表显示了工作线程的状态。对于多线程副本，该 replication_applier_status_by_coordinator 表显示协调线程的状态。
该replication_applier_status_by_worker 表具有以下列：
CHANNEL_NAME
此行显示的复制通道。总是有一个默认的复制通道，并且可以添加更多的复制通道。有关详细信息，请参阅 第 16.2.2 节，“复制通道”。
WORKER_ID
id工作人员标识符（与表中的列 值相同 mysql.slave_worker_info）。之后 STOP SLAVE， THREAD_ID列变为 NULL，但 WORKER_ID值被保留。
THREAD_ID
工作线程标识符。
SERVICE_STATE
ON（线程存在并且处于活动或空闲状态）或OFF（线程不再存在）。
LAST_SEEN_TRANSACTION
工作人员最后一次看到的事务。工作人员不一定应用此事务，因为它可能仍在执行此操作的过程中。
如果gtid_mode系统变量值为OFF，则此 ANONYMOUS列为 ，表示事务没有全局事务标识符（GTID），仅由文件和位置标识。
如果gtid_mode是 ON，列值定义如下：
-
- SELECT
LAST_SEEN_TRANSACTION,
- SELECT
FROM performance_schema.replication_applier_status_by_worker;
如果语句返回零，则事务尚未提交，或者因为它仍在处理中，或者因为在处理它时工作线程已停止。如果语句返回非零，则事务已提交。
LAST_ERROR_NUMBER,LAST_ERROR_MESSAGE
导致工作线程停止的最新错误的错误编号和错误消息。错误编号 0 和空字符串消息表示“没有错误”。如果该 LAST_ERROR_MESSAGE值不为空，则错误值也会出现在副本的错误日志中。
发布RESET MASTER或 RESET SLAVE重置这些列中显示的值。
LAST_ERROR_NUMBER和 列 中显示的所有错误代码和消息 LAST_ERROR_MESSAGE对应于 服务器错误消息参考中列出的错误值。
LAST_ERROR_TIMESTAMP
格式的时间戳YYMMDD hh:mm:ss ，显示最近的工作人员错误发生的时间。
TRUNCATE TABLE不允许用于该 replication_applier_status_by_worker 表。
下表显示了 replication_applier_status_by_worker 列和SHOW SLAVE STATUS 列之间的对应关系。
|
|
|
|
| 没有任何 |
|
| 没有任何 |
|
| 没有任何 |
|
| 没有任何 |
|
|
|
|
|
|
|
|
|
25.12.11.7 复制组成员表
此表显示复制组成员的网络和状态信息。显示的网络地址是用于将客户端连接到组的地址，不应与 指定的成员的内部组通信地址混淆 group_replication_local_address。
该replication_group_members表具有以下列：
CHANNEL_NAME
组复制通道的名称。
MEMBER_ID
该成员的标识符；与服务器 UUID 相同。
MEMBER_HOST
该成员的网络地址（主机名或 IP 地址）。从成员的 hostname变量中检索。
MEMBER_PORT
服务器正在侦听的端口。从成员的port变量中检索。
MEMBER_STATE
该成员的当前状态；可以是以下任何一项：
-
OFFLINE: Group Replication 插件已安装但尚未启动。RECOVERING：服务器已加入一个正在从中检索数据的组。ONLINE: 会员处于完全运作状态。ERROR：成员在应用事务期间或在恢复阶段遇到错误，并且未参与组的事务。UNREACHABLE：故障检测过程怀疑无法联系到该成员，因为群组消息已超时。
TRUNCATE TABLE不允许用于该replication_group_members 表。
25.12.11.8 replication_group_member_stats 表
25.12.11.8 replication_group_member_stats 表
此表显示 MySQL 组复制成员的统计信息。它仅在组复制运行时填充。
该replication_group_member_stats表具有以下列：
CHANNEL_NAME
组复制通道的名称。
VIEW_ID
该组的当前视图标识符。
MEMBER_ID
成员服务器 UUID。这对组中的每个成员都有不同的值。这也可以用作密钥，因为它对每个成员都是唯一的。
COUNT_TRANSACTIONS_IN_QUEUE
队列中等待冲突检测检查的事务数。一旦检查了事务是否存在冲突，如果它们通过了检查，它们也会排队等待应用。
COUNT_TRANSACTIONS_CHECKED
已检查冲突的事务数。
COUNT_CONFLICTS_DETECTED
未通过冲突检测检查的事务数。
COUNT_TRANSACTIONS_ROWS_VALIDATING
可用于认证但尚未被垃圾回收的事务行数。可以认为是冲突检测数据库的当前大小，每个事务都根据该数据库进行认证。
TRANSACTIONS_COMMITTED_ALL_MEMBERS
已在复制组的所有成员上成功提交的事务，显示为 GTID Sets。这以固定的时间间隔更新。
LAST_CONFLICT_FREE_TRANSACTION
检查的最后一个无冲突事务的事务标识符。
TRUNCATE TABLE不允许用于该 replication_group_member_stats 表。
性能模式提供了公开复制信息的表。这类似于从SHOW SLAVE STATUS语句中获得的信息，但表格形式的表示更易于访问并且具有可用性优势：
- SHOW SLAVE STATUS输出对于目视检查很有用，但对于编程使用却没有那么多。相比之下，使用 Performance Schema 表，可以使用一般SELECT查询来搜索有关副本状态的信息，包括复杂
WHERE条件、连接等。 - 查询结果可以保存在表中以供进一步分析，或分配给变量，从而在存储过程中使用。
- 复制表提供更好的诊断信息。对于多线程副本操作， 使用and 字段SHOW SLAVE STATUS报告所有协调器和工作线程错误 ，因此只有最近的这些错误是可见的并且信息可能会丢失。复制表在每个线程的基础上存储错误，而不会丢失信息。
Last_SQL_ErrnoLast_SQL_Error - 最后一次看到的事务在每个工作人员的复制表中是可见的。这是无法从 获得的信息SHOW SLAVE STATUS。
- 熟悉 Performance Schema 接口的开发人员可以通过向表中添加行来扩展复制表以提供附加信息。
Performance Schema 提供了以下与复制相关的表：
- 包含有关副本连接到复制源服务器的信息的表：
- replication_connection_configuration: 连接源的配置参数
- replication_connection_status：与源的连接的当前状态
- 包含有关事务应用程序的一般（非线程特定）信息的表：
- replication_applier_configuration：副本上的事务应用程序的配置参数。
- replication_applier_status：副本上的事务应用程序的当前状态。
- 包含有关负责应用从源接收的事务的特定线程的信息的表：
- replication_applier_status_by_coordinator：协调线程的状态（除非副本是多线程的，否则为空）。
- replication_applier_status_by_worker：如果副本是多线程的，则应用程序线程或工作线程的状态。
- 包含有关复制组成员信息的表：
- replication_group_members：为组成员提供网络和状态信息。
- replication_group_member_stats：提供有关组成员和他们参与的交易的统计信息。
以下部分更详细地描述了每个复制表，包括生成的SHOW SLAVE STATUS列与出现相同信息的复制表列之间的对应关系。
复制表介绍的其余部分描述了性能模式如何填充它们以及SHOW SLAVE STATUS表中未表示哪些字段。
性能模式按如下方式填充复制表：
- 在执行之前CHANGE MASTER TO，表是空的。
- 之后CHANGE MASTER TO，可以在表格中看到配置参数。此时，没有活动的副本线程，所以
THREAD_ID列是NULL，SERVICE_STATE列的值为OFF。 - 之后， 可以看到START SLAVE非值。
NULLTHREAD_ID空闲或活动线程的SERVICE_STATE值为ON。连接到源的线程的值是CONNECTINGwhile 它建立连接，ON此后只要连接持续。 - 之后STOP SLAVE，
THREAD_ID列变为NULL并且SERVICE_STATE不再存在的线程的列的值为OFF。 - 表在STOP SLAVE或线程因错误而死后被保留。
- replication_applier_status_by_worker 仅当副本在多线程模式下运行时， 该 表才为非空。即如果 slave_parallel_workers 系统变量大于0，START SLAVE则执行时填充此表，行数显示worker数。
SHOW SLAVE STATUS不在复制表中的信息
性能模式复制表中的信息与可用信息有所不同， SHOW SLAVE STATUS因为这些表面向使用全局事务标识符 (GTID)，而不是文件名和位置，并且它们代表服务器 UUID 值，而不是服务器 ID 值。由于这些差异，一些SHOW SLAVE STATUS列没有保留在 Performance Schema 复制表中，或者以不同的方式表示：
- 以下字段是指文件名和位置，不会保留：
Master_Log_FileRead_Master_Log_PosRelay_Log_FileRelay_Log_PosRelay_Master_Log_FileExec_Master_Log_PosUntil_ConditionUntil_Log_File
Until_Log_Pos- 该
Master_Info_File字段未保留。它指的是master.info已被崩溃安全表取代的文件。 - 以下字段基于 server_id、 not server_uuid且不保留：
Master_Server_Id
Replicate_Ignore_Server_Ids- 该
Skip_Counter字段基于事件计数，而不是 GTID，并且不保留。 - 这些错误字段是 and 的别名
Last_SQL_Errno，Last_SQL_Error因此它们不会被保留：
Last_Errno
Last_Error在性能模式中，此错误信息在表的LAST_ERROR_NUMBER和 LAST_ERROR_MESSAGE列中 可用replication_applier_status_by_worker （ replication_applier_status_by_coordinator 如果副本是多线程的）。这些表提供了比 和 更具体的每线程错误 Last_Errno信息 Last_Error。
- 不保留提供有关命令行过滤选项信息的字段：
Replicate_Do_DBReplicate_Ignore_DBReplicate_Do_TableReplicate_Ignore_TableReplicate_Wild_Do_Table
Replicate_Wild_Ignore_Table- 和字段
Slave_IO_State不Slave_SQL_Running_State保留。THREAD_ID如果需要，可以通过使用适当的复制表的列并将其与表中的ID列 连接INFORMATION_SCHEMAPROCESSLIST以选择后一个表的 列，从进程列表中获取这些值STATE。 - 该
Executed_Gtid_Set字段可以显示包含大量文本的大型集合。相反，Performance Schema 表显示副本当前正在应用的事务的 GTID。或者，可以从gtid_executed系统变量的值中获取执行的 GTID 集。 - 和字段处于待定状态，不保留
Seconds_Behind_Master。Relay_Log_Space
从 MySQL 版本 5.7.5 开始，以下状态变量（以前使用 监控SHOW STATUS）已移至性能模式复制表：
- Slave_retried_transactions
- Slave_last_heartbeat
- Slave_received_heartbeats
- Slave_heartbeat_period
- Slave_running
这些状态变量现在仅在使用单个复制通道时才相关，因为它们 仅报告默认复制通道的状态。当存在多个复制通道时，请使用本节中描述的性能模式复制表，该表报告每个现有复制通道的这些变量。
复制性能模式表的第一列是 CHANNEL_NAME。这使得可以按复制通道查看表。在非多源复制设置中，有一个默认复制通道。当您在副本上使用多个复制通道时，您可以过滤每个复制通道的表以监控特定的复制通道。有关更多信息，请参阅第 16.2.2 节，“复制通道” 和第 16.1.5.8 节，“多源复制监控”。
344
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
