性能模式提供了一种在运行时检查服务器内部执行的方法。它是使用 PERFORMANCE_SCHEMA 存储引擎和 performance_schema 数据库实现的。性能模式主要关注性能数据。这与 INFORMATION_SCHEMA 用于检查元数据的不同。
性能模式监视服务器事件。一个 “ 事件 ” 是什么，该服务器确实需要时间和被装备，使定时信息可以收集。通常，事件可以是函数调用，等待操作系统，SQL语句执行的阶段（例如解析或排序），或整个语句或语句组。事件集合提供对服务器和多个存储引擎的同步调用（例如互斥锁）文件和表I / O，表锁等信息的访问。
性能模式事件与写入服务器的二进制日志（描述数据修改）和事件调度程序事件（这是一种存储程序）的事件不同。
性能模式事件特定于MySQL服务器的给定实例。性能模式表被视为服务器的本地表，对它们的更改不会复制或写入二进制日志。
可以获得当前事件，以及事件历史和摘要。这使您可以确定已执行的已检测活动的次数以及执行的时间。事件信息可用于显示特定线程的活动，或与特定对象（如互斥锁或文件）关联的活动。
该 PERFORMANCE_SCHEMA 存储引擎使用收集事件数据 “ 检测点 ” 在服务器的源代码。
收集的事件存储在 performance_schema 数据库的表中。可以使用 SELECT 其他表之类的语句查询这些表。
可以 performance_schema 通过SQL语句更新数据库中的表来动态修改性能模式配置。配置更改会立即影响数据收集。
性能模式中的表是内存表，不使用持久性磁盘存储。从服务器启动开始重新填充内容，并在服务器关闭时丢弃。
监控可在MySQL支持的所有平台上使用。

可能存在一些限制：计时器的类型可能因平台而异。适用于存储引擎的仪器可能未针对所有存储引擎实施。每个第三方引擎的仪表是引擎维护者的责任。另见第C.8节“性能模式的限制” 。
通过修改服务器源代码来添加检测来实现数据收集。与其他功能（如复制或事件计划程序）不同，没有与Performance Schema关联的单独线程。

性能模式旨在提供对服务器执行的有用信息的访问，同时对服务器性能的影响最小。实现遵循以下设计目标：

激活性能模式不会导致服务器行为发生任何变化。例如，它不会导致线程调度发生更改，并且不会导致查询执行计划（如图所示 EXPLAIN ）发生更改。
服务器监控连续且不显眼地发生，只需很少的开销。激活性能架构不会使服务器无法使用。
解析器没有变化。没有新的关键字或陈述。
即使性能模式在内部失败，服务器代码的执行也会正常进行。
当在最初的事件收集期间或之后的事件检索期间执行处理之间存在选择时，优先考虑使收集更快。这是因为收集正在进行，而检索是按需进行的，可能永远不会发生。
大多数性能模式表都有索引，这使得优化器可以访问除全表扫描之外的执行计划。有关更多信息，请参见第8.2.4节“优化性能架构查询” 。
添加新的仪器点很容易。
仪表是版本化的。如果检测实现发生更改，则先前已检测的代码将继续工作。这有利于第三方插件的开发人员，因为没有必要升级每个插件以与最新的性能模式更改保持同步。

注意

MySQL sys 模式是一组对象，可以方便地访问性能模式收集的数据。该 sys 模式是默认安装的。有关使用说明，请参见第27章， MySQL sys Schema 。

26.1性能架构快速入门

本节简要介绍了性能模式，并提供了说明如何使用它的示例。有关其他示例，请参见第26.19节“使用性能模式诊断问题” 。

默认情况下启用性能架构。要显式启用或禁用它，请在 performance_schema 变量设置为适当值的情况下启动服务器。例如，在服务器 my.cnf 文件中使用以下行：

的[mysqld]
performance_schema = ON

当服务器启动时，它会看到 performance_schema 并尝试初始化性能模式。要验证成功初始化，请使用以下语句：

MySQL的> SHOW VARIABLES LIKE 'performance_schema';
+ -------------------- + ------- +
| Variable_name | 价值|
+ -------------------- + ------- +
| performance_schema | ON |
+ -------------------- + ------- +

值 ON 表示性能模式已成功初始化并可供使用。值 OFF 表示发生了一些错误。检查服务器错误日志以获取有关错误的信息。

性能模式是作为存储引擎实现的，因此您将在 INFORMATION_SCHEMA.ENGINES 表或 SHOW ENGINES 语句的输出中看到它：

MySQL的> SELECT * FROM INFORMATION_SCHEMA.ENGINES
       WHERE ENGINE='PERFORMANCE_SCHEMA'\G
*************************** 1。排******************** *******
      ENGINE：PERFORMANCE_SCHEMA
     支持：是的
     评论：性能模式
交易：没有
          XA：没有
  SAVEPOINTS：没有

MySQL的> SHOW ENGINES\G
...
      引擎：PERFORMANCE_SCHEMA
     支持：是的
     评论：性能架构
交易：NO
          XA：没有
  保存点：没有
...

在 PERFORMANCE_SCHEMA 存储引擎上的表进行操作 performance_schema 数据库。您可以创建 performance_schema 默认数据库，以便不需要使用数据库名称限定对其表的引用：

MySQL的> USE performance_schema;

性能模式表存储在 performance_schema 数据库中。通过从 INFORMATION_SCHEMA 数据库中选择或使用 SHOW 语句，可以获得有关此数据库及其表的结构的信息，就像任何其他数据库一样。例如，使用以下任一语句来查看存在哪些Performance Schema表：

MySQL的> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
       WHERE TABLE_SCHEMA = 'performance_schema';
+ ------------------------------------------------- ----- +
| TABLE_NAME |
+ ------------------------------------------------- ----- +
| 帐户|
| cond_instances |
...
| 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_history |
| events_statements_history_long |
...
| file_instances |
| file_summary_by_event_name |
| file_summary_by_instance |
| host_cache |
| 主持人|
| 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 |
| objects_summary_global_by_type |
| performance_timers |
| replication_connection_configuration |
| replication_connection_status |
| replication_applier_configuration |
| replication_applier_status |
| replication_applier_status_by_coordinator |
| replication_applier_status_by_worker |
| rwlock_instances |
| session_account_connect_attrs |
| session_connect_attrs |
| setup_actors |
| setup_consumers |
| setup_instruments |
| setup_objects |
| socket_instances |
| socket_summary_by_event_name |
| socket_summary_by_instance |
| table_handles |
| table_io_waits_summary_by_index_usage |
| table_io_waits_summary_by_table |
| table_lock_waits_summary_by_table |
| 线程|
| 用户|
+ ------------------------------------------------- ----- +

MySQL的> SHOW TABLES FROM performance_schema;
+ ------------------------------------------------- ----- +
| Tables_in_performance_schema |
+ ------------------------------------------------- ----- +
| 帐户|
| cond_instances |
| events_stages_current |
| events_stages_history |
| events_stages_history_long |
...

随着附加检测的实现的进行，性能模式表的数量随着时间的推移而增加。

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

要查看各个表的结构，请使用 SHOW CREATE TABLE ：

MySQL的> SHOW CREATE TABLE performance_schema.setup_consumers\G
*************************** 1。排******************** *******
       表：setup_consumers
创建表：CREATE TABLE`setup_consumers`（
  `NAME` varchar（64）NOT NULL，
  `ENABLED`枚举（'YES'，'NO'）NOT NULL，
  主键（`NAME`）
）ENGINE = PERFORMANCE_SCHEMA DEFAULT CHARSET = utf8mb4 COLLATE = utf8mb4_0900_ai_ci

表结构也可以从表中选择，例如 INFORMATION_SCHEMA.COLUMNS 使用或使用语句 SHOW COLUMNS 。

performance_schema 数据库中的表可以根据其中的信息类型进行分组：当前事件，事件历史和摘要，对象实例和设置（配置）信息。以下示例说明了这些表的一些用法。有关每个组中表的详细信息，请参见第26.12节“性能架构表描述” 。

最初，并非所有仪器和消费者都已启用，因此性能模式不会收集所有事件。要打开所有这些并启用事件计时，请执行两个语句（行计数可能因MySQL版本而异）：

MySQL的> UPDATE performance_schema.setup_instruments
       SET ENABLED = 'YES', TIMED = 'YES';
查询OK，560行受影响（0.04秒）
MySQL的> UPDATE performance_schema.setup_consumers
       SET ENABLED = 'YES';
查询OK，10行受影响（0.00秒）

要查看服务器当前正在执行的操作，请检查该 events_waits_current 表。它每个线程包含一行，显示每个线程最近监视的事件：

MySQL的> SELECT *
       FROM performance_schema.events_waits_current\G
*************************** 1。排******************** *******
            THREAD_ID：0
             EVENT_ID：5523
         END_EVENT_ID：5523
           EVENT_NAME：wait / synch / mutex / mysys / THR_LOCK :: mutex
               消息来源：thr_lock.c：525
          TIMER_START：201660494489586
            TIMER_END：201660494576112
           TIMER_WAIT：86526
                SPINS：NULL
        OBJECT_SCHEMA：NULL
          OBJECT_NAME：NULL
           INDEX_NAME：NULL
          OBJECT_TYPE：NULL
OBJECT_INSTANCE_BEGIN：142270668
     NESTING_EVENT_ID：NULL
   NESTING_EVENT_TYPE：NULL
            操作：锁定
      NUMBER_OF_BYTES：空
                标志：0
...

此事件表示线程0正在等待86,526皮秒来获取锁定 THR_LOCK::mutex ，即 mysys 子系统中的互斥锁。前几列提供以下信息：

ID列指示事件来自哪个线程以及事件编号。
EVENT_NAME 指示已检测的内容并 SOURCE 指示哪个源文件包含已检测的代码。
计时器列显示事件开始和停止的时间以及花费的时间。如果一个事件仍在进行中，在 TIMER_END 和 TIMER_WAIT 值 NULL 。定时器值是近似值，以皮秒表示。有关定时器和事件时间收集的信息，请参见第26.4.1节“性能模式事件定时” 。

历史记录表包含与当前事件表相同的行，但是有更多行并显示服务器 “ 最近 ” 而不是 “ 当前 ” 正在执行的操作。 ” 在 events_waits_history 和 events_waits_history_long 表分别包含每线程最近的10个事件和最近10,000个事件。例如，要查看线程13生成的最近事件的信息，请执行以下操作：

MySQL的> SELECT EVENT_ID, EVENT_NAME, TIMER_WAIT
       FROM performance_schema.events_waits_history
       WHERE THREAD_ID = 13
       ORDER BY EVENT_ID;
+ ---------- + -------------------------------------- --- + ------------ +
| EVENT_ID | EVENT_NAME | TIMER_WAIT |
+ ---------- + -------------------------------------- --- + ------------ +
| 86 | wait / synch / mutex / mysys / THR_LOCK :: mutex | 686322 |
| 87 | wait / synch / mutex / mysys / THR_LOCK_malloc | 320535 |
| 88 | wait / synch / mutex / mysys / THR_LOCK_malloc | 339390 |
| 89 | wait / synch / mutex / mysys / THR_LOCK_malloc | 377100 |
| 90 | wait / synch / mutex / sql / LOCK_plugin | 614673 |
| 91 | wait / synch / mutex / sql / LOCK_open | 659925 |
| 92 | wait / synch / mutex / sql / THD :: LOCK_thd_data | 494001 |
| 93 | wait / synch / mutex / mysys / THR_LOCK_malloc | 222489 |
| 94 | wait / synch / mutex / mysys / THR_LOCK_malloc | 214947 |
| 95 | wait / synch / mutex / mysys / LOCK_alarm | 312993 |
+ ---------- + -------------------------------------- --- + ------------ +

当新事件添加到历史记录表时，如果表已满，则会丢弃旧事件。

摘要表提供了一段时间内所有事件的汇总信息。该组中的表以不同方式汇总事件数据。要查看哪些工具执行次数最多或者等待时间最长，请 events_waits_summary_global_by_event_name 对 COUNT_STAR or或 SUM_TIMER_WAIT 列上的表进行排序，这些表分别对应于所有事件计算的 a COUNT(*) 或 SUM(TIMER_WAIT) 值：

MySQL的> SELECT EVENT_NAME, COUNT_STAR
       FROM performance_schema.events_waits_summary_global_by_event_name
       ORDER BY COUNT_STAR DESC LIMIT 10;
+ ------------------------------------------------- -  + ------------ +
| EVENT_NAME | COUNT_STAR |
+ ------------------------------------------------- -  + ------------ +
| wait / synch / mutex / mysys / THR_LOCK_malloc | 6419 |
| wait / io / file / sql / FRM | 452 |
| wait / synch / mutex / sql / LOCK_plugin | 337 |
| wait / synch / mutex / mysys / THR_LOCK_open | 187 |
| wait / synch / mutex / mysys / LOCK_alarm | 147 |
| wait / synch / mutex / sql / THD :: LOCK_thd_data | 115 |
| wait / io / file / myisam / kfile | 102 |
| wait / synch / mutex / sql / LOCK_global_system_variables | 89 |
| wait / synch / mutex / mysys / THR_LOCK :: mutex | 89 |
| wait / synch / mutex / sql / LOCK_open | 88 |
+ ------------------------------------------------- -  + ------------ +

MySQL的> SELECT EVENT_NAME, SUM_TIMER_WAIT
       FROM performance_schema.events_waits_summary_global_by_event_name
       ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;
+ ---------------------------------------- + -------- -------- +
| EVENT_NAME | SUM_TIMER_WAIT |
+ ---------------------------------------- + -------- -------- +
| wait / io / file / sql / MYSQL_LOG | 1599816582 |
| wait / synch / mutex / mysys / THR_LOCK_malloc | 1530083250 |
| wait / io / file / sql / binlog_index | 1385291934 |
| wait / io / file / sql / FRM | 1292823243 |
| wait / io / file / myisam / kfile | 411193611 |
| wait / io / file / myisam / dfile | 322401645 |
| wait / synch / mutex / mysys / LOCK_alarm | 145126935 |
| wait / io / file / sql / casetest | 104324715 |
| wait / synch / mutex / sql / LOCK_plugin | 86027823 |
| wait / io / file / sql / pid | 72591750 |
+ ---------------------------------------- + -------- -------- +

这些结果表明， THR_LOCK_malloc 互斥体 “ 热 ” ，无论是使用频率还是线程等待尝试获取它的时间。

注意

该 THR_LOCK_malloc 互斥仅用于调试版本。在生产构建中，它并不热，因为它不存在。

实例表记录了检测的对象类型。当由服务器使用时，检测对象产生事件。这些表提供事件名称和解释性说明或状态信息。例如，该 file_instances 表列出了文件I / O操作及其相关文件的工具实例：

MySQL的> SELECT *
       FROM performance_schema.file_instances\G
*************************** 1。排******************** *******
 FILE_NAME：/opt/mysql-log/60500/binlog.000007
EVENT_NAME：wait / io / file / sql / binlog
OPEN_COUNT：0
*************************** 2.排******************** *******
 FILE_NAME：/opt/mysql/60500/data/mysql/tables_priv.MYI
EVENT_NAME：wait / io / file / myisam / kfile
OPEN_COUNT：1
*************************** 3。排******************** *******
 FILE_NAME：/opt/mysql/60500/data/mysql/columns_priv.MYI
EVENT_NAME：wait / io / file / myisam / kfile
OPEN_COUNT：1
...

设置表用于配置和显示监视特征。例如， setup_instruments 列出可以收集事件的工具集，并显示哪些工具已启用：

MySQL的> SELECT NAME, ENABLED, TIMED
       FROM performance_schema.setup_instruments;
+ ------------------------------------------------- -  + --------- + ------- +
| NAME | 启用| 定时|
+ ------------------------------------------------- -  + --------- + ------- +
...
| stage / sql / end | 没有| 没有|
| stage / sql / execution | 没有| 没有|
| stage / sql / init | 没有| 没有|
| stage / sql / insert | 没有| 没有|
...
| statement / sql / load | 是的| 是的|
| statement / sql / grant | 是的| 是的|
| statement / sql / check | 是的| 是的|
| statement / sql / flush | 是的| 是的|
...
| wait / synch / mutex / sql / LOCK_global_read_lock | 是的| 是的|
| wait / synch / mutex / sql / LOCK_global_system_variables | 是的| 是的|
| wait / synch / mutex / sql / LOCK_lock_db | 是的| 是的|
| wait / synch / mutex / sql / LOCK_manager | 是的| 是的|
...
| wait / synch / rwlock / sql / LOCK_grant | 是的| 是的|
| wait / synch / rwlock / sql / LOGGER :: LOCK_logger | 是的| 是的|
| wait / synch / rwlock / sql / LOCK_sys_init_connect | 是的| 是的|
| wait / synch / rwlock / sql / LOCK_sys_init_slave | 是的| 是的|
...
| wait / io / file / sql / binlog | 是的| 是的|
| wait / io / file / sql / binlog_index | 是的| 是的|
| wait / io / file / sql / casetest | 是的| 是的|
| wait / io / file / sql / dbopt | 是的| 是的|
...

要了解如何解释仪器名称，请参见第26.6节“性能架构仪器命名约定” 。

要控制是否为仪器收集事件，请将其 ENABLED 值设置为 YES 或 NO 。例如：

MySQL的> UPDATE performance_schema.setup_instruments
       SET ENABLED = 'NO'
       WHERE NAME = 'wait/synch/mutex/sql/LOCK_mysql_create_db';

性能模式使用收集的事件来更新 performance_schema 数据库中的表，这些表充当事件信息的 “ 消费者 ” 。该 setup_consumers 表列出了可用的使用者以及哪些已启用：

MySQL的> SELECT * FROM performance_schema.setup_consumers;
+ ---------------------------------- + --------- +
| NAME | 启用|
+ ---------------------------------- + --------- +
| events_stages_current | 没有|
| events_stages_history | 没有|
| events_stages_history_long | 没有|
| events_statements_current | 是的|
| events_statements_history | 是的|
| events_statements_history_long | 没有|
| events_transactions_current | 是的|
| events_transactions_history | 是的|
| events_transactions_history_long | 没有|
| events_waits_current | 没有|
| events_waits_history | 没有|
| events_waits_history_long | 没有|
| global_instrumentation | 是的|
| thread_instrumentation | 是的|
| statements_digest | 是的|
+ ---------------------------------- + --------- +

要控制性能模式是否将使用者维护为事件信息的目标，请设置其 ENABLED 值。

有关设置表以及如何使用它们来控制事件收集的更多信息，请参见第26.4.2节“性能模式事件过滤” 。

有一些杂项表不属于任何以前的组。例如， performance_timers 列出可用的事件计时器及其特征。有关定时器的信息，请参见第26.4.1节“性能模式事件定时” 。

26.2性能架构构建配置

性能模式是强制性的，并且始终在其中编译。可以排除性能模式检测的某些部分。例如，要排除阶段和语句检测，请执行以下操作：

外壳> cmake . \
        -DDISABLE_PSI_STAGE=1 \
        -DDISABLE_PSI_STATEMENT=1

有关更多信息，请参见第2.9.4节“MySQL源配置选项” 中的 CMake 选项说明。 DISABLE_PSI_XXX

如果您在先前安装的情况下安装MySQL，而该安装是在没有性能架构的情况下配置的（或者是具有缺失或过时表的旧版本的性能架构）。此问题的一个指示是错误日志中存在以下消息：

[错误]原生表'performance_schema'。'events_waits_history'
有错误的结构
[错误]原生表'performance_schema'。'events_waits_history_long'
有错误的结构
...

要解决该问题，请执行MySQL升级过程。请参见第2.11节“升级MySQL” 。

由于性能模式在构建时配置到服务器中 PERFORMANCE_SCHEMA ，因此输出中会出现一行 SHOW ENGINES 。这意味着性能模式可用，而不是它已启用。要启用它，必须在服务器启动时执行此操作，如下一节中所述。

26.3性能模式启动配置

要使用MySQL性能模式，必须在服务器启动时启用它以启用事件收集。

的[mysqld]
performance_schema = ON

如果服务器在性能架构初始化期间无法分配任何内部缓冲区，则性能架构将禁用自身并设置 performance_schema 为 OFF ，并且服务器将在没有检测的情况下运行。

性能模式还允许在服务器启动时进行仪器和消费者配置。

要在服务器启动时控制仪器，请使用以下形式的选项：

--performance-schema-instrument =' instrument_name= value'

这里 instrument_name 是一个仪器名称，例如 wait/synch/mutex/sql/LOCK_open ，并且 value 是以下值之一：

OFF ,, FALSE 或 0 ：禁用仪器
ON ,, TRUE 或 1 ：启用和计时仪器
COUNTED ：启用并计算（而不是时间）仪器

每个 --performance-schema-instrument 选项只能指定一个仪器名称，但可以给出多个选项实例来配置多个仪器。此外，仪器名称中允许使用模式来配置与模式匹配的仪器。要将所有条件同步仪器配置为已启用和已计数，请使用此选项：

--performance-架构仪器= '等待/同步/ COND /％=计数'

要禁用所有仪器，请使用此选项：

--performance-架构仪器= '（％）= OFF'

例外： memory/performance_schema/% 仪器内置，启动时无法禁用。

无论顺序如何，较长的仪器名称字符串优先于较短的模式名称。有关指定选择乐器的模式的信息，请参见第26.4.9节“为过滤操作命名乐器或消费者” 。

无法识别的仪器名称将被忽略。稍后安装的插件可能会创建仪器，此时可以识别和配置名称。

要在服务器启动时控制使用者，请使用以下形式的选项：

--performance-schema-consumer- consumer_name=value

这里 consumer_name 是消费者名称，例如 events_waits_history ，并且 value 是以下值之一：

OFF ,, FALSE 或 0 ：不要为消费者收集活动
ON ,, TRUE 或 1 ：为消费者收集事件

例如，要启用 events_waits_history 使用者，请使用以下选项：

--performance-架构消费者的事件，等待历史= ON

通过检查 setup_consumers 表可以找到允许的使用者名称。不允许使用模式。 setup_consumers 表中的使用者名称使用下划线，但对于在启动时设置的使用者，名称中的短划线和下划线是等效的。

性能模式包括几个提供配置信息的系统变量：

MySQL的> SHOW VARIABLES LIKE 'perf%';
+ ------------------------------------------------- ------- + --------- +
| Variable_name | 价值|
+ ------------------------------------------------- ------- + --------- +
| performance_schema | ON |
| performance_schema_accounts_size | 100 |
| performance_schema_digests_size | 200 |
| performance_schema_events_stages_history_long_size | 10000 |
| performance_schema_events_stages_history_size | 10 |
| performance_schema_events_statements_history_long_size | 10000 |
| performance_schema_events_statements_history_size | 10 |
| performance_schema_events_waits_history_long_size | 10000 |
| performance_schema_events_waits_history_size | 10 |
| performance_schema_hosts_size | 100 |
| performance_schema_max_cond_classes | 80 |
| performance_schema_max_cond_instances | 1000 |
...

该 performance_schema 变量是 ON 或 OFF 指示是启用还是禁用性能架构。其他变量表示表大小（行数）或内存分配值。

注意

启用性能模式后，性能模式实例的数量可能会在很大程度上影响服务器内存占用。性能模式自动调整许多参数以仅在需要时使用内存; 请参见第26.17节“性能模式内存分配模型” 。

要更改Performance Schema系统变量的值，请在服务器启动时设置它们。例如，将以下行放在 my.cnf 文件中以更改等待事件的历史记录表的大小：

的[mysqld]
performance_schema
performance_schema_events_waits_history_size = 20
performance_schema_events_waits_history_long_size = 15000

如果未明确设置性能模式，则性能模式会在服务器启动时自动调整其几个参数的值。例如，它通过这种方式调整控制事件大小的参数。性能模式以递增方式分配内存，将其内存使用量扩展到实际服务器负载，而不是在服务器启动期间分配所需的所有内存。因此，根本不需要设置许多尺寸参数。要查看哪些参数是自动调整大小或自动调整的，请使用 mysqld --verbose --help 并检查选项描述，或参见第26.15节“性能架构系统变量” 。

对于未在服务器启动时设置的每个自动调整参数，性能模式将根据以下系统值的值确定如何设置其值，这些值被视为有关如何配置MySQL服务器的 “ 提示 ” ：

MAX_CONNECTIONS
open_files_limit
table_definition_cache
table_open_cache

要覆盖给定参数的自动调整大小或自动调节，请在启动时将其设置为-1以外的值。在这种情况下，性能模式为其分配指定的值。

在运行时， SHOW VARIABLES 显示自动调整参数设置的实际值。自动调整的参数显示值为-1。

如果禁用了性能模式，则其自动调整和自动调整的参数将保持设置为-1并 SHOW VARIABLES 显示-1。

可以在运行时启用特定性能架构功能，以控制发生哪些类型的事件收集。

性能架构设置表包含有关监视配置的信息：

MySQL的> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
       WHERE TABLE_SCHEMA = 'performance_schema'
       AND TABLE_NAME LIKE 'setup%';
+ ------------------- +
| TABLE_NAME |
+ ------------------- +
| setup_actors |
| setup_consumers |
| setup_instruments |
| setup_objects |
| setup_threads |
+ ------------------- +

您可以检查这些表的内容以获取有关性能架构监视特征的信息。如果您具有该 UPDATE 权限，则可以通过修改设置表来更改性能模式操作，以影响监视的发生方式。有关这些表的其他详细信息，请参见第26.12.2节“性能架构设置表” 。

在 setup_instruments 与 setup_consumers 表列出可以收集该事件的手段和类型哪个事件信息实际上被收集，分别消费者。其他设置表可以进一步修改监视配置。第26.4.2节“性能模式事件过滤” 讨论了如何修改这些表以影响事件收集。

如果必须在运行时使用SQL语句进行性能模式配置更改，并且您希望每次服务器启动时这些更改生效，请将语句放在文件中并使用该选项启动服务器。如果您有多个监视配置，每个监视配置都可以生成不同类型的监视，例如临时服务器运行状况监视，事件调查，应用程序行为故障排除等，则此策略也很有用。将每个监视配置的语句放入它们自己的文件中，并在启动服务器时将相应的文件指定为参数。 --init-file=file_name --init-file

26.4.1性能模式事件时序

通过添加到服务器源代码的检测来收集事件。仪器时间事件，这是性能模式提供事件所需时间的概念。还可以配置仪器不收集定时信息。本节讨论可用的计时器及其特征，以及如何在事件中表示计时值。

性能模式定时器

性能模式定时器的精度和开销量各不相同。要查看可用的计时器及其特性，请查看 performance_timers 表格：

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

如果与给定计时器名称关联的值为 NULL ，则您的平台不支持该计时器。

这些列具有以下含义：

该 TIMER_NAME 列显示可用计时器的名称。 CYCLE 指的是基于CPU（处理器）周期计数器的计时器。
TIMER_FREQUENCY 表示每秒的计时器单位数。对于循环定时器，频率通常与CPU速度有关。显示的值是在具有2.4GHz处理器的系统上获得的。其他计时器基于固定的秒数。
TIMER_RESOLUTION 表示定时器值一次增加的定时器单位数。如果计时器的分辨率为10，则其值每次增加10。
TIMER_OVERHEAD 是给定定时器获得一个定时的最小开销周期数。每个事件的开销是显示值的两倍，因为在事件的开始和结束时调用了计时器。

Performance Schema按如下方式分配定时器：

等待计时器使用 CYCLE 。
空闲，阶段，语句和事务计时器 NANOSECOND 在 NANOSECOND 计时器可用的平台上使用， MICROSECOND 否则使用。

在服务器启动时，性能模式验证在构建时关于计时器分配的假设是否正确，并在计时器不可用时显示警告。

对于等待事件的时间，最重要的标准是减少开销，可能以定时器精度为代价，因此使用 CYCLE 定时器是最好的。

语句（或阶段）执行所花费的时间通常比执行单个等待所花费的时间大几个数量级。对于时间陈述，最重要的标准是准确度量，不受处理器频率变化的影响，因此使用不基于周期的定时器是最好的。语句的默认计时器是 NANOSECOND 。额外的 “ 开销 ” 与之相比 CYCLE 计时器并不重要，因为调用计时器两次（一旦语句启动时，一次结束时）所产生的开销与用于执行语句本身的CPU时间相比要小几个数量级。使用 CYCLE 计时器在这里没有任何好处，只有缺点。

循环计数器提供的精度取决于处理器速度。如果处理器以1 GHz（10亿次/秒）或更高速度运行，则循环计数器可提供亚纳秒精度。使用循环计数器比获取实际时间要便宜得多。例如，标准 gettimeofday() 函数可能需要数百个周期，这对于数据收集来说是不可接受的开销，可能每秒发生数千或数百万次。

循环计数器也有缺点：

最终用户希望看到挂钟单位的时间，例如几分之一秒。从周期转换为几分之一秒可能很昂贵。因此，转换是一种快速且相当粗略的乘法运算。
处理器循环速率可能会发生变化，例如当笔记本电脑进入省电模式或CPU减速以减少热量产生时。如果处理器的循环速率波动，则从循环到实时单位的转换会出错。
根据处理器或操作系统的不同，循环计数器可能不可靠或不可用。例如，在Pentiums上，指令是 RDTSC （汇编语言而不是C指令），理论上操作系统可以阻止用户模式程序使用它。
与乱序执行或多处理器同步相关的某些处理器详细信息可能会使计数器看起来快或慢达1000个周期。

MySQL适用于x386（Windows，macOS，Linux，Solaris和其他Unix版本），PowerPC和IA-64上的循环计数器。

事件中的性能模式定时器表示

在性能模式中的表行存储时事和历史事件有三列表示定时信息 TIMER_START 和 TIMER_END 指示当事件开始和结束，并 TIMER_WAIT 表示事件持续时间。

该 setup_instruments 表有一 ENABLED 列表示要收集事件的工具。该表还有一 TIMED 列表明哪些工具是定时的。如果未启用仪器，则不会生成任何事件。如果启用了仪器不能定时，通过仪器产生的事件都 NULL 对 TIMER_START ， TIMER_END 和 TIMER_WAIT 定时器的值。这反过来会导致在汇总表（总和，最小值，最大值和平均值）中计算汇总时间值时忽略这些值。

在内部，事件内的时间以事件计时开始时有效的计时器给出的单位存储。对于从性能模式表中检索事件时的显示，无论选择哪个计时器，时间都以皮秒（万亿分之一秒）显示，以将它们标准化为标准单位。

计时器基线（ “ 时间零 ” ）发生在服务器启动期间的性能架构初始化中。 TIMER_START 并 TIMER_END 在活动值表示自基线皮秒。 TIMER_WAIT 值是以皮秒为单位的持续时间。

事件中的皮秒值是近似值。它们的准确性取决于从一个单元转换到另一个单元的常见错误形式。如果使用 CYCLE 定时器并且处理器速率变化，则可能存在漂移。由于这些原因， TIMER_START 将事件的值视为自服务器启动以来经过的时间的准确度量是不合理的。另一方面，在条款中使用 TIMER_START 或 TIMER_WAIT 值来合理 ORDER BY 按开始时间或持续时间排序事件是合理的。

在事件中选择皮秒而不是诸如微秒的值具有性能基础。一个实现目标是以统一的时间单位显示结果，而不管计时器如何。在一个理想的世界中，这个时间单位看起来像一个挂钟单位，并且相当精确; 换句话说，微秒。但是要将周期或纳秒转换为微秒，有必要对每个仪器执行除法。在许多平台上划分都很昂贵。乘法并不昂贵，所以这就是使用的。因此，时间单位是最高可能的整数倍 TIMER_FREQUENCY 值，使用足够大的乘数，以确保没有重大的精度损失。结果是时间单位是 “ 皮秒”。 “ 这种精确度是虚假的，但这一决定使得开销最小化。

在执行wait，stage，statement或transaction事件时，相应的当前事件表显示当前事件时序信息：

events_waits_current
events_stages_current
events_statements_current
events_transactions_current

为了能够确定尚未完成的事件运行了多长时间，计时器列的设置如下：

TIMER_START 填充。
TIMER_END 使用当前计时器值填充。
TIMER_WAIT 将填充到目前为止所用的时间（ TIMER_END - TIMER_START ）。

尚未完成的事件的 END_EVENT_ID 值为 NULL 。要评估事件到目前为止所用的时间，请使用该 TIMER_WAIT 列。因此，要识别尚未完成且已经花费超过 N 皮秒的事件，监视应用程序可以在查询中使用此表达式：

WHERE END_EVENT_ID是NULL和TIMER_WAIT> N

刚刚描述的事件识别假设相应的仪器具有 ENABLED 并 TIMED 设置为 YES 并且相关的消费者被启用。

26.4.2性能模式事件过滤

事件以生产者/消费者方式处理：

检测代码是事件的来源，并产生要收集的事件。该 setup_instruments 表列出了可以收集事件的工具，是否已启用，以及（对于已启用的工具）是否收集时间信息：

MySQL的> SELECT NAME, ENABLED, TIMED
       FROM performance_schema.setup_instruments;
+ ------------------------------------------------- -  + --------- + ------- +
| NAME | 启用| 定时|
+ ------------------------------------------------- -  + --------- + ------- +
...
| wait / synch / mutex / sql / LOCK_global_read_lock | 是的| 是的|
| wait / synch / mutex / sql / LOCK_global_system_variables | 是的| 是的|
| wait / synch / mutex / sql / LOCK_lock_db | 是的| 是的|
| wait / synch / mutex / sql / LOCK_manager | 是的| 是的|
...

该 setup_instruments 表提供了对事件生成的最基本控制形式。为了根据被监视的对象或线程的类型进一步细化事件生成，可以使用其他表，如第26.4.3节“事件预过滤”中所述。

性能架构表是事件和消耗事件的目标。该 setup_consumers 表列出了可以向其发送事件信息的消费者类型以及是否已启用它们：

MySQL的> SELECT * FROM performance_schema.setup_consumers;
+ ---------------------------------- + --------- +
| NAME | 启用|
+ ---------------------------------- + --------- +
| events_stages_current | 没有|
| events_stages_history | 没有|
| events_stages_history_long | 没有|
| events_statements_current | 是的|
| events_statements_history | 是的|
| events_statements_history_long | 没有|
| events_transactions_current | 是的|
| events_transactions_history | 是的|
| events_transactions_history_long | 没有|
| events_waits_current | 没有|
| events_waits_history | 没有|
| events_waits_history_long | 没有|
| global_instrumentation | 是的|
| thread_instrumentation | 是的|
| statements_digest | 是的|
+ ---------------------------------- + --------- +

过滤可以在性能监控的不同阶段完成：

预过滤。 这是通过修改性能模式配置来完成的，这样只从生产者收集某些类型的事件，并且收集的事件仅更新某些使用者。为此，请启用或禁用仪器或消费者。预过滤由性能模式完成，并具有适用于所有用户的全局效果。

使用预过滤的原因：
- 减少开销。即使启用了所有仪器，性能模式开销也应该很小，但也许您希望进一步降低它。或者您不关心时序事件，并希望禁用时序代码以消除时序开销。
- 避免使用您不感兴趣的事件填充当前事件或历史记录表。对于已启用的仪器类型，预过滤会在这些表中留出更多 “ 空间 ” 用于行的实例。如果仅启用具有预过滤功能的文件工具，则不会为非文件工具收集任何行。通过后过滤，可以收集非文件事件，从而为文件事件留下更少的行。
- 避免维护某些事件表。如果禁用使用者，则服务器不会花时间维护该使用者的目标。例如，如果您不关心事件历史记录，则可以禁用历史记录表使用者以提高性能。
后过滤。 这涉及在 WHERE 从Performance Schema表中选择信息的查询中使用子句，以指定要查看的可用事件。后过滤是基于每个用户执行的，因为各个用户选择感兴趣的哪些可用事件。

使用后过滤的原因：
- 避免为个别用户决定感兴趣的事件信息。
- 在预先不知道使用预过滤的限制时，使用性能模式来调查性能问题。

以下部分提供了有关预过滤的更多详细信息，并为过滤操作中的命名工具或使用者提供了指导。有关编写查询以检索信息（过滤后）的信息，请参见第26.5节“性能模式查询” 。

26.4.3事件预过滤

预过滤由性能模式完成，并具有适用于所有用户的全局效果。预过滤可以应用于事件处理的生产者或消费者阶段：

要在生产者阶段配置预过滤，可以使用几个表：
- setup_instruments 表示哪些仪器可用。无论其他与生产相关的设置表的内容如何，此表中禁用的工具都不会生成任何事件。允许在此表中启用的工具根据其他表的内容生成事件。
- setup_objects 控制性能模式是否监视特定表和存储的程序对象。
- threads 指示是否为每个服务器线程启用监视。
- setup_actors 确定新前台线程的初始监视状态。
要在使用者阶段配置预过滤，请修改该 setup_consumers 表。这确定了发送事件的目的地。 setup_consumers 也隐含地影响事件的产生。如果给定事件不会发送到任何目标（即，不会被使用），则性能模式不会生成它。

对这些表的任何修改都会立即影响监视，但对 setup_actors 表的修改仅影响修改后创建的前台线程，而不影响现有线程。

更改监视配置时，性能架构不会刷新历史记录表。已收集的事件将保留在当前事件和历史记录表中，直到被新事件取代。如果您禁用乐器，您可能需要等待一段时间，然后才能通过感兴趣的新事件取代它们。或者，用于 TRUNCATE TABLE 清空历史表。

进行检测更改后，您可能希望截断摘要表。通常，效果是将摘要列重置为0，或者 NULL 不删除行。这使您可以清除收集的值并重新启动聚合。例如，在您更改运行时配置之后，这可能很有用。单个摘要表部分中记录了此截断行为的例外情况。

以下部分描述如何使用特定表来控制性能架构预过滤。

26.4.4按仪器预过滤

该 setup_instruments 表列出了可用的工具：

MySQL的> SELECT NAME, ENABLED, TIMED
       FROM performance_schema.setup_instruments;
+ ------------------------------------------------- -  + --------- + ------- +
| NAME | 启用| 定时|
+ ------------------------------------------------- -  + --------- + ------- +
...
| stage / sql / end | 没有| 没有|
| stage / sql / execution | 没有| 没有|
| stage / sql / init | 没有| 没有|
| stage / sql / insert | 没有| 没有|
...
| statement / sql / load | 是的| 是的|
| statement / sql / grant | 是的| 是的|
| statement / sql / check | 是的| 是的|
| statement / sql / flush | 是的| 是的|
...
| wait / synch / mutex / sql / LOCK_global_read_lock | 是的| 是的|
| wait / synch / mutex / sql / LOCK_global_system_variables | 是的| 是的|
| wait / synch / mutex / sql / LOCK_lock_db | 是的| 是的|
| wait / synch / mutex / sql / LOCK_manager | 是的| 是的|
...
| wait / synch / rwlock / sql / LOCK_grant | 是的| 是的|
| wait / synch / rwlock / sql / LOGGER :: LOCK_logger | 是的| 是的|
| wait / synch / rwlock / sql / LOCK_sys_init_connect | 是的| 是的|
| wait / synch / rwlock / sql / LOCK_sys_init_slave | 是的| 是的|
...
| wait / io / file / sql / binlog | 是的| 是的|
| wait / io / file / sql / binlog_index | 是的| 是的|
| wait / io / file / sql / casetest | 是的| 是的|
| wait / io / file / sql / dbopt | 是的| 是的|
...

要控制是否启用仪器，请将其 ENABLED 列设置为 YES 或 NO 。要配置是否收集已启用仪器的计时信息，请将其 TIMED 值设置为 YES 或 NO 。设置 TIMED 列会影响性能架构表内容，如第26.4.1节“性能架构事件时序”中所述。

对大多数 setup_instruments 行的修改会立即影响监视。对于某些仪器，修改仅在服务器启动时有效; 在运行时更改它们没有任何效果。这主要影响服务器中的互斥锁，条件和rwlock，尽管可能有其他工具也是如此。

以下示例演示了对 setup_instruments 表的可能操作。与其他预过滤操作一样，这些更改会影响所有用户。其中一些查询使用 LIKE 运算符和模式匹配仪器名称。有关指定模式以选择仪器的其他信息，请参见第26.4.9节“命名仪器或消费者进行过滤操作” 。

禁用所有乐器：

更新performance_schema.setup_instruments
SET ENABLED ='NO';

现在不会收集任何事件。

禁用所有文件工具，将它们添加到当前禁用的工具集：

更新performance_schema.setup_instruments
SET ENABLED ='NO'
在哪里名称'wait / io / file /％';

仅禁用文件工具，启用所有其他工具：

更新performance_schema.setup_instruments
SET ENABLED = IF（NAME LIKE'wait / io / file /％'，'NO'，'YES'）;

启用 mysys 库中的所有工具：

更新performance_schema.setup_instruments
SET ENABLED =例如，名称如'％/ mysys /％'那么'是'''否''结束;

禁用特定仪器：

更新performance_schema.setup_instruments
SET ENABLED ='NO'
WHERE NAME ='wait / synch / mutex / mysys / TMPDIR_mutex';

要切换乐器的状态，请 “ 翻转 ” 其 ENABLED 值：

更新performance_schema.setup_instruments
SET ENABLED = IF（ENABLED ='YES'，'NO'，'YES'）
WHERE NAME ='wait / synch / mutex / mysys / TMPDIR_mutex';

禁用所有事件的时间：

更新performance_schema.setup_instruments
SET TIMED ='否';

26.4.5按对象预过滤

该 setup_objects 表控制性能模式是否监视特定表和存储的程序对象。初始 setup_objects 内容如下所示：

MySQL的> SELECT * FROM performance_schema.setup_objects;
+ ------------- + -------------------- + ------------- + --------- ------- + +
| OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | 启用| 定时|
+ ------------- + -------------------- + ------------- + --------- ------- + +
| 活动| mysql | ％| 没有| 没有|
| 活动| performance_schema | ％| 没有| 没有|
| 活动| information_schema | ％| 没有| 没有|
| 活动| ％| ％| 是的| 是的|
| 功能| mysql | ％| 没有| 没有|
| 功能| performance_schema | ％| 没有| 没有|
| 功能| information_schema | ％| 没有| 没有|
| 功能| ％| ％| 是的| 是的|
| 程序| mysql | ％| 没有| 没有|
| 程序| performance_schema | ％| 没有| 没有|
| 程序| information_schema | ％| 没有| 没有|
| 程序| ％| ％| 是的| 是的|
| 表| mysql | ％| 没有| 没有|
| 表| performance_schema | ％| 没有| 没有|
| 表| information_schema | ％| 没有| 没有|
| 表| ％| ％| 是的| 是的|
| TRIGGER | mysql | ％| 没有| 没有|
| TRIGGER | performance_schema | ％| 没有| 没有|
| TRIGGER | information_schema | ％| 没有| 没有|
| TRIGGER | ％| ％| 是的| 是的|
+ ------------- + -------------------- + ------------- + --------- ------- + +

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

该 OBJECT_TYPE 列指示行适用的对象类型。 TABLE 过滤会影响表I / O事件（ wait/io/table/sql/handler 仪器）和表锁定事件（ wait/lock/table/sql/handler 仪器）。

在 OBJECT_SCHEMA 与 OBJECT_NAME 列应包含文本模式或对象的名称，或 '%' 以匹配任何名称。

该 ENABLED 列指示是否监视匹配对象，并 TIMED 指示是否收集定时信息。设置 TIMED 列会影响性能架构表内容，如第26.4.1节“性能架构事件时序”中所述。

缺省对象配置的效果是仪器除了那些在所有对象 mysql ， INFORMATION_SCHEMA 和 performance_schema 数据库。（ INFORMATION_SCHEMA 无论内容如何，数据库中的表都不会被检测 setup_objects ;该行 information_schema.% 只是使其默认为显式。）

当性能模式检查匹配时 setup_objects ，它会尝试首先查找更具体的匹配项。对于与给定匹配的行， OBJECT_TYPE Performance Schema按以下顺序检查行：

与和的行。 OBJECT_SCHEMA='literal' OBJECT_NAME='literal'
与和的行。 OBJECT_SCHEMA='literal' OBJECT_NAME='%'
与 OBJECT_SCHEMA='%' 和的行 OBJECT_NAME='%' 。

例如，有一张桌子 db1.t1 ，性能架构看起来 TABLE 行的匹配 'db1' 和 't1' ，然后 'db1' 和 '%' ，然后 '%' 和 '%' 。匹配发生的顺序很重要，因为不同的匹配 setup_objects 行可以具有不同的值 ENABLED 和 TIMED 值。

对于与表相关的事件，性能模式将 setup_objects with 的内容组合在一起， setup_instruments 以确定是否启用仪器以及是否启用时间启用的仪器：

对于匹配一排桌子 setup_objects ，桌子仪器产生的事件仅 ENABLED 是 YES 在这两个 setup_instruments 和 setup_objects 。
TIMED 两个表中的值组合在一起，因此仅在两个值都收集时才收集定时信息 YES 。

对于存储的程序对象，性能模式直接从行中获取 ENABLED 和 TIMED 列 setup_objects 。没有价值观的组合 setup_instruments 。

假设 setup_objects 包含以下 TABLE 适用于行 db1 ， db2 以及 db3 ：

+ ------------- + --------------- + ------------- + ----- ---- + ------- +
| OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | 启用| 定时|
+ ------------- + --------------- + ------------- + ----- ---- + ------- +
| 表| db1 | t1 | 是的| 是的|
| 表| db1 | t2 | 没有| 没有|
| 表| db2 | ％| 是的| 是的|
| 表| db3 | ％| 没有| 没有|
| 表| ％| ％| 是的| 是的|
+ ------------- + --------------- + ------------- + ----- ---- + ------- +

如果与对象相关的仪器 setup_instruments 具有 ENABLED 值 NO ，则不监视对象的事件。如果 ENABLED 值为，则 YES 根据 ENABLED 相关 setup_objects 行中的值进行事件监视：

db1.t1 事件受到监控
db1.t2 事件不受监控
db2.t3 事件受到监控
db3.t4 事件不受监控
db4.t5 事件受到监控

类似的逻辑适用于组合 TIMED 来自 setup_instruments 和 setup_objects 表的列以确定是否收集事件定时信息。

如果持久表和临时表具有相同的名称，则对两 setup_objects 行的匹配方式相同。无法对一个表启用监视，而对另一个表启用监视。但是，每个表都是单独检测的。

26.4.6按线程预过滤

该 threads 表包含每个服务器线程的行。每行包含有关线程的信息，并指示是否为其启用了监视。要使Performance Schema监视线程，必须满足以下条件：

表中的 thread_instrumentation 消费者 setup_consumers 必须是 YES 。
该 threads.INSTRUMENTED 列必须是 YES 。
仅对 setup_instruments 表中启用的仪器生成的那些线程事件进行监视。

该 threads 表还为每个服务器线程指示是否执行历史事件记录。这包括等待，阶段，语句和事务事件，并影响到这些表的日志记录：

events_waits_history
events_waits_history_long
events_stages_history
events_stages_history_long
events_statements_history
events_statements_history_long
events_transactions_history
events_transactions_history_long

要进行历史事件记录，必须满足以下条件：

setup_consumers 必须启用表中适当的与历史记录相关的使用者。例如，在 events_waits_history 和 events_waits_history_long 表中的等待事件记录需要相应的 events_waits_history 和 events_waits_history_long 消费者 YES 。
该 threads.HISTORY 列必须是 YES 。
仅针对从 setup_instruments 表中启用的仪器生成的那些线程事件进行记录。

对于前台线程（由客户端连接产生），表行中 INSTRUMENTED 和 HISTORY 列的初始值 threads 由与线程关联的用户帐户是否与 setup_actors 表中的任何行匹配来确定。值来自匹配表行的 ENABLED 和 HISTORY 列 setup_actors 。

对于后台线程，没有关联的用户。 INSTRUMENTED 并且 HISTORY 是 YES 在默认情况下并 setup_actors 没有意见。

初始 setup_actors 内容如下所示：

MySQL的> SELECT * FROM performance_schema.setup_actors;
+ ------ + ------ + ------ + --------- + --------- +
| 主持人| 用户| 角色| 启用| 历史|
+ ------ + ------ + ------ + --------- + --------- +
| ％| ％| ％| 是的| 是的|
+ ------ + ------ + ------ + --------- + --------- +

在 HOST 与 USER 列应包含文本的主机或用户名，或 '%' 以匹配任何名称。

的 ENABLED 和 HISTORY 列表示是否使能仪器和历史事件记录进行匹配螺纹，受试者先前所描述的其他条件。

当性能模式检查每个新前台线程的匹配时 setup_actors ，它首先尝试使用 USER 和 HOST 列（ ROLE 未使用）查找更具体的匹配：

与和的行。 USER='literal' HOST='literal'
与和的行。 USER='literal' HOST='%'
与 USER='%' 和的行。 HOST='literal'
与 USER='%' 和的行 HOST='%' 。

匹配发生的顺序很重要，因为不同的匹配 setup_actors 行可以具有不同的值 USER 和 HOST 值。这样，可以根据 ENABLED 和 HISTORY 列值，根据主机，用户或帐户（用户和主机组合）有选择地应用检测和历史事件日志记录：

当最佳匹配是一行时 ENABLED=YES ， INSTRUMENTED 线程的值变为 YES 。当最佳匹配是一行时 HISTORY=YES ， HISTORY 线程的值变为 YES 。
当最佳匹配是一行时 ENABLED=NO ， INSTRUMENTED 线程的值变为 NO 。当最佳匹配是一行时 HISTORY=NO ， HISTORY 线程的值变为 NO 。
找不到匹配项时，线程的 INSTRUMENTED 和 HISTORY 值变为 NO 。

行中的 ENABLED 和 HISTORY 列 setup_actors 可以设置为彼此 YES 或 NO 彼此独立。这意味着您可以与是否收集历史事件分开启用检测。

默认情况下，为所有新的前台线程启用监视和历史事件收集，因为该 setup_actors 表最初包含一个包含 '%' for HOST 和的行 USER 。要执行更有限的匹配（例如，仅为某些前台线程启用监视），必须更改此行，因为它匹配任何连接，并添加更多特定 HOST / USER 组合的行。

假设您修改 setup_actors 如下：

更新performance_schema.setup_actors
SET ENABLED ='NO'，HISTORY ='NO'
WHERE HOST ='％'和USER ='％';
INSERT INTO performance_schema.setup_actors
（主机，用户，角色，启用，历史）
VALUES（ '本地主机'， '乔'， '％'， 'YES'， 'YES'）;
INSERT INTO performance_schema.setup_actors
（主机，用户，角色，启用，历史）
VALUES（ 'hosta.example.com'， '乔'， '％'， 'YES'， '否'）;
INSERT INTO performance_schema.setup_actors
（主机，用户，角色，启用，历史）
VALUES（ '％'， 'SAM'， '％'， '否'， 'YES'）;

该 UPDATE 语句更改默认匹配以禁用检测和历史事件收集。这些 INSERT 语句为更具体的匹配添加行。

现在，性能模式确定如何为新连接线程设置 INSTRUMENTED 和 HISTORY 值，如下所示：

如果 joe 从本地主机连接，则连接与第一个插入的行匹配。在 INSTRUMENTED 与 HISTORY 该线程值成为 YES 。
如果 joe 连接 hosta.example.com ，则连接与第二个插入的行匹配。在 INSTRUMENTED 该线程值变为 YES 和 HISTORY 值变为 NO 。
如果 joe 从任何其他主机连接，则不匹配。在 INSTRUMENTED 与 HISTORY 该线程值成为 NO 。
如果 sam 从任何主机连接，则连接与第三个插入的行匹配。在 INSTRUMENTED 该线程值变为 NO 和 HISTORY 值变为 YES 。
对于任何其他连接，带有 HOST 和 USER 设置为 '%' 匹配的行。该行目前已经 ENABLED 和 HISTORY 设置 NO ，所以 INSTRUMENTED 并 HISTORY 为线程值成为 NO 。

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

26.4.7消费者预过滤

该 setup_consumers 表列出了可用的使用者类型以及已启用的类型：

MySQL的> SELECT * FROM performance_schema.setup_consumers;
+ ---------------------------------- + --------- +
| NAME | 启用|
+ ---------------------------------- + --------- +
| events_stages_current | 没有|
| events_stages_history | 没有|
| events_stages_history_long | 没有|
| events_statements_current | 是的|
| events_statements_history | 是的|
| events_statements_history_long | 没有|
| events_transactions_current | 是的|
| events_transactions_history | 是的|
| events_transactions_history_long | 没有|
| events_waits_current | 没有|
| events_waits_history | 没有|
| events_waits_history_long | 没有|
| global_instrumentation | 是的|
| thread_instrumentation | 是的|
| statements_digest | 是的|
+ ---------------------------------- + --------- +

修改 setup_consumers 表以影响使用者阶段的预过滤并确定发送事件的目标。要启用或禁用使用者，请将其 ENABLED 值设置为 YES 或 NO 。

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

如果禁用使用者，则服务器不会花时间维护该使用者的目标。例如，如果您不关心历史事件信息，请禁用历史记录使用者：

更新performance_schema.setup_consumers
SET ENABLED ='NO'
名称在哪里'％history％';

setup_consumers 表中的使用者设置形成从较高级别到较低级别的层次结构。以下原则适用：

除非性能模式检查使用者并且启用了使用者，否则与使用者关联的目标不会接收任何事件。
仅在启用了依赖于（如果有）的所有使用者时才检查使用者。
如果未检查消费者，或者已对其进行检查但已禁用，则不会检查依赖于此消费者的其他消费者。
依赖消费者可能有自己的依赖消费者。
如果事件不会发送到任何目标，则性能架构不会生成它。

以下列表描述了可用的使用者值。有关几种有代表性的消费者配置及其对仪器的影响的讨论，请参见第26.4.8节“消费者配置示例” 。

全球和线程消费者
等待事件消费者
舞台活动消费者
声明事件消费者
交易事件消费者
声明摘要消费者

全球和线程消费者

global_instrumentation 是最高级别的消费者。如果 global_instrumentation 是 NO ，则禁用全局检测。所有其他设置均为较低级别，未进行检查; 他们的目标并不重要。不维护全局或每个线程信息，并且不会在当前事件或事件历史记录表中收集单个事件。如果 global_instrumentation 是 YES ，性能模式维护全局状态的信息并检查 thread_instrumentation 消费者。
thread_instrumentation 检查仅 global_instrumentation 是 YES 。否则，如果 thread_instrumentation 是 NO ，则禁用特定于线程的检测，并忽略所有较低级别的设置。每个线程不维护任何信息，并且当前事件或事件历史表中不收集任何单个事件。如果 thread_instrumentation 是 YES ，性能模式维护特定于线程的信息并检查使用者。 events_xxx_current

等待事件消费者

这些消费者既需要 global_instrumentation 和 thread_instrumentation 要 YES ，否则将无法检查。如果选中，它们的行为如下：

events_waits_current ，if NO ，禁用 events_waits_current 表中单个等待事件的收集。如果 YES ，它启用等待事件收集，并且性能模式检查 events_waits_history 和 events_waits_history_long 消费者。
events_waits_history 如果未选中 event_waits_current 的 NO 。否则，表的 events_waits_history 值为 NO 或 YES 禁用或启用等待事件的集合 events_waits_history 。
events_waits_history_long 如果未选中 event_waits_current 的 NO 。否则，表的 events_waits_history_long 值为 NO 或 YES 禁用或启用等待事件的集合 events_waits_history_long 。

舞台活动消费者

这些消费者既需要 global_instrumentation 和 thread_instrumentation 要 YES ，否则将无法检查。如果选中，它们的行为如下：

events_stages_current ，if NO ，禁用 events_stages_current 表中各个阶段事件的收集。如果 YES ，它启用阶段事件收集，性能模式检查 events_stages_history 和 events_stages_history_long 消费者。
events_stages_history 如果未选中 event_stages_current 的 NO 。否则，表的 events_stages_history 值为 NO 或 YES 禁用或启用阶段事件的集合 events_stages_history 。
events_stages_history_long 如果未选中 event_stages_current 的 NO 。否则，表的 events_stages_history_long 值为 NO 或 YES 禁用或启用阶段事件的集合 events_stages_history_long 。

声明事件消费者

这些消费者既需要 global_instrumentation 和 thread_instrumentation 要 YES ，否则将无法检查。如果选中，它们的行为如下：

events_statements_current ，if NO ，禁用 events_statements_current 表中单个语句事件的收集。如果 YES ，它启用语句事件收集和性能模式检查 events_statements_history 和 events_statements_history_long 消费者。
events_statements_history 如果未选中 events_statements_current 的 NO 。否则，表的 events_statements_history 值为 NO 或 YES 禁用或启用语句事件的集合 events_statements_history 。
events_statements_history_long 如果未选中 events_statements_current 的 NO 。否则，表的 events_statements_history_long 值为 NO 或 YES 禁用或启用语句事件的集合 events_statements_history_long 。

交易事件消费者

这些消费者既需要 global_instrumentation 和 thread_instrumentation 要 YES ，否则将无法检查。如果选中，它们的行为如下：

events_transactions_current ，if NO ，禁用 events_transactions_current 表中单个事务事件的收集。如果 YES ，它启用事务事件收集和性能架构检查 events_transactions_history 和 events_transactions_history_long 消费者。
events_transactions_history 如果未选中 events_transactions_current 的 NO 。否则，表的 events_transactions_history 值为 NO 或 YES 禁用或启用事务事件的集合 events_transactions_history 。
events_transactions_history_long 如果未选中 events_transactions_current 的 NO 。否则，表的 events_transactions_history_long 值为 NO 或 YES 禁用或启用事务事件的集合 events_transactions_history_long 。

声明摘要消费者

该 statements_digest 消费者要求 global_instrumentation 是 YES ，或者不进行检查。不依赖于语句事件使用者，因此您可以获取每个摘要的统计信息而无需收集统计信息 events_statements_current ，这在开销方面是有利的。相反，您可以在 events_statements_current 没有摘要的情况下获得详细的语句（ DIGEST 和 DIGEST_TEXT 列将是 NULL ）。

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

26.4.8消费者配置示例

setup_consumers 表中的使用者设置形成从较高级别到较低级别的层次结构。以下讨论描述了消费者如何工作，显示特定配置及其效果，因为消费者设置从高到低逐步启用。显示的消费者价值是代表性的。此处描述的一般原则适用于可能的其他消费者价值观。

配置描述按功能和开销增加的顺序发生。如果您不需要通过启用较低级别设置提供的信息，请禁用它们，性能架构将代表您执行较少的代码，您将获得较少的信息来筛选。

该 setup_consumers 表包含以下值的层次结构：

global_instrumentation
 thread_instrumentation
   events_waits_current
     events_waits_history
     events_waits_history_long
   events_stages_current
     events_stages_history
     events_stages_history_long
   events_statements_current
     events_statements_history
     events_statements_history_long
   events_transactions_current
     events_transactions_history
     events_transactions_history_long
 statements_digest

注意

在消费者层次结构中，等待，阶段，陈述和交易的消费者都处于同一水平。这与事件嵌套层次结构不同，事件嵌套层次结构在阶段事件中嵌套等待事件，这些事件嵌套在事务事件中的语句事件中。

如果给定的使用者设置是 NO ，则性能模式将禁用与使用者关联的检测并忽略所有较低级别的设置。如果给定的设置是 YES ，则性能模式将启用与其关联的检测，并检查下一个最低级别的设置。有关每个使用者的规则的说明，请参见第26.4.7节“按使用者预过滤” 。

例如，如果 global_instrumentation 已启用， thread_instrumentation 则选中。如果 thread_instrumentation 启用，则检查使用者。如果这些被启用，并进行检查。 events_xxx_current events_waits_current events_waits_history events_waits_history_long

以下每个配置描述都指示性能模式检查哪些设置元素以及它维护哪些输出表（即，它收集信息的表）。

没有仪器
仅限全球仪器
仅限全局和线程检测
全局，线程和当前事件检测
全局，线程，当前事件和事件历史记录工具

没有仪器

服务器配置状态：

MySQL的> SELECT * FROM performance_schema.setup_consumers;
+ --------------------------- + --------- +
| NAME | 启用|
+ --------------------------- + --------- +
| global_instrumentation | 没有|
...
+ --------------------------- + --------- +

在此配置中，不会检测任何内容。

检查设置元素：

表 setup_consumers ，消费者 global_instrumentation

保存输出表：

没有

仅限全球仪器

服务器配置状态：

MySQL的> SELECT * FROM performance_schema.setup_consumers;
+ --------------------------- + --------- +
| NAME | 启用|
+ --------------------------- + --------- +
| global_instrumentation | 是的|
| thread_instrumentation | 没有|
...
+ --------------------------- + --------- +

在此配置中，仅为全局状态维护检测。每线程检测已禁用。

相对于前面的配置，检查了其他设置元素：

表 setup_consumers ，消费者 thread_instrumentation
表 setup_instruments
表 setup_objects

相对于前面的配置，维护了额外的输出表：

mutex_instances
rwlock_instances
cond_instances
file_instances
users
hosts
accounts
socket_summary_by_event_name
file_summary_by_instance
file_summary_by_event_name
objects_summary_global_by_type
memory_summary_global_by_event_name
table_lock_waits_summary_by_table
table_io_waits_summary_by_index_usage
table_io_waits_summary_by_table
events_waits_summary_by_instance
events_waits_summary_global_by_event_name
events_stages_summary_global_by_event_name
events_statements_summary_global_by_event_name
events_transactions_summary_global_by_event_name

仅限全局和线程检测

服务器配置状态：

MySQL的> SELECT * FROM performance_schema.setup_consumers;
+ ---------------------------------- + --------- +
| NAME | 启用|
+ ---------------------------------- + --------- +
| global_instrumentation | 是的|
| thread_instrumentation | 是的|
| events_waits_current | 没有|
...
| events_stages_current | 没有|
...
| events_statements_current | 没有|
...
| events_transactions_current | 没有|
...
+ ---------------------------------- + --------- +

在此配置中，全局和每个线程都维护检测。当前事件或事件历史表中不会收集任何单个事件。

相对于前面的配置，检查了其他设置元素：

表 setup_consumers ，消费者，其中为，，， events_xxx_currentxxxwaitsstagesstatementstransactions
表 setup_actors
柱 threads.instrumented

相对于前面的配置，维护了额外的输出表：

events_xxx_summary_by_yyy_by_event_name ，其中 xxx 是 waits ， stages ， statements ， transactions ; 并且 yyy 为 thread ， user ， host ， account

全局，线程和当前事件检测

服务器配置状态：

MySQL的> SELECT * FROM performance_schema.setup_consumers;
+ ---------------------------------- + --------- +
| NAME | 启用|
+ ---------------------------------- + --------- +
| global_instrumentation | 是的|
| thread_instrumentation | 是的|
| events_waits_current | 是的|
| events_waits_history | 没有|
| events_waits_history_long | 没有|
| events_stages_current | 是的|
| events_stages_history | 没有|
| events_stages_history_long | 没有|
| events_statements_current | 是的|
| events_statements_history | 没有|
| events_statements_history_long | 没有|
| events_transactions_current | 是的|
| events_transactions_history | 没有|
| events_transactions_history_long | 没有|
...
+ ---------------------------------- + --------- +

在此配置中，全局和每个线程都维护检测。单个事件在current-events表中收集，但不在事件历史表中收集。

相对于前面的配置，检查了其他设置元素：

消费者，其中为，，， events_xxx_history xxx waits stages statements transactions
消费者，其中为，，， events_xxx_history_long xxx waits stages statements transactions

相对于前面的配置，维护了额外的输出表：

events_xxx_current ，其中 xxx 是 waits ， stages ， statements ， transactions

全局，线程，当前事件和事件历史记录工具

上述配置不会收集事件历史记录，因为已禁用和使用者。这些消费者可以单独或一起启用，以收集每个线程，全局或两者的事件历史记录。 events_xxx_history events_xxx_history_long

此配置收集每个线程的事件历史记录，但不是全局的：

MySQL的> SELECT * FROM performance_schema.setup_consumers;
+ ---------------------------------- + --------- +
| NAME | 启用|
+ ---------------------------------- + --------- +
| global_instrumentation | 是的|
| thread_instrumentation | 是的|
| events_waits_current | 是的|
| events_waits_history | 是的|
| events_waits_history_long | 没有|
| events_stages_current | 是的|
| events_stages_history | 是的|
| events_stages_history_long | 没有|
| events_statements_current | 是的|
| events_statements_history | 是的|
| events_statements_history_long | 没有|
| events_transactions_current | 是的|
| events_transactions_history | 是的|
| events_transactions_history_long | 没有|
...
+ ---------------------------------- + --------- +

为此配置维护的事件历史表：

events_xxx_history ，其中 xxx 是 waits ， stages ， statements ， transactions

此配置全局收集事件历史记录，但不是每个线程：

MySQL的> SELECT * FROM performance_schema.setup_consumers;
+ ---------------------------------- + --------- +
| NAME | 启用|
+ ---------------------------------- + --------- +
| global_instrumentation | 是的|
| thread_instrumentation | 是的|
| events_waits_current | 是的|
| events_waits_history | 没有|
| events_waits_history_long | 是的|
| events_stages_current | 是的|
| events_stages_history | 没有|
| events_stages_history_long | 是的|
| events_statements_current | 是的|
| events_statements_history | 没有|
| events_statements_history_long | 是的|
| events_transactions_current | 是的|
| events_transactions_history | 没有|
| events_transactions_history_long | 是的|
...
+ ---------------------------------- + --------- +

为此配置维护的事件历史表：

events_xxx_history_long ，其中 xxx 是 waits ， stages ， statements ， transactions

此配置收集每个线程和全局的事件历史记录：

MySQL的> SELECT * FROM performance_schema.setup_consumers;
+ ---------------------------------- + --------- +
| NAME | 启用|
+ ---------------------------------- + --------- +
| global_instrumentation | 是的|
| thread_instrumentation | 是的|
| events_waits_current | 是的|
| events_waits_history | 是的|
| events_waits_history_long | 是的|
| events_stages_current | 是的|
| events_stages_history | 是的|
| events_stages_history_long | 是的|
| events_statements_current | 是的|
| events_statements_history | 是的|
| events_statements_history_long | 是的|
| events_transactions_current | 是的|
| events_transactions_history | 是的|
| events_transactions_history_long | 是的|
...
+ ---------------------------------- + --------- +

为此配置维护的事件历史表：

events_xxx_history ，其中 xxx 是 waits ， stages ， statements ， transactions
events_xxx_history_long ，其中 xxx 是 waits ， stages ， statements ， transactions

26.4.9命名仪器或消费者进行过滤操作

为过滤操作指定的名称可以根据需要具体或一般。要指明单个工具或消费者，请完整指定其名称：

更新performance_schema.setup_instruments
SET ENABLED ='NO'
WHERE NAME ='wait / synch / mutex / myisammrg / MYRG_INFO :: mutex';

更新performance_schema.setup_consumers
SET ENABLED ='NO'
WHERE NAME ='events_waits_current';

要指定一组工具或消费者，请使用与组成员匹配的模式：

更新performance_schema.setup_instruments
SET ENABLED ='NO'
在哪里名称'wait / synch / mutex /％';

更新performance_schema.setup_consumers
SET ENABLED ='NO'
名称在哪里'％history％';

如果您使用模式，则应选择它以使其匹配所有感兴趣的项目而不匹配其他项目。例如，要选择所有文件I / O仪器，最好使用包含整个仪器名称前缀的模式：

...在哪里名称'wait / io / file /％';

一种模式 '%/file/%' 将匹配其他具有 '/file/' 名称中任何位置组件的工具。更不合适的是模式， '%file%' 因为它会匹配 'file' 名称中任何位置的乐器，例如 wait/synch/mutex/innodb/file_open_mutex 。

要检查模式匹配的仪器或消费者名称，请执行简单测试：

从performance_schema.setup_instruments中选择名称
名称在哪里' pattern';

从performance_schema.setup_consumers中选择名称
名称在哪里' pattern';

有关支持的名称类型的信息，请参见第26.6节“性能架构仪器命名约定” 。

26.4.10确定仪器的内容

通过查看 setup_instruments 表格，始终可以确定性能模式包含哪些工具。例如，要查看为 InnoDB 存储引擎检测的文件相关事件，请使用以下查询：

MySQL的> SELECT NAME, ENABLED, TIMED
       FROM performance_schema.setup_instruments
       WHERE NAME LIKE 'wait/io/file/innodb/%';
+ ------------------------------------------------- + --------- + ------- +
| NAME | 启用| 定时|
+ ------------------------------------------------- + --------- + ------- +
| wait / io / file / innodb / innodb_tablespace_open_file | 是的| 是的|
| wait / io / file / innodb / innodb_data_file | 是的| 是的|
| wait / io / file / innodb / innodb_log_file | 是的| 是的|
| wait / io / file / innodb / innodb_temp_file | 是的| 是的|
| wait / io / file / innodb / innodb_arch_file | 是的| 是的|
| wait / io / file / innodb / innodb_clone_file | 是的| 是的|
+ ------------------------------------------------- + --------- + ------- +

由于以下几个原因，本文档中未详细说明精确检测的内容：

检测的是服务器代码。对此代码的更改经常发生，这也会影响仪器集。
列出所有仪器是不切实际的，因为它们有数百种。
如前所述，可以通过查询 setup_instruments 表找出答案。此信息始终是您的MySQL版本的最新信息，还包括您可能已安装的不属于核心服务器的已检测插件的工具，并且可以由自动化工具使用。

26.5性能模式查询

预过滤限制收集哪些事件信息，并且独立于任何特定用户。相比之下，后过滤是由各个用户通过使用具有适当 WHERE 子句的查询来执行的，这些子句限制在应用预过滤之后从可用事件中选择哪些事件信息。

在第26.4.3节“事件预过滤”中，一个示例显示了如何对文件仪器进行预过滤。如果事件表包含文件和非文件信息，则后过滤是另一种仅查看文件事件信息的方法。 WHERE 在查询中添加一个子句以适当地限制事件选择：

MySQL的> SELECT THREAD_ID, NUMBER_OF_BYTES
       FROM performance_schema.events_waits_history
       WHERE EVENT_NAME LIKE 'wait/io/file/%'
       AND NUMBER_OF_BYTES IS NOT NULL;
+ ----------- + ----------------- +
| THREAD_ID | NUMBER_OF_BYTES |
+ ----------- + ----------------- +
| 11 | 66 |
| 11 | 47 |
| 11 | 139 |
| 5 | 24 |
| 5 | 834 |
+ ----------- + ----------------- +

大多数性能模式表都有索引，这使得优化器可以访问除全表扫描之外的执行计划。这些索引还可以提高相关对象的性能，例如 sys 使用这些表的架构视图。有关更多信息，请参见第8.2.4节“优化性能架构查询” 。

26.6性能架构仪器命名约定

仪器名称由一系列由 '/' 字符分隔的组件组成。示例名称：

等待/ IO /文件/ MyISAM数据/日志
等待/ IO /文件/ MYSYS /字符集
等待/锁/表/ SQL /处理器
等待/同步/湿/ MYSYS / COND_alarm
等待/同步/湿/ SQL / BINLOG :: update_cond
等待/同步/互斥/ MYSYS / BITMAP_mutex
等待/同步/互斥/ SQL / LOCK_delete
等待/同步/ rwlock中/ SQL / Query_cache_query ::锁
stage / sql / closing tables
stage / sql /排序结果
声明/ COM /执行
声明/ COM /查询
声明/ SQL / CREATE_TABLE
声明/ SQL / lock_tables
错误

仪器名称空间具有树状结构。仪器名称的组成部分从左到右提供从更一般到更具体的进展。名称所具有的组件数量取决于仪器的类型。

名称中给定组件的解释取决于其左侧的组件。例如， myisam 出现在以下两个名称中，但 myisam 第一个名称与文件I / O相关，而在第二个名称中，它与同步工具有关：

等待/ IO /文件/ MyISAM数据/日志
等待/同步/湿/ MyISAM数据/ MI_SORT_INFO :: COND

仪器名称包含一个前缀，该前缀具有由Performance Schema实现定义的结构，以及由实现仪器代码的开发人员定义的后缀。仪器前缀的顶级组件表示仪器的类型。该组件还确定 performance_timers 表中的哪个事件计时器适用于仪器。对于仪器名称的前缀部分，顶级表示仪器的类型。

仪器名称的后缀部分来自仪器本身的代码。后缀可能包括以下级别：

一种主要成分名（一服务器模块，例如 myisam ， innodb ， mysys ，或 sql ）或插件名称。
代码中变量的名称，形式 XXX （全局变量）或（类中的成员）。例如：，，。 CCC::MMM MMM CCC COND_thread_cache THR_LOCK_myisam BINLOG::LOCK_index

顶级仪器组件
闲置仪表组件
错误仪器组件
记忆仪器组件
舞台乐器组件
声明仪器组件
螺纹仪器组件
等待仪器组件

顶级仪器组件

idle ：一个仪表化的空闲事件。该仪器没有其他组件。
error ：检测错误事件。该仪器没有其他组件。
memory ：一个检测内存事件。
stage ：仪表化舞台活动。
statement ：一个检测语句事件。
transaction ：已检测的事务事件。该仪器没有其他组件。
wait ：一个仪表化的等待事件。

闲置仪表组件

该 idle 工具用于空闲事件，性能模式生成，如第26.12.3.5节“socket_instances表” 中的 socket_instances.STATE 列说明中所述。

错误仪器组件

该 error 仪器指示是否收集服务器错误和警告信息。默认情况下启用此仪器。表中行的 TIMED 列不适用，因为未收集计时信息。 error setup_instruments

记忆仪器组件

默认情况下启用内存检测。内存检测可以在启动时启用或禁用，也可以在运行时通过更新表中 ENABLED 相关仪器的列动态启用 setup_instruments 。记忆仪器具有表格的名称，其中的值是或，并且是仪器细节。 memory/code_area/instrument_name code_area sql myisam instrument_name

使用前缀命名的仪器会 memory/performance_schema/ 在性能模式中公开为内部缓冲区分配的内存量。该 memory/performance_schema/ 仪器是建立在，始终处于启用状态，并且不能在启动或运行时被禁用。内置记忆仪器仅显示在 memory_summary_global_by_event_name 表格中。有关更多信息，请参见第26.17节“性能模式内存分配模型” 。

舞台乐器组件

舞台乐器具有形式的名称，其中是诸如或的值，并且表示声明处理的阶段，例如或。阶段对应于表中显示的或在表中可见的线程状态。 stage/code_area/stage_name code_area sql myisam stage_name Sorting result Sending data SHOW PROCESSLIST INFORMATION_SCHEMA.PROCESSLIST

声明仪器组件

statement/abstract/* ：语句操作的抽象工具。在已知确切语句类型之前，在语句分类的早期阶段使用抽象工具，然后在已知类型时将其更改为更具体的语句工具。有关此过程的说明，请参见第26.12.6节“性能模式语句事件表” 。
statement/com ：一个检测的命令操作。它们具有与操作相对应的名称（参见头文件和。例如，和仪器对应于和命令。 COM_xxx mysql_com.h sql/sql_parse.cc statement/com/Connect statement/com/Init DB COM_CONNECT COM_INIT_DB
statement/scheduler/event ：用于跟踪事件调度程序执行的所有事件的单个工具。当预定事件开始执行时，该仪器开始起作用。
statement/sp ：由存储程序执行的检测内部指令。例如， statement/sp/cfetch 和 statement/sp/freturn 仪器使用游标提取和函数返回指令。
statement/sql ：检测的SQL语句操作。例如， statement/sql/create_db 和 statement/sql/select 仪器用于 CREATE DATABASE 和 SELECT 声明。

螺纹仪器组件

检测线程显示在 setup_threads 表中，该表公开了线程类名称和属性。

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

等待仪器组件

wait/io

仪表化I / O操作。
- wait/io/file
  
  检测文件I / O操作。对于文件，等待是等待文件操作完成的时间（例如，调用 fwrite() ）。由于缓存，磁盘上的物理文件I / O可能不会在此调用中发生。
- wait/io/socket
  
  一个检测的套接字操作。套接字工具具有表单的名称。服务器为其支持的每个网络协议都有一个侦听套接字。与TCP / IP或Unix套接字文件连接的侦听套接字关联的工具的值分别为或。当侦听套接字检测到连接时，服务器将连接传输到由单独线程管理的新套接字。新连接线程的工具的值为。 wait/io/socket/sql/socket_type socket_type server_tcpip_socket server_unix_socket socket_type client_connection
- wait/io/table
  
  一个检测表I / O操作。这些包括对持久性基表或临时表的行级访问。影响行的操作是获取，插入，更新和删除。对于视图，等待与视图引用的基表相关联。
  
  与大多数等待不同，表I / O等待可以包括其他等待。例如，表I / O可能包括文件I / O或内存操作。因此， events_waits_current 对于表I / O等待通常有两行。有关更多信息，请参见第26.8节“性能模式原子和分子事件” 。
  
  某些行操作可能会导致多个表I / O等待。例如，插入可能会激活导致更新的触发器。
wait/lock

仪表锁定操作。
- wait/lock/table
  
  一种检测表锁定操作。
- wait/lock/metadata/sql/mdl
  
  检测的元数据锁定操作。
wait/synch

检测的同步对象。对于同步对象， TIMER_WAIT 时间包括尝试获取对象锁定时被阻止的时间量（如果有）。
- wait/synch/cond
  
  一个线程使用一个条件向其他线程发信号通知它们正在等待的事情发生了。如果单个线程正在等待某个条件，则它可以唤醒并继续执行。如果有几个线程在等待，它们都可以醒来并争夺他们正在等待的资源。
- wait/synch/mutex
  
  互斥对象，用于允许访问资源（例如可执行代码的一部分），同时防止其他线程访问资源。
- wait/synch/prlock
  
  优先级 rwlock 锁定对象。
- wait/synch/rwlock
  
  一个普通的读/写锁对象，用于锁定特定变量以进行访问，同时防止其他线程使用它。共享读锁可以由多个线程同时获取。一次只能通过一个线程获取独占写锁。
- wait/synch/sxlock
  
  共享独占（SX）锁是一种 rwlock 锁对象，它提供对公共资源的写访问，同时允许其他线程的读取不一致。 sxlocks 优化并发性并提高读写工作负载的可伸缩性。

26.7性能模式状态监控

有几个与Performance Schema关联的状态变量：

MySQL的> SHOW STATUS LIKE 'perf%';
+ ----------------------------------------------- +  - ------ +
| Variable_name | 价值|
+ ----------------------------------------------- +  - ------ +
| Performance_schema_accounts_lost | 0 |
| Performance_schema_cond_classes_lost | 0 |
| Performance_schema_cond_instances_lost | 0 |
| Performance_schema_digest_lost | 0 |
| Performance_schema_file_classes_lost | 0 |
| Performance_schema_file_handles_lost | 0 |
| Performance_schema_file_instances_lost | 0 |
| Performance_schema_hosts_lost | 0 |
| Performance_schema_locker_lost | 0 |
| Performance_schema_memory_classes_lost | 0 |
| Performance_schema_metadata_lock_lost | 0 |
| Performance_schema_mutex_classes_lost | 0 |
| Performance_schema_mutex_instances_lost | 0 |
| Performance_schema_nested_statement_lost | 0 |
| Performance_schema_program_lost | 0 |
| Performance_schema_rwlock_classes_lost | 0 |
| Performance_schema_rwlock_instances_lost | 0 |
| Performance_schema_session_connect_attrs_lost | 0 |
| Performance_schema_socket_classes_lost | 0 |
| Performance_schema_socket_instances_lost | 0 |
| Performance_schema_stage_classes_lost | 0 |
| Performance_schema_statement_classes_lost | 0 |
| Performance_schema_table_handles_lost | 0 |
| Performance_schema_table_instances_lost | 0 |
| Performance_schema_thread_classes_lost | 0 |
| Performance_schema_thread_instances_lost | 0 |
| Performance_schema_users_lost | 0 |
+ ----------------------------------------------- +  - ------ +

Performance Schema状态变量提供有关由于内存限制而无法加载或创建的检测的信息。这些变量的名称有以下几种形式：

Performance_schema_xxx_classes_lost 表示 xxx 无法加载多少种类型的乐器。
Performance_schema_xxx_instances_lost 表示 xxx 无法创建多少个对象类型的实例。
Performance_schema_xxx_handles_lost 表示 xxx 无法打开多少个对象类型的实例。
Performance_schema_locker_lost 表示 “ 丢失 ” 或未记录的事件数。

例如，如果在服务器源中检测了互斥锁，但服务器无法在运行时为检测分配内存，则会增加 Performance_schema_mutex_classes_lost 。互斥锁仍然充当同步对象（即，服务器继续正常运行），但不会收集它的性能数据。如果可以分配仪器，则可以将其用于初始化已检测的互斥锁实例。对于单个互斥锁（如全局互斥锁），只有一个实例。其他互斥锁在每个连接上都有一个实例，或者在各种缓存和数据缓冲区中每页都有一个实例，因此实例数会随时间而变化。增加最大连接数或某些缓冲区的最大大小将增加可能一次分配的最大实例数。如果服务器无法创建给定的检测互斥锁实例，则会递增 Performance_schema_mutex_instances_lost 。

假设满足以下条件：

服务器启动时带有 --performance_schema_max_mutex_classes=200 选项，因此可以容纳200个互斥仪器。
已经加载了150个互斥仪器。
该插件名称 plugin_a 包含40个互斥乐器。
该插件 plugin_b 包含20个互斥乐器。

服务器根据插件的数量和可用数量分配插件的互斥工具，如以下语句序列所示：

安装PLUGIN plugin_a

服务器现在有150 + 40 = 190互斥仪器。

UNINSTALL PLUGIN plugin_a;

服务器仍然有190个仪器。插件代码生成的所有历史数据仍然可用，但不会收集仪器的新事件。

安装PLUGIN plugin_a;

服务器检测到已定义了40个仪器，因此不会创建新仪器，并且可以重复使用先前分配的内部存储器缓冲区。服务器仍然有190个仪器。

INSTALL PLUGIN plugin_b;

服务器有200-190 = 10个仪器的空间（在这种情况下，互斥类），并看到该插件包含20个新仪器。 10种仪器被加载，和10被丢弃或 “ 丢失。 ” 的 Performance_schema_mutex_classes_lost 指示仪表（互斥类）丢失的数目：

MySQL的> SHOW STATUS LIKE "perf%mutex_classes_lost";
+ --------------------------------------- + ------- +
| Variable_name | 价值|
+ --------------------------------------- + ------- +
| Performance_schema_mutex_classes_lost | 10 |
+ --------------------------------------- + ------- +
1排（0.10秒）

仪器仍然可以工作并收集（部分）数据 plugin_b 。

当服务器无法创建互斥锁仪器时，会出现以下结果：

没有仪器的行插入 setup_instruments 表中。
Performance_schema_mutex_classes_lost 增加1。
Performance_schema_mutex_instances_lost 不会改变。（如果未创建互斥锁仪器，则以后不能用于创建已检测的互斥锁实例。）

刚才描述的模式适用于所有类型的仪器，而不仅仅是互斥体。

Performance_schema_mutex_classes_lost 在两种情况下可能会发生大于0的值：

为了节省内存的几个字节，你先从服务器，其中小于默认值。选择默认值足以加载MySQL发行版中提供的所有插件，但如果从未加载某些插件，则可以减少此值。例如，您可以选择不在分发中加载某些存储引擎。 --performance_schema_max_mutex_classes=N N
您加载了为性能模式检测的第三方插件，但在启动服务器时不允许插件的检测内存要求。因为它来自第三方，所以此引擎的仪器内存消耗不计入所选的默认值 performance_schema_max_mutex_classes 。

如果服务器没有足够的资源用于插件的工具，并且您没有明确分配更多的使用，则加载插件会导致仪器的饥饿。 --performance_schema_max_mutex_classes=N

如果选择的值 performance_schema_max_mutex_classes 太小，则错误日志中不会报告错误，并且运行时没有失败。但是， performance_schema 数据库中表的内容将错过事件。该 Performance_schema_mutex_classes_lost 状态变量是唯一明显的迹象表明，一些事件因未能创建仪器内部下降。

如果仪器没有丢失，则表现为性能模式，并在检测实例时使用。例如，表 wait/synch/mutex/sql/LOCK_delete 中是互斥锁仪器的名称 setup_instruments 。在代码（in THD::LOCK_delete ）中创建互斥锁时使用此单个工具，但在服务器运行时需要多个互斥锁实例。在这种情况下， LOCK_delete 是每个连接（ THD ）的互斥锁，因此如果服务器有1000个连接，则有1000个线程和1000个已检测的 LOCK_delete 互斥锁实例（ THD::LOCK_delete ）。

如果服务器没有空间容纳所有这些1000个检测的互斥锁（实例），则会使用检测创建一些互斥锁，而某些互斥锁则在没有检测的情况下创建。如果服务器只能创建800个实例，则会丢失200个实例。服务器继续运行，但递增 Performance_schema_mutex_instances_lost 200以指示无法创建实例。

Performance_schema_mutex_instances_lost 当代码在运行时初始化多于分配的互斥锁时，可能会发生大于0的值。 --performance_schema_max_mutex_instances=N

最重要的是，如果 SHOW STATUS LIKE 'perf%' 说什么都没有丢失（所有值都为零），性能模式数据是准确的，可以依赖。如果丢失了某些内容，则数据不完整，并且在给定使用的内存量不足的情况下，性能模式无法记录所有内容。在这种情况下，特定变量表示问题区域。 Performance_schema_xxx_lost

在某些情况下，引起故意的仪器饥饿可能是恰当的。例如，如果您不关心文件I / O的性能数据，则可以使用与文件I / O设置为0相关的所有性能模式参数启动服务器。不会为与文件相关的类，实例分配内存，或句柄，所有文件事件都将丢失。

使用 SHOW ENGINE PERFORMANCE_SCHEMA STATUS 检查绩效模式的代码的内部操作：

MySQL的> SHOW ENGINE PERFORMANCE_SCHEMA STATUS\G
...
*************************** 3。排******************** *******
  输入：performance_schema
  名称：events_waits_history.size
状态：76
****************************排******************** *******
  输入：performance_schema
  名称：events_waits_history.count
状态：10000
****************************排******************** *******
  输入：performance_schema
  名称：events_waits_history.memory
状态：760000
...
*************************** 57.排******************** *******
  输入：performance_schema
  名称：performance_schema.memory
状态：26459600
...

此语句旨在帮助DBA了解不同性能模式选项对内存要求的影响。有关字段含义的说明，请参见第13.7.6.15节“SHOW ENGINE语法” 。

26.8性能模式原子和分子事件

对于表I / O事件，通常有两行 events_waits_current ，而不是一行。例如，行提取可能会产生如下行：

行＃EVENT_NAME TIMER_START TIMER_END
---- ---------- ----------- ---------
   1等待/ 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等待也是最近等待的任何类型。

26.9当前和历史事件的性能模式表

对于等待，阶段，语句和事务事件，性能模式可以监视和存储当前事件。此外，当事件结束时，性能模式可以将它们存储在历史表中。对于每种事件类型，性能模式使用三个表来存储当前事件和历史事件。该表具有以下形式的名称，其中， xxx 指示事件类型（ waits ， stages ， statements ， transactions ）：

events_xxx_current ： “ 当前事件 ” 表存储每个线程的当前受监视事件（每个线程一行）。
events_xxx_history ： “ 最近历史记录 ” 表存储每个线程已结束的最新事件（最多为每个线程的最大行数）。
events_xxx_history_long ： “ long history ” 表存储全局结束的最新事件（跨所有线程，最多每个表的最大行数）。

_current 每个事件类型的表包含每个线程一行，因此没有用于配置其最大大小的系统变量。性能模式自动调整历史记录表，或者可以使用特定于表的系统变量在服务器启动时显式配置大小，如描述各个历史记录表的部分所示。 _history 表的每个线程的典型自动调整值为10行，表的总计为10,000行 _history_long 。

对于每个事件类型， _current ， _history ，和 _history_long 表有相同的列。在 _current 与 _history 表具有相同的索引。该 _history_long 表没有索引。

该 _current 表显示了什么是目前服务器内发生的事情。当前事件结束时，将从其 _current 表中删除它。

这些 _history 和 _history_long 表格显示了最近发生的事情。当历史表变满时，旧事件将在添加新事件时被丢弃。行以不同的方式从 _history 和 _history_long 表到期，因为表用于不同的目的：

_history 用于调查各个线程，与全局服务器负载无关。
_history_long 是为了全局调查服务器，而不是每个线程。

两种类型的历史表之间的差异与数据保留策略有关。首次看到事件时，两个表都包含相同的数据。但是，每个表中的数据随着时间的推移会有所不同，因此每个表中的数据可能会保留更长或更短的时间：

因为 _history ，当表包含给定线程的最大行数时，当添加该线程的新行时，将丢弃最旧的线程行。
因为 _history_long ，当表变满时，添加新行时将丢弃最旧的行，而不管哪个行生成了哪一行。

当一个线程结束时，它的所有行都将从 _history 表中丢弃，但不会从 _history_long 表中丢弃。

以下示例说明了如何在两种类型的历史记录表中添加和丢弃事件的差异。这些原则同样适用于所有事件类型。该示例基于以下假设：

性能模式配置为在 _history 表中每个线程保留10行，在表中保留 10,000行 _history_long 。
线程A每秒生成1个事件。

线程B每秒生成100个事件。
没有其他线程在运行。

执行5秒后：

A和B分别产生了5和500个事件。
_history A包含5行，B包含10行。因为每个线程的存储限制为10行，所以A没有丢弃任何行，而B丢弃了490行。
_history_long 包含5行A和500行B.因为表的最大大小为10,000行，所以没有任何行被丢弃。

执行5分钟（300秒）后：

A和B分别产生了300和30,000个事件。
_history A包含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的行混合大约100比1而不是A.

26.10性能模式语句摘要和抽样

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

无论性能模式是否可用，解析器都会发生摘要，因此查询重写插件等其他服务器组件可以访问语句摘要。

声明摘要一般概念
性能模式中的语句摘要
声明摘要内存使用
声明抽样

声明摘要一般概念

当解析器收到SQL语句时，如果需要该摘要，它将计算语句摘要，如果满足以下任一条件，则为true：

已启用Performance Schema摘要检测
启用了“查询重写插件”

解析器也由 STATEMENT_DIGEST_TEXT() 和 STATEMENT_DIGEST() 函数使用，应用程序可以调用这些解析器分别从SQL语句计算规范化语句摘要和摘要散列值。

所述 max_digest_length 系统变量值确定归一化的语句摘要的计算每个会话中可用的字节的最大数量。在摘要计算期间使用该空间量后，将发生截断：不会收集来自已解析语句的其他标记或将其计入其摘要值。仅在解析的令牌的许多字节之后不同的语句产生相同的规范化语句摘要，并且如果比较或者如果聚合用于摘要统计则被认为是相同的。

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

如果启用了任何Query Rewrite Plugin，则会调用它，并且语句摘要和摘要值可用。
如果性能模式启用了摘要检测，它会生成规范化语句摘要的副本，为其分配最大 performance_schema_max_digest_length 字节数。因此，如果 performance_schema_max_digest_length 小于 max_digest_length ，则相对于原始副本被截断。规范化语句摘要的副本存储在相应的性能模式表中，以及从原始规范化语句计算的SHA-256哈希值。（如果Performance Schema截断了相对于原始语法的规范化语句摘要的副本，则它不会重新计算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 =？和数量>？

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

现在考虑以下陈述：

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 =？和......

在这种情况下，第二列名称的差异将丢失，并且两个语句都被视为相同。

性能模式中的语句摘要

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

表中的 statements_digest 使用者 setup_consumers 控制性能模式是否维护摘要信息。请参阅 Statement Digest Consumer 。
语句事件表（ 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哈希值。
请参见第26.12.6节“性能模式语句事件表” 。
该 events_statements_summary_by_digest 汇总表提供汇总声明摘要信息。此表汇总了语句per SCHEMA_NAME 和 DIGEST combination的信息。性能模式使用SHA-256哈希值进行聚合，因为它们计算速度快，并且具有有利的统计分布，可最大限度地减少冲突。请参见第26.12.16.3节“语句汇总表” 。

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

在 SQL_TEXT 该列 events_statements_current ， events_statements_history 和 events_statements_history_long 语句事件表。
摘要表的 QUERY_SAMPLE_TEXT 列 events_statements_summary_by_digest 。

默认情况下，语句显示的最大可用空间为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 ：
- 性能模式以外的服务器组件使用最多占用 max_digest_length 字节的规范化语句摘要。
- 性能模式进一步截断了它存储的规范化语句摘要，并且 max_digest_length 每个摘要分配的内存少于字节数。

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

需要为Performance Schema之外的服务器组件提供长规范化语句摘要
许多并发会话，每个会话分配摘要计算内存
存储许多语句摘要时，需要通过Performance Schema语句事件表限制内存消耗

该 performance_schema_max_digest_length 设置不是每个会话，它是per语句，并且会话可以在 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。

26.11性能模式通用表特性

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

performance_schema 数据库中的许多表都是只读的，无法修改：

MySQL的> TRUNCATE TABLE performance_schema.setup_instruments;
ERROR 1683（HY000）：performance_schema使用无效。

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

可以截断摘要表 TRUNCATE TABLE 。通常，效果是将摘要列重置为0，或者 NULL 不删除行。这使您可以清除收集的值并重新启动聚合。例如，在您更改运行时配置之后，这可能很有用。单个摘要表部分中记录了此截断行为的例外情况。

权限与其他数据库和表一样：

要从 performance_schema 表中检索，您必须具有该 SELECT 权限。
要更改可以修改的列，您必须具有该 UPDATE 权限。
要截断可以截断的表，您必须具有该 DROP 权限。

由于只有一组有限的权限适用于Performance Schema表，因此尝试 GRANT ALL 用作在数据库或表leval上授予权限的简写失败，并显示错误：

MySQL的> GRANT ALL ON performance_schema.*
       TO 'u1'@'localhost';
ERROR 1044（42000）：用户'root'@'localhost'拒绝访问
到数据库'performance_schema'
MySQL的> GRANT ALL ON performance_schema.setup_instruments
       TO 'u2'@'localhost';
ERROR 1044（42000）：用户'root'@'localhost'拒绝访问
到数据库'performance_schema'

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

MySQL的> GRANT SELECT ON performance_schema.*
       TO 'u1'@'localhost';
查询正常，0行受影响（0.03秒）

MySQL的> GRANT SELECT, UPDATE ON performance_schema.setup_instruments
       TO 'u2'@'localhost';
查询OK，0行受影响（0.02秒）

26.12性能架构表描述

26.12.1性能模式表索引
26.12.2性能模式设置表
26.12.3性能模式实例表
26.12.4性能模式等待事件表
26.12.5性能模式阶段事件表
26.12.6性能模式语句事件表
26.12.7性能模式事务表
26.12.8性能模式连接表
26.12.9性能模式连接属性表
26.12.10性能模式用户定义的变量表
26.12.11性能模式复制表
26.12.12性能模式锁表
26.12.13性能模式系统变量表
26.12.14性能模式状态变量表
26.12.15性能架构线程池表
26.12.16性能模式摘要表
26.12.17性能模式其他表

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 。
汇总表。这些表包含通过事件组聚合的信息，包括已从历史记录表中丢弃的事件。
实例表。这些表记录了检测的对象类型。当由服务器使用时，检测对象产生事件。这些表提供事件名称和解释性说明或状态信息。
杂项表。这些不属于任何其他表组。

26.12.1性能模式表索引

下表列出了每个Performance Schema表，并提供了每个表的简短描述。

表26.1性能架构表

表名	描述
`accounts`	每个客户帐户的连接统计
`cond_instances`	同步对象实例
`data_lock_waits`	数据锁等待关系
`data_locks`	持有和请求数据锁
`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`	Stage等待每个线程和事件名称
`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`	每个文件实例的文件事件
`global_status`	全局状态变量
`global_variables`	全局系统变量
`host_cache`	来自内部主机缓存的信息
`hosts`	每个客户端主机名的连接统计
`keyring_keys`	密钥环密钥的元数据
`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`	互斥同步对象实例
`objects_summary_global_by_type`	对象摘要
`performance_timers`	哪些活动计时器可用
`persisted_variables`	`mysqld-auto.cnf` 文件内容
`prepared_statements_instances`	准备好的语句实例和统计信息
`replication_applier_configuration`	从站上的事务应用程序的配置参数
`replication_applier_status`	从站上的事务应用程序的当前状态
`replication_applier_status_by_coordinator`	SQL或协调程序线程应用程序状态
`replication_applier_status_by_worker`	工作线程应用程序状态（除非slave是多线程的，否则为空）
`replication_connection_configuration`	用于连接主站的配置参数
`replication_connection_status`	与主站的连接的当前状态
`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`	有关服务器线程的信息
`tp_thread_group_state`	有关线程池线程组状态的信息
`tp_thread_group_stats`	线程组统计信息
`tp_thread_state`	有关线程池线程状态的信息
`user_defined_functions`	注册的用户定义函数
`user_variables_by_thread`	每个线程的用户定义变量
`users`	每个客户端用户名的连接统计
`variables_by_thread`	每个会话的会话系统变量
`variables_info`	最近如何设置系统变量

26.12.2性能模式设置表

26.12.2.1 setup_actors表
26.12.2.2 setup_consumers表
26.12.2.3 setup_instruments表
26.12.2.4 setup_objects表
26.12.2.5 setup_threads表
26.12.2.6 setup_timers表

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

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

这些设置表可用：

setup_actors ：如何初始化新前台线程的监视
setup_consumers ：可以发送和存储事件信息的目标
setup_instruments ：可以为其收集事件的已检测对象的类
setup_objects ：应监控哪些对象
setup_threads ：检测线程名称和属性

26.12.2.1 setup_actors表

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

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

对于后台线程，没有关联的用户。 INSTRUMENTED 并且 HISTORY 是 YES 在默认情况下并 setup_actors 没有意见。

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

MySQL的> SELECT * FROM performance_schema.setup_actors;
+ ------ + ------ + ------ + --------- + --------- +
| 主持人| 用户| 角色| 启用| 历史|
+ ------ + ------ + ------ + --------- + --------- +
| ％| ％| ％| 是的| 是的|
+ ------ + ------ + ------ + --------- + --------- +

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

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

该 setup_actors 表包含以下列：

HOST

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

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

没用过。
ENABLED

是否为行匹配的前台线程启用检测。值是 YES 或 NO 。
HISTORY

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

该 setup_actors 表包含以下索引：

在主键（ HOST ， USER ， ROLE ）

TRUNCATE TABLE 是允许的 setup_actors 表。它删除了行。

26.12.2.2 setup_consumers表

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

MySQL的> SELECT * FROM performance_schema.setup_consumers;
+ ---------------------------------- + --------- +
| NAME | 启用|
+ ---------------------------------- + --------- +
| events_stages_current | 没有|
| events_stages_history | 没有|
| events_stages_history_long | 没有|
| events_statements_current | 是的|
| events_statements_history | 是的|
| events_statements_history_long | 没有|
| events_transactions_current | 是的|
| events_transactions_history | 是的|
| events_transactions_history_long | 没有|
| events_waits_current | 没有|
| events_waits_history | 没有|
| events_waits_history_long | 没有|
| global_instrumentation | 是的|
| thread_instrumentation | 是的|
| statements_digest | 是的|
+ ---------------------------------- + --------- +

setup_consumers 表中的使用者设置形成从较高级别到较低级别的层次结构。有关启用不同消费者的效果的详细信息，请参见第26.4.7节“按消费者预过滤” 。

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

该 setup_consumers 表包含以下列：

NAME

消费者名称。
ENABLED

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

该 setup_consumers 表包含以下索引：

主键（ NAME ）

TRUNCATE TABLE 不允许使用该 setup_consumers 表。

26.12.2.3 setup_instruments表

该 setup_instruments 表列出了可以为其收集事件的检测对象的类：

MySQL的> SELECT * FROM performance_schema.setup_instruments\G
*************************** 1。排******************** *******
         名称：wait / synch / mutex / pfs / LOCK_pfs_share_list
      启用：没有
        时间：没有
   特性：单身
   挥发性：1
文档：组件可以提供自己的performance_schema表。
               此锁保护此类表定义的列表。
...
*************************** 369.排******************** *******
         名称：stage / sql / execution
      启用：没有
        时间：没有
   属性： 
   波动性：0
文档：NULL
...
*************************** 687.排******************** *******
         名称：statement / abstract / Query
      启用：是的
        时间：是的
   特性：可变
   波动性：0
文档：刚刚从网络收到的SQL查询。在此刻，
               真实的语句类型是未知的，类型将是
               SQL解析后改进。
...
*************************** 696.排******************** *******
         名称：memory / performance_schema / metadata_locks
      启用：是的
        TIMED：NULL
   属性：global_statistics
   挥发性：1
文档：用于表performance_schema.metadata_locks的内存
...

添加到源代码中的每个工具都为 setup_instruments 表提供了一行，即使未执行检测代码也是如此。启用并执行仪器后，将创建已检测的实例，这些实例在 xxx_instances 表中可见，例如 file_instances 或 rwlock_instances 。

有关 setup_instruments 表在事件过滤中的作用的更多信息，请参见第26.4.3节“事件预过滤” 。

该 setup_instruments 表包含以下列：

NAME

仪器名称。仪器名称可能有多个部分并形成层次结构，如第26.6节“性能架构仪器命名约定”中所述。执行仪器产生的事件具有 EVENT_NAME 取自仪器 NAME 值的值。（事件实际上没有 “ 名称 ”，但这提供了一种将事件与工具相关联的方法。）
ENABLED

仪器是否已启用。值是 YES 或 NO 。禁用的乐器不会产生任何事件。虽然设置 ENABLED 对已创建的仪器没有影响，但可以修改此列。
TIMED

仪器是否定时。值是 YES ， NO ，或 NULL 。虽然设置 TIMED 对已创建的仪器没有影响，但可以修改此列。

甲 TIMED 的值 NULL 表示该仪器不支持定时。例如，内存操作没有定时，所以它们的 TIMED 列是 NULL 。

设置 TIMED 到 NULL 对于支持定时没有影响的仪器，如不设置 TIMED 于非 NULL 对不支持定时的仪器。

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

仪器属性。此列使用 SET 数据类型，因此可以为每个工具设置以下列表中的多个标志：
- global_statistics ：该工具仅生成全局摘要。更精细级别的摘要不可用，例如每个线程，帐户，用户或主机。例如，大多数记忆仪器仅产生全局摘要。
- mutable ：该仪器可以 “ 变异 ” 为更具体的一种。此属性仅适用于声明工具。
- progress ：仪器能够报告进度数据。此属性仅适用于舞台乐器。
- singleton ：仪器有一个实例。例如，服务器中的大多数全局互斥锁都是单例，因此相应的工具也是如此。
- user ：仪器与用户工作负载直接相关（与系统工作负载相反）。一个这样的工具是 wait/io/socket/sql/client_connection 。
VOLATILITY

仪器波动。波动率值从低到高。这些值对应于头文件中定义的常量： PSI_VOLATILITY_xxx mysql/psi/psi_base.h
```
#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 现有会话互斥锁，但会对更新后创建的新会话产生影响：
```
更新performance_schema.setup_instruments
SET ENABLED =value
WHERE NAME ='wait / synch / mutex / sql / THD :: LOCK_query_plan';
```
该声明实际上根本没有效果：
```
更新performance_schema.setup_instruments
SET ENABLED =value
WHERE NAME ='wait / synch / mutex / pfs / LOCK_pfs_share_list';
```
此互斥锁是永久性的，并且在执行更新之前已创建。永远不会再次创建互斥锁，因此永远不会使用 ENABLED 值 setup_instruments 。要启用或禁用此互斥锁，请改用 mutex_instances 表格。
DOCUMENTATION

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

该 setup_instruments 表包含以下索引：

主键（ NAME ）

TRUNCATE TABLE 不允许使用该 setup_instruments 表。

26.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 | 启用| 定时|
+ ------------- + -------------------- + ------------- + --------- ------- + +
| 活动| mysql | ％| 没有| 没有|
| 活动| performance_schema | ％| 没有| 没有|
| 活动| information_schema | ％| 没有| 没有|
| 活动| ％| ％| 是的| 是的|
| 功能| mysql | ％| 没有| 没有|
| 功能| performance_schema | ％| 没有| 没有|
| 功能| information_schema | ％| 没有| 没有|
| 功能| ％| ％| 是的| 是的|
| 程序| mysql | ％| 没有| 没有|
| 程序| performance_schema | ％| 没有| 没有|
| 程序| information_schema | ％| 没有| 没有|
| 程序| ％| ％| 是的| 是的|
| 表| mysql | ％| 没有| 没有|
| 表| performance_schema | ％| 没有| 没有|
| 表| information_schema | ％| 没有| 没有|
| 表| ％| ％| 是的| 是的|
| TRIGGER | mysql | ％| 没有| 没有|
| TRIGGER | performance_schema | ％| 没有| 没有|
| TRIGGER | information_schema | ％| 没有| 没有|
| TRIGGER | ％| ％| 是的| 是的|
+ ------------- + -------------------- + ------------- + --------- ------- + +

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

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

缺省对象配置的效果是仪器除了那些在所有的表 mysql ， INFORMATION_SCHEMA 和 performance_schema 数据库。（ INFORMATION_SCHEMA 无论内容如何，数据库中的表都没有检测 setup_objects ;行为 information_schema.% 只是使其默认为显式。）

当性能模式检查匹配时 setup_objects ，它会尝试首先查找更具体的匹配项。例如，有一张桌子 db1.t1 ，它会寻找一个匹配 'db1' 和 't1' ，然后 'db1' 和 '%' ，然后 '%' 和 '%' 。匹配发生的顺序很重要，因为不同的匹配 setup_objects 行可以具有不同的值 ENABLED 和 TIMED 值。

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

有关 setup_objects 表在事件过滤中的作用的更多信息，请参见第26.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

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

该 setup_objects 表包含以下索引：

指数（ OBJECT_TYPE ， OBJECT_SCHEMA ， OBJECT_NAME ）

TRUNCATE TABLE 是允许的 setup_objects 表。它删除了行。

26.12.2.5 setup_threads表

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

MySQL的> SELECT * FROM performance_schema.setup_threads\G
*************************** 1。排******************** *******
         名称：thread / performance_schema / setup
      启用：是的
      历史：是的
   特性：单身
   波动性：0
文档：NULL
...
****************************排******************** *******
         名称：thread / sql / main
      启用：是的
      历史：是的
   特性：单身
   波动性：0
文档：NULL
****************************排******************** *******
         名称：thread / sql / one_connection
      启用：是的
      历史：是的
   属性：用户
   波动性：0
文档：NULL
...
*************************** 10.排******************** *******
         名称：thread / sql / event_scheduler
      启用：是的
      历史：是的
   特性：单身
   波动性：0
文档：NULL

该 setup_threads 表包含以下列：

NAME

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

仪器是否已启用。值是 YES 或 NO 。虽然设置 ENABLED 对已经运行的线程没有影响，但可以修改此列。

对于后台线程，设置 ENABLED 值控制 INSTRUMENTED 是设置为 YES 还是 NO 为随后为此工具创建并在 threads 表中列出的线程。对于前台线程，此列无效; 该 setup_actors 表优先。
HISTORY

是否记录仪器的历史事件。值是 YES 或 NO 。虽然设置 HISTORY 对已经运行的线程没有影响，但可以修改此列。

对于后台线程，设置 HISTORY 值控制 HISTORY 是设置为 YES 还是 NO 为随后为此工具创建并在 threads 表中列出的线程。对于前台线程，此列无效; 该 setup_actors 表优先。
PROPERTIES

仪器属性。此列使用 SET 数据类型，因此可以为每个工具设置以下列表中的多个标志：
- singleton ：仪器有一个实例。例如， thread/sql/main 仪器只有一个螺纹。
- user ：仪器与用户工作负载直接相关（与系统工作负载相反）。例如，诸如 thread/sql/one_connection 执行用户会话之类的线程具有将 user 它们与系统线程区分开的属性。
VOLATILITY

仪器波动。此列与 setup_instruments 表中的含义相同。请参见第26.12.2.3节“setup_instruments表” 。
DOCUMENTATION

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

该 setup_threads 表包含以下索引：

主键（ NAME ）

TRUNCATE TABLE 不允许使用该 setup_threads 表。

26.12.2.6 setup_timers表

此表已在MySQL 8.0.4中删除。

26.12.3性能模式实例表

26.12.3.1 cond_instances表
26.12.3.2 file_instances表
26.12.3.3 mutex_instances表
26.12.3.4 rwlock_instances表
26.12.3.5 socket_instances表

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

cond_instances ：条件同步对象实例
file_instances ：文件实例
mutex_instances ：Mutex同步对象实例
rwlock_instances ：锁定同步对象实例
socket_instances ：活动连接实例

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

在 mutex_instances.LOCKED_BY_THREAD_ID 与 rwlock_instances.WRITE_LOCKED_BY_THREAD_ID 列调查性能瓶颈或死锁非常重要的。有关如何将其用于此目的的示例，请参见第26.19节“使用性能模式诊断问题”

26.12.3.1 cond_instances表

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

当线程正在等待某事发生时，条件名称表示线程正在等待什么，但是没有直接的方法来判断哪个其他线程或线程将导致该条件发生。

该 cond_instances 表包含以下列：

NAME

与条件关联的仪器名称。
OBJECT_INSTANCE_BEGIN

仪表化条件的内存地址。

该 cond_instances 表包含以下索引：

主键（ OBJECT_INSTANCE_BEGIN ）
索引（ NAME ）

TRUNCATE TABLE 不允许使用该 cond_instances 表。

26.12.3.2 file_instances表

该 file_instances 表列出了执行文件I / O检测时性能模式所看到的所有文件。如果磁盘上的文件从未打开过，则不会打开 file_instances 。从磁盘中删除文件时，也会从 file_instances 表中删除该文件。

该 file_instances 表包含以下列：

FILE_NAME

文件名。
EVENT_NAME

与文件关联的仪器名称。
OPEN_COUNT

文件上打开句柄的计数。如果文件已打开然后关闭，则会打开一次，但 OPEN_COUNT 会打开 0.要列出服务器当前打开的所有文件，请使用 WHERE OPEN_COUNT > 0 。

该 file_instances 表包含以下索引：

主键（ FILE_NAME ）
索引（ EVENT_NAME ）

TRUNCATE TABLE 不允许使用该 file_instances 表。

26.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 。

该 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 。

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

events_waits_current ，看看线程正在等待什么互斥量
mutex_instances ，查看哪个其他线程目前拥有互斥锁

26.12.3.4 rwlock_instances表

该 rwlock_instances 表列出了服务器执行时Performance Schema看到的所有 rwlock （读写锁）实例。 An 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.这只是一个计数器，所以它不能直接用于查找哪个线程持有读锁定，但它可以用于查看是否存在a上的读取争用 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 只能用于识别持有写锁定的线程，而不能用于识别持有读锁定的线程。

26.12.3.5 socket_instances表

该 socket_instances 表提供了与MySQL服务器的活动连接的实时快照。该表包含每个TCP / IP或Unix套接字文件连接一行。此表中提供的信息提供了与服务器的活动连接的实时快照。（附加信息在套接字汇总表中可用，包括网络活动，如套接字操作和发送和接收的字节数;请参见第26.12.16.9节“套接字汇总表” ）。

MySQL的> SELECT * FROM performance_schema.socket_instances\G
*************************** 1。排******************** *******
           EVENT_NAME：wait / io / socket / sql / server_unix_socket
OBJECT_INSTANCE_BEGIN：4316619408
            THREAD_ID：1
            SOCKET_ID：16
                   IP：
                 港口：0
                状态：有效
*************************** 2.排******************** *******
           EVENT_NAME：wait / io / socket / sql / client_connection
OBJECT_INSTANCE_BEGIN：4316644608
            THREAD_ID：21
            SOCKET_ID：39
                   IP：127.0.0.1
                 港口：55233
                状态：有效
*************************** 3。排******************** *******
           EVENT_NAME：wait / io / socket / sql / server_tcpip_socket
OBJECT_INSTANCE_BEGIN：4316699040
            THREAD_ID：1
            SOCKET_ID：14
                   IP：0.0.0.0
                 港口：50603
                状态：有效

套接字工具具有表单的名称，并使用如下： wait/io/socket/sql/socket_type

服务器为其支持的每个网络协议都有一个侦听套接字。与TCP / IP或Unix套接字文件连接的侦听套接字关联的工具的 socket_type 值分别为 server_tcpip_socket 或 server_unix_socket 。
当侦听套接字检测到连接时，服务器将连接传输到由单独线程管理的新套接字。新连接线程的工具的 socket_type 值为 client_connection 。
当连接终止时，将 socket_instances 删除与其对应的行。

该 socket_instances 表包含以下列：

EVENT_NAME

wait/io/socket/* 产生事件的工具的名称。这是表中的 NAME 值 setup_instruments 。仪器名称可能有多个部分并形成层次结构，如第26.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 ）

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 ）的客户端连接，端口是服务器分配的任何内容，但从不为0. IP是发起主机（ 127.0.0.1 或 ::1 本地主机）的IP

26.12.4性能模式等待事件表

26.12.4.1 events_waits_current表
26.12.4.2 events_waits_history表
26.12.4.3 events_waits_history_long表

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

这些表存储等待事件：

events_waits_current ：每个线程的当前等待事件。
events_waits_history ：每个线程结束的最新等待事件。
events_waits_history_long ：最近全局结束的等待事件（跨所有线程）。

以下部分描述了等待事件表。还有汇总表来汇总有关等待事件的信息; 请参见第26.12.16.1节“等待事件汇总表” 。

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

配置等待事件收集

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

该 setup_instruments 表包含以名称开头的工具 wait 。使用这些工具启用或禁用单个等待事件类的收集。
该 setup_consumers 表包含消费者值，其名称对应于当前和历史等待事件表名称。使用这些使用者来过滤等待事件的集合。

默认情况下启用一些等待仪器; 其他人被禁用。例如：

MySQL的> SELECT NAME, ENABLED, TIMED
       FROM performance_schema.setup_instruments
       WHERE NAME LIKE 'wait/io/file/innodb%';
+ ------------------------------------------------- + --------- + ------- +
| NAME | 启用| 定时|
+ ------------------------------------------------- + --------- + ------- +
| wait / io / file / innodb / innodb_tablespace_open_file | 是的| 是的|
| wait / io / file / innodb / innodb_data_file | 是的| 是的|
| wait / io / file / innodb / innodb_log_file | 是的| 是的|
| wait / io / file / innodb / innodb_temp_file | 是的| 是的|
| wait / io / file / innodb / innodb_arch_file | 是的| 是的|
| wait / io / file / innodb / innodb_clone_file | 是的| 是的|
+ ------------------------------------------------- + --------- + ------- +
MySQL的> SELECT NAME, ENABLED, TIMED
       FROM performance_schema.setup_instruments
       WHERE NAME LIKE 'wait/io/socket/%';
+ ---------------------------------------- + -------- -  + ------- +
| NAME | 启用| 定时|
+ ---------------------------------------- + -------- -  + ------- +
| wait / io / socket / sql / server_tcpip_socket | 没有| 没有|
| wait / io / socket / sql / server_unix_socket | 没有| 没有|
| wait / io / socket / sql / client_connection | 没有| 没有|
+ ---------------------------------------- + -------- -  + ------- +

默认情况下禁用等待使用者：

MySQL的> SELECT *
       FROM performance_schema.setup_consumers
       WHERE NAME LIKE 'events_waits%';
+ --------------------------- + --------- +
| NAME | 启用|
+ --------------------------- + --------- +
| events_waits_current | 没有|
| events_waits_history | 没有|
| events_waits_history_long | 没有|
+ --------------------------- + --------- +

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

启用：

的[mysqld]
性能架构仪器=“等待/％= ON”
性能架构的消费活动，等待电流= ON
性能架构的消费活动，等待历史= ON
性能架构的消费活动，等待历史长= ON

禁用：

的[mysqld]
性能架构仪器=“等待/％= OFF”
性能架构的消费活动，等待电流= OFF
性能架构的消费活动，等待历史= OFF
性能架构的消费活动，等待历史长= OFF

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

启用：

更新performance_schema.setup_instruments
SET ENABLED ='YES'，TIMED ='YES'
WHERE NAME ='wait /％';

更新performance_schema.setup_consumers
SET ENABLED ='YES'
在哪里名称'events_waits％';

禁用：

更新performance_schema.setup_instruments
SET ENABLED ='NO'，TIMED ='NO'
WHERE NAME ='wait /％';

更新performance_schema.setup_consumers
SET ENABLED ='NO'
在哪里名称'events_waits％';

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

有关配置事件收集的其他信息，请参见第26.3节“性能架构启动配置” 和第26.4节“性能架构运行时配置” 。

26.12.4.1 events_waits_current表

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

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

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

有关配置是否收集等待事件的信息，请参见第26.12.4节“性能架构等待事件表” 。

该 events_waits_current 表包含以下列：

THREAD_ID ， EVENT_ID

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

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

产生事件的工具的名称。这是表中的 NAME 值 setup_instruments 。仪器名称可能有多个部分并形成层次结构，如第26.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 。

有关皮秒作为事件时间单位和影响时间值的因素的讨论，请参见第26.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 ...
```
表 “ 扇出 ” 是在连接处理期间添加表的行数的增加或减少。如果表的扇出 t3 大于1，则大多数行获取操作都是针对该表的。假设访问加入10行从 t1 ，20行从 t2 每行从 t1 ，并从30行 t3 每表中的行 t2 。对于单行报告，检测操作的总数为：
```
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 ）

TRUNCATE TABLE 是允许的 events_waits_current 表。它删除了行。

26.12.4.2 events_waits_history表

该 events_waits_history 表包含 N 每个线程结束的最新等待事件。等待事件在结束之前不会添加到表中。当表包含给定线程的最大行数时，当添加该线程的新行时，将丢弃最旧的线程行。当一个线程结束时，它的所有行都将被丢弃。

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

该 events_waits_history 表具有相同的列和索引 events_waits_current 。请参见第26.12.4.1节“events_waits_current表” 。

TRUNCATE TABLE 是允许的 events_waits_history 表。它删除了行。

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

有关配置是否收集等待事件的信息，请参见第26.12.4节“性能架构等待事件表” 。

26.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 。请参见第26.12.4.1节“events_waits_current表” 。不像 events_waits_current ， events_waits_history_long 没有索引。

TRUNCATE TABLE 是允许的 events_waits_history_long 表。它删除了行。

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

有关配置是否收集等待事件的信息，请参见第26.12.4节“性能架构等待事件表” 。

26.12.5性能模式阶段事件表

26.12.5.1 events_stages_current表
26.12.5.2 events_stages_history表
26.12.5.3 events_stages_history_long表

性能模式工具阶段，它们是语句执行过程中的步骤，例如解析语句，打开表或执行 filesort 操作。阶段对应 SHOW PROCESSLIST 于 INFORMATION_SCHEMA.PROCESSLIST 表中显示的或在表中可见的线程状态。当状态值发生变化时，阶段开始和结束。

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

这些表存储舞台事件：

events_stages_current ：每个线程的当前阶段事件。
events_stages_history ：每个线程结束的最新阶段事件。
events_stages_history_long ：全局结束的最新阶段事件（跨所有线程）。

以下部分描述了舞台事件表。还有汇总表，汇总有关舞台事件的信息; 请参见第26.12.16.2节“阶段汇总表” 。

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

配置舞台事件收集

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

该 setup_instruments 表包含以名称开头的工具 stage 。使用这些工具启用或禁用各个阶段事件类的收集。
该 setup_consumers 表包含消费者值，其名称对应于当前和历史阶段事件表名称。使用这些使用者过滤阶段事件的集合。

除提供报表进度信息的那些工具外，默认情况下禁用舞台工具。例如：

MySQL的> SELECT NAME, ENABLED, TIMED
       FROM performance_schema.setup_instruments
       WHERE NAME RLIKE 'stage/sql/[a-c]';
+ ------------------------------------------------- --- + --------- + ------- +
| NAME | 启用| 定时|
+ ------------------------------------------------- --- + --------- + ------- +
| stage / sql /创建后| 没有| 没有|
| stage / sql / assign本地表| 没有| 没有|
| stage / sql / altering table | 没有| 没有|
| stage / sql /将alter table提交到存储引擎| 没有| 没有|
| stage / sql /更改master | 没有| 没有|
| stage / sql /检查主版本| 没有| 没有|
| stage / sql / checking permissions | 没有| 没有|
| stage / sql /清理| 没有| 没有|
| stage / sql / closing tables | 没有| 没有|
| stage / sql /连接到master | 没有| 没有|
| stage / sql /将HEAP转换为MyISAM | 没有| 没有|
| stage / sql /复制到组表| 没有| 没有|
| stage / sql /复制到tmp表| 没有| 没有|
| stage / sql / copy to tmp table | 没有| 没有|
| stage / sql /创建排序索引| 没有| 没有|
| stage / sql / creating table | 没有| 没有|
| stage / sql /创建tmp表| 没有| 没有|
+ ------------------------------------------------- --- + --------- + ------- +

提供语句进度信息的舞台事件工具默认启用并定时：

MySQL的> SELECT NAME, ENABLED, TIMED
       FROM performance_schema.setup_instruments
       WHERE ENABLED='YES' AND NAME LIKE "stage/%";
+ ------------------------------------------------- ----- + --------- + ------- +
| NAME | 启用| 定时|
+ ------------------------------------------------- ----- + --------- + ------- +
| stage / sql / copy to tmp table | 是的| 是的|
| stage / sql /应用批量的行更改（写入）| 是的| 是的|
| stage / sql /应用批量的行更改（更新）| 是的| 是的|
| stage / sql /应用批量行更改（删除）| 是的| 是的|
| stage / innodb / alter table（结束）| 是的| 是的|
| stage / innodb / alter table（flush）| 是的| 是的|
| stage / innodb / alter table（insert）| 是的| 是的|
| stage / innodb / alter table（log apply index）| 是的| 是的|
| stage / innodb / alter table（log apply table）| 是的| 是的|
| stage / innodb / alter table（合并排序）| 是的| 是的|
| stage / innodb / alter table（读取PK和内部排序）| 是的| 是的|
| stage / innodb / buffer pool load | 是的| 是的|
| stage / innodb / clone（文件副本）| 是的| 是的|
| stage / innodb / clone（redo copy）| 是的| 是的|
| stage / innodb / clone（页面副本）| 是的| 是的|
+ ------------------------------------------------- ----- + --------- + ------- +

默认情况下禁用阶段使用者：

MySQL的> SELECT *
       FROM performance_schema.setup_consumers
       WHERE NAME LIKE 'events_stages%';
+ ---------------------------- + --------- +
| NAME | 启用|
+ ---------------------------- + --------- +
| events_stages_current | 没有|
| events_stages_history | 没有|
| events_stages_history_long | 没有|
+ ---------------------------- + --------- +

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

启用：

的[mysqld]
性能架构仪器=“阶段/％= ON”
性能架构消费者的事件，阶段电流= ON
性能架构消费者的事件，阶段历史= ON
性能架构消费者的事件，阶段历史长= ON

禁用：

的[mysqld]
性能架构仪器=“阶段/％= OFF”
性能架构消费者的事件，阶段电流= OFF
性能架构消费者的事件，阶段历史= OFF
性能架构消费者的事件，阶段历史长= OFF

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

启用：

更新performance_schema.setup_instruments
SET ENABLED ='YES'，TIMED ='YES'
在哪里NAME ='stage /％';

更新performance_schema.setup_consumers
SET ENABLED ='YES'
名称在哪里'events_stages％';

禁用：

更新performance_schema.setup_instruments
SET ENABLED ='NO'，TIMED ='NO'
在哪里NAME ='stage /％';

更新performance_schema.setup_consumers
SET ENABLED ='NO'
名称在哪里'events_stages％';

要仅收集特定的舞台活动，请仅启用相应的舞台乐器。要仅为特定阶段事件表收集阶段事件，请启用阶段工具，但仅启用与所需表对应的阶段使用者。

有关配置事件收集的其他信息，请参见第26.3节“性能架构启动配置” 和第26.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 都是有意义的，并且它们的比率表示任务百分比已完成。

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

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

更新performance_schema.setup_consumers
SET ENABLED ='YES'
名称在哪里'events_stages_％';

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

26.12.5.1 events_stages_current表

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

包含阶段事件行的表中， events_stages_current 是最基本的。包含阶段事件行的其他表在逻辑上从当前事件派生。例如， events_stages_history 和 events_stages_history_long 表是已结束的最新阶段事件的集合，分别是每个线程的最大行数和所有线程的全局行数。

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

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

该 events_stages_current 表包含以下列：

THREAD_ID ， EVENT_ID

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

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

产生事件的工具的名称。这是表中的 NAME 值 setup_instruments 。仪器名称可能有多个部分并形成层次结构，如第26.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 。

有关皮秒作为事件时间单位和影响时间值的因素的讨论，请参见第26.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 表。它删除了行。

26.12.5.2 events_stages_history表

该 events_stages_history 表包含 N 每个线程结束的最新阶段事件。阶段事件在结束之前不会添加到表中。当表包含给定线程的最大行数时，当添加该线程的新行时，将丢弃最旧的线程行。当一个线程结束时，它的所有行都将被丢弃。

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

该 events_stages_history 表具有相同的列和索引 events_stages_current 。请参见第26.12.5.1节“events_stages_current表” 。

TRUNCATE TABLE 是允许的 events_stages_history 表。它删除了行。

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

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

26.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 。请参见第26.12.5.1节“events_stages_current表” 。不像 events_stages_current ， events_stages_history_long 没有索引。

TRUNCATE TABLE 是允许的 events_stages_history_long 表。它删除了行。

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

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

26.12.6性能模式语句事件表

26.12.6.1 events_statements_current表
26.12.6.2 events_statements_history表
26.12.6.3 events_statements_history_long表
26.12.6.4 prepared_statements_instances表

Performance Schema instruments语句执行。语句事件发生在事件层次结构的高级别。在事件层次结构中，等待事件嵌套在阶段事件中，阶段事件嵌套在事务事件中的语句事件中。

这些表存储语句事件：

events_statements_current ：每个线程的当前语句事件。
events_statements_history ：每个线程结束的最新语句事件。
events_statements_history_long ：全局结束的最新语句事件（跨所有线程）。
prepared_statements_instances ：准备好的语句实例和统计信息

以下部分描述了语句事件表。还有汇总表来汇总有关语句事件的信息; 请参见第26.12.16.3节“语句汇总表” 。

有关三个事件表之间关系的更多信息，请参见第26.9节“当前事件和历史事件的性能架构表” 。 events_statements_xxx

配置语句事件排序规则

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

该 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 | 启用| 定时|
+ --------------------------------------------- + --- ------ + ------- +
| statement / sql / select | 是的| 是的|
| statement / sql / create_table | 是的| 是的|
| statement / sql / create_index | 是的| 是的|
...
| statement / sp / stmt | 是的| 是的|
| statement / sp / set | 是的| 是的|
| statement / sp / set_trigger_field | 是的| 是的|
| 声明/调度程序/事件| 是的| 是的|
| 声明/ com /睡眠| 是的| 是的|
| 声明/ com /退出| 是的| 是的|
| statement / com / Init DB | 是的| 是的|
...
| 声明/摘要/查询| 是的| 是的|
| statement / abstract / new_packet | 是的| 是的|
| statement / abstract / relay_log | 是的| 是的|
+ --------------------------------------------- + --- ------ + ------- +

MySQL的> SELECT *
       FROM performance_schema.setup_consumers
       WHERE NAME LIKE '%statements%';
+ -------------------------------- + --------- +
| NAME | 启用|
+ -------------------------------- + --------- +
| events_statements_current | 是的|
| events_statements_history | 是的|
| events_statements_history_long | 没有|
| statements_digest | 是的|
+ -------------------------------- + --------- +

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

启用：

的[mysqld]
性能架构的仪器=“语句/％= ON”
性能架构消费者的事件陈述电流= ON
性能架构消费者的事件陈述历史= ON
性能架构消费者的事件陈述历史长= ON
性能架构的消费报表消化= ON

禁用：

的[mysqld]
性能架构的仪器=“语句/％= OFF”
性能架构消费者的事件陈述电流= OFF
性能架构消费者的事件陈述历史= OFF
性能架构消费者的事件陈述历史长= OFF
性能架构的消费报表消化= OFF

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

启用：

更新performance_schema.setup_instruments
SET ENABLED ='YES'，TIMED ='YES'
名称在哪里'声明/％';

更新performance_schema.setup_consumers
SET ENABLED ='YES'
在哪里名称像'％statement％';

禁用：

更新performance_schema.setup_instruments
SET ENABLED ='NO'，TIMED ='NO'
名称在哪里'声明/％';

更新performance_schema.setup_consumers
SET ENABLED ='NO'
在哪里名称像'％statement％';

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

有关配置事件收集的其他信息，请参见第26.3节“性能架构启动配置” 和第26.4节“性能架构运行时配置” 。

报表监控

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

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

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

服务器命令对应于头文件中定义并在其中处理。例子是和。命令仪器的名称以，例如和开头。 COM_xxx codes mysql_com.h 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 使用并且语句事件包含指示错误性质的信息。

可以从以下任何来源获取请求：

作为来自客户端的命令或语句请求，它将请求作为数据包发送
作为从复制从站上的中继日志中读取的语句字符串
作为事件调度程序的事件

请求的详细信息最初未知，并且性能模式从抽象到特定工具名称的顺序依赖于请求的来源。

对于从客户收到的请求：

当服务器在套接字级别检测到新数据包时，将使用抽象工具名称启动新语句 statement/abstract/new_packet 。
当服务器读取数据包编号时，它会更多地了解收到的请求类型，并且性能模式会优化仪器名称。例如，如果请求是 COM_PING 数据包，则仪器名称将成为 statement/com/Ping 最终名称。如果请求是 COM_QUERY 数据包，则已知它对应于SQL语句但不对应于特定类型的语句。在这种情况下，工具从一个抽象名称更改为更具体但仍然是抽象的名称 statement/abstract/Query ，并且该请求需要进一步分类。
如果请求是语句，则读取语句文本并将其提供给解析器。解析后，确切的语句类型是已知的。例如，如果请求是一个 INSERT 语句，则性能模式将仪器名称从最终名称 statement/abstract/Query 改为 statement/sql/insert 。

对于从复制从站上的中继日志中读取的语句请求：

中继日志中的语句存储为文本，并按原样读取。没有网络协议，因此 statement/abstract/new_packet 不使用该仪器。相反，最初的工具是 statement/abstract/relay_log 。
解析语句时，确切的语句类型是已知的。例如，如果请求是一个 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/* 必须同时启用 abtract 工具。这通常不是问题，因为默认情况下启用所有语句工具。但是，有选择地启用或禁用语句工具的应用程序必须考虑到禁用抽象工具还会禁用各个语句工具的统计信息收集。例如，要收集 INSERT 语句的统计信息， statement/sql/insert 必须启用，还要 statement/abstract/new_packet 和 statement/abstract/Query 。同样，对于要检测的复制语句， statement/abstract/relay_log 必须启用。

没有为抽象工具汇总统计数据，例如 statement/abstract/Query 因为没有任何陈述用抽象工具作为最终陈述名称进行分类。

26.12.6.1 events_statements_current表

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

包含语句事件行的表中， events_statements_current 是最基本的。包含语句事件行的其他表在逻辑上从当前事件派生。例如， events_statements_history 和 events_statements_history_long 表是最近结束的语句事件的集合，分别是每个线程的最大行数和所有线程的全局行数。

有关三个事件表之间关系的更多信息，请参见第26.9节“当前事件和历史事件的性能架构表” 。 events_statements_xxx

有关配置是否收集语句事件的信息，请参见第26.12.6节“性能架构语句事件表” 。

该 events_statements_current 表包含以下列：

THREAD_ID ， EVENT_ID

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

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

收集事件的工具的名称。这是表中的 NAME 值 setup_instruments 。仪器名称可能有多个部分并形成层次结构，如第26.6节“性能架构仪器命名约定”中所述。

对于SQL语句，该 EVENT_NAME 值最初是 statement/com/Query 在解析语句之前，然后更改为更合适的值，如第26.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 。

有关皮秒作为事件时间单位和影响时间值的因素的讨论，请参见第26.4.1节“性能模式事件时序” 。
LOCK_TIME

等待表锁的时间。此值以微秒计算，但标准化为皮秒，以便于与其他性能模式计时器进行比较。
SQL_TEXT

SQL语句的文本。对于与SQL语句无关的命令，值为 NULL 。

默认情况下，语句显示的最大可用空间为1024字节。要更改此值，请 performance_schema_max_sql_text_length 在服务器启动时设置系统变量。（更改此值也会影响其他Performance Schema表中的列。请参见第26.10节“性能架构语句摘要和采样” 。）
DIGEST

该语句将SHA-256值摘要为64个十六进制字符的字符串，或者 NULL 如果 statements_digest 消费者是 no 。有关语句摘要的更多信息，请参见第26.10节“性能模式语句摘要和采样” 。
DIGEST_TEXT

标准化语句摘要文本，或者 NULL 如果是 statements_digest 消费者 no 。有关语句摘要的更多信息，请参见第26.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

是否为语句发生错误。如果SQLSTATE值以 00 （完成）或 01 （警告）开头，则值为0 。值为1是SQLSTATE值是其他任何值。
WARNINGS

语句诊断区域中的警告数。
ROWS_AFFECTED

受语句影响的行数。有关 “ 受影响 ” 含义的说明，请参见第28.7.7.1节“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。有关详细信息，请参阅的描述 Extra 列从 EXPLAIN 输出为 Range checked for each record 在值第8.8.2节“EXPLAIN输出格式”中。

NESTING_EVENT_ID ， NESTING_EVENT_TYPE ， NESTING_EVENT_LEVEL

这三列与其他列一起使用，为顶级（unnested）语句和嵌套语句（在存储程序中执行）提供如下信息。

对于顶级声明：

OBJECT_TYPE = NULL
OBJECT_SCHEMA = NULL
OBJECT_NAME = NULL
NESTING_EVENT_ID = NULL
NESTING_EVENT_TYPE = NULL
NESTING_LEVEL = 0

对于嵌套语句：

OBJECT_TYPE =父语句对象类型
OBJECT_SCHEMA =父语句对象模式
OBJECT_NAME =父语句对象名称
NESTING_EVENT_ID =父语句EVENT_ID
NESTING_EVENT_TYPE ='声明'
NESTING_LEVEL =父语句NESTING_LEVEL加1

STATEMENT_ID

服务器在SQL级别维护的查询ID。该值对于服务器实例是唯一的，因为这些ID是使用以原子方式递增的全局计数器生成的。这个专栏是在MySQL 8.0.14中添加的。

该 events_statements_current 表包含以下索引：

主键（ THREAD_ID ， EVENT_ID ）

TRUNCATE TABLE 是允许的 events_statements_current 表。它删除了行。

26.12.6.2 events_statements_history表

该 events_statements_history 表包含 N 每个线程结束的最新语句事件。语句事件在结束之前不会添加到表中。当表包含给定线程的最大行数时，当添加该线程的新行时，将丢弃最旧的线程行。当一个线程结束时，它的所有行都将被丢弃。

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

该 events_statements_history 表具有相同的列和索引 events_statements_current 。请参见第26.12.6.1节“events_statements_current表” 。

TRUNCATE TABLE 是允许的 events_statements_history 表。它删除了行。

有关三个事件表之间关系的更多信息，请参见第26.9节“当前事件和历史事件的性能架构表” 。 events_statements_xxx

有关配置是否收集语句事件的信息，请参见第26.12.6节“性能架构语句事件表” 。

26.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 。请参见第26.12.6.1节“events_statements_current表” 。不像 events_statements_current ， events_statements_history_long 没有索引。

TRUNCATE TABLE 是允许的 events_statements_history_long 表。它删除了行。

有关三个事件表之间关系的更多信息，请参见第26.9节“当前事件和历史事件的性能架构表” 。 events_statements_xxx

有关配置是否收集语句事件的信息，请参见第26.12.6节“性能架构语句事件表” 。

26.12.6.4 prepared_statements_instances表

性能模式为预准备语句提供了检测，其中有两个协议：

二进制协议。这可以通过MySQL C API访问并映射到底层服务器命令，如下表所示。

C API函数	相应的服务器命令
`mysql_stmt_prepare()`	`COM_STMT_PREPARE`
`mysql_stmt_execute()`	`COM_STMT_EXECUTE`
`mysql_stmt_close()`	`COM_STMT_CLOSE`

文本协议。可以使用SQL语句和映射到底层服务器命令来访问它，如下表所示。

SQL语句	相应的服务器命令
`PREPARE`	`SQLCOM_PREPARE`
`EXECUTE`	`SQLCOM_EXECUTE`
`DEALLOCATE PREPARE` ， `DROP PREPARE`	`SQLCOM_DEALLOCATE PREPARE`

Performance Schema准备语句检测涵盖两种协议。以下讨论涉及服务器命令，而不是C API函数或SQL语句。

表中提供了有关预准备语句的信息 prepared_statements_instances 。此表允许检查服务器中使用的预准备语句，并提供有关它们的汇总统计信息。要控制此表的大小，请 performance_schema_max_prepared_statements_instances 在服务器启动时设置系统变量。

准备好的报表信息的收集取决于下表中显示的报表工具。默认情况下启用这些仪器。要修改它们，请更新 setup_instruments 表格。

仪器	服务器命令
`statement/com/Prepare`	`COM_STMT_PREPARE`
`statement/com/Execute`	`COM_STMT_EXECUTE`
`statement/sql/prepare_sql`	`SQLCOM_PREPARE`
`statement/sql/execute_sql`	`SQLCOM_EXECUTE`

Performance Schema管理 prepared_statements_instances 表的内容，如下所示：

声明准备

一个 COM_STMT_PREPARE 或者 SQLCOM_PREPARE 命令在服务器一份准备好的声明。如果成功检测了语句，则会向 prepared_statements_instances 表中添加一个新行。如果无法检测语句，则 Performance_schema_prepared_statements_lost 状态变量会递增。
准备好的声明执行

为已检测的预准备语句实例执行 COM_STMT_EXECUTE 或 SQLCOM_PREPARE 命令会更新相应的 prepared_statements_instances 表行。
准备好的声明解除分配

对已检测的预准备语句实例执行 COM_STMT_CLOSE 或 SQLCOM_DEALLOCATE_PREPARE 命令将删除相应的 prepared_statements_instances 表行。为避免资源泄漏，即使先前描述的准备好的声明工具被禁用，也会发生删除。

该 prepared_statements_instances 表包含以下列：

OBJECT_INSTANCE_BEGIN

已检测的预准备语句的内存地址。
STATEMENT_ID

服务器分配的内部语句ID。文本和二进制协议都使用语句ID。
STATEMENT_NAME

对于二进制协议，此列是 NULL 。对于文本协议，此列是用户分配的外部语句名称。例如，对于以下SQL语句，预准备语句的名称为 stmt ：
```
从'SELECT 1'预备stmt FROM;
```
SQL_TEXT

准备好的声明文本，带有 ? 占位符标记。
OWNER_THREAD_ID ， OWNER_EVENT_ID

这些列指示创建预准备语句的事件。
OWNER_OBJECT_TYPE ， OWNER_OBJECT_SCHEMA ， OWNER_OBJECT_NAME

对于由客户机会话创建的预准备语句，这些列是 NULL 。对于由存储程序创建的预准备语句，这些列指向存储的程序。典型的用户错误是忘记取消分配准备好的语句。这些列可用于查找泄漏预准备语句的存储程序：
```
选择
  OWNER_OBJECT_TYPE，OWNER_OBJECT_SCHEMA，OWNER_OBJECT_NAME，
  STATEMENT_NAME，SQL_TEXT
来自performance_schema.prepared_statements_instances
在哪里OWNER_OBJECT_TYPE不为空;
```
TIMER_PREPARE

执行语句准备本身所花费的时间。
COUNT_REPREPARE

语句在内部重新编写的次数（请参见第8.10.3节“准备语句和存储程序的缓存” ）。无法获得表示的计时统计数据，因为它被视为语句执行的一部分，而不是单独的操作。
COUNT_EXECUTE ， SUM_TIMER_EXECUTE ， MIN_TIMER_EXECUTE ， AVG_TIMER_EXECUTE ， MAX_TIMER_EXECUTE

执行准备好的声明的汇总统计数据。
SUM_xxx

其余列与语句摘要表相同（请参见第26.12.16.3节“语句摘要表” ）。 SUM_xxx

该 prepared_statements_instances 表包含以下索引：

主键（ OBJECT_INSTANCE_BEGIN ）
索引（ STATEMENT_ID ）
索引（ STATEMENT_NAME ）
索引（ OWNER_THREAD_ID ， OWNER_EVENT_ID ）
指数（ OWNER_OBJECT_TYPE ， OWNER_OBJECT_SCHEMA ， OWNER_OBJECT_NAME ）

TRUNCATE TABLE 重置 prepared_statements_instances 表的统计信息列。

26.12.7性能模式事务表

26.12.7.1 events_transactions_current表
26.12.7.2 events_transactions_history表
26.12.7.3 events_transactions_history_long表

绩效架构工具交易。在事件层次结构中，等待事件嵌套在阶段事件中，阶段事件嵌套在事务事件中的语句事件中。

这些表存储事务事件：

events_transactions_current ：每个线程的当前事务事件。
events_transactions_history ：每个线程结束的最新事务事件。
events_transactions_history_long ：全局（跨所有线程）结束的最新事务事件。

以下部分描述了事务事件表。还有汇总表来汇总有关交易事件的信息; 请参见第26.12.16.5节“事务汇总表” 。

有关三个事务事件表之间关系的更多信息，请参见第26.9节“当前事件和历史事件的性能架构表” 。

配置事务事件排序规则

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

该 setup_instruments 表包含一个名为的工具 transaction 。使用此工具启用或禁用单个事务事件类的收集。
该 setup_consumers 表包含名称对应于当前和历史事务事件表名称的使用者值。使用这些使用者来过滤事务事件的集合。

该 transaction 仪器与 events_transactions_current 和 events_transactions_history 交易的消费者是默认启用的：

MySQL的> SELECT NAME, ENABLED, TIMED
       FROM performance_schema.setup_instruments
       WHERE NAME = 'transaction';
+ ------------- + --------- + ------- +
| NAME | 启用| 定时|
+ ------------- + --------- + ------- +
| 交易| 是的| 是的|
+ ------------- + --------- + ------- +
MySQL的> SELECT *
       FROM performance_schema.setup_consumers
       WHERE NAME LIKE 'events_transactions%';
+ ---------------------------------- + --------- +
| NAME | 启用|
+ ---------------------------------- + --------- +
| events_transactions_current | 是的|
| events_transactions_history | 是的|
| events_transactions_history_long | 没有|
+ ---------------------------------- + --------- +

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

启用：

的[mysqld]
性能架构仪器=“交易= ON”
性能架构的消费事件，交易电流= ON
性能架构的消费事件，交易历史= ON
性能架构的消费事件，交易历史长= ON

禁用：

的[mysqld]
性能架构的仪器=“交易= OFF”
性能架构的消费事件，交易电流= OFF
性能架构的消费事件，交易历史= OFF
性能架构的消费事件，交易历史长= OFF

要在运行时控制事务事件集合，请更新 setup_instruments 和 setup_consumers 表：

启用：

更新performance_schema.setup_instruments
SET ENABLED ='YES'，TIMED ='YES'
在哪里NAME ='交易';

更新performance_schema.setup_consumers
SET ENABLED ='YES'
在哪里名称像'events_transactions％';

禁用：

更新performance_schema.setup_instruments
SET ENABLED ='NO'，TIMED ='NO'
在哪里NAME ='交易';

更新performance_schema.setup_consumers
SET ENABLED ='NO'
在哪里名称像'events_transactions％';

要仅为特定事务事件表收集事务事件，请启用该 transaction 工具，但仅启用与所需表对应的事务使用者。

有关配置事件收集的其他信息，请参见第26.3节“性能架构启动配置” 和第26.4节“性能架构运行时配置” 。

交易边界

在MySQL Server中，事务以这些语句显式开始：

开始交易| 开始| 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 。

性能模式定义了与服务器类似的事务边界。事务事件的开始和结束与服务器中相应的状态转换紧密匹配：

对于显式启动的事务，事务事件在处理 START TRANSACTION 语句期间启动。
对于隐式启动的事务，事务事件在上一个事务结束后使用事务引擎的第一个语句上启动。
对于任何交易，无论明示或暗示结束，本次交易活动结束时的处理过程中的服务器转换出来的活跃交易状态的 COMMIT 或 ROLLBACK 。

这种方法有一些微妙的含义：

在Performance模式，交易事件不完全包括与对应的相关联的声明事件 START TRANSACTION ， COMMIT 或 ROLLBACK 语句。事务事件和这些语句之间存在大量的时序重叠。
使用非事务性引擎的语句对连接的事务状态没有影响。对于隐式事务，事务事件以使用事务引擎的第一个语句开始。这意味着，即使在下面，也会忽略专门针对非事务表的语句 START TRANSACTION 。

为了说明，请考虑以下情形：

1. SET autocommit = OFF;
2. CREATE TABLE t1（INT）ENGINE = InnoDB;
3.开始交易;  - 交易1开始
4.插入t1值（1），（2），（3）;
5. CREATE TABLE t2（INT）ENGINE = MyISAM;  - 交易1 COMMIT
                                            - （隐式; DDL强制提交）
6.插入t2值（1），（2），（3）;  - 更新非交易表
7.更新t2设置a = a + 1;  -  ... 然后再次
8.插入t1值（4），（5），（6）;  - 写入交易表
                                            - 交易2开始（隐含）
9. COMMIT;  - 交易2 COMMIT

从服务器的角度来看，事务1在 t2 创建表时结束。事务2在访问事务表之前不会启动，尽管对非事务表的干预更新。

从性能模式的角度来看，当服务器转换为活动事务状态时，事务2开始。语句6和7不包含在事务2的边界内，这与服务器如何将事务写入二进制日志一致。

交易工具

三个属性定义事务：

访问模式（只读，读写）
隔离级别（ SERIALIZABLE ， REPEATABLE READ 等等）
隐式（已 autocommit 启用）或显式（已 autocommit 禁用）

为了降低事务检测的复杂性并确保收集的事务数据提供完整，有意义的结果，所有事务都独立于访问模式，隔离级别或自动提交模式进行检测。

要选择性地检查交易记录，在交易事件表使用的属性列： ACCESS_MODE ， ISOLATION_LEVEL ，和 AUTOCOMMIT 。

可以通过各种方式减少事务检测的成本，例如根据用户，帐户，主机或线程（客户端连接）启用或禁用事务检测。

事务和嵌套事件

事务事件的父级是启动事务的事件。对于显式启动的事务，这包括 START TRANSACTION 和 COMMIT AND CHAIN 语句。对于隐式启动的事务，它是在前一个事务结束后使用事务引擎的第一个语句。

通常，事务是事务期间启动的所有事件的顶级父级，包括显式结束事务的语句，如 COMMIT 和 ROLLBACK 。异常是隐式结束事务的语句，例如DDL语句，在这种情况下，必须在执行新语句之前提交当前事务。

交易和存储程序

事务和存储的程序事件相关如下：

存储过程

存储过程独立于事务运行。可以在事务内启动存储过程，并且可以从存储过程内启动或结束事务。如果从事务内部调用，则存储过程可以执行强制提交父事务的语句，然后启动新事务。

如果在事务中启动存储过程，则该事务是存储过程事件的父事务。

如果事务由存储过程启动，则存储过程是事务事件的父级。
存储功能

限制存储的函数不会导致显式或隐式提交或回滚。存储的函数事件可以驻留在父事务事件中。
触发器

触发器作为访问与其关联的表的语句的一部分激活，因此触发器事件的父级始终是激活它的语句。

触发器不能发出导致显式或隐式提交或回滚事务的语句。
预定活动

预定事件正文中的语句执行发生在新连接中。在父事务中嵌套预定事件不适用。

交易和保存点

Savepoint语句记录为单独的语句事件。交易活动包括独立的计数器 SAVEPOINT ， ROLLBACK TO SAVEPOINT 以及 RELEASE SAVEPOINT 在交易期间发表的声明。

交易和错误

事务中发生的错误和警告记录在语句事件中，但不记录在相应的事务事件中。这包括特定于事务的错误和警告，例如非事务性表上的回滚或GTID一致性错误。

26.12.7.1 events_transactions_current表

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

MySQL的> SELECT *
       FROM performance_schema.events_transactions_current LIMIT 1\G
*************************** 1。排******************** *******
                      THREAD_ID：26
                       EVENT_ID：7
                   END_EVENT_ID：NULL
                     EVENT_NAME：交易
                          状态：有效
                         TRX_ID：NULL
                           GTID：3E11FA47-71CA-11E1-9E33-C80AA9429562：56
                            XID：NULL
                       XA_STATE：NULL
                         消息来源：transaction.cc：150
                    TIMER_START：420833537900000
                      TIMER_END：NULL
                     TIMER_WAIT：NULL
                    ACCESS_MODE：READ WRITE
                ISOLATION_LEVEL：REPEATABLE READ
                     AUTOCOMMIT：没有
           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：声明

包含事务事件行的表中， events_transactions_current 是最基本的。包含事务事件行的其他表在逻辑上从当前事件派生。例如， events_transactions_history 和 events_transactions_history_long 表是最近已结束的事务事件的集合，分别是每个线程的最大行数和所有线程的全局行数。

有关三个事务事件表之间关系的更多信息，请参见第26.9节“当前事件和历史事件的性能架构表” 。

有关配置是否收集事务事件的信息，请参见第26.12.7节“性能架构事务表” 。

该 events_transactions_current 表包含以下列：

THREAD_ID ， EVENT_ID

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

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

收集事件的工具的名称。这是表中的 NAME 值 setup_instruments 。仪器名称可能有多个部分并形成层次结构，如第26.6节“性能架构仪器命名约定”中所述。
STATE

当前的交易状态。值为 ACTIVE （after START TRANSACTION 或 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.8.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 ）。

在复制从属服务器上，相同的XA事务可以出现在 events_transactions_current 表中，在不同的线程上具有不同的状态。这是因为在准备好XA事务之后，它立即与从属应用程序线程分离，并且可以由从属服务器上的任何线程提交或回滚。该 events_transactions_current 表显示线程上最近监视的事务事件的当前状态，并且在线程空闲时不更新此状态。所以XA事务仍然可以显示在 PREPARED 原始applier线程的状态，在被另一个线程处理之后。要正确识别仍处于 PREPARED 状态且需要恢复的 XA事务，请使用 XA RECOVER 语句而不是性能模式事务表。
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 。

有关皮秒作为事件时间单位和影响时间值的因素的讨论，请参见第26.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 不会出现，因为无法嵌套事务。）

该 events_transactions_current 表包含以下索引：

主键（ THREAD_ID ， EVENT_ID ）

TRUNCATE TABLE 是允许的 events_transactions_current 表。它删除了行。

26.12.7.2 events_transactions_history表

该 events_transactions_history 表包含 N 每个线程结束的最新事务事件。在事务结束之前，事务事件不会添加到表中。当表包含给定线程的最大行数时，当添加该线程的新行时，将丢弃最旧的线程行。当一个线程结束时，它的所有行都将被丢弃。

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

该 events_transactions_history 表具有相同的列和索引 events_transactions_current 。请参见第26.12.7.1节“events_transactions_current表” 。

TRUNCATE TABLE 是允许的 events_transactions_history 表。它删除了行。

有关三个事务事件表之间关系的更多信息，请参见第26.9节“当前事件和历史事件的性能架构表” 。

有关配置是否收集事务事件的信息，请参见第26.12.7节“性能架构事务表” 。

26.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 。请参见第26.12.7.1节“events_transactions_current表” 。不像 events_transactions_current ， events_transactions_history_long 没有索引。

TRUNCATE TABLE 是允许的 events_transactions_history_long 表。它删除了行。

有关三个事务事件表之间关系的更多信息，请参见第26.9节“当前事件和历史事件的性能架构表” 。

有关配置是否收集事务事件的信息，请参见第26.12.7节“性能架构事务表” 。

26.12.8性能模式连接表

26.12.8.1账户表
26.12.8.2主机表
26.12.8.3用户表

当客户端连接到MySQL服务器时，它会根据特定用户名和特定主机进行连接。性能模式使用以下表提供有关这些连接的统计信息，按帐户（用户和主机组合）跟踪它们以及按用户名和主机名单独分别：

accounts ：每个客户帐户的连接统计信息
hosts ：每个客户端主机名的连接统计信息
users ：每个客户端用户名的连接统计信息

连接表中 “ account ” 的含义类似于 mysql 系统数据库中 MySQL授权表中的含义，即该术语是指用户和主机值的组合。它们的不同之处在于，对于授权表，帐户的主机部分可以是模式，而对于性能模式表，主机值始终是特定的非模式主机名。

每个连接表都有列 CURRENT_CONNECTIONS 和 TOTAL_CONNECTIONS 列，用于跟踪其统计信息所基于的每个 “ 跟踪值 ” 的当前和总连接数。表格与跟踪值的不同之处不同。该 accounts 表有 USER 和 HOST 列跟踪每个用户和主机组合连接。所述 users 和 hosts 表具有一个 USER 和 HOST 柱，分别，以跟踪每个用户名和主机名的连接。

性能模式还使用具有 USER 和 HOST 列值的行来计算未能进行身份验证的用户会话的内部线程和线程 NULL 。

假设客户命名 user1 ，并 user2 分别从连接一个时间 hosta 和 hostb 。性能模式跟踪连接如下：

该 accounts 表有四行，用于 user1 / hosta ， user1 / hostb ， user2 / hosta 和 user2 / hostb account值，每行计算一个帐户的一个连接。
该 hosts 表有两行，for hosta 和 hostb 每行计算每个主机名两个连接。
该 users 表有两行，for user1 和 user2 每行计算每个用户名两个连接。

当客户端连接时，性能模式使用适合于每个表的跟踪值确定每个连接表中的哪一行适用。如果没有这样的行，则添加一行。然后，性能模式将增加该行中的一个 CURRENT_CONNECTIONS 和 TOTAL_CONNECTIONS 列。

当客户端断开连接时，性能模式会将 CURRENT_CONNECTIONS 行中的列减1，并保持 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_errors_summary_by_account_by_error |
| events_errors_summary_by_host_by_error |
| events_errors_summary_by_user_by_error |
| 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 |
+ ------------------------------------------------- ----- +

有关各个连接摘要表的详细信息，请参阅描述汇总事件类型的表的部分：

等待事件摘要：第26.12.16.1节“等待事件摘要表”
阶段事件摘要：第26.12.16.2节，“阶段汇总表”
报表事件摘要：第26.12.16.3节“语句摘要表”
事务事件摘要：第26.12.16.5节“事务汇总表”
内存事件摘要：第26.12.16.10节“内存摘要表”
错误事件摘要：第26.12.16.11节“错误摘要表”

TRUNCATE TABLE 允许连接摘要表。它会删除没有连接的帐户，主机或用户的行，并将剩余行的摘要列重置为零。此外，由帐户，主机，用户或线程聚合的每个摘要表都会通过截断它所依赖的连接表而被隐式截断。下表描述了连接表截断和隐式截断表之间的关系。

表26.2连接表截断的隐式影响

截断的连接表	隐式截断的摘要表
`accounts`	名称中包含的表格 `_summary_by_account` ， `_summary_by_thread`
`hosts`	包含名称表 `_summary_by_account` ， `_summary_by_host` ， `_summary_by_thread`
`users`	包含名称表 `_summary_by_account` ， `_summary_by_user` ， `_summary_by_thread`

截断 _summary_global 摘要表还会隐式截断其对应的连接和线程摘要表。例如，截断 events_waits_summary_global_by_event_name 隐式截断由帐户，主机，用户或线程聚合的等待事件摘要表。

26.12.8.1账户表

该 accounts 表包含已连接到MySQL服务器的每个帐户的行。对于每个帐户，该表计算当前和总连接数。表大小在服务器启动时自动调整。要显式设置表大小，请 performance_schema_accounts_size 在服务器启动时设置系统变量。要禁用帐户统计信息，请将此变量设置为0。

该 accounts 表包含以下列。有关性能模式如何在此表中维护行的说明（包括效果） TRUNCATE TABLE ，请参见第26.12.8节“性能模式连接表” 。

USER

连接的客户端用户名。这 NULL 适用于内部线程或无法进行身份验证的用户会话。
HOST

客户端连接的主机。这 NULL 适用于内部线程或无法进行身份验证的用户会话。
CURRENT_CONNECTIONS

帐户的当前连接数。
TOTAL_CONNECTIONS

帐户的连接总数。

该 accounts 表包含以下索引：

主键（ USER ， HOST ）

26.12.8.2主机表

该 hosts 表包含客户端已连接到MySQL服务器的每个主机的行。对于每个主机名，该表计算当前连接数和总连接数。表大小在服务器启动时自动调整。要显式设置表大小，请 performance_schema_hosts_size 在服务器启动时设置系统变量。要禁用主机统计信息，请将此变量设置为0。

该 hosts 表包含以下列。有关性能模式如何在此表中维护行的说明（包括效果） TRUNCATE TABLE ，请参见第26.12.8节“性能模式连接表” 。

HOST

客户端连接的主机。这 NULL 适用于内部线程或无法进行身份验证的用户会话。
CURRENT_CONNECTIONS

主机的当前连接数。
TOTAL_CONNECTIONS

主机的连接总数。

该 hosts 表包含以下索引：

主键（ HOST ）

26.12.8.3用户表

该 users 表包含连接到MySQL服务器的每个用户的行。对于每个用户名，该表计算当前和总连接数。表大小在服务器启动时自动调整。要显式设置表大小，请 performance_schema_users_size 在服务器启动时设置系统变量。要禁用用户统计信息，请将此变量设置为0。

该 users 表包含以下列。有关性能模式如何在此表中维护行的说明（包括效果） TRUNCATE TABLE ，请参见第26.12.8节“性能模式连接表” 。

USER

连接的客户端用户名。这 NULL 适用于内部线程或无法进行身份验证的用户会话。
CURRENT_CONNECTIONS

用户的当前连接数。
TOTAL_CONNECTIONS

用户的连接总数。

该 users 表包含以下索引：

主键（ USER ）

26.12.9性能模式连接属性表

26.12.9.1 session_account_connect_attrs表
26.12.9.2 session_connect_attrs表

连接属性是应用程序可以在连接时传递给服务器的键值对。基于C API的应用程序使用 mysql_options() 和 mysql_options4() 函数定义属性集。其他MySQL连接器可以提供自己的属性定义方法。

这些表公开了属性信息：

session_account_connect_attrs ：当前会话的连接属性以及与会话帐户关联的其他会话
session_connect_attrs ：所有会话的连接属性

以下划线（ _ ）开头的属性名称保留供内部使用，不应由应用程序创建。此约定允许MySQL引入新属性而不与应用程序属性发生冲突，并使应用程序能够定义自己的属性，这些属性不会与内部属性发生冲突。

在给定连接上可见的连接属性集取决于诸如平台，用于建立连接的MySQL连接器或客户端程序等因素。

的 libmysqlclient 客户端库（在MySQL和MySQL连接器/ C分布提供）设置这些属性：

_client_name ：客户端名称（ libmysql 用于客户端库）。
_client_version ：客户端库版本。
_os ：操作系统（例如 Linux ， Win64 ）。
_pid ：客户端进程ID。
_platform ：机器平台（例如 x86_64 ）。
_thread ：客户端线程ID（仅限Windows）。

其他MySQL连接器可以定义自己的连接属性。

MySQL Connector / C ++ 8.0.16及更高版本为使用X DevAPI或X DevAPI for C的应用程序定义了这些属性：

_client_license ：连接器许可证（例如 GPL-2.0 ）。
_client_name ：连接器名称（ mysql-connector-cpp ）。
_client_version ：连接器版本。
_os ：操作系统（例如 Linux ， Win64 ）。
_pid ：客户端进程ID。
_platform ：机器平台（例如 x86_64 ）。
_source_host ：运行客户端的计算机的主机名。
_thread ：客户端线程ID（仅限Windows）。

MySQL Connector / J定义了这些属性：

_client_name ：客户端名称
_client_version ：客户端库版本
_os ：操作系统（例如 Linux ， Win64 ）
_client_license ：连接器许可证类型
_platform ：机器平台（例如 x86_64 ）
_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 Shell设置 program_name 为 mysqlsh 。

一些MySQL客户端程序定义了其他属性：

mysql （从MySQL 8.0.17开始）：
- os_user ：运行该程序的操作系统用户的名称。可在Unix和类Unix系统和Windows上使用。
- os_sudouser ： SUDO_USER 环境变量的值。可在Unix和类Unix系统上使用。
不发送值为空的 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_longest_seen 状态变量中最长缓冲区的大小。
对于接受的连接，性能模式检查聚合属性大小与 performance_schema_session_connect_attrs_size 系统变量的值。如果属性大小超过此值，则会执行以下操作：
- 性能模式截断属性数据并递增 Performance_schema_session_connect_attrs_lost 状态变量，该变量指示发生属性截断的连接数。
- 如果是，性能架构会将消息写入错误日志 log_error_verbosity 系统变量大于1，：
```
连接属性的长度 N被截断
（N字节丢失）
用于连接N，用户user_name@ host_name
（作为user_name），auth：{yes | no}
```
  警告消息中的信息旨在帮助DBA识别发生属性截断的客户端。
- 甲 _truncated 属性被添加到与指示了多少字节丢失，如果属性缓冲器具有足够的空间的值的会话属性。这使性能模式能够在连接属性表中公开每个连接的截断信息。无需检查错误日志即可检查此信息。

26.12.9.1 session_account_connect_attrs表

应用程序可以提供在连接时传递给服务器的键值连接属性。有关公共属性的说明，请参见第26.12.9节“性能模式连接属性表” 。

该 session_account_connect_attrs 表仅包含当前会话的连接属性，以及与会话帐户关联的其他会话。要查看所有会话的连接属性，请使用该 session_connect_attrs 表。

该 session_account_connect_attrs 表包含以下列：

PROCESSLIST_ID

会话的连接标识符。
ATTR_NAME

属性名称。
ATTR_VALUE

属性值。
ORDINAL_POSITION

属性添加到连接属性集的顺序。

该 session_account_connect_attrs 表包含以下索引：

主键（ PROCESSLIST_ID ， ATTR_NAME ）

TRUNCATE TABLE 不允许使用该 session_account_connect_attrs 表。

26.12.9.2 session_connect_attrs表

应用程序可以提供在连接时传递给服务器的键值连接属性。有关公共属性的说明，请参见第26.12.9节“性能模式连接属性表” 。

该 session_connect_attrs 表包含所有会话的连接属性。要仅查看当前会话的连接属性以及与会话帐户关联的其他会话，请使用 session_account_connect_attrs 表。

该 session_connect_attrs 表包含以下列：

PROCESSLIST_ID

会话的连接标识符。
ATTR_NAME

属性名称。
ATTR_VALUE

属性值。
ORDINAL_POSITION

属性添加到连接属性集的顺序。

该 session_connect_attrs 表包含以下索引：

主键（ PROCESSLIST_ID ， ATTR_NAME ）

TRUNCATE TABLE 不允许使用该 session_connect_attrs 表。

26.12.10性能模式用户定义的变量表

性能模式提供了一个 user_variables_by_thread 公开用户定义变量的表。这些是在特定会话中定义的变量，包括 @ 名称前面的字符; 请参见第9.4节“用户定义的变量” 。

该 user_variables_by_thread 表包含以下列：

THREAD_ID

定义变量的会话的线程标识符。
VARIABLE_NAME

变量名称，不带前导 @ 字符。
VARIABLE_VALUE

变量值。

该 user_variables_by_thread 表包含以下索引：

主键（ THREAD_ID ， VARIABLE_NAME ）

TRUNCATE TABLE 不允许使用该 user_variables_by_thread 表。

26.12.11性能模式复制表

26.12.11.1 replication_connection_configuration表
26.12.11.2 replication_connection_status表
26.12.11.3 replication_applier_configuration表
26.12.11.4 replication_applier_status表
26.12.11.5 replication_applier_status_by_coordinator表
26.12.11.6 replication_applier_status_by_worker表
26.12.11.7 replication_applier_global_filters表
26.12.11.8 replication_applier_filters表
26.12.11.9 replication_group_members表
26.12.11.10 replication_group_member_stats表

性能模式提供了公开复制信息的表。这与 SHOW SLAVE STATUS 声明中提供的信息类似，但表格形式的表示更易于访问且具有可用性优势：

SHOW SLAVE STATUS 输出对于目视检查很有用，但对于程序化使用则没有那么多。相反，使用性能模式表，可以使用常规 SELECT 查询（包括复杂 WHERE 条件，连接等）搜索有关从属状态的信息。
查询结果可以保存在表中以供进一步分析，或者分配给变量，从而在存储过程中使用。
复制表提供了更好的诊断信息。对于多线程从属操作， SHOW SLAVE STATUS 使用 Last_SQL_Errno 和 Last_SQL_Error 字段报告所有协调器和工作线程错误，因此只有最新的错误可见且信息可能丢失。复制表在每个线程的基础上存储错误，而不会丢失信息。
最后一次看到的事务在每个工作者的复制表中可见。这是无法提供的信息 SHOW SLAVE STATUS 。
熟悉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_applier_filters ：提供有关在特定复制通道上配置的复制筛选器的信息。
- replication_applier_global_filters ：提供有关适用于所有复制通道的全局复制筛选器的信息。
包含有关组复制成员的信息的表：
- replication_group_members ：为组成员提供网络和状态信息。
- replication_group_member_stats ：提供有关他们参与的组成员和交易的统计信息。
有关更多信息，请参见第18.3节“监控组复制” 。

禁用性能架构时，将继续填充以下性能架构复制表：

replication_connection_configuration
replication_connection_status
replication_applier_configuration
replication_applier_status
replication_applier_status_by_coordinator
replication_applier_status_by_worker

唯一的例外是本地定时信息（开始和结束的交易时间戳）在复制表 replication_connection_status ， replication_applier_status_by_coordinator 和 replication_applier_status_by_worker 。禁用性能架构时不会收集此信息。

以下各节更详细地描述了每个复制表，包括生成的 SHOW SLAVE STATUS 列与出现相同信息的复制表列之间的对应关系。

复制表介绍的其余部分描述了性能模式如何填充它们以及哪些字段 SHOW SLAVE STATUS 未在表中表示。

复制表生命周期

性能模式按如下方式填充复制表：

在执行之前 CHANGE MASTER TO ，表是空的。
之后 CHANGE MASTER TO ，可以在表格中看到配置参数。此时，没有活动的从属线程，因此 THREAD_ID 列 NULL 和 SERVICE_STATE 列的值为 OFF 。
之后 START SLAVE ， NULL THREAD_ID 可以看到非值。空闲或活动的线程的 SERVICE_STATE 值为 ON 。连接到主服务器的线程 CONNECTING 在建立连接时具有值， ON 此后只要连接持续。
之后 STOP SLAVE ， THREAD_ID 列成为 NULL ， SERVICE_STATE 不再存在的线程列的值为 OFF 。
STOP SLAVE 由于错误，表被保留或线程死亡。
replication_applier_status_by_worker 仅当从器件在多线程模式下运行时，该表才是非空的。也就是说，如果 slave_parallel_workers 系统变量大于0，则在 START SLAVE 执行时填充此表，并且行数显示工作者数。

SHOW SLAVE STATUS信息不在复制表中

性能模式复制表中的信息与可用信息略有不同， SHOW SLAVE STATUS 因为这些表面向使用全局事务标识符（GTID），而不是文件名和位置，它们表示服务器UUID值，而不是服务器ID值。由于存在这些差异， SHOW SLAVE STATUS 性能模式复制表中不会保留多个列，或者以不同的方式表示：

以下字段引用文件名和位置，不保留：

MASTER_LOG_FILE
Read_Master_Log_Pos
RELAY_LOG_FILE
RELAY_LOG_POS
Relay_Master_Log_File
Exec_Master_Log_Pos
Until_Condition
Until_Log_File
Until_Log_Pos

该 Master_Info_File 字段未保留。它指的是 master.info 用于从属主信息存储库的文件，该文件已被崩溃安全的从属表取代。
以下字段基于 server_id ，而不是 server_uuid ，并且不会保留：
```
Master_Server_Id
Replicate_Ignore_Server_Ids
```
该 Skip_Counter 字段基于事件计数，而不是GTID，并且不会保留。
这些错误字段是 Last_SQL_Errno 和的别名 Last_SQL_Error ，因此不会保留它们：
```
Last_Errno
Last_Error
```
在性能模式中，此错误信息在表的列 LAST_ERROR_NUMBER 和 LAST_ERROR_MESSAGE 列中可用 replication_applier_status_by_coordinator （ replication_applier_status_by_worker 如果从属是多线程的）。这些表提供比可从更具体的每个线程的错误信息 Last_Errno 和 Last_Error 。

提供有关命令行筛选选项的信息的字段不会保留：

Replicate_Do_DB
Replicate_Ignore_DB
Replicate_Do_Table
Replicate_Ignore_Table
Replicate_Wild_Do_Table
Replicate_Wild_Ignore_Table

该 Slave_IO_State 和 Slave_SQL_Running_State 字段不保留。如果需要，可以使用 THREAD_ID 相应复制表的 ID 列并将其与 INFORMATION_SCHEMA PROCESSLIST 表中的列连接，从进程列表中获取这些值，以选择 STATE 后一个表的列。
该 Executed_Gtid_Set 字段可以显示包含大量文本的大集。相反，性能模式表显示了当前正由从属应用的事务的GTID。或者，可以从 gtid_executed 系统变量的值获得该组执行的GTID 。
该 Seconds_Behind_Master 和 Relay_Log_Space 字段在待决定状态，并不会保留。

状态变量已移至复制表

从MySQL 5.7.5版开始，以下状态变量（以前使用过监视 SHOW STATUS ）被移动到Perfomance Schema复制表：

现在，这些状态变量仅在使用单个复制通道时才相关，因为它们仅报告默认复制通道的状态。如果存在多个复制通道，请使用本节中描述的性能架构复制表，该表为每个现有复制通道报告这些变量。

复制通道

复制性能架构表的第一列是 CHANNEL_NAME 。这样可以按复制通道查看表。在非多源复制设置中，有一个默认复制通道。在从属服务器上使用多个复制通道时，可以过滤每个复制通道的表以监视特定的复制通道。有关更多信息，请参见第17.2.3节“复制通道” 和第17.1.4.3节“多源复制监视” 。

26.12.11.1 replication_connection_configuration表

此表显示从属服务器用于连接主服务器的配置参数。存储在表中的参数可以在运行时使用 CHANGE MASTER TO 语句进行更改，如列说明中所示。

与 replication_connection_status 表相比， replication_connection_configuration 变化较少。它包含定义从站连接到主站的方式以及在连接期间保持不变的 replication_connection_status 值，而包含在连接期间更改的值。

该 replication_connection_configuration 表包含以下列：

CHANNEL_NAME

此行正在显示的复制通道。始终存在默认复制通道，可以添加更多复制通道。有关更多信息，请参见第17.2.3节“复制通道” 。
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.6节“加密连接协议和密码” 。
PUBLIC_KEY_PATH

包含主服务器所需的公钥的从属端副本的文件的路径名，用于基于RSA密钥对的密码交换。该文件必须采用PEM格式。此列适用于使用 sha256_password 或 caching_sha2_password 身份验证插件进行身份验证的从属服务器。

如果 PUBLIC_KEY_PATH 给定并指定了有效的公钥文件，则优先于 GET_PUBLIC_KEY 。
GET_PUBLIC_KEY

是否向主服务器请求基于RSA密钥对的密码交换所需的公钥。此列适用于使用 caching_sha2_password 身份验证插件进行身份验证的从属服务器。对于该插件，除非请求，否则主服务器不会发送公钥。

如果 PUBLIC_KEY_PATH 给定并指定了有效的公钥文件，则优先于 GET_PUBLIC_KEY 。

该 replication_connection_configuration 表包含以下索引：

主键（ CHANNEL_NAME ）

TRUNCATE TABLE 不允许使用该 replication_connection_configuration 表。

下表显示了 replication_connection_configuration 列和 SHOW SLAVE STATUS 列之间的对应关系。

`replication_connection_configuration` 柱	`SHOW SLAVE STATUS` 柱
`HOST`	`Master_Host`
`PORT`	`Master_Port`
`USER`	`Master_User`
`NETWORK_INTERFACE`	`Master_Bind`
`AUTO_POSITION`	`Auto_Position`
`SSL_ALLOWED`	`Master_SSL_Allowed`
`SSL_CA_FILE`	`Master_SSL_CA_File`
`SSL_CA_PATH`	`Master_SSL_CA_Path`
`SSL_CERTIFICATE`	`Master_SSL_Cert`
`SSL_CIPHER`	`Master_SSL_Cipher`
`SSL_KEY`	`Master_SSL_Key`
`SSL_VERIFY_SERVER_CERTIFICATE`	`Master_SSL_Verify_Server_Cert`
`SSL_CRL_FILE`	`Master_SSL_Crl`
`SSL_CRL_PATH`	`Master_SSL_Crlpath`
`CONNECTION_RETRY_INTERVAL`	`Connect_Retry`
`CONNECTION_RETRY_COUNT`	`Master_Retry_Count`
`TLS_VERSION`	`Master_TLS_Version`
`PUBLIC_KEY_PATH`	`Master_public_key_path`
`GET_PUBLIC_KEY`	`Get_master_public_key`

26.12.11.2 replication_connection_status表

此表显示处理从服务器与主服务器的连接的I / O线程的当前状态，有关在中继日志中排队的最后一个事务的信息，以及当前正在中继日志中排队的事务的信息。

与 replication_connection_configuration 表相比， replication_connection_status 更改频率更高。它包含在连接期间更改的值，而 replication_connection_configuration 包含定义从站连接到主站的方式以及在连接期间保持不变的值。

该 replication_connection_status 表包含以下列：

CHANNEL_NAME

此行正在显示的复制通道。始终存在默认复制通道，可以添加更多复制通道。有关更多信息，请参见第17.2.3节“复制通道” 。
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

格式的时间戳，显示最近的I / O错误发生的时间。 'YYYY-MM-DD hh:mm:ss[.fraction]'
LAST_HEARTBEAT_TIMESTAMP

格式的时间戳，显示复制从站何时收到最新的心跳信号。 'YYYY-MM-DD hh:mm:ss[.fraction]'
COUNT_RECEIVED_HEARTBEATS

复制从站自上次重新启动或重置或发出 CHANGE MASTER TO 语句以来收到的心跳信号总数。
LAST_QUEUED_TRANSACTION

排队到中继日志的最后一个事务的全局事务ID（GTID）。
LAST_QUEUED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP

格式化的时间戳，显示在中继日志中排队的最后一个事务何时在原始主服务器上提交。 'YYYY-MM-DD hh:mm:ss[.fraction]'
LAST_QUEUED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP

格式化的时间戳，显示在直接主服务器上提交在中继日志中排队的最后一个事务的时间。 'YYYY-MM-DD hh:mm:ss[.fraction]'
LAST_QUEUED_TRANSACTION_START_QUEUE_TIMESTAMP

格式化的时间戳，显示此I / O线程将最后一个事务放入中继日志队列的时间。 'YYYY-MM-DD hh:mm:ss[.fraction]'
LAST_QUEUED_TRANSACTION_END_QUEUE_TIMESTAMP

格式的时间戳，显示上次事务排队到中继日志文件的时间。 'YYYY-MM-DD hh:mm:ss[.fraction]'
QUEUEING_TRANSACTION

中继日志中当前排队事务的全局事务ID（GTID）。
QUEUEING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP

格式化的时间戳，显示当前排队事务在原始主服务器上提交的时间。 'YYYY-MM-DD hh:mm:ss[.fraction]'
QUEUEING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP

格式化的时间戳，显示当前排队事务何时在直接主服务器上提交。 'YYYY-MM-DD hh:mm:ss[.fraction]'
QUEUEING_TRANSACTION_START_QUEUE_TIMESTAMP

格式化的时间戳，显示当前排队事务的第一个事件何时被此I / O线程写入中继日志。 'YYYY-MM-DD hh:mm:ss[.fraction]'

禁用性能架构时，不会收集本地计时信息，因此显示排队事务的开始和结束时间戳的字段为零。

该 replication_connection_status 表包含以下索引：

主键（ CHANNEL_NAME ）
索引（ THREAD_ID ）

下表显示了 replication_connection_status 列和 SHOW SLAVE STATUS 列之间的对应关系。

`replication_connection_status` 柱	`SHOW SLAVE STATUS` 柱
`SOURCE_UUID`	`Master_UUID`
`THREAD_ID`	没有
`SERVICE_STATE`	`Slave_IO_Running`
`RECEIVED_TRANSACTION_SET`	`Retrieved_Gtid_Set`
`LAST_ERROR_NUMBER`	`Last_IO_Errno`
`LAST_ERROR_MESSAGE`	`Last_IO_Error`
`LAST_ERROR_TIMESTAMP`	`Last_IO_Error_Timestamp`

26.12.11.3 replication_applier_configuration表

此表显示影响从属服务器应用的事务的配置参数。存储在表中的参数可以在运行时使用 CHANGE MASTER TO 语句进行更改，如列说明中所示。

该 replication_applier_configuration 表包含以下列：

CHANNEL_NAME

此行正在显示的复制通道。始终存在默认复制通道，可以添加更多复制通道。有关更多信息，请参见第17.2.3节“复制通道” 。
DESIRED_DELAY

从站必须滞后主站的秒数。（ CHANGE MASTER TO 选项 :) 有关更多信息， MASTER_DELAY 请参见第17.3.12节“延迟复制” 。

该 replication_applier_configuration 表包含以下索引：

主键（ CHANNEL_NAME ）

TRUNCATE TABLE 不允许使用该 replication_applier_configuration 表。

下表显示了 replication_applier_configuration 列和 SHOW SLAVE STATUS 列之间的对应关系。

`replication_applier_configuration` 柱	`SHOW SLAVE STATUS` 柱
`DESIRED_DELAY`	`SQL_Delay`

26.12.11.4 replication_applier_status表

此表显示从属服务器上的当前常规事务执行状态。该表提供有关事务应用程序状态的一般方面的信息，这些信息并非特定于所涉及的任何线程。 replication_applier_status_by_coordinator 表中提供了特定于线程的状态信息（ replication_applier_status_by_worker 如果从属是多线程的）。

该 replication_applier_status 表包含以下列：

CHANNEL_NAME

此行正在显示的复制通道。始终存在默认复制通道，可以添加更多复制通道。有关更多信息，请参见第17.2.3节“复制通道” 。
SERVICE_STATE

显示 ON 复制通道的应用程序线程处于活动状态还是空闲状态时， OFF 表示应用程序线程未处于活动状态。
REMAINING_DELAY

如果从属设备 DESIRED_DELAY 在应用事务后等待秒数，则此字段包含剩余的延迟秒数。在其他时候，这个领域是 NULL 。（该 DESIRED_DELAY 值存储在 replication_applier_configuration 表中。）有关更多信息，请参见第17.3.12节“延迟复制” 。
COUNT_TRANSACTIONS_RETRIES

显示由于从属SQL线程无法应用事务而进行的重试次数。给定事务的最大重试次数由 slave_transaction_retries 系统变量设置。该 replication_applier_status_by_worker 表显示了有关单线程或多线程从站的事务重试的详细信息。

该 replication_applier_status 表包含以下索引：

主键（ CHANNEL_NAME ）

TRUNCATE TABLE 不允许使用该 replication_applier_status 表。

下表显示了 replication_applier_status 列和 SHOW SLAVE STATUS 列之间的对应关系。

`replication_applier_status` 柱	`SHOW SLAVE STATUS` 柱
`SERVICE_STATE`	没有
`REMAINING_DELAY`	`SQL_Remaining_Delay`

26.12.11.5 replication_applier_status_by_coordinator表

对于多线程从站，从站使用多个工作线程和协调器线程来管理它们，此表显示协调器线程的状态。对于单线程从站，此表为空。对于一个多线程的奴隶， replication_applier_status_by_worker 表显示了工作线程的状态。此表提供有关协调器线程缓冲到工作队列的最后一个事务的信息，以及它当前正在缓冲的事务。开始时间戳指的是此线程从中继日志读取事务的第一个事件以将其缓冲到工作队列，而结束时间戳指的是最后一个事件缓冲到工作队列的时间。

该 replication_applier_status_by_coordinator 表包含以下列：

CHANNEL_NAME

此行正在显示的复制通道。始终存在默认复制通道，可以添加更多复制通道。有关更多信息，请参见第17.2.3节“复制通道” 。
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 列中显示的所有错误代码和消息都对应于第B.3.1节“服务器错误消息参考”中列出的错误值。
LAST_ERROR_TIMESTAMP

格式的时间戳，显示最近发生的SQL /协调程序错误的时间。 'YYYY-MM-DD hh:mm:ss[.fraction]'
LAST_PROCESSED_TRANSACTION

此协调程序处理的最后一个事务的全局事务ID（GTID）。
LAST_PROCESSED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP

格式化的时间戳，显示此协调程序处理的最后一个事务何时在原始主服务器上提交。 'YYYY-MM-DD hh:mm:ss[.fraction]'
LAST_PROCESSED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP

格式化的时间戳，显示此协调程序处理的最后一个事务何时在直接主服务器上提交。 'YYYY-MM-DD hh:mm:ss[.fraction]'
LAST_PROCESSED_TRANSACTION_START_BUFFER_TIMESTAMP

格式化的时间戳，显示此协调程序线程何时开始将最后一个事务写入工作线程的缓冲区。 'YYYY-MM-DD hh:mm:ss[.fraction]'
LAST_PROCESSED_TRANSACTION_END_BUFFER_TIMESTAMP

格式化的时间戳，显示此协调器线程将最后一个事务写入工作线程的缓冲区的时间。 'YYYY-MM-DD hh:mm:ss[.fraction]'
PROCESSING_TRANSACTION

此协调器线程当前正在处理的事务的全局事务ID（GTID）。
PROCESSING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP

格式化的时间戳，显示当前处理事务在原始主服务器上提交的时间。 'YYYY-MM-DD hh:mm:ss[.fraction]'
PROCESSING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP

格式化的时间戳，显示当前处理事务何时在直接主服务器上提交。 'YYYY-MM-DD hh:mm:ss[.fraction]'
PROCESSING_TRANSACTION_START_BUFFER_TIMESTAMP

格式化的时间戳，显示此协调程序线程何时开始将当前处理的事务写入工作线程的缓冲区。 'YYYY-MM-DD hh:mm:ss[.fraction]'

禁用性能模式时，不会收集本地计时信息，因此显示缓冲事务的开始和结束时间戳的字段为零。

该 replication_applier_status_by_coordinator 表包含以下索引：

主键（ CHANNEL_NAME ）
索引（ THREAD_ID ）

下表显示了 replication_applier_status_by_coordinator 列和 SHOW SLAVE STATUS 列之间的对应关系。

`replication_applier_status_by_coordinator` 柱	`SHOW SLAVE STATUS` 柱
`THREAD_ID`	没有
`SERVICE_STATE`	`Slave_SQL_Running`
`LAST_ERROR_NUMBER`	`Last_SQL_Errno`
`LAST_ERROR_MESSAGE`	`Last_SQL_Error`
`LAST_ERROR_TIMESTAMP`	`Last_SQL_Error_Timestamp`

26.12.11.6 replication_applier_status_by_worker表

此表提供复制从属组或组复制组成员上的应用程序线程处理的事务的详细信息。对于单线程从站，将显示从站的单个应用程序线程的数据。对于多线程从站，将为每个应用程序线程单独显示数据。多线程从站上的应用程序线程有时称为工作程序。复制从属组或组复制组成员上的应用程序线程数由 slave_parallel_workers 系统变量设置，对于单线程从属设置，该变量设置为零。多线程从属服务器还有一个协调器线程来管理应用程序线程，并且该线程的状态显示在 replication_applier_status_by_coordinator 表。

与错误相关的列中显示的所有错误代码和消息都对应于第B.3.1节“服务器错误消息参考”中列出的错误值。

禁用性能架构时，不会收集本地计时信息，因此显示已应用事务的开始和结束时间戳的字段为零。此表中的开始时间戳指的是工作程序何时开始应用第一个事件，结束时间戳指的是应用事务的最后一个事件的时间。

通过 START SLAVE 语句重新启动复制从站时，将 APPLYING_TRANSACTION 重置列开头。在MySQL 8.0.13之前，这些列未在以单线程模式运行的从站上重置，仅在多线程从站上运行。

该 replication_applier_status_by_worker 表包含以下列：

CHANNEL_NAME

此行正在显示的复制通道。始终存在默认复制通道，可以添加更多复制通道。有关更多信息，请参见第17.2.3节“复制通道” 。
WORKER_ID

worker标识符（与表中的 id 列相同 mysql.slave_worker_info ）。之后 STOP SLAVE ， THREAD_ID 列变为 NULL ，但 WORKER_ID 值保留。
THREAD_ID

工作线程ID。
SERVICE_STATE

ON （线程存在且处于活动状态或空闲状态）或 OFF （线程不再存在）。
LAST_ERROR_NUMBER ， LAST_ERROR_MESSAGE

导致工作线程停止的最新错误的错误号和错误消息。错误号为0，空字符串的消息表示 “ 无错误 ” 。如果该 LAST_ERROR_MESSAGE 值不为空，则错误值也会出现在从站的错误日志中。

发出 RESET MASTER 或 RESET SLAVE 重置这些列中显示的值。
LAST_ERROR_TIMESTAMP

格式的时间戳，显示最近发生的工作程序错误发生的时间。 'YYYY-MM-DD hh:mm:ss[.fraction]'
LAST_APPLIED_TRANSACTION

此工作程序应用的上一个事务的全局事务ID（GTID）。
LAST_APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP

格式的时间戳，显示此工作程序应用的最后一个事务何时在原始主服务器上提交。 'YYYY-MM-DD hh:mm:ss[.fraction]'
LAST_APPLIED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP

格式化的时间戳，显示此工作程序应用的最后一个事务何时在直接主服务器上提交。 'YYYY-MM-DD hh:mm:ss[.fraction]'
LAST_APPLIED_TRANSACTION_START_APPLY_TIMESTAMP

格式化的时间戳，显示此工作程序何时开始应用上次应用的事务。 'YYYY-MM-DD hh:mm:ss[.fraction]'
LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP

格式的时间戳，显示此工作程序何时完成应用上次应用的事务。 'YYYY-MM-DD hh:mm:ss[.fraction]'
APPLYING_TRANSACTION

此工作程序当前正在应用的事务的全局事务ID（GTID）。
APPLYING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP

格式的时间戳，显示此工作程序当前应用的事务何时在原始主服务器上提交。 'YYYY-MM-DD hh:mm:ss[.fraction]'
APPLYING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP

格式的时间戳，显示此工作程序当前应用的事务何时在直接主服务器上提交。 'YYYY-MM-DD hh:mm:ss[.fraction]'
APPLYING_TRANSACTION_START_APPLY_TIMESTAMP

格式的时间戳，显示此工作程序何时开始应用当前正在应用的事务的第一次尝试。在MySQL 8.0.13之前，当由于瞬时错误而重试事务时刷新了此时间戳，因此它显示了最近尝试应用事务的时间戳。 'YYYY-MM-DD hh:mm:ss[.fraction]'
LAST_APPLIED_TRANSACTION_RETRIES_COUNT

第一次尝试后工作程序重试上次应用的事务的次数。如果在第一次尝试时应用了该交易，则该数字为零。
LAST_APPLIED_TRANSACTION_LAST_TRANSIENT_ERROR_NUMBER

导致重试事务的最后一个瞬态错误的错误号。
LAST_APPLIED_TRANSACTION_LAST_TRANSIENT_ERROR_MESSAGE

导致重试事务的最后一个瞬态错误的消息文本。
LAST_APPLIED_TRANSACTION_LAST_TRANSIENT_ERROR_TIMESTAMP

导致重试事务的最后一个瞬态错误的格式的时间戳。 'YYYY-MM-DD hh:mm:ss[.fraction]'
APPLYING_TRANSACTION_RETRIES_COUNT

直到此时重试当前正在应用的事务的次数。如果在第一次尝试时应用了该交易，则该数字为零。
APPLYING_TRANSACTION_LAST_TRANSIENT_ERROR_NUMBER

导致重试当前事务的最后一个瞬态错误的错误号。
APPLYING_TRANSACTION_LAST_TRANSIENT_ERROR_MESSAGE

导致重试当前事务的上一个瞬态错误的消息文本。
APPLYING_TRANSACTION_LAST_TRANSIENT_ERROR_TIMESTAMP

导致重试当前事务的上一个瞬态错误的格式时间戳。 'YYYY-MM-DD hh:mm:ss[.fraction]'

该 replication_applier_status_by_worker 表包含以下索引：

主键（ CHANNEL_NAME ， WORKER_ID ）
索引（ THREAD_ID ）

下表显示了 replication_applier_status_by_worker 列和 SHOW SLAVE STATUS 列之间的对应关系。

`replication_applier_status_by_worker` 柱	`SHOW SLAVE STATUS` 柱
`WORKER_ID`	没有
`THREAD_ID`	没有
`SERVICE_STATE`	没有
`LAST_ERROR_NUMBER`	`Last_SQL_Errno`
`LAST_ERROR_MESSAGE`	`Last_SQL_Error`
`LAST_ERROR_TIMESTAMP`	`Last_SQL_Error_Timestamp`

26.12.11.7 replication_applier_global_filters表

此表显示在此从属服务器上配置的全局复制筛选器。该 replication_applier_global_filters 表包含以下列：

FILTER_NAME

已配置的复制筛选器类型。
FILTER_RULE

使用 --replicate-* 命令选项或为复制过滤器类型配置的规则 CHANGE REPLICATION FILTER 。
CONFIGURED_BY

用于配置复制过滤器的方法可以是以下之一：
- CHANGE_REPLICATION_FILTER 使用 CHANGE REPLICATION FILTER 语句由全局复制筛选器配置。
- STARTUP_OPTIONS 使用 --replicate-* 选项由全局复制筛选器配置。
ACTIVE_SINCE

配置复制筛选器的时间戳。

26.12.11.8 replication_applier_filters表

此表显示在此从站上配置的复制通道特定筛选器。每行提供有关复制通道配置的过滤器类型的信息。该 replication_applier_filters 表包含以下列：

CHANNEL_NAME

配置了复制筛选器的复制通道的名称。
FILTER_NAME

已为此复制通道配置的复制筛选器类型。
FILTER_RULE

使用 --replicate-* 命令选项或为复制过滤器类型配置的规则 CHANGE REPLICATION FILTER 。
CONFIGURED_BY

用于配置复制过滤器的方法可以是以下之一：
- CHANGE_REPLICATION_FILTER 使用 CHANGE REPLICATION FILTER 语句由全局复制筛选器配置。
- STARTUP_OPTIONS 使用 --replicate-* 选项由全局复制筛选器配置。
- CHANGE_REPLICATION_FILTER_FOR_CHANNEL 使用 CHANGE REPLICATION FILTER FOR CHANNEL 语句由特定于通道的复制过滤器配置。
- STARTUP_OPTIONS_FOR_CHANNEL 使用 --replicate-* 选项由特定于通道的复制筛选器配置。
ACTIVE_SINCE

配置复制筛选器的时间戳。
COUNTER

复制筛选器自配置以来的使用次数。

26.12.11.9 replication_group_members表

此表显示复制组成员的网络和状态信息。显示的网络地址是用于将客户端连接到组的地址，不应与指定的成员的内部组通信地址混淆 group_replication_local_address 。

该 replication_group_members 表包含以下列：

CHANNEL_NAME

组复制通道的名称。
MEMBER_ID

成员服务器UUID。这对于组中的每个成员具有不同的值。这也是一个关键，因为它对每个成员都是独一无二的。
MEMBER_HOST

该成员的网络地址（主机名或IP地址）。从成员的 hostname 变量中检索。这是客户端连接的地址，与用于内部组通信的group_replication_local_address不同。
MEMBER_PORT

服务器正在侦听的端口。从成员的 port 变量中检索。
MEMBER_STATE

该成员的现状; 可以是以下任何一种：
- ONLINE ：该成员处于完全运行状态。
- RECOVERING ：服务器已加入一个从中检索数据的组。
- OFFLINE ：组复制插件已安装但尚未启动。
- ERROR ：成员在应用事务期间或在恢复阶段遇到错误，并且未参与组的事务。
- UNREACHABLE ：故障检测过程怀疑无法联系此成员，因为组消息已超时。
请参见第18.3.1节“组Replication Server状态” 。
MEMBER_ROLE

成员在组中的角色， PRIMARY 或者 SECONDARY 。
MEMBER_VERSION

MySQL版本的成员。

该 replication_group_members 表包含以下索引：

没有

TRUNCATE TABLE 不允许使用该 replication_group_members 表。

26.12.11.10 replication_group_member_stats表

此表显示复制组成员的统计信息。仅在组复制正在运行时才会填充它。

该 replication_group_member_stats 表包含以下列：

CHANNEL_NAME

组复制通道的名称
VIEW_ID

此组的当前视图标识符。
MEMBER_ID

成员服务器UUID。这对于组中的每个成员具有不同的值。这也是一个关键，因为它对每个成员都是独一无二的。
COUNT_TRANSACTIONS_IN_QUEUE

待处理冲突检测的队列中的事务数。一旦检查了事务的冲突，如果它们通过了检查，它们就会排队等待应用。
COUNT_TRANSACTIONS_CHECKED

已检查冲突的事务数。
COUNT_CONFLICTS_DETECTED

未通过冲突检测检查的事务数。
COUNT_TRANSACTIONS_VALIDATING

可用于认证但尚未进行垃圾回收的交易数量。可以被认为是每个事务被认证的冲突检测数据库的当前大小。
TRANSACTIONS_COMMITTED_ALL_MEMBERS

已在复制组的所有成员上成功提交的事务，显示为 GTID集。这是以固定的时间间隔更新的。
LAST_CONFLICT_FREE_TRANSACTION

已检查的最后一个无冲突事务的事务标识符。
COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE

此成员从复制组收到的等待应用的事务数。
COUNT_TRANSACTIONS_REMOTE_APPLIED

此成员从组中收到并已应用的事务数。
COUNT_TRANSACTIONS_LOCAL_PROPOSED

源自此成员并发送给该组的交易数量。
COUNT_TRANSACTIONS_LOCAL_ROLLBACK

源自此成员并由该组回滚的事务数。

该 replication_group_member_stats 表包含以下索引：

没有

TRUNCATE TABLE 不允许使用该 replication_group_member_stats 表。

26.12.12性能模式锁表

26.12.12.1 data_locks表
26.12.12.2 data_lock_waits表
26.12.12.3 metadata_locks表
26.12.12.4 table_handles表

性能模式通过这些表公开锁信息：

data_locks ：持有和请求数据锁
data_lock_waits ：数据锁所有者与这些所有者阻止的数据锁请求者之间的关系
metadata_locks ：持有和请求的元数据锁
table_handles ：持有和请求表锁

以下部分更详细地描述了这些表。

26.12.12.1 data_locks表

该 data_locks 表显示了持有和请求的数据锁。有关哪些锁定请求被哪些锁定阻塞阻止的信息，请参见第26.12.12.2节“data_lock_waits表” 。

示例数据锁定信息：

MySQL的> SELECT * FROM performance_schema.data_locks\G
*************************** 1。排******************** *******
               发动机：INNODB
       ENGINE_LOCK_ID：139664434886512：1059：139664350547912
ENGINE_TRANSACTION_ID：2569
            THREAD_ID：46
             EVENT_ID：12
        OBJECT_SCHEMA：测试
          OBJECT_NAME：t1
       PARTITION_NAME：NULL
    SUBPARTITION_NAME：NULL
           INDEX_NAME：NULL
OBJECT_INSTANCE_BEGIN：139664350547912
            LOCK_TYPE：TABLE
            LOCK_MODE：IX
          LOCK_STATUS：已授权
            LOCK_DATA：NULL
*************************** 2.排******************** *******
               发动机：INNODB
       ENGINE_LOCK_ID：139664434886512：2：4：1：139664350544872
ENGINE_TRANSACTION_ID：2569
            THREAD_ID：46
             EVENT_ID：12
        OBJECT_SCHEMA：测试
          OBJECT_NAME：t1
       PARTITION_NAME：NULL
    SUBPARTITION_NAME：NULL
           INDEX_NAME：GEN_CLUST_INDEX
OBJECT_INSTANCE_BEGIN：139664350544872
            LOCK_TYPE：记录
            LOCK_MODE：X
          LOCK_STATUS：已授权
            LOCK_DATA：supremum伪记录

与大多数性能模式数据收集不同，没有用于控制是否收集数据锁定信息的工具或用于控制数据锁定表大小的系统变量。性能模式收集服务器中已有的信息，因此没有内存或CPU开销来生成此信息或需要控制其集合的参数。

使用该 data_locks 表可帮助诊断在并发负载较重时发生的性能问题。有关 InnoDB ，请参见第15.14.2节“InnoDB INFORMATION_SCHEMA事务和锁定信息” 中对此主题的讨论。

该 data_locks 表包含以下列：

ENGINE

保存或请求锁定的存储引擎。
ENGINE_LOCK_ID

存储引擎保持或请求的锁的ID。（ ENGINE_LOCK_ID ， ENGINE ）值的元组是唯一的。

锁定ID格式是内部的，并且可能随时更改。应用程序不应该依赖具有特定格式的锁ID。
ENGINE_TRANSACTION_ID

请求锁定的事务的存储引擎内部标识。这可以被认为是锁的所有者，虽然锁可能仍然是挂起的，实际上还没有被授予（ LOCK_STATUS='WAITING' ）。

如果事务尚未执行任何写入操作（仍被认为是只读），则该列包含用户不应尝试解释的内部数据。否则，该列是事务ID。

对于 InnoDB ，以获取有关交易详情，与加入这一列 TRX_ID 的列 INFORMATION_SCHEMA INNODB_TRX 表。
THREAD_ID

创建锁的会话的线程ID。要获取有关该线程的详细信息，请将此列与 THREAD_ID Performance Schema threads 表的列连接。

THREAD_ID 可以与一起使用 EVENT_ID 以确定在内存中创建锁数据结构的事件。（如果数据结构用于存储多个锁，则此事件可能在此特定锁请求发生之前发生。）
EVENT_ID

导致锁定的Performance Schema事件。（ THREAD_ID ， EVENT_ID ）值的元组隐式标识其他Performance Schema表中的父事件：
- 表中的父等待事件 events_waits_xxx
- 表中的父级事件 events_stages_xxx
- 表中的父语句事件 events_statements_xxx
- 在父事务事件 events_transactions_current 表
要获取有关父事件的详细信息，请在相应的父事件表中使用相同名称的列连接 THREAD_ID 和 EVENT_ID 列。请参见第26.19.2节“获取父事件信息” 。
OBJECT_SCHEMA

包含锁定表的架构。
OBJECT_NAME

锁定表的名称。
PARTITION_NAME

锁定分区的名称（如果有）; NULL 除此以外。
SUBPARTITION_NAME

锁定子分区的名称（如果有）; NULL 除此以外。
INDEX_NAME

锁定索引的名称（如果有）; NULL 除此以外。

在实践中， InnoDB 总是创建索引（ GEN_CLUST_INDEX ），所以 INDEX_NAME 是不 NULL 为 InnoDB 表。
OBJECT_INSTANCE_BEGIN

锁内存中的地址。
LOCK_TYPE

锁的类型。

该值取决于存储引擎。对于表级锁定 InnoDB ，允许值 RECORD 用于行 TABLE 级锁定。
LOCK_MODE

如何请求锁定。

该值取决于存储引擎。为 InnoDB ，允许值是 S[,GAP] ， X[,GAP] ， IS[,GAP] ， IX[,GAP] ， AUTO_INC ，和 UNKNOWN 。锁定模式除了 AUTO_INC 并 UNKNOWN 指示间隙锁定（如果存在）。有关信息 S ， X ， IS ， IX ，和差距锁，请参阅第15.7.1，“InnoDB的锁定” 。
LOCK_STATUS

锁定请求的状态。

该值取决于存储引擎。因为 InnoDB ，允许的值是 GRANTED （保持锁定）和 WAITING （等待锁定）。
LOCK_DATA

与锁相关的数据（如果有）。该值取决于存储引擎。对于 InnoDB ，如果 LOCK_TYPE 是 RECORD ，则显示值，否则为值 NULL 。锁定记录的主键值显示在主键索引上的锁定。显示锁定记录的辅助索引值，并为放置在辅助索引上的锁附加主键值。如果没有主键，则根据规则 LOCK_DATA 显示所选唯一索引的键值或唯一 InnoDB 内部行ID号 InnoDB 聚簇索引（请参见第15.6.2.1节“聚簇和二级索引”））。 LOCK_DATA 报告对 supremum伪记录采取锁定的 “ supremum伪记录 ” 。如果包含锁定记录的页面不在缓冲池中，因为它在保持锁定时写入磁盘， InnoDB 则不会从磁盘中获取页面。相反， LOCK_DATA 报告 NULL 。

该 data_locks 表包含以下索引：

主键（ ENGINE_LOCK_ID ， ENGINE ）
索引（ ENGINE_TRANSACTION_ID ， ENGINE ）
索引（ THREAD_ID ， EVENT_ID ）
指数（ OBJECT_SCHEMA ， OBJECT_NAME ， PARTITION_NAME ， SUBPARTITION_NAME ）

TRUNCATE TABLE 不允许使用该 data_locks 表。

26.12.12.2 data_lock_waits表

该 data_lock_waits 表实现了多对多关系，表明 data_locks 表中的哪些数据锁请求被表中的哪些数据锁阻塞 data_locks 。在持有的锁 data_locks 出现 data_lock_waits ，只有当他们阻止某些锁定请求。

此信息使您可以了解会话之间的数据锁依赖性。该表不仅公开会话或事务正在等待的锁定，而且还公开当前持有该锁定的会话或事务。

示例数据锁等待信息：

MySQL的> SELECT * FROM performance_schema.data_lock_waits\G
*************************** 1。排******************** *******
                          发动机：INNODB
       REQUESTING_ENGINE_LOCK_ID：140211201964816：2：4：2：140211086465800
REQUESTING_ENGINE_TRANSACTION_ID：1555
            REQUESTING_THREAD_ID：47
             REQUESTING_EVENT_ID：5
REQUESTING_OBJECT_INSTANCE_BEGIN：140211086465800
         BLOCKING_ENGINE_LOCK_ID：140211201963888：2：4：2：140211086459880
  BLOCKING_ENGINE_TRANSACTION_ID：1554
              BLOCKING_THREAD_ID：46
               BLOCKING_EVENT_ID：12
  BLOCKING_OBJECT_INSTANCE_BEGIN：140211086459880

使用该 data_lock_waits 表可帮助诊断在并发负载较重时发生的性能问题。有关 InnoDB ，请参见第15.14.2节“InnoDB INFORMATION_SCHEMA事务和锁定信息” 中对此主题的讨论。

由于表中的列与 data_lock_waits 表中的列类似 data_locks ，因此这里的列描述是缩写的。有关更详细的列说明，请参见第26.12.12.1节“data_locks表” 。

该 data_lock_waits 表包含以下列：

ENGINE

请求锁定的存储引擎。
REQUESTING_ENGINE_LOCK_ID

存储引擎请求的锁的ID。要获取有关锁的详细信息，请将此列与表的 ENGINE_LOCK_ID 列连接 data_locks 。
REQUESTING_ENGINE_TRANSACTION_ID

请求锁定的事务的存储引擎内部标识。
REQUESTING_THREAD_ID

请求锁定的会话的线程ID。
REQUESTING_EVENT_ID

导致请求锁定的会话中的锁定请求的Performance Schema事件。
REQUESTING_OBJECT_INSTANCE_BEGIN

请求锁定的内存中的地址。
BLOCKING_ENGINE_LOCK_ID

阻塞锁的ID。要获取有关锁的详细信息，请将此列与表的 ENGINE_LOCK_ID 列连接 data_locks 。
BLOCKING_ENGINE_TRANSACTION_ID

保存阻塞锁的事务的存储引擎内部标识。
BLOCKING_THREAD_ID

保存阻塞锁的会话的线程ID。
BLOCKING_EVENT_ID

导致阻塞锁定的Performance Schema事件。
BLOCKING_OBJECT_INSTANCE_BEGIN

阻塞锁内存中的地址。

该 data_lock_waits 表包含以下索引：

索引（ REQUESTING_ENGINE_LOCK_ID ， ENGINE ）
索引（ BLOCKING_ENGINE_LOCK_ID ， ENGINE ）
索引（ REQUESTING_ENGINE_TRANSACTION_ID ， ENGINE ）
索引（ BLOCKING_ENGINE_TRANSACTION_ID ， ENGINE ）
索引（ REQUESTING_THREAD_ID ， REQUESTING_EVENT_ID ）
索引（ BLOCKING_THREAD_ID ， BLOCKING_EVENT_ID ）

TRUNCATE TABLE 不允许使用该 data_lock_waits 表。

26.12.12.3 metadata_locks表

MySQL使用元数据锁定来管理对数据库对象的并发访问并确保数据一致性; 请参见第8.11.4节“元数据锁定” 。

性能模式通过 metadata_locks 表格公开元数据锁定信息：

已授予的锁（显示哪些会话拥有哪些当前元数据锁定）。
已请求但尚未授予的锁（显示哪些会话正在等待哪些元数据锁定）。
锁定已被死锁检测器杀死的请求。
已超时并正在等待请求会话的锁定请求被丢弃的锁定请求。

此信息使您可以了解会话之间的元数据锁定依赖关系。您不仅可以看到会话正在等待哪个锁，而且当前哪个会话持有该锁。

该 metadata_locks 表是只读的，无法更新。它默认是自动调整的; 配置表大小，设置 performance_schema_max_metadata_locks 在服务器启动时系统变量。

元数据锁定工具使用 wait/lock/metadata/sql/mdl 默认启用工具。

要在服务器启动时控制元数据锁定检测状态，请在 my.cnf 文件中使用以下行：

启用：

的[mysqld]
性能架构仪器= '等待/锁定/元数据/ SQL / MDL = ON'

禁用：

的[mysqld]
性能架构仪器= '等待/锁定/元数据/ SQL / MDL = OFF'

要在运行时控制元数据锁定检测状态，请更新 setup_instruments 表：

启用：

更新performance_schema.setup_instruments
SET ENABLED ='YES'，TIMED ='YES'
WHERE NAME ='wait / lock / metadata / sql / mdl';

禁用：

更新performance_schema.setup_instruments
SET ENABLED ='NO'，TIMED ='NO'
WHERE NAME ='wait / lock / metadata / sql / mdl';

性能模式维护 metadata_locks 表内容如下，使用 LOCK_STATUS 列指示每个锁的状态：

当请求并立即获得元数据锁定时， GRANTED 插入状态为的行。
当请求元数据锁定而不立即获取时， PENDING 会插入状态为的行。
当授予先前请求的元数据锁时，其行状态将更新为 GRANTED 。
释放元数据锁定后，将删除其行。
当死锁检测器取消挂起的锁定请求以打破死锁（ ER_LOCK_DEADLOCK ）时，其行状态将从更新 PENDING 为 VICTIM 。
当挂起的锁定请求超时（ ER_LOCK_WAIT_TIMEOUT ）时，其行状态将从更新 PENDING 为 TIMEOUT 。
当准予的锁定或挂起的锁请求被杀害，其行状态从更新 GRANTED 或 PENDING 到 KILLED 。
的 VICTIM ， TIMEOUT 和 KILLED 状态值是短暂的，并表示该行锁定即将被删除。
该 PRE_ACQUIRE_NOTIFY 和 POST_RELEASE_NOTIFY 状态值是短暂的，并表示该元数据锁定subsubsystem的通知感兴趣的存储引擎，而进入锁定获取操作或离开锁释放操作。

该 metadata_locks 表包含以下列：

OBJECT_TYPE

元数据锁子系统中使用的锁类型。值中的一个 GLOBAL ， SCHEMA ， TABLE ， FUNCTION ， PROCEDURE ， TRIGGER （当前未用的），， EVENT ， COMMIT ， USER LEVEL LOCK ， TABLESPACE 或 LOCKING SERVICE 。

值为 USER LEVEL LOCK 表示获取的锁 GET_LOCK() 。值为 LOCKING SERVICE 表示使用第29.3.1节“锁定服务”中描述的锁定服务获取的锁。
OBJECT_SCHEMA

包含该对象的架构。
OBJECT_NAME

已检测对象的名称。
OBJECT_INSTANCE_BEGIN

已检测对象的内存中的地址。
LOCK_TYPE

来自元数据锁子系统的锁类型。值中的一个 INTENTION_EXCLUSIVE ， SHARED ， SHARED_HIGH_PRIO ， SHARED_READ ， SHARED_WRITE ， SHARED_UPGRADABLE ， SHARED_NO_WRITE ， SHARED_NO_READ_WRITE ，或 EXCLUSIVE 。
LOCK_DURATION

来自元数据锁子系统的锁定持续时间。值中的一个 STATEMENT ， TRANSACTION 或 EXPLICIT 。该 STATEMENT 和 TRANSACTION 值表示，它们分别隐含释放在语句或事务结束，锁具。该 EXPLICIT 值表示在语句或事务结束后仍然存在的锁，并由显式操作释放，例如使用获取的全局锁 FLUSH TABLES WITH READ LOCK 。
LOCK_STATUS

来自元数据锁子系统的锁定状态。值中的一个 PENDING ， GRANTED ， VICTIM ， TIMEOUT ， KILLED ， PRE_ACQUIRE_NOTIFY ，或 POST_RELEASE_NOTIFY 。性能模式如前所述分配这些值。
SOURCE

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

请求元数据锁定的线程。
OWNER_EVENT_ID

请求元数据锁定的事件。

该 metadata_locks 表包含以下索引：

主键（ OBJECT_INSTANCE_BEGIN ）
指数（ OBJECT_TYPE ， OBJECT_SCHEMA ， OBJECT_NAME ）
索引（ OWNER_THREAD_ID ， OWNER_EVENT_ID ）

TRUNCATE TABLE 不允许使用该 metadata_locks 表。

26.12.12.4 table_handles表

性能模式通过 table_handles 表公开表锁信息，以显示当前对每个打开的表句柄有效的表锁。 table_handles 报告表锁定工具记录的内容。此信息显示哪个表处理服务器已打开，如何锁定以及哪些会话。

该 table_handles 表是只读的，无法更新。它默认是自动调整的; 要配置表大小，请 performance_schema_max_table_handles 在服务器启动时设置系统变量。

表锁检测使用 wait/lock/table/sql/handler 默认启用的仪器。

要在服务器启动时控制表锁定检测状态，请在 my.cnf 文件中使用以下行：

启用：

的[mysqld]
性能架构仪器=“等待/锁定/表/ SQL /处理器= ON”

禁用：

的[mysqld]
性能架构仪器=“等待/锁定/表/ SQL /处理器= OFF”

要在运行时控制表锁定检测状态，请更新 setup_instruments 表：

启用：

更新performance_schema.setup_instruments
SET ENABLED ='YES'，TIMED ='YES'
WHERE NAME ='wait / lock / table / sql / handler';

禁用：

更新performance_schema.setup_instruments
SET ENABLED ='NO'，TIMED ='NO'
WHERE NAME ='wait / lock / table / sql / handler';

该 table_handles 表包含以下列：

OBJECT_TYPE

桌子由桌子把手打开。
OBJECT_SCHEMA

包含该对象的架构。
OBJECT_NAME

已检测对象的名称。
OBJECT_INSTANCE_BEGIN

表句柄地址在内存中。
OWNER_THREAD_ID

拥有表句柄的线程。
OWNER_EVENT_ID

导致表句柄打开的事件。
INTERNAL_LOCK

在SQL级别使用的表锁。值中的一个 READ ， READ WITH SHARED LOCKS ， READ HIGH PRIORITY ， READ NO INSERT ， WRITE ALLOW WRITE ， WRITE CONCURRENT INSERT ， WRITE LOW PRIORITY ，或 WRITE 。有关这些锁类型的信息，请参阅 include/thr_lock.h 源文件。
EXTERNAL_LOCK

在存储引擎级别使用的表锁。值是 READ EXTERNAL 或之一 WRITE EXTERNAL 。

该 table_handles 表包含以下索引：

主键（ OBJECT_INSTANCE_BEGIN ）
指数（ OBJECT_TYPE ， OBJECT_SCHEMA ， OBJECT_NAME ）
索引（ OWNER_THREAD_ID ， OWNER_EVENT_ID ）

TRUNCATE TABLE 不允许使用该 table_handles 表。

26.12.13性能模式系统变量表

26.12.13.1性能模式persisted_variables表
26.12.13.2性能模式variables_info表

MySQL服务器维护许多系统变量，指示它的配置方式（参见第5.1.8节“服务器系统变量” ）。这些性能模式表中提供了系统变量信息：

global_variables ：全局系统变量。仅需要全局值的应用程序应使用此表。
session_variables ：当前会话的系统变量。要将所有系统变量值用于其自己的会话的应用程序应使用此表。它包括其会话的会话变量，以及没有会话对应的全局变量的值。
variables_by_thread ：每个活动会话的会话系统变量。想要知道特定会话的会话变量值的应用程序应使用此表。它仅包含会话变量，由线程ID标识。
persisted_variables ：为 mysqld-auto.cnf 存储全局系统变量设置的文件提供SQL接口。请参见第26.12.13.1节“性能模式persisted_variables表” 。
variables_info ：为每个系统变量显示最近设置的源及其值范围。请参见第26.12.13.2节“性能模式variables_info表” 。

会话变量表（ session_variables ， variables_by_thread ）仅包含活动会话的信息，而不包含已终止的会话。

TRUNCATE TABLE Performance Schema系统变量表不支持。

在 global_variables 与 session_variables 表有这些列：

VARIABLE_NAME

系统变量名称。
VARIABLE_VALUE

系统变量值。对于 global_variables ，此列包含全局值。对于 session_variables 此列，包含对当前会话有效的变量值。

在 global_variables 与 session_variables 表有这些索引：

主键（ VARIABLE_NAME ）

该 variables_by_thread 表包含以下列：

THREAD_ID

定义系统变量的会话的线程标识符。
VARIABLE_NAME

系统变量名称。
VARIABLE_VALUE

列所指定的会话的会话变量值 THREAD_ID 。

该 variables_by_thread 表包含以下索引：

主键（ THREAD_ID ， VARIABLE_NAME ）

该 variables_by_thread 表仅包含有关前台线程的系统变量信息。如果并非所有线程都由性能模式检测，则此表将遗漏一些行。在这种情况下， Performance_schema_thread_instances_lost 状态变量将大于零。

26.12.13.1性能模式persisted_variables表

该 persisted_variables 表提供了一个 mysqld-auto.cnf 存储全局系统变量设置的文件的SQL接口，允许在运行时使用 SELECT 语句检查文件内容。使用 SET PERSIST 或 PERSIST_ONLY 语句持久保存变量 ; 请参见第13.7.5.1节“变量赋值的SET语法” 。该表包含文件中每个持久系统变量的行。不持久的变量不会出现在表中。

有关持久系统变量的信息，请参见第13.7.5.1节“变量赋值的SET语法” 。

假设 mysqld-auto.cnf 看起来像这样（稍微重新格式化）：

{
  “版本”：1，
  “mysql_server”：{
    “max_connections”：{
      “价值”：“1000”，
      “元数据”：{
        “时间戳”：1.519921706e + 15，
        “用户”：“root”，
        “主持人”：“localhost”
      }
    }，
    “autocommit”：{
      “价值”：“开”，
      “元数据”：{
        “时间戳”：1.519921707e + 15，
        “用户”：“root”，
        “主持人”：“localhost”
      }
    }
  }
}

然后 persisted_variables 有这些内容：

MySQL的> SELECT * FROM performance_schema.persisted_variables;
+ ----------------- + ---------------- +
| VARIABLE_NAME | VARIABLE_VALUE |
+ ----------------- + ---------------- +
| 自动提交| ON |
| max_connections | 1000 |
+ ----------------- + ---------------- +

persisted_variables 有这些列：

VARIABLE_NAME

列出的变量名称 mysqld-auto.cnf 。
VARIABLE_VALUE

为变量列出的值 mysqld-auto.cnf 。

persisted_variables 有这些索引：

主键（ VARIABLE_NAME ）

TRUNCATE TABLE 不允许使用该 persisted_variables 表。

26.12.13.2性能模式variables_info表

该 variables_info 表显示了每个系统变量最近设置的源及其值范围。

variables_info 有这些列：

VARIABLE_NAME

变量名称。
VARIABLE_SOURCE

最近设置变量的源：
- COMMAND_LINE
  
  该变量在命令行中设置。
- COMPILED
  
  该变量具有其编译的默认值。 COMPILED 是用于不以任何其他方式设置的变量的值。
- DYNAMIC
  
  变量在运行时设置。这包括使用该 --init-file 选项指定的文件中设置的变量。
- EXPLICIT
  
  该变量是使用选项命名的选项文件设置的 --defaults-file 。
- EXTRA
  
  该变量是使用选项命名的选项文件设置的 --defaults-extra-file 。
- GLOBAL
  
  变量是从全局选项文件设置的。这包括未覆盖的文件选项 EXPLICIT ， EXTRA ， LOGIN ， PERSISTED ， SERVER ，或 USER 。
- LOGIN
  
  该变量是从用户特定的登录路径文件（ ~/.mylogin.cnf ）设置的。
- PERSISTED
  
  该变量是从特定于服务器的 mysqld-auto.cnf 选项文件中设置的。如果服务器以 persisted_globals_load 禁用方式启动，则没有行具有此值。
- SERVER
  
  该变量是从特定于服务器的 $MYSQL_HOME/my.cnf 选项文件中设置的。有关如何 MYSQL_HOME 设置的详细信息，请参见第4.2.2.2节“使用选项文件” 。
- USER
  
  该变量是由用户特定的 ~/.my.cnf 选项文件设置的。
VARIABLE_PATH

如果变量是从选项文件设置的， VARIABLE_PATH 则是该文件的路径名。否则，该值为空字符串。
MIN_VALUE ， MAX_VALUE

变量的最小和最大允许值。对于没有这些值的变量（即非数字变量），两者都为0。
SET_TIME

变量最近设置的时间。默认值是服务器在启动期间初始化全局系统变量的时间。
SET_USER ， SET_HOST

最近设置变量的客户端用户的用户名和主机名。如果客户端连接作为 user17 从主机 host34.example.com 使用的帐户 'user17'@'%.example.com ， SET_USER 并且 SET_HOST 将 user17 和 host34.example.com 分别。对于代理用户连接，这些值对应于外部（代理）用户，而不是对其执行权限检查的代理用户。每列的默认值为空字符串，表示自服务器启动以来尚未设置该变量。

该 variables_info 表包含以下索引：

没有

TRUNCATE TABLE 不允许使用该 variables_info 表。

如果具有一个可变 VARIABLE_SOURCE 比其它值 DYNAMIC 被设定在运行时， VARIABLE_SOURCE 成为 DYNAMIC 和 VARIABLE_PATH 成为空字符串。

只有会话值（例如 debug_sync ）的系统变量无法在启动时设置或保持不变。对于仅会话的系统变量， VARIABLE_SOURCE 可以只是 COMPILED 或 DYNAMIC 。

如果系统变量具有意外 VARIABLE_SOURCE 值，请考虑您的服务器启动方法。例如， mysqld_safe 读取选项文件并传递它在那里找到的某些选项，作为它用来启动 mysqld 的命令行的一部分。因此，您在选项文件中设置一些系统变量可能会显示 variables_info 为 COMMAND_LINE ，而不是作为 GLOBAL 或 SERVER 作为您预期。

一些使用该 variables_info 表的示例查询，具有代表性输出：

显示在命令行上设置的变量：

MySQL的> SELECT VARIABLE_NAME
       FROM performance_schema.variables_info
       WHERE VARIABLE_SOURCE = 'COMMAND_LINE'
       ORDER BY VARIABLE_NAME;
+ --------------- +
| VARIABLE_NAME |
+ --------------- +
| basedir |
| datadir |
| log_error |
| pid_file |
| plugin_dir |
| 港口|
+ --------------- +

显示从持久存储设置的变量：

MySQL的> SELECT VARIABLE_NAME
       FROM performance_schema.variables_info
       WHERE VARIABLE_SOURCE = 'PERSISTED'
       ORDER BY VARIABLE_NAME;
+ -------------------------- +
| VARIABLE_NAME |
+ -------------------------- +
| event_scheduler |
| max_connections |
| validate_password.policy |
+ -------------------------- +

加入 variables_info 与 global_variables 表与他们的值的范围，以显示持续变量的当前值，一起：

MySQL的> SELECT
         VI.VARIABLE_NAME, GV.VARIABLE_VALUE,
         VI.MIN_VALUE,VI.MAX_VALUE
       FROM performance_schema.variables_info AS VI
         INNER JOIN performance_schema.global_variables AS GV
         USING(VARIABLE_NAME)
       WHERE VI.VARIABLE_SOURCE = 'PERSISTED'
       ORDER BY VARIABLE_NAME;
+ -------------------------- + ---------------- + ----- ------ + ----------- +
| VARIABLE_NAME | VARIABLE_VALUE | MIN_VALUE | MAX_VALUE |
+ -------------------------- + ---------------- + ----- ------ + ----------- +
| event_scheduler | ON | 0 | 0 |
| max_connections | 200 | 1 | 100000 |
| validate_password.policy | 强| 0 | 0 |
+ -------------------------- + ---------------- + ----- ------ + ----------- +

26.12.14性能模式状态变量表

MySQL服务器维护许多状态变量，提供有关其操作的信息（请参见第5.1.10节“服务器状态变量” ）。这些性能模式表中提供了状态变量信息：

global_status ：全局状态变量。仅需要全局值的应用程序应使用此表。
session_status ：当前会话的状态变量。想要为其自己的会话使用所有状态变量值的应用程序应使用此表。它包括其会话的会话变量，以及没有会话对应的全局变量的值。
status_by_thread ：每个活动会话的会话状态变量。想要知道特定会话的会话变量值的应用程序应使用此表。它仅包含会话变量，由线程ID标识。

还有一些摘要表，提供按帐户，主机名和用户名聚合的状态变量信息。请参见第26.12.16.12节“状态变量汇总表” 。

会话变量表（ session_status ， status_by_thread ）仅包含活动会话的信息，而不包含已终止的会话。

性能架构收集全局的状态变量的统计数据只适合线程 INSTRUMENTED 值 YES 在 threads 表中。无论如何，始终会收集会话状态变量的统计信息 INSTRUMENTED 值。

性能模式不收集状态变量表中状态变量的统计信息。要获取全局和每会话语句执行计数，请使用和 Com_xxx events_statements_summary_global_by_event_name events_statements_summary_by_thread_by_event_name ，请分别表。例如：

SELECT EVENT_NAME，COUNT_STAR
FROM performance_schema.events_statements_summary_global_by_event_name
在哪里EVENT_NAME LIKE'statement / sql /％';

在 global_status 与 session_status 表有这些列：

VARIABLE_NAME

状态变量名称。
VARIABLE_VALUE

状态变量值。对于 global_status ，此列包含全局值。对于 session_status ，此列包含当前会话的变量值。

在 global_status 与 session_status 表有这些索引：

主键（ VARIABLE_NAME ）

该 status_by_thread 表包含每个活动线程的状态。它有以下列：

THREAD_ID

定义状态变量的会话的线程标识符。
VARIABLE_NAME

状态变量名称。
VARIABLE_VALUE

列所指定的会话的会话变量值 THREAD_ID 。

该 status_by_thread 表包含以下索引：

主键（ THREAD_ID ， VARIABLE_NAME ）

该 status_by_thread 表仅包含有关前台线程的状态变量信息。如果 performance_schema_max_thread_instances 系统变量未自动调整（由值-1表示）并且允许的最大检测线程对象数不大于后台线程数，则该表将为空。

性能模式支持 TRUNCATE TABLE 状态变量表，如下所示：

global_status ：重置线程，帐户，主机和用户状态。重置全局状态变量，但服务器永不重置的变量除外。
session_status ：不支持。
status_by_thread ：将所有线程的状态聚合到全局状态和帐户状态，然后重置线程状态。如果未收集帐户统计信息，则会在收集主机和用户状态时将会话状态添加到主机和用户状态。

如果帐户，主机和用户的统计数据没有收集 performance_schema_accounts_size ， performance_schema_hosts_size 和 performance_schema_users_size 系统变量，分别被设置为0。

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

26.12.15性能架构线程池表

26.12.15.1 tp_thread_group_state表
26.12.15.2 tp_thread_group_stats表
26.12.15.3 tp_thread_state表

注意

此处描述的性能模式表从MySQL 8.0.14开始提供。在MySQL 8.0.14之前，请使用相应的 INFORMATION_SCHEMA 表; 请参见第25.40节“INFORMATION_SCHEMA线程池表” 。

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

tp_thread_group_state ：有关线程池线程组状态的信息
tp_thread_group_stats ：线程组统计信息
tp_thread_state ：有关线程池线程状态的信息

这些表中的行代表快照及时。在这种情况下 tp_thread_state ，线程组的所有行都包含时间快照。因此，MySQL服务器在生成快照时保留线程组的互斥锁。但是它并没有同时在所有线程组上保存互斥锁，以防止语句 tp_thread_state 阻止整个MySQL服务器。

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

26.12.15.1 tp_thread_group_state表

注意

此处描述的性能架构表自MySQL 8.0.14起可用。在MySQL 8.0.14之前，请使用相应的 INFORMATION_SCHEMA 表; 请参见第25.40.1节“INFORMATION_SCHEMA TP_THREAD_GROUP_STATE表” 。

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

该 tp_thread_group_state 表包含以下列：

TP_GROUP_ID

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

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

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

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

使用此线程组的连接数。
QUEUED_QUERIES

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

在低优先级队列中等待的语句数。这些是尚未启动的事务的初始语句，因此它们也表示排队的事务。
STALL_LIMIT

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

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

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

线程池中作为此线程组的一部分启动的线程数。
ACTIVE_THREAD_COUNT

执行语句时活动的线程数。
STALLED_THREAD_COUNT

线程组中停滞的语句数。一个停滞的语句可能正在执行，但从线程池的角度来看，它已停滞不前并且没有任何进展。长期运行的声明很快就会出现在这一类别中。
WAITING_THREAD_NUMBER

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

最旧的排队语句等待执行的时间长度（以毫秒为单位）。
MAX_THREAD_IDS_IN_GROUP

组中线程的最大线程ID。这与 MAX(TP_THREAD_NUMBER) 从 tp_thread_state 表中选择时的线程相同。也就是说，这两个查询是等价的：
```
SELECT TP_GROUP_ID，MAX_THREAD_IDS_IN_GROUP
FROM tp_thread_group_state;

SELECT TP_GROUP_ID，MAX（TP_THREAD_NUMBER）
FROM tp_thread_state GROUP BY TP_GROUP_ID;
```

该 tp_thread_group_state 表包含以下索引：

（ TP_GROUP_ID ）上的唯一索引

TRUNCATE TABLE 不允许使用该 tp_thread_group_state 表。

26.12.15.2 tp_thread_group_stats表

注意

此处描述的性能架构表自MySQL 8.0.14起可用。在MySQL 8.0.14之前，请使用相应的 INFORMATION_SCHEMA 表; 请参见第25.40.2节“INFORMATION_SCHEMA TP_THREAD_GROUP_STATS表” 。

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

该 tp_thread_group_stats 表包含以下列：

TP_GROUP_ID

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

连接数已启动。
CONNECTIONS_CLOSED

连接数已关闭。
QUERIES_EXECUTED

执行的语句数。当语句开始执行时，此数字会递增，而不是在语句结束时递增。
QUERIES_QUEUED

收到的已排队等待执行的语句数。这不计算线程组在没有排队的情况下能够立即开始执行的语句，这可以在第5.6.3.3节“线程池操作”中描述的条件下发生。
THREADS_STARTED

线程数已启动。
PRIO_KICKUPS

根据 thread_pool_prio_kickup_timer 系统变量的值从低优先级队列移动到高优先级队列的语句数。如果此数字快速增加，请考虑增加该变量的值。快速增加的计数器意味着优先级系统不会使交易过早开始。因为 InnoDB ，这很可能意味着由于并发事务太多而导致性能下降。
STALLED_QUERIES_EXECUTED

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

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

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

已为线程分配服务器线程角色的次数。当语句排队时，即使在正常操作中也经常发生这种情况，因此在高负载系统（其中语句排队）的情况下，此值的快速增加是正常的。
WAKE_THREAD_STALL_CHECKER

失速检查线程决定唤醒或创建线程以处理某些语句或处理服务员线程角色的次数。
SLEEP_WAITS

THD_WAIT_SLEEP 等待的数量。这些在线程进入休眠状态时发生（例如，通过调用该 SLEEP() 函数）。
DISK_IO_WAITS

THD_WAIT_DISKIO 等待的数量。当线程执行可能未命中文件系统缓存的磁盘I / O时，会发生这些情况。当缓冲池读取和写入数据到磁盘时，不会发生正常的读取和写入文件，从而发生此类等待。
ROW_LOCK_WAITS

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

THD_WAIT_GLOBAL_LOCK 要释放全局锁的等待数。
META_DATA_LOCK_WAITS

THD_WAIT_META_DATA_LOCK 要释放元数据锁的等待数。
TABLE_LOCK_WAITS

THD_WAIT_TABLE_LOCK 语句需要访问的表的等待数量。
USER_LOCK_WAITS

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

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

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

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

该 tp_thread_group_stats 表包含以下索引：

（ TP_GROUP_ID ）上的唯一索引

TRUNCATE TABLE 不允许使用该 tp_thread_group_stats 表。

26.12.15.3 tp_thread_state表

注意

此处描述的性能架构表自MySQL 8.0.14起可用。在MySQL 8.0.14之前，请使用相应的 INFORMATION_SCHEMA 表; 请参见第25.40.3节“INFORMATION_SCHEMA TP_THREAD_STATE表” 。

该 tp_thread_state 表在线程池创建的每个线程中有一行来处理连接。

该 tp_thread_state 表包含以下列：

TP_GROUP_ID

线程组ID。
TP_THREAD_NUMBER

其线程组中线程的ID。 TP_GROUP_ID 并 TP_THREAD_NUMBER 一起提供表中的唯一键。
PROCESS_COUNT

使用此线程的语句当前正在执行的10ms间隔。 0表示没有语句正在执行，1表示它在前10毫秒，依此类推。

WAIT_TYPE

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

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

表26.3 tp_thread_state表WAIT_TYPE值

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

该 tp_thread_state 表包含以下索引：

（ TP_GROUP_ID ， TP_THREAD_NUMBER ）上的唯一索引

TRUNCATE TABLE 不允许使用该 tp_thread_state 表。

26.12.16性能模式摘要表

26.12.16.1等待事件汇总表
26.12.16.2阶段汇总表
26.12.16.3语句汇总表
26.12.16.4声明直方图汇总表
26.12.16.5事务汇总表
26.12.16.6对象等待汇总表
26.12.16.7文件I / O摘要表
26.12.16.8表I / O和锁定等待汇总表
26.12.16.9套接字汇总表
26.12.16.10内存摘要表
26.12.16.11错误汇总表
26.12.16.12状态变量摘要表

摘要表提供终止事件的聚合信息。该组中的表以不同方式汇总事件数据。

等待事件摘要

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 ：每个事件名称等待事件

舞台总结

events_stages_summary_by_account_by_event_name ：每个帐户和事件名称的舞台事件
events_stages_summary_by_host_by_event_name ：每个主机名和事件名称的舞台事件
events_stages_summary_by_thread_by_event_name ：Stage等待每个线程和事件名称
events_stages_summary_by_user_by_event_name ：每个用户名和事件名称的舞台事件
events_stages_summary_global_by_event_name ：Stage等待每个事件名称

声明摘要

events_statements_histogram_by_digest ：每个架构和摘要值的语句直方图。
events_statements_histogram_global ：全局汇总语句直方图。
events_statements_summary_by_account_by_event_name ：每个帐户和事件名称的语句事件
events_statements_summary_by_digest ：每个架构和摘要值的语句事件
events_statements_summary_by_host_by_event_name ：每个主机名和事件名称的语句事件
events_statements_summary_by_program ：每个存储程序的语句事件（存储过程和函数，触发器和事件）
events_statements_summary_by_thread_by_event_name ：每个线程和事件名称的语句事件
events_statements_summary_by_user_by_event_name ：每个用户名和事件名称的语句事件
events_statements_summary_global_by_event_name ：每个事件名称的语句事件
prepared_statements_instances ：准备好的语句实例和统计信息

交易摘要

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 ：每个事件名称的事务事件

对象等待摘要

objects_summary_global_by_type ：对象摘要

文件I / O摘要

file_summary_by_event_name ：每个事件名称的文件事件
file_summary_by_instance ：每个文件实例的文件事件

表I / O和锁定等待摘要

table_io_waits_summary_by_index_usage ：表I / O等待每个索引
table_io_waits_summary_by_table ：表I / O等待每个表
table_lock_waits_summary_by_table ：表锁等待每个表

套接字摘要

socket_summary_by_instance ：Socket等待每个实例的I / O.
socket_summary_by_event_name ：每个事件名称的套接字等待和I / O.

记忆摘要

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 ：每个事件名称的全局内存操作

错误摘要

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 ：每个错误代码的错误

状态变量摘要

status_by_account ：每个帐户的状态变量
status_by_host ：每个主机名的状态变量
status_by_user ：每个用户名的状态变量

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

26.12.16.1等待事件汇总表

性能模式维护用于收集当前和最近等待事件的表，并在汇总表中聚合该信息。第26.12.4节“性能架构等待事件表” 描述了等待摘要所基于的事件。有关等待事件内容，当前和最近等待事件表以及如何控制等待事件收集的信息，请参阅该讨论，默认情况下禁用此事件。

示例等待事件摘要信息：

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

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

events_waits_summary_by_account_by_event_name 有 EVENT_NAME ， USER 和 HOST 列。每行汇总给定帐户（用户和主机组合）和事件名称的事件。
events_waits_summary_by_host_by_event_name 有 EVENT_NAME 和 HOST 列。每行汇总给定主机和事件名称的事件。
events_waits_summary_by_instance 有 EVENT_NAME 和 OBJECT_INSTANCE_BEGIN 列。每行汇总给定事件名称和对象的事件。如果使用工具创建多个实例，则每个实例都具有唯一 OBJECT_INSTANCE_BEGIN 值，并在此表中单独汇总。
events_waits_summary_by_thread_by_event_name 有 THREAD_ID 和 EVENT_NAME 列。每行汇总给定线程和事件名称的事件。
events_waits_summary_by_user_by_event_name 有 EVENT_NAME 和 USER 列。每行汇总给定用户和事件名称的事件。
events_waits_summary_global_by_event_name 有一个 EVENT_NAME 专栏。每行汇总给定事件名称的事件。可以使用仪器来创建检测对象的多个实例。例如，如果为每个连接创建了一个用于互斥锁的工具，则存在与连接一样多的实例。仪器的摘要行汇总了所有这些实例。

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

COUNT_STAR

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

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

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

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

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

等待事件摘要表具有以下索引：

events_waits_summary_by_account_by_event_name ：
- 在主键（ USER ， HOST ， EVENT_NAME ）
events_waits_summary_by_host_by_event_name ：
- 主键（ HOST ， EVENT_NAME ）
events_waits_summary_by_instance ：
- 主键（ OBJECT_INSTANCE_BEGIN ）
- 索引（ EVENT_NAME ）
events_waits_summary_by_thread_by_event_name ：
- 主键（ THREAD_ID ， EVENT_NAME ）
events_waits_summary_by_user_by_event_name ：
- 主键（ USER ， EVENT_NAME ）
events_waits_summary_global_by_event_name ：
- 主键（ EVENT_NAME ）

TRUNCATE TABLE 允许等待汇总表。它有这些影响：

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

此外，由帐户，主机，用户或线程聚合的每个等待摘要表都会通过截断它所依赖的连接表或截断来隐式截断 events_waits_summary_global_by_event_name 。有关详细信息，请参见第26.12.8节“性能模式连接表” 。

26.12.16.2阶段汇总表

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

示例阶段事件摘要信息：

MySQL的> SELECT *
       FROM performance_schema.events_stages_summary_global_by_event_name\G
...
****************************排******************** *******
    EVENT_NAME：stage / sql / checking权限
    COUNT_STAR：57
SUM_TIMER_WAIT：26501888880
MIN_TIMER_WAIT：7317456
AVG_TIMER_WAIT：464945295
MAX_TIMER_WAIT：12858936792
...
*************************** 9。排******************** *******
    EVENT_NAME：stage / sql / closing表
    COUNT_STAR：37
SUM_TIMER_WAIT：662606568
MIN_TIMER_WAIT：1593864
AVG_TIMER_WAIT：17907891
MAX_TIMER_WAIT：437977248
...

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

events_stages_summary_by_account_by_event_name 有 EVENT_NAME ， USER 和 HOST 列。每行汇总给定帐户（用户和主机组合）和事件名称的事件。
events_stages_summary_by_host_by_event_name 有 EVENT_NAME 和 HOST 列。每行汇总给定主机和事件名称的事件。
events_stages_summary_by_thread_by_event_name 有 THREAD_ID 和 EVENT_NAME 列。每行汇总给定线程和事件名称的事件。
events_stages_summary_by_user_by_event_name 有 EVENT_NAME 和 USER 列。每行汇总给定用户和事件名称的事件。
events_stages_summary_global_by_event_name 有一个 EVENT_NAME 专栏。每行汇总给定事件名称的事件。

每个阶段汇总表具有包含聚合值这些摘要列： COUNT_STAR ， SUM_TIMER_WAIT ， MIN_TIMER_WAIT ， AVG_TIMER_WAIT ，和 MAX_TIMER_WAIT 。这些列类似于等待事件摘要表中相同名称的列（请参见第26.12.16.1节“等待事件摘要表” ），除了阶段摘要表聚合事件 events_stages_current 而不是 events_waits_current 。

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

events_stages_summary_by_account_by_event_name ：
- 主键上（ USER ， HOST ， EVENT_NAME ）
events_stages_summary_by_host_by_event_name ：
- 主键上（ HOST ， EVENT_NAME ）
events_stages_summary_by_thread_by_event_name ：
- 主键（ THREAD_ID ， EVENT_NAME ）
events_stages_summary_by_user_by_event_name ：
- 主键（ USER ， EVENT_NAME ）
events_stages_summary_global_by_event_name ：
- 主键（ EVENT_NAME ）

TRUNCATE TABLE 允许用于阶段汇总表。它有这些影响：

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

此外，由帐户，主机，用户或线程聚合的每个阶段摘要表都会通过截断它所依赖的连接表或截断来隐式截断 events_stages_summary_global_by_event_name 。有关详细信息，请参见第26.12.8节“性能模式连接表” 。

26.12.16.3语句汇总表

性能模式维护用于收集当前和最近语句事件的表，并在汇总表中聚合该信息。第26.12.6节“性能模式语句事件表” 描述了语句摘要所基于的事件。请参阅该讨论，以获取有关语句事件内容，当前和历史语句事件表以及如何控制语句事件集合的信息，默认情况下已部分禁用。

示例语句事件摘要信息：

MySQL的> SELECT *
       FROM performance_schema.events_statements_summary_global_by_event_name\G
*************************** 1。排******************** *******
                 EVENT_NAME：statement / sql / select
                 COUNT_STAR：25
             SUM_TIMER_WAIT：1535983999000
             MIN_TIMER_WAIT：209823000
             AVG_TIMER_WAIT：61439359000
             MAX_TIMER_WAIT：1363397650000
              SUM_LOCK_TIME：20186000000
                 SUM_ERRORS：0
               SUM_WARNINGS：0
          SUM_ROWS_AFFECTED：0
              SUM_ROWS_SENT：388
          SUM_ROWS_EXAMINED：370
SUM_CREATED_TMP_DISK_TABLES：0
     SUM_CREATED_TMP_TABLES：0
       SUM_SELECT_FULL_JOIN：0
 SUM_SELECT_FULL_RANGE_JOIN：0
           SUM_SELECT_RANGE：0
     SUM_SELECT_RANGE_CHECK：0
            SUM_SELECT_SCAN：6
      SUM_SORT_MERGE_PASSES：0
             SUM_SORT_RANGE：0
              SUM_SORT_ROWS：0
              SUM_SORT_SCAN：0
          SUM_NO_INDEX_USED：6
     SUM_NO_GOOD_INDEX_USED：0
...

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

events_statements_summary_by_account_by_event_name 有 EVENT_NAME ， USER 和 HOST 列。每行汇总给定帐户（用户和主机组合）和事件名称的事件。
events_statements_summary_by_digest 有 SCHEMA_NAME 和 DIGEST 列。每行汇总每个架构和摘要值的事件。（该 DIGEST_TEXT 列包含相应的归语句消化文本，但既不是分组也不是总结列中的。 QUERY_SAMPLE_TEXT ， QUERY_SAMPLE_SEEN 和 QUERY_SAMPLE_TIMER_WAIT 列也既不分组或简要的列;它们支持声明采样。）

表中的最大行数在服务器启动时自动调整。要显式设置此最大值，请 performance_schema_digests_size 在服务器启动时设置系统变量。
events_statements_summary_by_host_by_event_name 有 EVENT_NAME 和 HOST 列。每行汇总给定主机和事件名称的事件。
events_statements_summary_by_program 有 OBJECT_TYPE ， OBJECT_SCHEMA 和 OBJECT_NAME 列。每行汇总给定存储程序的事件（存储过程或函数，触发器或事件）。
events_statements_summary_by_thread_by_event_name 有 THREAD_ID 和 EVENT_NAME 列。每行汇总给定线程和事件名称的事件。
events_statements_summary_by_user_by_event_name 有 EVENT_NAME 和 USER 列。每行汇总给定用户和事件名称的事件。
events_statements_summary_global_by_event_name 有一个 EVENT_NAME 专栏。每行汇总给定事件名称的事件。
prepared_statements_instances 有一个 OBJECT_INSTANCE_BEGIN 专栏。每行汇总给定预准备语句的事件。

每个语句摘要表都包含这些汇总列，其中包含聚合值（如上所述，除外）：

COUNT_STAR ， SUM_TIMER_WAIT ， MIN_TIMER_WAIT ， AVG_TIMER_WAIT ， MAX_TIMER_WAIT

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

该 prepared_statements_instances 表没有这些列。
SUM_xxx

表中相应 xxx 列的聚合 events_statements_current 。例如， SUM_LOCK_TIME 并且 SUM_ERRORS 在声明汇总表列的骨料 LOCK_TIME 和 ERRORS 列 events_statements_current 表。

该 events_statements_summary_by_digest 表包含以下附加摘要列：

FIRST_SEEN ， LAST_SEEN

时间戳指示何时首次显示具有给定摘要值的语句以及最近看到的语句。
QUANTILE_95 ：语句延迟的第95个百分位，以皮秒为单位。该百分位数是根据收集的直方图数据计算的高估计值。换句话说，对于给定的摘要，95％的测量语句的延迟低于 QUANTILE_95 。

要访问直方图数据，请使用第26.12.16.4节“语句直方图汇总表”中所述的表。
QUANTILE_99 ：类似于 QUANTILE_95 ，但是对于第99百分位数。
QUANTILE_999 ：类似于 QUANTILE_95 ，但是对于第99.9百分位数。

该 events_statements_summary_by_digest 表包含以下列。这些既不是分组列也不是汇总列; 他们支持声明抽样：

QUERY_SAMPLE_TEXT

一个示例SQL语句，用于在行中生成摘要值。对于给定的摘要值，此列允许应用程序访问生成该摘要的服务器实际看到的语句。这样做的一个用途可能是 EXPLAIN 在语句上运行以检查与频繁出现的摘要相关联的代表性语句的执行计划。

为 QUERY_SAMPLE_TEXT 列分配值时，也会为 QUERY_SAMPLE_SEEN 和 QUERY_SAMPLE_TIMER_WAIT 列分配值。

默认情况下，语句显示的最大可用空间为1024字节。要更改此值，请 performance_schema_max_sql_text_length 在服务器启动时设置系统变量。（更改此值也会影响其他Performance Schema表中的列。请参见第26.10节“性能架构语句摘要和采样” 。）

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

一个时间戳，指示何时 QUERY_SAMPLE_TEXT 看到列中的语句。
QUERY_SAMPLE_TIMER_WAIT

QUERY_SAMPLE_TEXT 列中示例语句的等待时间。

该 events_statements_summary_by_program 表包含以下附加摘要列：

COUNT_STATEMENTS ， SUM_STATEMENTS_WAIT ， MIN_STATEMENTS_WAIT ， AVG_STATEMENTS_WAIT ， MAX_STATEMENTS_WAIT

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

该 prepared_statements_instances 表包含以下附加摘要列：

COUNT_EXECUTE ， SUM_TIMER_EXECUTE ， MIN_TIMER_EXECUTE ， AVG_TIMER_EXECUTE ， MAX_TIMER_EXECUTE

执行准备好的声明的汇总统计数据。

语句摘要表包含以下索引：

events_transactions_summary_by_account_by_event_name ：
- 在主键（ USER ， HOST ， EVENT_NAME ）
events_statements_summary_by_digest ：
- 主键（ SCHEMA_NAME ， DIGEST ）
events_transactions_summary_by_host_by_event_name ：
- 主键（ HOST ， EVENT_NAME ）
events_statements_summary_by_program ：
- 在主键（ OBJECT_TYPE ， OBJECT_SCHEMA ， OBJECT_NAME ）
events_statements_summary_by_thread_by_event_name ：
- 主键（ THREAD_ID ， EVENT_NAME ）
events_transactions_summary_by_user_by_event_name ：
- 主键（ USER ， EVENT_NAME ）
events_statements_summary_global_by_event_name ：
- 主键（ EVENT_NAME ）

TRUNCATE TABLE 允许用于语句摘要表。它有这些影响：

对于 events_statements_summary_by_digest ，它删除行。
对于未按帐户，主机或用户聚合的其他汇总表，截断会将汇总列重置为零，而不是删除行。
对于按帐户，主机或用户聚合的其他汇总表，截断将删除没有连接的帐户，主机或用户的行，并将剩余行的汇总列重置为零。

此外，由帐户，主机，用户或线程聚合的每个语句摘要表都会通过截断它所依赖的连接表或截断来隐式截断 events_statements_summary_global_by_event_name 。有关详细信息，请参见第26.12.8节“性能模式连接表” 。

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

声明摘要聚合规则

如果 statements_digest 启用了使用者，则 events_statements_summary_by_digest 在语句完成时，将按以下方式进行聚合。聚合基于 DIGEST 为语句计算的值。

如果 events_statements_summary_by_digest 已存在的行包含刚刚完成的语句的摘要值，则该语句的统计信息将聚合到该行。该 LAST_SEEN 列已更新为当前时间。
如果没有行具有刚刚完成的语句的摘要值，并且表未满，则为该语句创建新行。该 FIRST_SEEN 和 LAST_SEEN 列初始化为当前时间。
如果没有行具有刚刚完成的语句的语句摘要值，并且表已满，则刚刚完成的语句的统计信息将添加到带有 = 的特殊 “ catch-all ” 行，如果需要，将创建该行。如果创建了行，则使用当前时间初始化和列。否则，使用当前时间更新列。 DIGEST NULL FIRST_SEEN LAST_SEEN LAST_SEEN

保留 DIGEST = 的行 NULL 是因为性能模式表由于内存限制而具有最大大小。该 DIGEST = NULL 行允许不匹配的其他行进行计数，即使汇总表已满，采用通用摘要 “ 其他 ” 斗。此行可帮助您估计摘要摘要是否具有代表性：

A DIGEST = NULL 具有 COUNT_STAR 代表所有摘要的5％的值的行表明摘要摘要表非常具有代表性; 其他行覆盖了95％的陈述。
A DIGEST = NULL 具有 COUNT_STAR 代表所有摘要的50％的值的行表明摘要摘要表不是很有代表性; 其他行只覆盖了所见的一半。最有可能的是，DBA应该增加最大表大小，以便使用更具体的行来计算 DIGEST = NULL 行中计数的更多行。为此，请 performance_schema_digests_size 在服务器启动时将系统变量设置为更大的值。默认大小为200。

存储程序仪表行为

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

在服务器中首次使用对象时，会为该对象添加一行。
删除对象时将删除对象的行。
统计信息在执行时聚合在对象的行中。

另请参见第26.4.3节“事件预过滤” 。

26.12.16.4声明直方图汇总表

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

第26.12.6节“性能模式语句事件表” 描述了语句摘要所基于的事件。请参阅该讨论，以获取有关语句事件内容，当前和历史语句事件表以及如何控制语句事件集合的信息，默认情况下已部分禁用。

示例语句直方图信息：

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

例如，在第3行中，这些值表示23.52％的查询在75.86微秒内运行：

BUCKET_TIMER_HIGH：75857757
  BUCKET_QUANTILE：0.235294

在第4行中，这些值表示62.50％的查询在79.44微秒内运行：

BUCKET_TIMER_HIGH：79432823
  BUCKET_QUANTILE：0.625000

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

events_statements_histogram_by_digest 有 SCHEMA_NAME ， DIGEST 和 BUCKET_NUMBER 列：
- 在 SCHEMA_NAME 与 DIGEST 列标识声明消化行的 events_statements_summary_by_digest 表。
- events_statements_histogram_by_digest 具有相同 SCHEMA_NAME 和 DIGEST 值的行包括该模式/摘要组合的直方图。
- 在给定的直方图中，该 BUCKET_NUMBER 列表示桶号。
events_statements_histogram_global 有一个 BUCKET_NUMBER 专栏。此表使用单个直方图总结了模式名称和摘要值之间的全局延迟。该 BUCKET_NUMBER 列指示此全局直方图中的存储桶编号。

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

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

BUCKET_TIMER_LOW ， BUCKET_TIMER_HIGH

存储桶计算具有延迟的语句，以皮秒为单位，在 BUCKET_TIMER_LOW 和之间测量 BUCKET_TIMER_HIGH ：
- 第 BUCKET_TIMER_LOW 一个桶（ BUCKET_NUMBER = 0）的值为0。
- BUCKET_TIMER_LOW bucket（ BUCKET_NUMBER = k ）的值 BUCKET_TIMER_HIGH 与前一个bucket（ BUCKET_NUMBER = k -1）的值相同
- 最后一个桶是对于直方图中具有超过先前桶的延迟的语句的捕获。
COUNT_BUCKET

从 BUCKET_TIMER_LOW 最多但不包括的间隔中以延迟测量的语句数 BUCKET_TIMER_HIGH 。
COUNT_BUCKET_AND_LOWER

在从0到但不包括的间隔内以延迟测量的语句数 BUCKET_TIMER_HIGH 。
BUCKET_QUANTILE

落入此桶或较低桶的语句比例。该比例根据定义对应 COUNT_BUCKET_AND_LOWER / SUM(COUNT_BUCKET) 并显示为便利栏。

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

events_statements_histogram_by_digest ：
- 对唯一索引（ SCHEMA_NAME ， DIGEST ， BUCKET_NUMBER ）
events_statements_histogram_global ：
- 主键（ BUCKET_NUMBER ）

TRUNCATE TABLE 允许用于语句直方图汇总表。截断将 COUNT_BUCKET 和 COUNT_BUCKET_AND_LOWER 列设置为0。

26.12.16.5事务汇总表

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

示例事务事件摘要信息：

MySQL的> SELECT *
       FROM performance_schema.events_transactions_summary_global_by_event_name
       LIMIT 1\G
*************************** 1。排******************** *******
          EVENT_NAME：交易
          COUNT_STAR：5
      SUM_TIMER_WAIT：19550092000
      MIN_TIMER_WAIT：2954148000
      AVG_TIMER_WAIT：3910018000
      MAX_TIMER_WAIT：5486275000
    COUNT_READ_WRITE：5
SUM_TIMER_READ_WRITE：19550092000
MIN_TIMER_READ_WRITE：2954148000
AVG_TIMER_READ_WRITE：3910018000
MAX_TIMER_READ_WRITE：5486275000
     COUNT_READ_ONLY：0
 SUM_TIMER_READ_ONLY：0
 MIN_TIMER_READ_ONLY：0
 AVG_TIMER_READ_ONLY：0
 MAX_TIMER_READ_ONLY：0

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

events_transactions_summary_by_account_by_event_name 有 USER ， HOST 和 EVENT_NAME 列。每行汇总给定帐户（用户和主机组合）和事件名称的事件。
events_transactions_summary_by_host_by_event_name 有 HOST 和 EVENT_NAME 列。每行汇总给定主机和事件名称的事件。
events_transactions_summary_by_thread_by_event_name 有 THREAD_ID 和 EVENT_NAME 列。每行汇总给定线程和事件名称的事件。
events_transactions_summary_by_user_by_event_name 有 USER 和 EVENT_NAME 列。每行汇总给定用户和事件名称的事件。
events_transactions_summary_global_by_event_name 有一个 EVENT_NAME 专栏。每行汇总给定事件名称的事件。

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

COUNT_STAR ， SUM_TIMER_WAIT ， MIN_TIMER_WAIT ， AVG_TIMER_WAIT ， MAX_TIMER_WAIT

这些列类似于等待事件摘要表中相同名称的列（请参见第26.12.16.1节“等待事件摘要表” ），但事务摘要表汇总了事件 events_transactions_current 而不是 events_waits_current 。这些列总结了读写和只读事务。
COUNT_READ_WRITE ， SUM_TIMER_READ_WRITE ， MIN_TIMER_READ_WRITE ， AVG_TIMER_READ_WRITE ， MAX_TIMER_READ_WRITE

它们与 COUNT_STAR 和 xxx_TIMER_WAIT 列类似，但仅汇总了读写事务。事务访问模式指定事务是以读/写还是以只读模式运行。
COUNT_READ_ONLY ， SUM_TIMER_READ_ONLY ， MIN_TIMER_READ_ONLY ， AVG_TIMER_READ_ONLY ， MAX_TIMER_READ_ONLY

它们与 COUNT_STAR 和 xxx_TIMER_WAIT 列类似，但仅汇总只读事务。事务访问模式指定事务是以读/写还是以只读模式运行。

事务摘要表具有以下索引：

events_transactions_summary_by_account_by_event_name ：
- 在主键（ USER ， HOST ， EVENT_NAME ）
events_transactions_summary_by_host_by_event_name ：
- 主键（ HOST ， EVENT_NAME ）
events_transactions_summary_by_thread_by_event_name ：
- 主键（ THREAD_ID ， EVENT_NAME ）
events_transactions_summary_by_user_by_event_name ：
- 主键（ USER ， EVENT_NAME ）
events_transactions_summary_global_by_event_name ：
- 主键（ EVENT_NAME ）

TRUNCATE TABLE 允许用于事务汇总表。它有这些影响：

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

此外，由帐户，主机，用户或线程聚合的每个事务摘要表都会通过截断它所依赖的连接表或截断来隐式截断 events_transactions_summary_global_by_event_name 。有关详细信息，请参见第26.12.8节“性能模式连接表” 。

交易聚合规则

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

对服务器启动的所有未中止事务（包括空事务）进行事务事件收集。

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

资源需求也可能随事务隔离级别而变化。但是，假设每个服务器只使用一个隔离级别，则不提供按隔离级别进行聚合。

26.12.16.6对象等待汇总表

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

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

MySQL的> SELECT * FROM performance_schema.objects_summary_global_by_type\G
...
*************************** 3。排******************** *******
   OBJECT_TYPE：TABLE
 OBJECT_SCHEMA：测试
   OBJECT_NAME：t
    COUNT_STAR：3
SUM_TIMER_WAIT：263126976
MIN_TIMER_WAIT：1522272
AVG_TIMER_WAIT：87708678
MAX_TIMER_WAIT：258428280
...
*************************** 10.排******************** *******
   OBJECT_TYPE：TABLE
 OBJECT_SCHEMA：mysql
   OBJECT_NAME：用户
    COUNT_STAR：14
SUM_TIMER_WAIT：365567592
MIN_TIMER_WAIT：1141704
AVG_TIMER_WAIT：26111769
MAX_TIMER_WAIT：334783032
...

该 objects_summary_global_by_type 表有这些分组列示意表如何聚集事件： OBJECT_TYPE ， OBJECT_SCHEMA ，和 OBJECT_NAME 。每行汇总给定对象的事件。

objects_summary_global_by_type 具有与表相同的汇总列。请参见第26.12.16.1节“等待事件汇总表” 。 events_waits_summary_by_xxx

该 objects_summary_global_by_type 表包含以下索引：

在主键（ OBJECT_TYPE ， OBJECT_SCHEMA ， OBJECT_NAME ）

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

26.12.16.7文件I / O摘要表

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

示例文件I / O事件摘要信息：

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

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

file_summary_by_event_name 有一个 EVENT_NAME 专栏。每行汇总给定事件名称的事件。
file_summary_by_instance 有 FILE_NAME ， EVENT_NAME 和 OBJECT_INSTANCE_BEGIN 列。每行汇总给定文件和事件名称的事件。

每个文件I / O摘要表都包含以下包含聚合值的摘要列。某些列更通用，其值与更细粒度列的值的总和相同。通过这种方式，可以直接获得更高级别的聚合，而无需对低级列进行求和的用户定义视图。

COUNT_STAR ， SUM_TIMER_WAIT ， MIN_TIMER_WAIT ， AVG_TIMER_WAIT ， MAX_TIMER_WAIT

这些列聚合所有I / O操作。
COUNT_READ ， SUM_TIMER_READ ， MIN_TIMER_READ ， AVG_TIMER_READ ， MAX_TIMER_READ ， SUM_NUMBER_OF_BYTES_READ

这些列聚集所有的读操作，其中包括 FGETS ， FGETC ， FREAD ，和 READ 。
COUNT_WRITE ， SUM_TIMER_WRITE ， MIN_TIMER_WRITE ， AVG_TIMER_WRITE ， MAX_TIMER_WRITE ， SUM_NUMBER_OF_BYTES_WRITE

这些列聚集所有的写操作，其中包括 FPUTS ， FPUTC ， FPRINTF ， VFPRINTF ， FWRITE ，和 PWRITE 。
COUNT_MISC ， SUM_TIMER_MISC ， MIN_TIMER_MISC ， AVG_TIMER_MISC ， MAX_TIMER_MISC

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

文件I / O摘要表具有以下索引：

file_summary_by_event_name ：
- 主键（ EVENT_NAME ）
file_summary_by_instance ：
- 主键（ OBJECT_INSTANCE_BEGIN ）
- 索引（ FILE_NAME ）
- 索引（ EVENT_NAME ）

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

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

26.12.16.8表I / O和锁定等待汇总表

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

table_io_waits_summary_by_index_usage ：表I / O等待每个索引
table_io_waits_summary_by_table ：表I / O等待每个表
table_lock_waits_summary_by_table ：表锁等待每个表

26.12.16.8.1 table_io_waits_summary_by_table表

该 table_io_waits_summary_by_table 表汇总了 wait/io/table/sql/handler 仪器生成的所有表I / O等待事件。分组是按表格进行的。

该 table_io_waits_summary_by_table 表有这些分组列示意表如何聚集事件： OBJECT_TYPE ， OBJECT_SCHEMA ，和 OBJECT_NAME 。这些列与 events_waits_current 表中的含义相同。它们标识行适用的表。

table_io_waits_summary_by_table 具有包含聚合值的以下摘要列。如列描述中所示，某些列更通用，其值与更细粒度列的值的总和相同。例如，聚合所有写入的列包含聚合插入，更新和删除的相应列的总和。通过这种方式，可以直接获得更高级别的聚合，而无需对低级列进行求和的用户定义视图。

COUNT_STAR ， SUM_TIMER_WAIT ， MIN_TIMER_WAIT ， AVG_TIMER_WAIT ， MAX_TIMER_WAIT

这些列聚合所有I / O操作。它们与相应列 xxx_READ 和 xxx_WRITE 列的总和相同。
COUNT_READ ， SUM_TIMER_READ ， MIN_TIMER_READ ， AVG_TIMER_READ ， MAX_TIMER_READ

这些列聚合所有读取操作。它们与相应 xxx_FETCH 列的总和相同。
COUNT_WRITE ， SUM_TIMER_WRITE ， MIN_TIMER_WRITE ， AVG_TIMER_WRITE ， MAX_TIMER_WRITE

这些列聚合所有写操作。他们是一样的相应的总和 xxx_INSERT ， xxx_UPDATE 和 xxx_DELETE 列。
COUNT_FETCH ， SUM_TIMER_FETCH ， MIN_TIMER_FETCH ， AVG_TIMER_FETCH ， MAX_TIMER_FETCH

这些列聚合所有获取操作。
COUNT_INSERT ， SUM_TIMER_INSERT ， MIN_TIMER_INSERT ， AVG_TIMER_INSERT ， MAX_TIMER_INSERT

这些列聚合所有插入操作。
COUNT_UPDATE ， SUM_TIMER_UPDATE ， MIN_TIMER_UPDATE ， AVG_TIMER_UPDATE ， MAX_TIMER_UPDATE

这些列聚合所有更新操作。
COUNT_DELETE ， SUM_TIMER_DELETE ， MIN_TIMER_DELETE ， AVG_TIMER_DELETE ， MAX_TIMER_DELETE

这些列聚合所有删除操作。

该 table_io_waits_summary_by_table 表包含以下索引：

对唯一索引（ OBJECT_TYPE ， OBJECT_SCHEMA ， OBJECT_NAME ）

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

26.12.16.8.2 table_io_waits_summary_by_index_usage表

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

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

值为 PRIMARY 表示表I / O使用主索引。
值 NULL 表示表I / O不使用索引。
插入内容将被计入 INDEX_NAME = NULL 。

该 table_io_waits_summary_by_index_usage 表包含以下索引：

对唯一索引（ OBJECT_TYPE ， OBJECT_SCHEMA ， OBJECT_NAME ， INDEX_NAME ）

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

26.12.16.8.3 table_lock_waits_summary_by_table表

该 table_lock_waits_summary_by_table 表汇总了 wait/lock/table/sql/handler 仪器生成的所有表锁等待事件。分组是按表格进行的。

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

内部锁对应于SQL层中的锁。目前通过调用来实现 thr_lock() 。在事件行中，这些锁由 OPERATION 列区分，该列具有以下值之一：
```
阅读正常
用共享锁读取
读高优先级
读不插入
写允许写
写并发插入
写延迟
写低优先级
写得正常
```
外部锁对应于存储引擎层中的锁。目前通过调用来实现 handler::external_lock() 。在事件行中，这些锁由 OPERATION 列区分，该列具有以下值之一：
```
读外部
写外部
```

该 table_lock_waits_summary_by_table 表有这些分组列示意表如何聚集事件： OBJECT_TYPE ， OBJECT_SCHEMA ，和 OBJECT_NAME 。这些列与 events_waits_current 表中的含义相同。它们标识行适用的表。

table_lock_waits_summary_by_table 具有包含聚合值的以下摘要列。如列描述中所示，某些列更通用，其值与更细粒度列的值的总和相同。例如，聚合所有锁的列包含聚合读写锁的相应列的总和。通过这种方式，可以直接获得更高级别的聚合，而无需对低级列进行求和的用户定义视图。

COUNT_STAR ， SUM_TIMER_WAIT ， MIN_TIMER_WAIT ， AVG_TIMER_WAIT ， MAX_TIMER_WAIT

这些列聚合所有锁定操作。它们与相应列 xxx_READ 和 xxx_WRITE 列的总和相同。
COUNT_READ ， SUM_TIMER_READ ， MIN_TIMER_READ ， AVG_TIMER_READ ， MAX_TIMER_READ

这些列聚合所有读锁操作。他们是一样的相应的总和 xxx_READ_NORMAL ， xxx_READ_WITH_SHARED_LOCKS ， xxx_READ_HIGH_PRIORITY ，和 xxx_READ_NO_INSERT 列。
COUNT_WRITE ， SUM_TIMER_WRITE ， MIN_TIMER_WRITE ， AVG_TIMER_WRITE ， MAX_TIMER_WRITE

这些列聚合所有写锁操作。他们是一样的相应的总和 xxx_WRITE_ALLOW_WRITE ， xxx_WRITE_CONCURRENT_INSERT ， xxx_WRITE_LOW_PRIORITY ，和 xxx_WRITE_NORMAL 列。
COUNT_READ_NORMAL ， SUM_TIMER_READ_NORMAL ， MIN_TIMER_READ_NORMAL ， AVG_TIMER_READ_NORMAL ， MAX_TIMER_READ_NORMAL

这些列聚合内部读锁。
COUNT_READ_WITH_SHARED_LOCKS ， SUM_TIMER_READ_WITH_SHARED_LOCKS ， MIN_TIMER_READ_WITH_SHARED_LOCKS ， AVG_TIMER_READ_WITH_SHARED_LOCKS ， MAX_TIMER_READ_WITH_SHARED_LOCKS

这些列聚合内部读锁。
COUNT_READ_HIGH_PRIORITY ， SUM_TIMER_READ_HIGH_PRIORITY ， MIN_TIMER_READ_HIGH_PRIORITY ， AVG_TIMER_READ_HIGH_PRIORITY ， MAX_TIMER_READ_HIGH_PRIORITY

这些列聚合内部读锁。
COUNT_READ_NO_INSERT ， SUM_TIMER_READ_NO_INSERT ， MIN_TIMER_READ_NO_INSERT ， AVG_TIMER_READ_NO_INSERT ， MAX_TIMER_READ_NO_INSERT

这些列聚合内部读锁。
COUNT_READ_EXTERNAL ， SUM_TIMER_READ_EXTERNAL ， MIN_TIMER_READ_EXTERNAL ， AVG_TIMER_READ_EXTERNAL ， MAX_TIMER_READ_EXTERNAL

这些列聚合外部读锁。
COUNT_WRITE_ALLOW_WRITE ， SUM_TIMER_WRITE_ALLOW_WRITE ， MIN_TIMER_WRITE_ALLOW_WRITE ， AVG_TIMER_WRITE_ALLOW_WRITE ， MAX_TIMER_WRITE_ALLOW_WRITE

这些列聚合内部写锁。
COUNT_WRITE_CONCURRENT_INSERT ， SUM_TIMER_WRITE_CONCURRENT_INSERT ， MIN_TIMER_WRITE_CONCURRENT_INSERT ， AVG_TIMER_WRITE_CONCURRENT_INSERT ， MAX_TIMER_WRITE_CONCURRENT_INSERT

这些列聚合内部写锁。
COUNT_WRITE_LOW_PRIORITY ， SUM_TIMER_WRITE_LOW_PRIORITY ， MIN_TIMER_WRITE_LOW_PRIORITY ， AVG_TIMER_WRITE_LOW_PRIORITY ， MAX_TIMER_WRITE_LOW_PRIORITY

这些列聚合内部写锁。
COUNT_WRITE_NORMAL ， SUM_TIMER_WRITE_NORMAL ， MIN_TIMER_WRITE_NORMAL ， AVG_TIMER_WRITE_NORMAL ， MAX_TIMER_WRITE_NORMAL

这些列聚合内部写锁。
COUNT_WRITE_EXTERNAL ， SUM_TIMER_WRITE_EXTERNAL ， MIN_TIMER_WRITE_EXTERNAL ， AVG_TIMER_WRITE_EXTERNAL ， MAX_TIMER_WRITE_EXTERNAL

这些列聚合外部写锁。

该 table_lock_waits_summary_by_table 表包含以下索引：

对唯一索引（ OBJECT_TYPE ， OBJECT_SCHEMA ， OBJECT_NAME ）

TRUNCATE TABLE 表锁定汇总表允许使用。它将汇总列重置为零而不是删除行。

26.12.16.9套接字汇总表

这些套接字摘要表聚合套接字操作的计时器和字节计数信息：

socket_summary_by_event_name ： wait/io/socket/* 每个套接字仪器的所有套接字I / O操作的仪器生成的聚合定时器和字节数统计信息。
socket_summary_by_instance ： wait/io/socket/* 每个套接字实例的所有套接字I / O操作的仪器生成的聚合计时器和字节计数统计信息。当连接终止时，将 socket_summary_by_instance 删除与其对应的行。

idle 当套接字等待来自客户端的下一个请求时，套接字摘要表不会聚合事件生成的等待。对于 idle 事件聚合，请使用wait-event摘要表; 请参见第26.12.16.1节“等待事件汇总表” 。

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

socket_summary_by_event_name 有一个 EVENT_NAME 专栏。每行汇总给定事件名称的事件。
socket_summary_by_instance 有一个 OBJECT_INSTANCE_BEGIN 专栏。每行汇总给定对象的事件。

每个套接字摘要表都包含这些汇总列，其中包含聚合值：

COUNT_STAR ， SUM_TIMER_WAIT ， MIN_TIMER_WAIT ， AVG_TIMER_WAIT ， MAX_TIMER_WAIT

这些列聚合所有操作。
COUNT_READ ， SUM_TIMER_READ ， MIN_TIMER_READ ， AVG_TIMER_READ ， MAX_TIMER_READ ， SUM_NUMBER_OF_BYTES_READ

这些列聚集所有接收操作（ RECV ， RECVFROM ，和 RECVMSG ）。
COUNT_WRITE ， SUM_TIMER_WRITE ， MIN_TIMER_WRITE ， AVG_TIMER_WRITE ， MAX_TIMER_WRITE ， SUM_NUMBER_OF_BYTES_WRITE

这些列汇总所有发送操作（ SEND ， SENDTO ，和 SENDMSG ）。
COUNT_MISC ， SUM_TIMER_MISC ， MIN_TIMER_MISC ， AVG_TIMER_MISC ， MAX_TIMER_MISC

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

该 socket_summary_by_instance 表还具有一个 EVENT_NAME 指示类插座的列： client_connection ， server_tcpip_socket ， server_unix_socket 。可以对此列进行分组，以隔离客户端活动与服务器侦听套接字的活动。

套接字摘要表包含以下索引：

socket_summary_by_event_name ：
- 主键（ EVENT_NAME ）
socket_summary_by_instance ：
- 主键（ OBJECT_INSTANCE_BEGIN ）
- 索引（ EVENT_NAME ）

TRUNCATE TABLE 允许套接字摘要表。除此之外 events_statements_summary_by_digest ，tt将汇总列重置为零而不是删除行。

26.12.16.10内存摘要表

性能模式检测内存使用情况并汇总内存使用情况统计信息，详细信息如下：

使用的内存类型（各种缓存，内部缓冲区等）
线程，帐户，用户，主机间接执行内存操作

性能模式具有以下内存使用方面的功能

使用的内存大小
操作计数
低水位和高水位

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

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

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

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

有关收集内存使用情况数据的信息，请参阅内存检测行为。

内存事件摘要信息示例：

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

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

memory_summary_by_account_by_event_name 有 USER ， HOST 和 EVENT_NAME 列。每行汇总给定帐户（用户和主机组合）和事件名称的事件。
memory_summary_by_host_by_event_name 有 HOST 和 EVENT_NAME 列。每行汇总给定主机和事件名称的事件。
memory_summary_by_thread_by_event_name 有 THREAD_ID 和 EVENT_NAME 列。每行汇总给定线程和事件名称的事件。
memory_summary_by_user_by_event_name 有 USER 和 EVENT_NAME 列。每行汇总给定用户和事件名称的事件。
memory_summary_global_by_event_name 有一个 EVENT_NAME 专栏。每行汇总给定事件名称的事件。

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

COUNT_ALLOC ， COUNT_FREE

对内存分配和无内存函数的聚合调用次数。
SUM_NUMBER_OF_BYTES_ALLOC ， SUM_NUMBER_OF_BYTES_FREE

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

尚未释放的当前已分配块的聚合数。这是一个方便栏，等于 COUNT_ALLOC - COUNT_FREE 。
CURRENT_NUMBER_OF_BYTES_USED

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

与 CURRENT_COUNT_USED 柱相对应的低水位线和高水位线。
LOW_NUMBER_OF_BYTES_USED ， HIGH_NUMBER_OF_BYTES_USED

与 CURRENT_NUMBER_OF_BYTES_USED 柱相对应的低水位线和高水位线。

内存摘要表包含以下索引：

memory_summary_by_account_by_event_name ：
- 在主键（ USER ， HOST ， EVENT_NAME ）
memory_summary_by_host_by_event_name ：
- 主键（ HOST ， EVENT_NAME ）
memory_summary_by_thread_by_event_name ：
- 主键（ THREAD_ID ， EVENT_NAME ）
memory_summary_by_user_by_event_name ：
- 主键（ USER ， EVENT_NAME ）
memory_summary_global_by_event_name ：
- 主键（ EVENT_NAME ）

TRUNCATE TABLE 允许用于内存汇总表。它有这些影响：

通常，截断会重置统计信息的基线，但不会更改服务器状态。也就是说，截断内存表不会释放内存。
COUNT_ALLOC 并 COUNT_FREE 通过将每个计数器减少相同的值来重置为新的基线。
同样， SUM_NUMBER_OF_BYTES_ALLOC 并 SUM_NUMBER_OF_BYTES_FREE 重置为新基线。
LOW_COUNT_USED 并 HIGH_COUNT_USED 重置为 CURRENT_COUNT_USED 。
LOW_NUMBER_OF_BYTES_USED 并 HIGH_NUMBER_OF_BYTES_USED 重置为 CURRENT_NUMBER_OF_BYTES_USED 。

此外，由帐户，主机，用户或线程聚合的每个内存摘要表都会通过截断它所依赖的连接表或截断来隐式截断 memory_summary_global_by_event_name 。有关详细信息，请参见第26.12.8节“性能模式连接表” 。

内存检测行为

记忆仪器列在 setup_instruments 表中并具有表格的名称。默认情况下启用内存检测。 memory/code_area/instrument_name

使用前缀命名的仪器会 memory/performance_schema/ 在Performance Schema本身中公开为内部缓冲区分配的内存量。该 memory/performance_schema/ 仪器是建立在，始终处于启用状态，并且不能在启动或运行时被禁用。内置记忆仪器仅显示在 memory_summary_global_by_event_name 表格中。

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

启用：

的[mysqld]
性能架构仪器=“存储器/％= ON”

禁用：

的[mysqld]
性能架构仪器=“存储器/％= OFF”

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

启用：

更新performance_schema.setup_instruments
SET ENABLED ='YES'
名称在哪里'记忆/％';

禁用：

更新performance_schema.setup_instruments
SET ENABLED ='NO'
名称在哪里'记忆/％';

对于内存仪器，会忽略 TIMED 列， setup_instruments 因为内存操作没有定时。

当服务器中的线程执行已检测的内存分配时，这些规则适用：

如果未检测线程或未启用存储器，则不会检测分配的存储器块。
否则（即，线程和仪器都被启用），分配的内存块被检测。

对于解除分配，这些规则适用：

如果检测到内存分配操作，则无论当前仪器或线程启用状态如何，都会检测相应的自由操作。
如果未检测到内存分配操作，则无论当前仪器或线程启用状态如何，都不会检测相应的空闲操作。

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

当 N 分配了大小的检测内存块时，性能模式会对内存摘要表列进行以下更新：

COUNT_ALLOC ：增加1
CURRENT_COUNT_USED ：增加1
HIGH_COUNT_USED ：如果 CURRENT_COUNT_USED 是新的最大值，则增加
SUM_NUMBER_OF_BYTES_ALLOC ：被...所提升 N
CURRENT_NUMBER_OF_BYTES_USED ：被...所提升 N
HIGH_NUMBER_OF_BYTES_USED ：如果 CURRENT_NUMBER_OF_BYTES_USED 是新的最大值，则增加

解除分配已检测的内存块后，性能模式会对内存摘要表列进行以下更新：

COUNT_FREE ：增加1
CURRENT_COUNT_USED ：减少1
LOW_COUNT_USED ：如果 CURRENT_COUNT_USED 是新的最小值，则减少
SUM_NUMBER_OF_BYTES_FREE ：被...所提升 N
CURRENT_NUMBER_OF_BYTES_USED ：减少 N
LOW_NUMBER_OF_BYTES_USED ：如果 CURRENT_NUMBER_OF_BYTES_USED 是新的最小值，则减少

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

LOW_COUNT_USED 而且 LOW_NUMBER_OF_BYTES_USED 估计值较低。性能模式报告的值保证小于或等于运行时有效使用的最低内存或大小。
HIGH_COUNT_USED 并且 HIGH_NUMBER_OF_BYTES_USED 是更高的估计。性能模式报告的值保证大于或等于运行时有效使用的最大内存数或大小。

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

这是估算计算的一个例子; 但请注意，估计实施可能会有所变化：

线程1在执行期间使用1MB到2MB范围内的内存，由表的列 LOW_NUMBER_OF_BYTES_USED 和 HIGH_NUMBER_OF_BYTES_USED 列报告 memory_summary_by_thread_by_event_name 。

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

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

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

仅当两个线程同时达到高使用率标记时，才能发生14MB的更高估计。

此帐户的实际内存使用量可能介于11.5MB到13.5MB之间。

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

26.12.16.11错误汇总表

性能模式维护汇总表，用于汇总有关服务器错误（和警告）的统计信息。有关服务器错误的列表，请参见第B.3.1节“服务器错误消息参考” 。

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

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

ERROR_NUMBER 是数字错误值。价值是独一无二的。
ERROR_NAME 是与 ERROR_NUMBER 值对应的符号错误名称。价值是独一无二的。
SQLSTATE 是与该值对应的SQLSTATE ERROR_NUMBER 值。价值不一定是唯一的。

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

示例错误事件摘要信息：

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

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

events_errors_summary_by_account_by_error 有 USER ， HOST 和 ERROR_NUMBER 列。每行汇总给定帐户（用户和主机组合）和错误的事件。
events_errors_summary_by_host_by_error 有 HOST 和 ERROR_NUMBER 列。每行汇总给定主机和错误的事件。
events_errors_summary_by_thread_by_error 有 THREAD_ID 和 ERROR_NUMBER 列。每行汇总给定线程和错误的事件。
events_errors_summary_by_user_by_error 有 USER 和 ERROR_NUMBER 列。每行汇总给定用户的事件和错误。
events_errors_summary_global_by_error 有一个 ERROR_NUMBER 专栏。每行汇总给定错误的事件。

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

SUM_ERROR_RAISED

此列汇总了错误发生的次数。
SUM_ERROR_HANDLED

此列聚合SQL异常处理程序处理错误的次数。
FIRST_SEEN ， LAST_SEEN

时间戳指示何时首次看到错误并且最近看到错误。

一个 NULL 在每个错误汇总表行用于汇总统计对于处在出来的仪器误差范围内的所有错误。例如，如果MySQL服务器错误位于from的范围内 M ， N 并且引发错误的数字 Q 不在该范围内，则会 NULL 在行中聚合错误。该 NULL 行与行 ERROR_NUMBER=0 ， ERROR_NAME=NULL 和 SQLSTATE=NULL 。

错误摘要表包含以下索引：

events_errors_summary_by_account_by_error ：
- 在主键（ USER ， HOST ， ERROR_NUMBER ）
events_errors_summary_by_host_by_error ：
- 主键（ HOST ， ERROR_NUMBER ）
events_errors_summary_by_thread_by_error ：
- 主键（ THREAD_ID ， ERROR_NUMBER ）
events_errors_summary_by_user_by_error ：
- 主键（ USER ， ERROR_NUMBER ）
events_errors_summary_global_by_error ：
- 主键（ ERROR_NUMBER ）

TRUNCATE TABLE 允许用于错误摘要表。它有这些影响：

对于未按帐户，主机或用户聚合的摘要表，截断会将摘要列重置为零，或者 NULL 不是删除行。
对于按帐户，主机或用户聚合的汇总表，截断将删除没有连接的帐户，主机或用户的行，并将汇总列重置为零或 NULL 其余行。

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

26.12.16.12状态变量摘要表

性能模式使状态变量信息在第26.12.14节“性能模式状态变量表”中描述的表中可用。它还使汇总状态变量信息在汇总表中可用，如此处所述。每个状态变量摘要表都有一个或多个分组列，以指示表如何聚合状态值：

status_by_account has USER ， HOST 和 VARIABLE_NAME columns按帐户汇总状态变量。
status_by_host has HOST 和 VARIABLE_NAME columns，用于通过客户端连接的主机汇总状态变量。
status_by_user has USER 和 VARIABLE_NAME columns按客户端用户名汇总状态变量。

每个状态变量摘要表都包含此汇总列，其中包含聚合值：

VARIABLE_VALUE

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

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

status_by_account ：
- 在主键（ USER ， HOST ， VARIABLE_NAME ）
status_by_host ：
- 主键（ HOST ， VARIABLE_NAME ）
status_by_user ：
- 主键（ USER ， VARIABLE_NAME ）

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

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

如果帐户，主机和用户的统计数据没有收集 performance_schema_accounts_size ， performance_schema_hosts_size 和 performance_schema_users_size 系统变量，分别被设置为0。

性能模式支持 TRUNCATE TABLE 状态变量汇总表，如下所示; 在所有情况下，活动会话的状态不受影响：

status_by_account ：将已终止会话的帐户状态聚合到用户和主机状态，然后重置帐户状态。
status_by_host ：重置已终止会话的聚合主机状态。
status_by_user ：重置已终止会话的聚合用户状态。

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

26.12.17性能模式其他表

26.12.17.1 host_cache表
26.12.17.2 keyring_keys表
26.12.17.3 log_status表
26.12.17.4 performance_timers表
26.12.17.5线程表
26.12.17.6 user_defined_functions表

以下部分描述的表不属于前面部分讨论的表类别：

host_cache ：来自内部主机缓存的信息
performance_timers ：哪些事件计时器可用
threads ：有关服务器线程的信息
user_defined_functions ：由服务器组件，插件或 CREATE FUNCTION 语句注册的用户定义函数
log_status ：有关服务器日志的信息以进行备份

26.12.17.1 host_cache表

该 host_cache 表提供对主机缓存内容的访问，主机缓存包含客户端主机名和IP地址信息，用于避免域名系统（DNS）查找。所述 host_cache_size 系统变量控制主机高速缓存的大小，以及所述的尺寸 host_cache 暴露该高速缓存内容表。有关主机缓存的操作和配置信息，请参见第8.12.4.2节“DNS查找优化和主机缓存” 。

因为该 host_cache 表公开了主机缓存的内容，所以可以使用 SELECT 语句来检查它。这可以帮助您诊断连接问题的原因。必须启用性能架构或此表为空。

该 host_cache 表包含以下列：

IP

连接到服务器的客户端的IP地址，表示为字符串。
HOST

已解析的该客户端IP的DNS主机名，或者 NULL 名称未知。
HOST_VALIDATED

是否已成功为客户端IP执行IP到主机名称到IP DNS解析。如果 HOST_VALIDATED 是 YES ，则该 HOST 列用作与IP对应的主机名，以便可以避免对DNS的其他调用。尽管 HOST_VALIDATED 是 NO ，DNS解析尝试为每个连接尝试，直到它最终与合法的结果或永久出错完成。此信息使服务器可以避免在临时DNS故障期间缓存错误或丢失的主机名，这将永远对客户端产生负面影响。
SUM_CONNECT_ERRORS

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

一旦 SUM_CONNECT_ERRORS 给定主机达到该值 max_connect_errors ，则阻止来自该主机的新连接。该 SUM_CONNECT_ERRORS 值可能超过该 max_connect_errors 值，因为在未阻止主机的情况下，可以同时发生来自主机的多次连接尝试。任何或所有这些都可能失败，独立递增 SUM_CONNECT_ERRORS ，可能超出其价值 max_connect_errors 。

假设这 max_connect_errors 是200并且 SUM_CONNECT_ERRORS 对于给定主机是199.如果10个客户端同时尝试从该主机连接，则没有一个被阻止，因为 SUM_CONNECT_ERRORS 没有达到200.如果五个客户端发生阻塞错误， SUM_CONNECT_ERRORS 则每个客户端增加一个客户端，结果 SUM_CONNECT_ERRORS 值为204.其他五个客户端成功并且未被阻止，因为 SUM_CONNECT_ERRORS 它们的连接尝试开始时的值未达到200. SUM_CONNECT_ERRORS 阻止了在达到200 之后开始的主机的新连接。
COUNT_HOST_BLOCKED_ERRORS

由于 SUM_CONNECT_ERRORS 超出 max_connect_errors 系统变量值而被阻止的连接数。
COUNT_NAMEINFO_TRANSIENT_ERRORS

IP到主机名DNS解析期间的瞬态错误数。
COUNT_NAMEINFO_PERMANENT_ERRORS

IP到主机名DNS解析期间的永久性错误数。
COUNT_FORMAT_ERRORS

主机名格式错误的数量。 MySQL不会 Host 对 mysql.user 系统表中的列值与名称的一个或多个初始组件完全是数字的主机名执行匹配，例如 1.2.example.com 。而是使用客户端IP地址。有关未出现此类匹配的原因，请参见第6.2.4节“指定帐户名” 。
COUNT_ADDRINFO_TRANSIENT_ERRORS

主机名到IP反向DNS解析期间的瞬态错误数。
COUNT_ADDRINFO_PERMANENT_ERRORS

主机名到IP反向DNS解析期间的永久性错误数。
COUNT_FCRDNS_ERRORS

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

由于不允许用户从客户端主机进行连接而发生的错误数。在这种情况下，服务器返回 ER_HOST_NOT_PRIVILEGED 甚至不询问用户名或密码。
COUNT_NO_AUTH_PLUGIN_ERRORS

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

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

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

在有线协议级别检测到的错误数。
COUNT_PROXY_USER_ERRORS

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

当代理用户A代理到确实存在但是A没有该 PROXY 特权的另一个用户B时检测到的错误数。
COUNT_AUTHENTICATION_ERRORS

验证失败导致的错误数。
COUNT_SSL_ERRORS

SSL问题导致的错误数。
COUNT_MAX_USER_CONNECTIONS_ERRORS

超出每用户连接配额导致的错误数。请参见第6.2.20节“设置帐户资源限制” 。
COUNT_MAX_USER_CONNECTIONS_PER_HOUR_ERRORS

超过每用户每小时连接数配额导致的错误数。请参见第6.2.20节“设置帐户资源限制” 。
COUNT_DEFAULT_DATABASE_ERRORS

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

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

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

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

从 IP 列中的客户端看到的第一次连接尝试的时间戳。
LAST_SEEN

从 IP 列中的客户端看到的最近一次连接尝试的时间戳。
FIRST_ERROR_SEEN

从 IP 列中的客户端看到的第一个错误的时间戳。
LAST_ERROR_SEEN

从 IP 列中的客户端看到的最新错误的时间戳。

该 host_cache 表包含以下索引：

主键（ IP ）
索引（ HOST ）

该 FLUSH HOSTS 声明， TRUNCATE TABLE host_cache 声明，和 中mysqladmin嵌入式主机 命令有同样的效果：他们清除主机缓存，从删除所有行 host_cache 暴露出缓存目录，并解除封锁的任何主机（见第B.4.2.5，“主机'host_name'被阻止“ ）。 FLUSH HOSTS 和 mysqladmin flush-hosts 需要 RELOAD 特权。 TRUNCATE TABLE 需要表的 DROP 权限 host_cache 。

26.12.17.2 keyring_keys表

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

从MySQL 8.0.16开始，该 keyring_keys 表公开了密钥环中密钥的元数据。关键元数据包括密钥ID，密钥所有者和后端密钥ID。该 keyring_keys 表并没有透露任何敏感数据钥匙圈等重点内容。

该 keyring_keys 表包含以下列：

KEY_ID

密钥标识符。
KEY_OWNER

密钥的所有者。
BACKEND_KEY_ID

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

该 keyring_keys 表没有索引。

TRUNCATE TABLE 不允许使用该 keyring_keys 表。

26.12.17.3 log_status表

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

当 log_status 查询表，服务器块日志记录和足够长的时间来填充表相关的行政变化，然后释放资源。该 log_status 表通知联机备份它应该在主服务器的二进制日志和 gtid_executed 记录中复制哪个点，以及每个复制通道的中继日志。它还为各个存储引擎提供相关信息，例如最后一个日志序列号（LSN）和为 InnoDB 存储引擎采用的最后一个检查点的LSN 。

该 log_status 表包含以下列：

SERVER_UUID

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

来自主服务器的日志位置状态信息，作为单个JSON对象提供，具有以下键：

binary_log_file

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

binary_log_position

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

gtid_executed

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

一个JSON通道数组，每个通道都包含以下信息：

channel_name

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

relay_log_file

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

relay_log_pos

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

来自各个存储引擎的相关信息，作为JSON对象提供，每个适用的存储引擎都有一个密钥。

该 log_status 表没有索引。

BACKUP_ADMIN 访问 log_status 表时需要该权限。

TRUNCATE TABLE 不允许使用该 log_status 表。

26.12.17.4 performance_timers表

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

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

如果与给定计时器名称关联的值为 NULL ，则您的平台不支持该计时器。有关事件时序如何发生的说明，请参见第26.4.1节“性能模式事件时序” 。

该 performance_timers 表包含以下列：

TIMER_NAME

计时器名称。
TIMER_FREQUENCY

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

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

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

该 performance_timers 表包含以下索引：

没有

TRUNCATE TABLE 不允许使用该 performance_timers 表。

26.12.17.5线程表

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

MySQL的> SELECT * FROM performance_schema.threads\G
*************************** 1。排******************** *******
          THREAD_ID：1
               名称：thread / sql / main
               类型：背景
     PROCESSLIST_ID：NULL
   PROCESSLIST_USER：NULL
   PROCESSLIST_HOST：NULL
     PROCESSLIST_DB：NULL
PROCESSLIST_COMMAND：NULL
   PROCESSLIST_TIME：80284
  PROCESSLIST_STATE：NULL
   PROCESSLIST_INFO：NULL
   PARENT_THREAD_ID：NULL
               角色：空
       仪表：是的
            历史：是的
    CONNECTION_TYPE：NULL
       THREAD_OS_ID：489803
     RESOURCE_GROUP：SYS_default
...
****************************排******************** *******
          THREAD_ID：51
               名称：thread / sql / one_connection
               类型：FOREGROUND
     PROCESSLIST_ID：34
   PROCESSLIST_USER：伊莎贝拉
   PROCESSLIST_HOST：localhost
     PROCESSLIST_DB：performance_schema
PROCESSLIST_COMMAND：查询
   PROCESSLIST_TIME：0
  PROCESSLIST_STATE：发送数据
   PROCESSLIST_INFO：SELECT * FROM performance_schema.threads
   PARENT_THREAD_ID：1
               角色：空
       仪表：是的
            历史：是的
    CONNECTION_TYPE：SSL / TLS
       THREAD_OS_ID：755399
     RESOURCE_GROUP：USR_default
...

当Performance Schema初始化时，它会 threads 根据当前存在的线程填充表。此后，每次服务器创建一个线程时都会添加一个新行。

的 INSTRUMENTED 和 HISTORY 新的线程列值是由内容确定 setup_actors 表。有关如何使用 setup_actors 表来控制这些列的信息，请参见第26.4.6节“按线程预过滤” 。

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

threads 名称前缀为的表列 PROCESSLIST_ 提供的信息类似于 INFORMATION_SCHEMA.PROCESSLIST 表或 SHOW PROCESSLIST 语句中提供的信息。因此，所有三个源都提供线程监视信息。使用 threads 不同于以下方式使用其他两个来源：

访问 threads 不需要互斥锁，对服务器性能的影响最小。 INFORMATION_SCHEMA.PROCESSLIST 并且 SHOW PROCESSLIST 因为它们需要互斥量而产生负面的性能影响。
threads 为每个线程提供附加信息，例如它是前台线程还是后台线程，以及与线程关联的服务器内的位置。
threads 提供有关后台线程的信息，因此它可用于监视其他线程信息源无法进行的活动。
您可以启用或禁用线程监视（即，是否检测线程执行的事件）和历史事件日志记录。要控制新前台线程的初始值 INSTRUMENTED 和 HISTORY 值，请使用该 setup_actors 表。要控制现有线程的这些方面，请设置表行的列 INSTRUMENTED 和 HISTORY 列 threads 。（有关线程监视和历史事件日志记录发生的条件的详细信息，请参阅 INSTRUMENTED 和 HISTORY 列的说明。）

出于这些原因，执行服务器监视的DBA使用 INFORMATION_SCHEMA.PROCESSLIST 或者 SHOW PROCESSLIST 可能希望使用 threads 表来监视。

注意

对于 INFORMATION_SCHEMA.PROCESSLIST 和 SHOW PROCESSLIST ，仅当当前用户具有该 PROCESS 权限时，才会显示有关其他用户的线程的信息。 threads 表格不是这样 ; 所有行都显示给拥有 SELECT 该表特权的任何用户。不应该为那些不能为其他用户查看线程的用户提供该权限。

该 threads 表包含以下列：

THREAD_ID

唯一的线程标识符。
NAME

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

线程类型， FOREGROUND 或者 BACKGROUND 。用户连接线程是前台线程。与内部服务器活动关联的线程是后台线程。示例是内部 InnoDB 线程， “ binlog dump ” 线程向从站发送信息，以及从站I / O和SQL线程。
PROCESSLIST_ID

对于 INFORMATION_SCHEMA.PROCESSLIST 表中显示的线程，这 ID 与该表的列中显示的值相同。它也是输出 Id 列中显示的值 SHOW PROCESSLIST ，以及 CONNECTION_ID() 将在该线程内返回的值。

对于后台线程（未与用户连接相关联的线程）， PROCESSLIST_ID 是 NULL ，这样的值是不是唯一的。
PROCESSLIST_USER

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

PROCESSLIST_HOST

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

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

MySQL的> SELECT NAME, ENABLED, TIMED
       FROM performance_schema.setup_instruments
       WHERE NAME LIKE 'wait/io/socket%';
+ ---------------------------------------- + -------- -  + ------- +
| NAME | 启用| 定时|
+ ---------------------------------------- + -------- -  + ------- +
| wait / io / socket / sql / server_tcpip_socket | 没有| 没有|
| wait / io / socket / sql / server_unix_socket | 没有| 没有|
| wait / io / socket / sql / client_connection | 没有| 没有|
+ ---------------------------------------- + -------- -  + ------- +
3行（0.01秒）

MySQL的> UPDATE performance_schema.setup_instruments
       SET ENABLED='YES'
       WHERE NAME LIKE 'wait/io/socket%';
查询OK，3行受影响（0.00秒）
匹配的行数：3已更改：3警告：0

MySQL的> SELECT * FROM performance_schema.socket_instances\G
*************************** 1。排******************** *******
           EVENT_NAME：wait / io / socket / sql / client_connection
OBJECT_INSTANCE_BEGIN：140612577298432
            THREAD_ID：31
            SOCKET_ID：53
                   IP：:: ffff：127.0.0.1
                 港口：55642
                状态：有效
...

PROCESSLIST_DB

线程的默认数据库， NULL 如果没有。
PROCESSLIST_COMMAND

对于前台线程，线程代表客户端执行的命令类型，或者 Sleep 会话是否空闲。有关线程命令的说明，请参见第8.14节“检查线程信息” 。此列的值对应于客户端/服务器协议和状态变量的命令。请参见第5.1.10节“服务器状态变量” COM_xxx Com_xxx

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

线程处于当前状态的时间（以秒为单位）。
PROCESSLIST_STATE

指示线程正在执行的操作，事件或状态。有关 PROCESSLIST_STATE 值的说明，请参见第8.14节“检查线程信息” 。如果值为 NULL ，则线程可能对应于空闲客户端会话或其正在进行的工作没有使用阶段进行检测。

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

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

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

没用过。
INSTRUMENTED

是否检测了线程执行的事件。价值是 YES 或 NO 。
- 对于前台线程，初始 INSTRUMENTED 值由与线程关联的用户帐户是否与 setup_actors 表中的任何行匹配来确定。匹配基于 PROCESSLIST_USER 和 PROCESSLIST_HOST 列的值。
  
  如果线程产生子线程，则为子线程 threads 创建的表行再次进行匹配。
- 对于后台线程， INSTRUMENTED 就是 YES 默认。 setup_actors 没有咨询，因为后台线程没有关联的用户。
- 对于任何线程，它 INSTRUMENTED 值可以在线程的生命周期内更改。
要监视线程执行的事件，必须满足以下条件：
- 该 thread_instrumentation 消费 setup_consumers 表中必须是 YES 。
- 该 threads.INSTRUMENTED 列必须是 YES 。
- 监控只对从具有仪器产生的那些线程事件发生 ENABLED 列设置为 YES 在 setup_instruments 表中。
HISTORY

是否记录线程的历史事件。值是 YES 或 NO 。
- 对于前台线程，初始 HISTORY 值由与线程关联的用户帐户是否与 setup_actors 表中的任何行匹配来确定。匹配基于 PROCESSLIST_USER 和 PROCESSLIST_HOST 列的值。
  
  如果线程产生子线程，则再次进行匹配 threads 创建表行。
- 对于后台线程， HISTORY 就是 YES 默认。 setup_actors 没有咨询，因为后台线程没有关联的用户。
- 对于任何线程，其 HISTORY 值可以在线程的生命周期内更改。
对于要发生的线程的历史事件日志记录，这些事情必须为真：
- setup_consumers 必须启用表中适当的与历史记录相关的使用者。例如，在 events_waits_history 和 events_waits_history_long 表中的等待事件记录需要相应的 events_waits_history 和 events_waits_history_long 消费者 YES 。
- 该 threads.HISTORY 列必须是 YES 。
- 记录仅针对从具有仪器产生的那些线程事件发生 ENABLED 列设置为 YES 在 setup_instruments 表中。
CONNECTION_TYPE

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

底层操作系统定义的线程或任务标识符，如果有的话：
- 当MySQL线程在其生命周期内与同一操作系统线程关联时， THREAD_OS_ID 包含操作系统线程ID。
- 当MySQL线程在其生命周期内没有与同一操作系统线程关联时， THREAD_OS_ID 包含 NULL 。这对于使用线程池插件时的用户会话是典型的（请参见第5.6.3节“MySQL Enterprise线程池” ）。
对于Windows， THREAD_OS_ID 对应于Process Explorer中可见的线程ID（ https://technet.microsoft.com/en-us/sysinternals/bb896653.aspx ）。

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

资源组标签。此值是 NULL 当前平台或服务器配置不支持的资源组（请参阅资源组限制）。

该 threads 表包含以下索引：

主键（ THREAD_ID ）
索引（ NAME ）
索引（ PROCESSLIST_ID ）
索引（ PROCESSLIST_USER ， PROCESSLIST_HOST ）
索引（ PROCESSLIST_HOST ）
索引（ THREAD_OS_ID ）
索引（ RESOURCE_GROUP ）

TRUNCATE TABLE 不允许使用该 threads 表。

26.12.17.6 user_defined_functions表

该 user_defined_functions 表包含由服务器组件或插件或由a注册的每个用户定义函数（UDF）的行 CREATE FUNCTION 语句。

user_defined_functions 有这些列：

UDF_NAME

SQL语句中引用的UDF名称。该值是 NULL 函数是否由 CREATE FUNCTION 语句注册并且正在卸载的过程中。
UDF_RETURN_TYPE

UDF返回值类型。值中的一个 int ， decimal ， real ， char ，或 row 。
UDF_TYPE

UDF类型。值是 function （标量）或 aggregate 。之一。
UDF_LIBRARY

包含可执行UDF代码的UDF库文件的名称。该文件位于 plugin_dir 系统变量指定的目录中。值是 NULL 指使用服务器组件服务而不是 CREATE FUNCTION 语句注册UDF 。
UDF_USAGE_COUNT

当前的UDF使用计数。

该 user_defined_functions 表包含以下索引：

主键（ UDF_NAME ）

TRUNCATE TABLE 不允许使用该 user_defined_functions 表。

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

表26.4性能模式变量参考

名称	CMD线	选项文件	系统变量	状态变量	Var范围	动态
performance_schema	是	是	是		全球	没有
Performance_schema_accounts_lost				是	全球	没有
performance_schema_accounts_size	是	是	是		全球	没有
Performance_schema_cond_classes_lost				是	全球	没有
Performance_schema_cond_instances_lost				是	全球	没有
性能架构消费者的事件，阶段电流	是	是
性能架构消费者的事件，阶段历史	是	是
性能架构消费者的事件，阶段 - 历史悠久	是	是
性能架构消费者的事件陈述电流	是	是
性能架构消费者的事件陈述历史	是	是
性能架构消费者的事件陈述历史长	是	是
性能架构的消费事件，交易流	是	是
性能架构的消费事件，交易历史	是	是
性能架构的消费事件，交易历史长	是	是
性能架构的消费活动，等待电流	是	是
性能架构的消费活动，等待历史	是	是
性能架构的消费活动，等待历史长	是	是
性能架构的消费全球仪器仪表	是	是
性能架构的消费报表消化	是	是
性能架构消费者线程仪表	是	是
Performance_schema_digest_lost				是	全球	没有
performance_schema_digests_size	是	是	是		全球	没有
performance_schema_events_stages_history_long_size	是	是	是		全球	没有
performance_schema_events_stages_history_size	是	是	是		全球	没有
performance_schema_events_statements_history_long_size	是	是	是		全球	没有
performance_schema_events_statements_history_size	是	是	是		全球	没有
performance_schema_events_transactions_history_long_size	是	是	是		全球	没有
performance_schema_events_transactions_history_size	是	是	是		全球	没有
performance_schema_events_waits_history_long_size	是	是	是		全球	没有
performance_schema_events_waits_history_size	是	是	是		全球	没有
Performance_schema_file_classes_lost				是	全球	没有
Performance_schema_file_handles_lost				是	全球	没有
Performance_schema_file_instances_lost				是	全球	没有
Performance_schema_hosts_lost				是	全球	没有
performance_schema_hosts_size	是	是	是		全球	没有
性能架构仪	是	是
Performance_schema_locker_lost				是	全球	没有
performance_schema_max_cond_classes	是	是	是		全球	没有
performance_schema_max_cond_instances	是	是	是		全球	没有
performance_schema_max_digest_length	是	是	是		全球	没有
performance_schema_max_file_classes	是	是	是		全球	没有
performance_schema_max_file_handles	是	是	是		全球	没有
performance_schema_max_file_instances	是	是	是		全球	没有
performance_schema_max_memory_classes	是	是	是		全球	没有
performance_schema_max_metadata_locks	是	是	是		全球	没有
performance_schema_max_mutex_classes	是	是	是		全球	没有
performance_schema_max_mutex_instances	是	是	是		全球	没有
performance_schema_max_prepared_statements_instances	是	是	是		全球	没有
performance_schema_max_program_instances	是	是	是		全球	没有
performance_schema_max_rwlock_classes	是	是	是		全球	没有
performance_schema_max_rwlock_instances	是	是	是		全球	没有
performance_schema_max_socket_classes	是	是	是		全球	没有
performance_schema_max_socket_instances	是	是	是		全球	没有
performance_schema_max_stage_classes	是	是	是		全球	没有
performance_schema_max_statement_classes	是	是	是		全球	没有
performance_schema_max_statement_stack	是	是	是		全球	没有
performance_schema_max_table_handles	是	是	是		全球	没有
performance_schema_max_table_instances	是	是	是		全球	没有
performance_schema_max_thread_classes	是	是	是		全球	没有
performance_schema_max_thread_instances	是	是	是		全球	没有
Performance_schema_memory_classes_lost				是	全球	没有
Performance_schema_metadata_lock_lost				是	全球	没有
Performance_schema_mutex_classes_lost				是	全球	没有
Performance_schema_mutex_instances_lost				是	全球	没有
Performance_schema_nested_statement_lost				是	全球	没有
Performance_schema_prepared_statements_lost				是	全球	没有
Performance_schema_program_lost				是	全球	没有
Performance_schema_rwlock_classes_lost				是	全球	没有
Performance_schema_rwlock_instances_lost				是	全球	没有
Performance_schema_session_connect_attrs_lost				是	全球	没有
performance_schema_session_connect_attrs_size	是	是	是		全球	没有
performance_schema_setup_actors_size	是	是	是		全球	没有
performance_schema_setup_objects_size	是	是	是		全球	没有
Performance_schema_socket_classes_lost				是	全球	没有
Performance_schema_socket_instances_lost				是	全球	没有
Performance_schema_stage_classes_lost				是	全球	没有
Performance_schema_statement_classes_lost				是	全球	没有
Performance_schema_table_handles_lost				是	全球	没有
Performance_schema_table_instances_lost				是	全球	没有
Performance_schema_thread_classes_lost				是	全球	没有
Performance_schema_thread_instances_lost				是	全球	没有
Performance_schema_users_lost				是	全球	没有
performance_schema_users_size	是	是	是		全球	没有

26.14性能模式命令选项

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

可以使用以下语法在启动时配置性能架构使用者和仪器。有关其他详细信息，请参见第26.3节“性能架构启动配置” 。

--performance-schema-consumer-consumer_name=value

配置性能架构使用者。 setup_consumers 表中的使用者名称使用下划线，但对于在启动时设置的使用者，名称中的短划线和下划线是等效的。本节稍后将详细介绍配置单个使用者的选项。
--performance-schema-instrument=instrument_name=value

配置性能架构工具。该名称可以作为模式给出，以配置与模式匹配的工具。

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

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

配置 events-stages-current 使用者。
--performance-schema-consumer-events-stages-history=value

配置 events-stages-history 使用者。
--performance-schema-consumer-events-stages-history-long=value

配置 events-stages-history-long 使用者。
--performance-schema-consumer-events-statements-current=value

配置 events-statements-current 使用者。
--performance-schema-consumer-events-statements-history=value

配置 events-statements-history 使用者。
--performance-schema-consumer-events-statements-history-long=value

配置 events-statements-history-long 使用者。
--performance-schema-consumer-events-transactions-current=value

配置Performance Schema events-transactions-current 使用者。
--performance-schema-consumer-events-transactions-history=value

配置Performance Schema events-transactions-history 使用者。
--performance-schema-consumer-events-transactions-history-long=value

配置Performance Schema events-transactions-history-long 使用者。
--performance-schema-consumer-events-waits-current=value

配置 events-waits-current 使用者。
--performance-schema-consumer-events-waits-history=value

配置 events-waits-history 使用者。
--performance-schema-consumer-events-waits-history-long=value

配置 events-waits-history-long 使用者。
--performance-schema-consumer-global-instrumentation=value

配置 global-instrumentation 使用者。
--performance-schema-consumer-statements-digest=value

配置 statements-digest 使用者。
--performance-schema-consumer-thread-instrumentation=value

配置 thread-instrumentation 使用者。

26.15性能模式系统变量

Performance Schema实现了几个提供配置信息的系统变量：

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

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

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

Performance Schema系统变量具有以下含义：

performance_schema

属性	值
命令行格式	`--performance-schema[={OFF\|ON}]`
系统变量	`performance_schema`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	布尔
默认值	`ON`

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

即使禁用了性能架构，它也会继续填充 global_variables ， session_variables ， global_status ，和 session_status 表格。必要时会发生这种情况，以允许从这些表中提取 SHOW VARIABLES 和 SHOW STATUS 语句的结果，具体取决于 show_compatibility_56 系统变量的设置。性能模式还会在禁用时填充一些复制表。

performance_schema_accounts_size

属性	值
命令行格式	`--performance-schema-accounts-size=#`
系统变量	`performance_schema_accounts_size`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`-1` （表示自动缩放;不指定此文字值）
最低价值	`-1` （表示自动缩放;不指定此文字值）
最大价值	`1048576`

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

performance_schema_digests_size

属性	值
命令行格式	`--performance-schema-digests-size=#`
系统变量	`performance_schema_digests_size`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`-1` （表示自动调整大小;不指定此文字值）
最低价值	`-1`
最大价值	`1048576`

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

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

performance_schema_error_size

属性	值
命令行格式	`--performance-schema-error-size=#`
系统变量	`performance_schema_error_size`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`number of server error codes`
最低价值	`0`
最大价值	`1048576`

已检测的服务器错误代码的数量。默认值是服务器错误代码的实际数量。尽管该值可以设置为从0到最大值，但预期用途是将其设置为默认值（以检测所有错误）或0（设置无错误）。

错误信息汇总在汇总表中; 请参见第26.12.16.11节“错误汇总表” 。如果发生未检测的错误，则将该事件的信息聚合到 NULL 每个摘要表中的行; 也就是说，给行 ERROR_NUMBER=0 ， ERROR_NAME=NULL 和 SQLSTATE=NULL 。

performance_schema_events_stages_history_long_size

属性	值
命令行格式	`--performance-schema-events-stages-history-long-size=#`
系统变量	`performance_schema_events_stages_history_long_size`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`-1` （表示自动调整大小;不指定此文字值）

events_stages_history_long 表中的行数。

performance_schema_events_stages_history_size

属性	值
命令行格式	`--performance-schema-events-stages-history-size=#`
系统变量	`performance_schema_events_stages_history_size`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`-1` （表示自动调整大小;不指定此文字值）

events_stages_history 表中每个线程的行数。

performance_schema_events_statements_history_long_size

属性	值
命令行格式	`--performance-schema-events-statements-history-long-size=#`
系统变量	`performance_schema_events_statements_history_long_size`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`-1` （表示自动调整大小;不指定此文字值）

events_statements_history_long 表中的行数。

performance_schema_events_statements_history_size

属性	值
命令行格式	`--performance-schema-events-statements-history-size=#`
系统变量	`performance_schema_events_statements_history_size`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`-1` （表示自动调整大小;不指定此文字值）

events_statements_history 表中每个线程的行数。

performance_schema_events_transactions_history_long_size

属性	值
命令行格式	`--performance-schema-events-transactions-history-long-size=#`
系统变量	`performance_schema_events_transactions_history_long_size`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`-1` （表示自动调整大小;不指定此文字值）

events_transactions_history_long 表中的行数。

performance_schema_events_transactions_history_size

属性	值
命令行格式	`--performance-schema-events-transactions-history-size=#`
系统变量	`performance_schema_events_transactions_history_size`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`-1` （表示自动调整大小;不指定此文字值）

events_transactions_history 表中每个线程的行数。

performance_schema_events_waits_history_long_size

属性	值
命令行格式	`--performance-schema-events-waits-history-long-size=#`
系统变量	`performance_schema_events_waits_history_long_size`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`-1` （表示自动调整大小;不指定此文字值）

events_waits_history_long 表中的行数。

performance_schema_events_waits_history_size

属性	值
命令行格式	`--performance-schema-events-waits-history-size=#`
系统变量	`performance_schema_events_waits_history_size`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`-1` （表示自动调整大小;不指定此文字值）

events_waits_history 表中每个线程的行数。

performance_schema_hosts_size

属性	值
命令行格式	`--performance-schema-hosts-size=#`
系统变量	`performance_schema_hosts_size`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`-1` （表示自动缩放;不指定此文字值）
最低价值	`-1` （表示自动缩放;不指定此文字值）
最大价值	`1048576`

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

performance_schema_max_cond_classes

属性	值
命令行格式	`--performance-schema-max-cond-classes=#`
系统变量	`performance_schema_max_cond_classes`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`80`
最低价值	`0`
最大值（> = 8.0.12）	`1024`
最大值（<= 8.0.11）	`256`

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

performance_schema_max_cond_instances

属性	值
命令行格式	`--performance-schema-max-cond-instances=#`
系统变量	`performance_schema_max_cond_instances`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`-1` （表示自动缩放;不指定此文字值）

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

performance_schema_max_digest_length

属性	值
命令行格式	`--performance-schema-max-digest-length=#`
系统变量	`performance_schema_max_digest_length`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`1024`
最低价值	`0`
最大价值	`1048576`

每个语句保留的最大内存字节数，用于计算性能模式中的规范化语句摘要值。这个变量与 max_digest_length ; 请参见第5.1.8节“服务器系统变量” 中该变量的说明。

有关语句摘要的更多信息，包括有关内存使用的注意事项，请参见第26.10节“性能模式语句摘要和采样” 。

performance_schema_max_digest_sample_age

属性	值
命令行格式	`--performance-schema-max-digest-sample-age=#`
介绍	8.0.3
系统变量	`performance_schema_max_digest_sample_age`
范围	全球
动态	是
`SET_VAR` 提示适用	没有
类型	整数
默认值	`60`
最低价值	`0`
最大价值	`1048576`

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

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

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

performance_schema_max_file_classes

属性	值
命令行格式	`--performance-schema-max-file-classes=#`
系统变量	`performance_schema_max_file_classes`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`80`
最低价值	`0`
最大值（> = 8.0.12）	`1024`
最大值（<= 8.0.11）	`256`

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

performance_schema_max_file_handles

属性	值
命令行格式	`--performance-schema-max-file-handles=#`
系统变量	`performance_schema_max_file_handles`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`32768`

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

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

performance_schema_max_file_instances

属性	值
命令行格式	`--performance-schema-max-file-instances=#`
系统变量	`performance_schema_max_file_instances`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`-1` （表示自动缩放;不指定此文字值）

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

performance_schema_max_index_stat

属性	值
命令行格式	`--performance-schema-max-index-stat=#`
系统变量	`performance_schema_max_index_stat`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`-1` （表示自动调整大小;不指定此文字值）

性能模式维护统计信息的最大索引数。如果超出此最大值以使索引统计信息丢失，则性能模式会增加 Performance_schema_index_stat_lost 状态变量。默认值使用值自动调整 performance_schema_max_table_instances 。

performance_schema_max_memory_classes

属性	值
命令行格式	`--performance-schema-max-memory-classes=#`
系统变量	`performance_schema_max_memory_classes`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值（> = 8.0.1）	`450`
默认值（8.0.0）	`350`

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

performance_schema_max_metadata_locks

属性	值
命令行格式	`--performance-schema-max-metadata-locks=#`
系统变量	`performance_schema_max_metadata_locks`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`-1` （表示自动缩放;不指定此文字值）

元数据锁定工具的最大数量。此值控制 metadata_locks 表的大小。如果超出此最大值，以便无法检测元数据锁定，则性能模式会增加 Performance_schema_metadata_lock_lost 状态变量。

performance_schema_max_mutex_classes

属性	值
命令行格式	`--performance-schema-max-mutex-classes=#`
系统变量	`performance_schema_max_mutex_classes`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值（> = 8.0.12）	`300`
默认值（> = 8.0.3，<= 8.0.11）	`250`
默认值（> = 8.0.1，<= 8.0.2）	`220`
默认值（8.0.0）	`200`
最低价值	`0`
最大值（> = 8.0.12）	`1024`
最大值（<= 8.0.11）	`256`

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

performance_schema_max_mutex_instances

属性	值
命令行格式	`--performance-schema-max-mutex-instances=#`
系统变量	`performance_schema_max_mutex_instances`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`-1` （表示自动缩放;不指定此文字值）

已检测的互斥对象的最大数量。有关如何设置和使用此变量的信息，请参见第26.7节“性能模式状态监视” 。

performance_schema_max_prepared_statements_instances

属性	值
命令行格式	`--performance-schema-max-prepared-statements-instances=#`
系统变量	`performance_schema_max_prepared_statements_instances`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`-1` （表示自动缩放;不指定此文字值）

表中的最大行数 prepared_statements_instances 。如果超出此最大值，以便无法检测预准备语句，则性能模式会增加 Performance_schema_prepared_statements_lost 状态变量。有关如何设置和使用此变量的信息，请参阅第26.7节“性能架构状态监视” 。

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

performance_schema_max_rwlock_classes

属性	值
命令行格式	`--performance-schema-max-rwlock-classes=#`
系统变量	`performance_schema_max_rwlock_classes`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`40`
最低价值	`0`
最大值（> = 8.0.12）	`1024`
最大值（<= 8.0.11）	`256`

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

performance_schema_max_program_instances

属性	值
命令行格式	`--performance-schema-max-program-instances=#`
系统变量	`performance_schema_max_program_instances`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`-1` （表示自动缩放;不指定此文字值）

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

performance_schema_max_rwlock_instances

属性	值
命令行格式	`--performance-schema-max-rwlock-instances=#`
系统变量	`performance_schema_max_rwlock_instances`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`-1` （表示自动缩放;不指定此文字值）

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

performance_schema_max_socket_classes

属性	值
命令行格式	`--performance-schema-max-socket-classes=#`
系统变量	`performance_schema_max_socket_classes`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`10`
最低价值	`0`
最大值（> = 8.0.12）	`1024`
最大值（<= 8.0.11）	`256`

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

performance_schema_max_socket_instances

属性	值
命令行格式	`--performance-schema-max-socket-instances=#`
系统变量	`performance_schema_max_socket_instances`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`-1` （表示自动缩放;不指定此文字值）

已检测的套接字对象的最大数量。有关如何设置和使用此变量的信息，请参见第26.7节“性能模式状态监视” 。

performance_schema_max_sql_text_length

属性	值
命令行格式	`--performance-schema-max-sql-text-length=#`
系统变量	`performance_schema_max_sql_text_length`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`1024`
最低价值	`0`
最大价值	`1048576`

用于存储SQL语句的最大字节数。该值适用于这些列所需的存储：

在 SQL_TEXT 该列 events_statements_current ， events_statements_history 和 events_statements_history_long 语句事件表。
摘要表的 QUERY_SAMPLE_TEXT 列 events_statements_summary_by_digest 。

超出的任何字节 performance_schema_max_sql_text_length 都将被丢弃，并且不会出现在列中。只有在列中无法区分许多初始字节之后，语句才会有所不同。

减小 performance_schema_max_sql_text_length 值会减少内存使用量，但如果它们仅在结尾处有所不同，则会导致更多语句无法区分。增加该值会增加内存使用，但允许区分更长的语句。

performance_schema_max_stage_classes

属性	值
命令行格式	`--performance-schema-max-stage-classes=#`
系统变量	`performance_schema_max_stage_classes`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`150`
最低价值	`0`
最大值（> = 8.0.12）	`1024`
最大值（<= 8.0.11）	`256`

舞台乐器的最大数量。有关如何设置和使用此变量的信息，请参见第26.7节“性能模式状态监视” 。

performance_schema_max_statement_classes

属性	值
命令行格式	`--performance-schema-max-statement-classes=#`
系统变量	`performance_schema_max_statement_classes`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`-1` （表示自动调整大小;不指定此文字值）

声明工具的最大数量。有关如何设置和使用此变量的信息，请参见第26.7节“性能架构状态监视” 。

根据客户端/服务器协议中的命令数以及服务器支持的SQL语句类型数，在服务器构建时计算默认值。

除非将其设置为0以禁用所有语句检测并保存与其关联的所有内存，否则不应更改此变量。将变量设置为非零值而非默认值没有任何好处; 特别是，大于默认值的值会导致需要分配更多内存。

performance_schema_max_statement_stack

属性	值
命令行格式	`--performance-schema-max-statement-stack=#`
系统变量	`performance_schema_max_statement_stack`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`10`

性能模式维护统计信息的嵌套存储程序调用的最大深度。超过此最大值时，性能模式会 Performance_schema_nested_statement_lost 为每个执行的存储程序语句递增状态变量。

performance_schema_max_table_handles

属性	值
命令行格式	`--performance-schema-max-table-handles=#`
系统变量	`performance_schema_max_table_handles`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`-1` （表示自动缩放;不指定此文字值）

已打开的表对象的最大数量。此值控制 table_handles 表的大小。如果超出此最大值以使得无法检测表句柄，则性能模式会增加 Performance_schema_table_handles_lost 状态变量。有关如何设置和使用此变量的信息，请参见第26.7节“性能模式状态监视” 。

performance_schema_max_table_instances

属性	值
命令行格式	`--performance-schema-max-table-instances=#`
系统变量	`performance_schema_max_table_instances`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`-1` （表示自动缩放;不指定此文字值）

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

performance_schema_max_table_lock_stat

属性	值
命令行格式	`--performance-schema-max-table-lock-stat=#`
系统变量	`performance_schema_max_table_lock_stat`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`-1` （表示自动调整大小;不指定此文字值）

性能模式维护锁定统计信息的最大表数。如果超出此最大值以使表锁统计信息丢失，则性能模式会增加 Performance_schema_table_lock_stat_lost 状态变量。

performance_schema_max_thread_classes

属性	值
命令行格式	`--performance-schema-max-thread-classes=#`
系统变量	`performance_schema_max_thread_classes`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值（> = 8.0.3）	`100`
默认值（<= 8.0.2）	`50`
最低价值	`0`
最大值（> = 8.0.12）	`1024`
最大值（<= 8.0.11）	`256`

最大线程数量。有关如何设置和使用此变量的信息，请参见第26.7节“性能模式状态监视” 。

performance_schema_max_thread_instances

属性	值
命令行格式	`--performance-schema-max-thread-instances=#`
系统变量	`performance_schema_max_thread_instances`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`-1` （表示自动缩放;不指定此文字值）

已检测的线程对象的最大数量。该值控制 threads 表的大小。如果超出此最大值以使得无法检测线程，则性能模式会增加 Performance_schema_thread_instances_lost 状态变量。有关如何设置和使用此变量的信息，请参见第26.7节“性能模式状态监视” 。

该 max_connections 系统变量会影响多少个线程可以在服务器端运行。 performance_schema_max_thread_instances 影响可以检测多少个正在运行的线程。

在 variables_by_thread 和 status_by_thread 表格只包含约前台线程系统状态变量信息。如果并非所有线程都由性能模式检测，则此表将遗漏一些行。在这种情况下， Performance_schema_thread_instances_lost 状态变量将大于零。

performance_schema_session_connect_attrs_size

属性	值
命令行格式	`--performance-schema-session-connect-attrs-size=#`
系统变量	`performance_schema_session_connect_attrs_size`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`-1` （表示自动调整大小;不指定此文字值）
最低价值	`-1`
最大价值	`1048576`

每个线程保留的预分配内存量，用于保存连接属性键值对。如果客户端发送的连接属性数据的聚合大小大于此数量，则性能模式会截断属性数据，递增 Performance_schema_session_connect_attrs_lost 状态变量，并将错误写入错误日志，指示如果发生截断，则会发生截断 log_error_verbosity 系统变量大于1. A _truncated 如果属性缓冲区有足够的空间，属性也会添加到会话属性中，并带有一个值，表示丢失了多少字节。这使性能模式能够在连接属性表中公开每个连接的截断信息。无需检查错误日志即可检查此信息。

默认值 performance_schema_session_connect_attrs_size 是在服务器启动时自动调整大小。此值可能很小，因此如果发生截断（ Performance_schema_session_connect_attrs_lost 变为非零），您可能希望设置 performance_schema_session_connect_attrs_size 显式设置为更大的值。

虽然最大允许 performance_schema_session_connect_attrs_size 值为1MB，但有效最大值为64KB，因为服务器对它将接受的连接属性数据的聚合大小施加了64KB的限制。如果客户端尝试发送超过64KB的属性数据，则服务器拒绝连接。有关更多信息，请参见第26.12.9节“性能架构连接属性表” 。

performance_schema_setup_actors_size

属性	值
命令行格式	`--performance-schema-setup-actors-size=#`
系统变量	`performance_schema_setup_actors_size`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`-1` （表示自动缩放;不指定此文字值）

setup_actors 表中的行数。

performance_schema_setup_objects_size

属性	值
命令行格式	`--performance-schema-setup-objects-size=#`
系统变量	`performance_schema_setup_objects_size`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`-1` （表示自动缩放;不指定此文字值）

setup_objects 表中的行数。

performance_schema_users_size

属性	值
命令行格式	`--performance-schema-users-size=#`
系统变量	`performance_schema_users_size`
范围	全球
动态	没有
`SET_VAR` 提示适用	没有
类型	整数
默认值	`-1` （表示自动缩放;不指定此文字值）
最低价值	`-1` （表示自动缩放;不指定此文字值）
最大价值	`1048576`

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

26.16性能模式状态变量

性能模式实现了几个状态变量，这些变量提供有关由于内存限制而无法加载或创建的检测的信息：

MySQL的> SHOW STATUS LIKE 'perf%';
+ ------------------------------------------- + ----- -  +
| Variable_name | 价值|
+ ------------------------------------------- + ----- -  +
| Performance_schema_accounts_lost | 0 |
| Performance_schema_cond_classes_lost | 0 |
| Performance_schema_cond_instances_lost | 0 |
| Performance_schema_file_classes_lost | 0 |
| Performance_schema_file_handles_lost | 0 |
| Performance_schema_file_instances_lost | 0 |
| Performance_schema_hosts_lost | 0 |
| Performance_schema_locker_lost | 0 |
| Performance_schema_mutex_classes_lost | 0 |
| Performance_schema_mutex_instances_lost | 0 |
| Performance_schema_rwlock_classes_lost | 0 |
| Performance_schema_rwlock_instances_lost | 0 |
| Performance_schema_socket_classes_lost | 0 |
| Performance_schema_socket_instances_lost | 0 |
| Performance_schema_stage_classes_lost | 0 |
| Performance_schema_statement_classes_lost | 0 |
| Performance_schema_table_handles_lost | 0 |
| Performance_schema_table_instances_lost | 0 |
| Performance_schema_thread_classes_lost | 0 |
| Performance_schema_thread_instances_lost | 0 |
| Performance_schema_users_lost | 0 |
+ ------------------------------------------- + ----- -  +

有关使用这些变量检查性能架构状态的信息，请参见第26.7节“性能架构状态监视” 。

Performance Schema状态变量具有以下含义：

Performance_schema_accounts_lost

行无法添加到 accounts 表中的次数，因为它已满。
Performance_schema_cond_classes_lost

有多少条件工具无法加载。
Performance_schema_cond_instances_lost

无法创建多少条件工具实例。
Performance_schema_digest_lost

无法在 events_statements_summary_by_digest 表中检测的摘要实例数。如果值 performance_schema_digests_size 太小，这可能是非零的。
Performance_schema_file_classes_lost

无法加载多少个文件工具。
Performance_schema_file_handles_lost

无法打开多少个文件工具实例。
Performance_schema_file_instances_lost

无法创建多少个文件工具实例。
Performance_schema_hosts_lost

行无法添加到 hosts 表中的次数，因为它已满。
Performance_schema_index_stat_lost

丢失统计信息的索引数。如果值 performance_schema_max_index_stat 太小，这可能是非零的。
Performance_schema_locker_lost

由于以下条件，有多少事件被 “ 丢失 ” 或未被记录：
- 事件是递归的（例如，等待A导致B等待，这导致C等待）。
- 嵌套事件堆栈的深度大于实现强加的限制。
Performance Schema记录的事件不是递归的，因此该变量应始终为0。
Performance_schema_memory_classes_lost

无法加载内存仪器的次数。
Performance_schema_metadata_lock_lost

无法在 metadata_locks 表中检测的元数据锁的数量。如果值 performance_schema_max_metadata_locks 太小，这可能是非零的。
Performance_schema_mutex_classes_lost

无法加载多少个互斥工具。
Performance_schema_mutex_instances_lost

无法创建多少个互斥工具实例。
Performance_schema_nested_statement_lost

丢失统计信息的存储程序语句数。如果值 performance_schema_max_statement_stack 太小，这可能是非零的。
Performance_schema_prepared_statements_lost

表中无法检测的预准备语句数 prepared_statements_instances 。如果值 performance_schema_max_prepared_statements_instances 太小，这可能是非零的。
Performance_schema_program_lost

丢失统计信息的存储程序数。如果值 performance_schema_max_program_instances 太小，这可能是非零的。
Performance_schema_rwlock_classes_lost

无法加载多少个rwlock乐器。
Performance_schema_rwlock_instances_lost

无法创建多少个rwlock仪器实例。
Performance_schema_session_connect_attrs_longest_seen

除了由性能模式对 performance_schema_session_connect_attrs_size 系统变量的值执行的连接属性大小限制检查之外，服务器还执行初步检查，对其将接受的连接属性数据的聚合大小施加64KB的限制。如果客户端尝试发送超过64KB的属性数据，则服务器拒绝连接。否则，服务器认为属性缓冲区有效并跟踪 Performance_schema_session_connect_attrs_longest_seen 状态变量中最长缓冲区的大小。如果此值大于 performance_schema_session_connect_attrs_size ，DBA可能希望增加后一个值，或者，或者，调查哪些客户端正在发送大量属性数据。

有关连接属性的更多信息，请参见第26.12.9节“性能架构连接属性表” 。
Performance_schema_session_connect_attrs_lost

发生连接属性截断的连接数。对于给定连接，如果客户端发送聚合大小大于 performance_schema_session_connect_attrs_size 系统变量值允许的保留存储的连接属性键值对，则性能模式将截断属性数据并递增 Performance_schema_session_connect_attrs_lost 。如果此值非零，您可能希望设置 performance_schema_session_connect_attrs_size 为更大的值。

有关连接属性的更多信息，请参见第26.12.9节“性能架构连接属性表” 。
Performance_schema_socket_classes_lost

无法装入多少个插座乐器。
Performance_schema_socket_instances_lost

无法创建多少个套接字工具实例。
Performance_schema_stage_classes_lost

无法装载多少台舞台乐器。
Performance_schema_statement_classes_lost

无法加载多少语句工具。
Performance_schema_table_handles_lost

无法打开多少个表工具实例。如果值 performance_schema_max_table_handles 太小，这可能是非零的。
Performance_schema_table_instances_lost

无法创建多少个表工具实例。
Performance_schema_table_lock_stat_lost

锁定统计信息丢失的表的数量。如果值 performance_schema_max_table_lock_stat 太小，这可能是非零的。
Performance_schema_thread_classes_lost

无法加载多少个线程乐器。
Performance_schema_thread_instances_lost

无法在 threads 表中检测的线程实例数。如果值 performance_schema_max_thread_instances 太小，这可能是非零的。
Performance_schema_users_lost

行无法添加到 users 表中的次数，因为它已满。

26.17性能模式内存分配模型

性能模式使用此内存分配模型：

可以在服务器启动时分配内存
可以在服务器操作期间分配额外内存
在服务器运行期间永远不要释放内存（尽管可能会被回收）
释放关机时使用的所有内存

结果是放松内存约束，以便可以使用较少的配置来使用性能模式，并减少内存占用，以便消耗与服务器负载一起扩展。使用的内存取决于实际看到的负载，而不是估计或明确配置的负载。

多个性能架构大小调整参数是自动调整的，除非您要对内存分配建立明确限制，否则无需显式配置：

performance_schema_accounts_size
performance_schema_hosts_size
performance_schema_max_cond_instances
performance_schema_max_file_instances
performance_schema_max_index_stat
performance_schema_max_metadata_locks
performance_schema_max_mutex_instances
performance_schema_max_prepared_statements_instances
performance_schema_max_program_instances
performance_schema_max_rwlock_instances
performance_schema_max_socket_instances
performance_schema_max_table_handles
performance_schema_max_table_instances
performance_schema_max_table_lock_stat
performance_schema_max_thread_instances
performance_schema_users_size

对于自动调整的参数，配置的工作方式如下：

将值设置为-1（默认值），参数将自动调整为：
- 最初相应的内部缓冲区为空，没有分配内存。
- 当性能模式收集数据时，内存将分配在相应的缓冲区中。缓冲区大小是无限制的，并且可能随负载而增长。
将值设置为0：
- 最初相应的内部缓冲区为空，没有分配内存。
将值设置为 N > 0：
- 最初相应的内部缓冲区为空，没有分配内存。
- 当性能模式收集数据时，内存将在相应的缓冲区中分配，直到达到缓冲区大小 N 。
- 缓冲区大小达到后 N ，不再分配内存。性能模式为此缓冲区收集的数据将丢失，并且任何相应的 “ 丢失实例 ” 计数器都会递增。

要查看性能模式使用了多少内存，请检查为此目的设计的仪器。性能模式在内部分配内存，并将每个缓冲区与专用仪器相关联，以便可以将内存消耗跟踪到各个缓冲区。使用前缀命名的仪器会 memory/performance_schema/ 显示为这些内部缓冲区分配的内存量。缓冲区对于服务器是全局的，因此仪器仅显示在 memory_summary_global_by_event_name 表中，而不显示在其他表中。 memory_summary_by_xxx_by_event_name

此查询显示与内存仪器关联的信息：

SELECT * FROM performance_schema.memory_summary_global_by_event_name
在哪里EVENT_NAME喜欢'memory / performance_schema /％';

26.18性能架构和插件

删除插件 UNINSTALL PLUGIN 不会影响已为该插件中的代码收集的信息。即使稍后卸载插件，在插件加载时执行代码所花费的时间仍然花费。相关的事件信息（包括聚合信息）在 performance_schema 数据库表中仍然可读。有关插件安装和删除的影响的其他信息，请参见第26.7节“性能架构状态监视” 。

监视插件代码的插件实现者应记录其工具特性，以使加载插件的人能够满足其要求。例如，第三方存储引擎应在其文档中包含引擎对互斥锁和其他工具所需的内存量。

26.19使用性能模式诊断问题

26.19.1使用性能模式进行查询分析
26.19.2获取父事件信息

性能模式是一种工具，通过采用实际测量而不是 “ 疯狂的猜测 ” 来帮助DBA进行性能调整。 “ 本节演示了为此目的使用性能模式的一些方法。这里的讨论依赖于事件过滤的使用，第26.4.2节“性能模式事件过滤”中对此进行了描述。

以下示例提供了一种可用于分析可重复问题的方法，例如调查性能瓶颈。首先，您应该有一个可重复的用例，其中性能被认为 “ 太慢 ” 并且需要优化，您应该启用所有仪器（根本没有预过滤）。

运行用例。
使用性能架构表，分析性能问题的根本原因。此分析将严重依赖于后过滤。
对于排除的问题区域，请禁用相应的仪器。例如，如果分析显示问题与特定存储引擎中的文件I / O无关，请禁用该引擎的文件I / O工具。然后截断历史记录和摘要表以删除以前收集的事件。
在步骤1重复该过程。

在每次迭代时，性能模式输出，特别是 events_waits_history_long 表格，将包含越来越少的 “ 噪音 ” 工具引起的，并且假设该表具有固定的大小，将包含越来越多的与分析问题相关的数据。手。

在每次迭代中，调查应该越来越接近问题的根本原因，因为 “ 信号/噪声 ” 比率将提高，使分析更容易。
一旦确定了性能瓶颈的根本原因，请采取适当的纠正措施，例如：
- 调整服务器参数（缓存大小，内存等）。
- 通过不同的方式调整查询，
- 调整数据库模式（表，索引等）。
- 调整代码（这仅适用于存储引擎或服务器开发人员）。
从第1步开始，查看更改对性能的影响。

在 mutex_instances.LOCKED_BY_THREAD_ID 与 rwlock_instances.WRITE_LOCKED_BY_THREAD_ID 列调查性能瓶颈或死锁非常重要的。这可以通过Performance Schema工具实现，如下所示：

假设线程1卡在等待互斥锁。
您可以确定线程正在等待的内容：
```
SELECT * FROM performance_schema.events_waits_current
在哪里THREAD_ID = thread_1;
```
说查询结果判断该线程正在等待互斥体，在发现 events_waits_current.OBJECT_INSTANCE_BEGIN 。
您可以确定哪个线程持有互斥锁A：
```
SELECT * FROM performance_schema.mutex_instances
WHERE OBJECT_INSTANCE_BEGIN = mutex_A;
```
假设查询结果标识它是线程2持有互斥锁A，如中所示 mutex_instances.LOCKED_BY_THREAD_ID 。

你可以看到2正在做什么线程：

SELECT * FROM performance_schema.events_waits_current
在哪里THREAD_ID = thread_2;

26.19.1使用性能模式进行查询分析

以下示例演示如何使用性能架构语句事件和阶段事件来检索与由 SHOW PROFILES 和 SHOW PROFILE 语句提供的性能分析信息相当的数据。

该 setup_actors 表可用于限制主机，用户或帐户对历史事件的收集，以减少运行时开销和历史表中收集的数据量。该示例的第一步显示如何将历史事件的集合限制为特定用户。

性能模式以皮秒（万亿分之一秒）显示事件定时器信息，以将定时数据标准化为标准单元。在以下示例中， TIMER_WAIT 值除以1000000000000以显示以秒为单位的数据。值也被截断为6位小数，以 SHOW PROFILES 与 SHOW PROFILE 语句相同的格式显示数据。

将历史事件的集合限制为将运行查询的用户。默认情况下， setup_actors 配置为允许所有前台线程的监视和历史事件收集：

MySQL的> SELECT * FROM performance_schema.setup_actors;
+ ------ + ------ + ------ + --------- + --------- +
| 主持人| 用户| 角色| 启用| 历史|
+ ------ + ------ + ------ + --------- + --------- +
| ％| ％| ％| 是的| 是的|
+ ------ + ------ + ------ + --------- + --------- +

更新 setup_actors 表中的默认行以禁用所有前台线程的历史事件收集和监视，并插入一个新行，以便为将运行查询的用户启用监视和历史事件收集：

MySQL的> UPDATE performance_schema.setup_actors
       SET ENABLED = 'NO', HISTORY = 'NO'
       WHERE HOST = '%' AND USER = '%';

MySQL的> INSERT INTO performance_schema.setup_actors
       (HOST,USER,ROLE,ENABLED,HISTORY)
       VALUES('localhost','test_user','%','YES','YES');

setup_actors 现在，表格中的数据应与以下内容类似：

MySQL的> SELECT * FROM performance_schema.setup_actors;
+ ----------- ----------- + + ------ + --------- + -------- -  +
| 主持人| 用户| 角色| 启用| 历史|
+ ----------- ----------- + + ------ + --------- + -------- -  +
| ％| ％| ％| 没有| 没有|
| localhost | test_user | ％| 是的| 是的|
+ ----------- ----------- + + ------ + --------- + -------- -  +

通过更新 setup_instruments 表确保启用语句和阶段检测。某些仪器可能已默认启用。

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

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

确保启用 events_statements_* 和 events_stages_* 消费者。某些消费者可能已默认启用。

MySQL的> UPDATE performance_schema.setup_consumers
       SET ENABLED = 'YES'
       WHERE NAME LIKE '%events_statements_%';

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

在您正在监视的用户帐户下，运行要分析的语句。例如：

MySQL的> SELECT * FROM employees.employees WHERE emp_no = 10001;
+ -------- + ------------ + ------------ + ----------- +  - ------ + ------------ +
| emp_no | birth_date | first_name | last_name | 性别| hire_date |
+ -------- + ------------ + ------------ + ----------- +  - ------ + ------------ +
| 10001 | 1953-09-02 | Georgi | Facello | M | 1986-06-26 |
+ -------- + ------------ + ------------ + ----------- +  - ------ + ------------ +

EVENT_ID 通过查询 events_statements_history_long 表来识别语句。此步骤类似于运行 SHOW PROFILES 以识别 Query_ID 。以下查询生成类似于的输出 SHOW PROFILES ：

MySQL的> SELECT EVENT_ID, TRUNCATE(TIMER_WAIT/1000000000000,6) as Duration, SQL_TEXT
       FROM performance_schema.events_statements_history_long WHERE SQL_TEXT like '%10001%';
+ ---------- + ---------- + --------------------------- ----------------------------- +
| event_id | 持续时间| sql_text |
+ ---------- + ---------- + --------------------------- ----------------------------- +
| 31 | 0.028310 | SELECT * FROM employees.employees WHERE emp_no = 10001 |
+ ---------- + ---------- + --------------------------- ----------------------------- +

查询 events_stages_history_long 表以检索语句的阶段事件。阶段与使用事件嵌套的语句相关联。每个阶段事件记录都有一个 NESTING_EVENT_ID 包含该列的列 EVENT_ID 父语句的列。

MySQL的> SELECT event_name AS Stage, TRUNCATE(TIMER_WAIT/1000000000000,6) AS Duration
       FROM performance_schema.events_stages_history_long WHERE NESTING_EVENT_ID=31;
+ -------------------------------- + ---------- +
| 舞台| 持续时间|
+ -------------------------------- + ---------- +
| stage / sql / starting | 0.000080 |
| stage / sql / checking permissions | 0.000005 |
| stage / sql / Opening tables | 0.027759 |
| stage / sql / init | 0.000052 |
| stage / sql /系统锁定| 0.000009 |
| stage / sql / optimize | 0.000006 |
| stage / sql / statistics | 0.000082 |
| stage / sql / prepare | 0.000008 |
| stage / sql / execution | 0.000000 |
| stage / sql /发送数据| 0.000017 |
| stage / sql / end | 0.000001 |
| stage / sql / query end | 0.000004 |
| stage / sql / closing tables | 0.000006 |
| stage / sql / freeing items | 0.000272 |
| stage / sql /清理| 0.000001 |
+ -------------------------------- + ---------- +

26.19.2获取父事件信息

该 data_locks 表显示了持有和请求的数据锁。此表的行有一 THREAD_ID 列指示拥有锁的会话的线程ID，以及一 EVENT_ID 列指示导致锁的Performance Schema事件。（ THREAD_ID ， EVENT_ID ）值的元组隐式标识其他Performance Schema表中的父事件：

表中的父等待事件 events_waits_xxx
表中的父级事件 events_stages_xxx
表中的父语句事件 events_statements_xxx
在父事务事件 events_transactions_current 表

要获取有关父事件的详细信息，请在相应的父事件表中使用相同名称的列连接 THREAD_ID 和 EVENT_ID 列。该关系基于嵌套集数据模型，因此连接具有多个子句。给定的父表和子表分别由 parent 和表示， child 如下所示：

哪里
  parent.THREAD_ID = child.THREAD_ID / * 1 * /
  AND parent.EVENT_ID <child.EVENT_ID / * 2 * /
  AND（
    child.EVENT_ID <= parent.END_EVENT_ID / * 3a * /
    OR parent.END_EVENT_ID IS NULL / * 3b * /
  ）

加入的条件是：

父事件和子事件位于同一个线程中。
子事件在父事件之后开始，因此其 EVENT_ID 值大于父事件的值。
父事件已完成或仍在运行。

要查找锁定信息， data_locks 是包含子事件的表。

该 data_locks 表仅显示现有锁，因此这些注意事项适用于哪个表包含父事件：

对于交易，唯一的选择是 events_transactions_current 。如果事务已完成，则它可能位于事务历史记录表中，但锁已经消失。
对于语句，这一切都取决于采用锁定的语句是否是已经完成（使用 events_statements_history ）或语句仍在运行（使用 events_statements_current ）的事务中的语句。
对于阶段，逻辑类似于语句的逻辑; 用 events_stages_history 或 events_stages_current 。
对于等待，逻辑类似于语句的逻辑; 用 events_waits_history 或 events_waits_current 。但是，记录了如此多的等待，导致锁定的等待很可能已经从历史表中消失。

等待，阶段和语句事件从历史记录中快速消失。如果很久以前执行的语句发生了锁定但处于仍然打开的事务中，则可能无法找到该语句，但可以找到该事务。

这就是嵌套集数据模型更适合定位父事件的原因。当中间节点已从历史表中消失时，父/子关系中的以下链接（数据锁 - >父等待 - >父级 - >父事务）不能正常工作。

以下方案说明了如何查找已执行锁定的语句的父事务：

会议A：

[1] START TRANSACTION;
[2] SELECT * FROM t1 WHERE pk = 1;
[3]选择'你好，世界';

会议B：

选择 ...
FROM performance_schema.events_transactions_current AS parent
  INNER JOIN performance_schema.data_locks AS child
哪里
  parent.THREAD_ID = child.THREAD_ID
  AND parent.EVENT_ID <child.EVENT_ID
  AND（
    child.EVENT_ID <= parent.END_EVENT_ID
    或者父.END_EVENT_ID是NULL
  ）;

会话B的查询应该将语句[2]显示为拥有记录上的数据锁 pk=1 。

如果会话A执行更多语句，[2]将从历史表中淡出。

查询应显示在[1]中启动的事务，无论执行了多少语句，阶段或等待。

要查看更多数据，您还可以使用除事务之外的表，假设服务器中没有运行其他查询（以便保留历史记录）。 events_xxx_history_long

上一页	向上	下一个
第25章INFORMATION_SCHEMA表	家	第27章MySQL sys Schema