MySQL8-中文参考-四十八-

MySQL8 中文参考（四十八）

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

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

29.12.2.2 The setup_consumers Table

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

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

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

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

setup_consumers 表具有以下列：

NAME

消费者名称。
ENABLED

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

setup_consumers 表具有以下索引：

主键为 (NAME)

不允许对 setup_consumers 表执行 TRUNCATE TABLE。

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

29.12.2.3 setup_instruments 表

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

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

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

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

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

setup_instruments 表包含以下列：

NAME

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

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

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

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

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

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

仪器属性。此列使用SET数据类型，因此每个仪器可以设置以下列表中的多个标志：
- controlled_by_default: 默认情况下为该仪器收集内存。
- global_statistics: 该仪器仅生成全局摘要。较细级别的摘要不可用，例如每个线程、账户、用户或主机。例如，大多数内存仪器仅生成全局摘要。
- mutable: 该仪器可以“变异”为更具体的仪器。此属性仅适用于语句仪器。
- progress: 该仪器能够报告进度数据。此属性仅适用于阶段仪器。
- singleton: 该仪器具有单个实例。例如，服务器中的大多数全局互斥锁都是单例的，因此相应的仪器也是如此。
- user: 该仪器与用户工作量直接相关（与系统工作量相反）。其中一个这样的仪器是wait/io/socket/sql/client_connection。
FLAGS

仪器的内存是否受控。

该标志仅支持非全局内存仪器，并且可以设置或取消设置。例如：
```
 SQL> UPDATE PERFORMANCE_SCHEMA.SETUP_INTRUMENTS SET FLAGS="controlled" WHERE NAME='memory/sql/NET::buff';
```
注意

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

仪器的不稳定性。不稳定性值从低到高。这些值对应于mysql/psi/psi_base.h头文件中定义的PSI_VOLATILITY_*xxx*常量：
```
#define PSI_VOLATILITY_UNKNOWN 0
#define PSI_VOLATILITY_PERMANENT 1
#define PSI_VOLATILITY_PROVISIONING 2
#define PSI_VOLATILITY_DDL 3
#define PSI_VOLATILITY_CACHE 4
#define PSI_VOLATILITY_SESSION 5
#define PSI_VOLATILITY_TRANSACTION 6
#define PSI_VOLATILITY_QUERY 7
#define PSI_VOLATILITY_INTRA_QUERY 8
```
VOLATILITY列纯粹是信息性的，为用户（以及性能模式代码）提供有关仪器运行时行为的一些提示。

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

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

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

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

另一个不稳定性的方面涉及ENABLED列的更新实际上是否产生某种效果：
- 对ENABLED的更新会影响随后创建的被仪器化对象，但不会影响已经创建的仪器。
- 更“不稳定”的仪器会更快地使用setup_instruments表中的新设置。
例如，此语句不会影响现有会话的LOCK_query_plan互斥体，但会影响在更新后创建的新会话：
```
UPDATE performance_schema.setup_instruments
SET ENABLED=*value*
WHERE NAME = 'wait/synch/mutex/sql/THD::LOCK_query_plan';
```
这个语句实际上根本没有任何效果：
```
UPDATE performance_schema.setup_instruments
SET ENABLED=*value*
WHERE NAME = 'wait/synch/mutex/pfs/LOCK_pfs_share_list';
```
这个互斥体是永久的，在更新执行之前已经创建。互斥体永远不会再次创建，因此setup_instruments中的ENABLED值永远不会被使用。要启用或禁用此互斥体，请改用mutex_instances表。
DOCUMENTATION

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

setup_instruments表具有以下索引：

主键为(NAME)

不允许对setup_instruments表进行TRUNCATE TABLE。

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

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

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

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

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

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

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

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

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

29.12.2.4 `setup_objects`表

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

初始的setup_objects内容如下：

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

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

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

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

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

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

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

setup_objects表具有以下列：

OBJECT_TYPE

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

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

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

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

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

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

setup_objects表具有以下索引：

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

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

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

29.12.2.5 The setup_threads Table

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

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

setup_threads 表具有以下列：

NAME

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

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

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

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

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

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

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

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

setup_threads表具有以下索引：

主键为(NAME)

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

29.12.3 性能模式实例表

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

29.12.3.1 条件实例表

29.12.3.2 文件实例表

29.12.3.3 互斥实例表

29.12.3.4 读写锁实例表

29.12.3.5 套接字实例表

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

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

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

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

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

29.12.3.1 cond_instances 表

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

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

cond_instances 表具有以下列：

NAME

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

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

cond_instances 表具有以下索引：

在 (OBJECT_INSTANCE_BEGIN) 上的主键
在 (NAME) 上的索引

TRUNCATE TABLE 不允许用于 cond_instances 表。

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

29.12.3.2 文件实例表

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

file_instances 表包含以下列：

FILE_NAME

文件名。
EVENT_NAME

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

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

file_instances 表包含以下索引：

主键 (FILE_NAME)
(EVENT_NAME) 上的索引

TRUNCATE TABLE 不允许用于 file_instances 表。

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

29.12.3.3 mutex_instances 表

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

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

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

mutex_instances 表具有以下列：

NAME

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

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

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

mutex_instances 表具有以下索引：

主键为 (OBJECT_INSTANCE_BEGIN)
索引为 (NAME)
索引为 (LOCKED_BY_THREAD_ID)

TRUNCATE TABLE 不允许用于 mutex_instances 表。

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

setup_instruments 表列出了仪器点的名称，带有前缀 wait/synch/mutex/。
当一些代码创建一个互斥锁时，会向 mutex_instances 表添加一行。OBJECT_INSTANCE_BEGIN 列是一个唯一标识互斥锁的属性。
当一个线程尝试锁定一个互斥锁时，events_waits_current 表显示了一个针对该线程的行，指示它正在等待一个互斥锁（在 EVENT_NAME 列中），并指示正在等待的互斥锁是哪个（在 OBJECT_INSTANCE_BEGIN 列中）。
当一个线程成功锁定一个互斥锁时：
- events_waits_current显示互斥锁上的等待已完成（在TIMER_END和TIMER_WAIT列中）
- 完成的等待事件被添加到events_waits_history和events_waits_history_long表中
- mutex_instances显示该互斥锁现在由该线程拥有（在THREAD_ID列中）。
当线程解锁互斥锁时，mutex_instances显示该互斥锁现在没有所有者（THREAD_ID列为NULL）。
当互斥锁对象被销毁时，相应的行从mutex_instances中移除。

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

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

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

29.12.3.4 `rwlock_instances`表

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

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

rwlock_instances表具有以下列：

NAME

与锁相关联的工具名称。
OBJECT_INSTANCE_BEGIN

工具锁在内存中的地址。
WRITE_LOCKED_BY_THREAD_ID

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

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

rwlock_instances表具有以下索引：

主键为(OBJECT_INSTANCE_BEGIN)
索引为(NAME)
索引为(WRITE_LOCKED_BY_THREAD_ID)

TRUNCATE TABLE不允许用于rwlock_instances表。

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

events_waits_current，查看线程正在等待哪个rwlock
rwlock_instances，查看当前拥有rwlock的其他线程。

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

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

29.12.3.5 The socket_instances Table

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

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

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

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

socket_instances表具有以下列：

EVENT_NAME

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

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

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

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

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

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

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

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

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

socket_instances 表具有以下索引：

在 (OBJECT_INSTANCE_BEGIN) 上建立主键
在 (THREAD_ID) 上建立索引
在 (SOCKET_ID) 上建立索引
在 (IP, PORT) 上建立索引

不允许对 socket_instances 表使用 TRUNCATE TABLE。

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

对于 Unix 域监听器套接字 (server_unix_socket)，端口为 0，IP 为 ''。
对通过 Unix 域监听器 (client_connection) 的客户端连接，端口为 0，IP 为 ''。
对于 TCP/IP 服务器监听器套接字 (server_tcpip_socket)，端口始终是主端口（例如，3306），IP 始终是 0.0.0.0。
对通过 TCP/IP 监听器 (client_connection) 的客户端连接，端口是服务器分配的任何端口，但绝不是 0。IP 是发起主机的 IP (127.0.0.1 或 ::1 为本地主机)

29.12.4 性能模式等待事件表

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

29.12.4.1 events_waits_current 表

29.12.4.2 events_waits_history 表

29.12.4.3 events_waits_history_long 表

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

这些表存储等待事件：

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

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

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

配置等待事件收集

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

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

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

mysql> SELECT NAME, ENABLED, TIMED
       FROM performance_schema.setup_instruments
       WHERE NAME LIKE 'wait/io/file/innodb%';
+-------------------------------------------------+---------+-------+
| NAME                                            | ENABLED | TIMED |
+-------------------------------------------------+---------+-------+
| wait/io/file/innodb/innodb_tablespace_open_file | YES     | YES   |
| wait/io/file/innodb/innodb_data_file            | YES     | YES   |
| wait/io/file/innodb/innodb_log_file             | YES     | YES   |
| wait/io/file/innodb/innodb_temp_file            | YES     | YES   |
| wait/io/file/innodb/innodb_arch_file            | YES     | YES   |
| wait/io/file/innodb/innodb_clone_file           | YES     | YES   |
+-------------------------------------------------+---------+-------+
mysql> SELECT NAME, ENABLED, TIMED
       FROM performance_schema.setup_instruments
       WHERE NAME LIKE 'wait/io/socket/%';
+----------------------------------------+---------+-------+
| NAME                                   | ENABLED | TIMED |
+----------------------------------------+---------+-------+
| wait/io/socket/sql/server_tcpip_socket | NO      | NO    |
| wait/io/socket/sql/server_unix_socket  | NO      | NO    |
| wait/io/socket/sql/client_connection   | NO      | NO    |
+----------------------------------------+---------+-------+

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

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

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

启用：

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

禁用：

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

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

启用：

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

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

禁用：

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

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

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

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

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

29.12.4.1 events_waits_current 表

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

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

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

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

events_waits_current 表具有以下列：

THREAD_ID, EVENT_ID

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

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

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

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

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

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

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

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

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

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

对于一个同步对象（cond，mutex，rwlock）：
- OBJECT_SCHEMA，OBJECT_NAME和OBJECT_TYPE为NULL。
- OBJECT_INSTANCE_BEGIN是内存中同步对象的地址。
对于文件 I/O 对象：
- OBJECT_SCHEMA为NULL。
- OBJECT_NAME是文件名。
- OBJECT_TYPE为FILE。
- OBJECT_INSTANCE_BEGIN是内存中的地址。
对于套接字对象：
- OBJECT_NAME是套接字的IP:PORT值。
- OBJECT_INSTANCE_BEGIN是内存中的地址。
对于表 I/O 对象：
- OBJECT_SCHEMA是包含表的模式的名称。
- OBJECT_NAME是表名。
- 对于持久基表的OBJECT_TYPE为TABLE或临时表的OBJECT_TYPE为TEMPORARY TABLE。
- OBJECT_INSTANCE_BEGIN是内存中的地址。
OBJECT_INSTANCE_BEGIN值本身没有意义，除非不同的值表示不同的对象。OBJECT_INSTANCE_BEGIN可用于调试。例如，可以与GROUP BY OBJECT_INSTANCE_BEGIN一起使用，以查看对 1,000 个互斥锁（保护 1,000 个页面或数据块）的负载是否均匀分布或只是击中了一些瓶颈。如果在日志文件或其他调试或性能工具中看到相同的对象地址，这可以帮助您与其他信息源进行关联。
INDEX_NAME

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

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

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

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

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

MySQL 使用嵌套循环实现连接。性能模式仪表化的工作是为连接中的每个表提供行数和累积执行时间。假设执行以下形式的连接查询，使用表连接顺序为t1，t2，t3：
```
SELECT ... FROM t1 JOIN t2 ON ... JOIN t3 ON ...
```
表“扇出”是在连接处理过程中添加表后行数增加或减少的情况。如果表t3的扇出大于 1，则大部分行提取操作是针对该表的。假设连接从t1提取 10 行，从t2每行t1提取 20 行，从t3每行t2提取 30 行。使用单行报告，总仪表化操作数为：
```
10 + (10 * 20) + (10 * 20 * 30) = 6210
```
通过按扫描（即从t1和t2的唯一组合）对其进行聚合，可以显著减少仪表化操作的数量。使用批量 I/O 报告，性能模式为内部表t3的每次扫描产生一个事件，而不是每行，仪表化行操作数量减少为：
```
10 + (10 * 20) + (10 * 20) = 410
```
这是 93%的减少，说明批量报告策略通过减少报告调用的数量显著减少了表 I/O 的性能模式开销。权衡是事件定时的准确性较低。与每行报告中的单行操作的时间不同，批量 I/O 的时间包括用于操作的时间，例如连接缓冲，聚合和将行返回给客户端的时间。

要发生批量 I/O 报告，必须满足以下条件：
- 查询执行访问查询块的最内部表（对于单表查询，该表计为最内部）
- 查询执行不会从表中请求单行（因此，例如，eq_ref访问会阻止批量报告的使用）
- 查询执行不会评估包含表访问的子查询的表
FLAGS

保留供将来使用。

events_waits_current表具有以下索引：

主键为（THREAD_ID，EVENT_ID）

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

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

29.12.4.2 事件等待历史表

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

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

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

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

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

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

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

29.12.4.3 events_waits_history_long 表

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

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

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

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

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

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

29.12.5 性能模式阶段事件表

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

29.12.5.1 events_stages_current 表

29.12.5.2 events_stages_history 表

29.12.5.3 events_stages_history_long 表

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

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

这些表存储阶段事件：

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

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

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

配置阶段事件收集
阶段事件进度信息

配置阶段事件收集

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

setup_instruments 包含以stage开头的仪器。使用这些仪器来启用或禁用单个阶段事件类的收集。
setup_consumers表包含与当前和历史阶段事件表名称对应的消费者值。使用这些消费者来过滤阶段事件的收集。

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

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

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

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

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

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

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

启用：

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

禁用：

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

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

启用：

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

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

禁用：

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

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

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

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

阶段事件进度信息

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

WORK_COMPLETED：阶段完成的工作单元数量
WORK_ESTIMATED：阶段预期的工作单元数量

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

“工作单元”是一个整数度量，随着执行时间的增加而增加，例如处理的字节数、行数、文件数或表数。对于特定仪器的“工作单元”的定义由提供数据的仪器代码确定。
WORK_COMPLETED值可以根据被仪器化的代码一次或多次增加一个单位。
WORK_ESTIMATED值可以在阶段期间更改，具体取决于被仪器化的代码。

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

无进度仪器

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

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

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

WORK_COMPLETED和WORK_ESTIMATED列都是有意义的。

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

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

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

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

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

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

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

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

29.12.5.1 events_stages_current 表

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

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

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

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

events_stages_current表具有以下列：

THREAD_ID，EVENT_ID

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

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

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

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

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

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

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

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

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

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

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

events_stages_current表具有以下索引：

主键为(THREAD_ID, EVENT_ID)

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

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

29.12.5.2 `events_stages_history` 表

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

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

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

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

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

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

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

29.12.5.3 events_stages_history_long 表

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

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

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

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

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

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

29.12.6 性能模式语句事件表

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

29.12.6.1 events_statements_current 表

29.12.6.2 events_statements_history 表

29.12.6.3 events_statements_history_long 表

29.12.6.4 prepared_statements_instances 表

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

这些表存储语句事件：

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

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

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

配置语句事件收集
语句监控

配置语句事件收集

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

setup_instruments表包含以statement开头的工具名称。使用这些工具来启用或禁用单个语句事件类的收集。
setup_consumers表包含与当前和历史语句事件表名称以及语句摘要消费者对应的消费者值。使用这些消费者来过滤语句事件和语句摘要的收集。

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

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

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

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

启用：

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

禁用：

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

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

启用：

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

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

禁用：

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

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

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

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

语句监控

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

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

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

服务器命令对应于mysql_com.h头文件中定义的COM_*xxx* codes，并在sql/sql_parse.cc中进行处理。例如COM_PING和COM_QUIT。命令的工具具有以statement/com开头的名称，例如statement/com/Ping和statement/com/Quit。
SQL 语句以文本形式表示，例如DELETE FROM t1或SELECT * FROM t2。SQL 语句的仪器名称以statement/sql开头，例如statement/sql/delete和statement/sql/select。

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

statement/com/Error用于处理服务器接收到的超出带外的消息。它可用于检测服务器不理解的客户端发送的命令。这可能有助于识别配置错误或使用比服务器更近期的 MySQL 版本的客户端，或者试图攻击服务器的客户端。
statement/sql/error用于处理无法解析的 SQL 语句。它可用于检测客户端发送的格式错误的查询。无法解析的查询与解析但在执行过程中由于错误而失败的查询不同。例如，SELECT * FROM是格式错误的，将使用statement/sql/error仪器。相比之下，SELECT *解析但由于No tables used错误而失败。在这种情况下，将使用statement/sql/select，并且语句事件包含信息以指示错误的性质。

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

作为客户端发送的命令或语句请求，该请求以数据包形式发送
作为从副本的中继日志中读取的语句字符串
作为事件来自事件调度程序

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

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

当服务器在套接字级别检测到新数据包时，将以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/*工具。这通常不是问题，因为所有语句工具默认都是启用的。然而，选择性启用或禁用语句工具的应用程序必须考虑到禁用抽象工具也会禁用对单个语句工具的统计信息收集。例如，要收集INSERT语句的统计信息，必须启用statement/sql/insert，还必须启用statement/abstract/new_packet和statement/abstract/Query。同样，要对复制语句进行检测，必须启用statement/abstract/relay_log。

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

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

29.12.6.1 events_statements_current 表

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

在包含语句事件行的表中，events_statements_current是最基本的。其他包含语句事件行的表从当前事件逻辑派生。例如，events_statements_history和events_statements_history_long表是最近已结束的语句事件的集合，每个线程最多一定数量的行，并在全局范围内跨所有线程。

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

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

events_statements_current表具有以下列：

THREAD_ID，EVENT_ID

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

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

从中收集事件的仪器的名称。这是来自setup_instruments表的NAME值。仪器名称可能有多个部分并形成层次结构，如第 29.6 节，“性能模式仪器命名约定”中所讨论的那样。

对于 SQL 语句，EVENT_NAME值最初为statement/com/Query，直到语句被解析，然后根据需要更改为更合适的值，如第 29.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。

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

等待表锁的时间。此值以微秒计算，但为了与其他性能模式计时器更容易比较，已标准化为皮秒。
SQL_TEXT

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

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

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

标准化的语句摘要文本，或者如果statements_digest消费者为no，则为NULL。有关语句摘要的更多信息，请参见第 29.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。如果 SQLSTATE 值为其他值，则值为 1。
WARNINGS

来自语句诊断区域的警告数量。
ROWS_AFFECTED

语句影响的行数。有关“受影响”的含义，请参阅 mysql_affected_rows()。
ROWS_SENT

语句返回的行数。
ROWS_EXAMINED

服务器层检查的行数（不包括存储引擎内部处理）。
CREATED_TMP_DISK_TABLES

类似于Created_tmp_disk_tables状态变量，但特定于语句。
CREATED_TMP_TABLES

类似于Created_tmp_tables状态变量，但特定于语句。
SELECT_FULL_JOIN

类似于Select_full_join状态变量，但特定于语句。
SELECT_FULL_RANGE_JOIN

类似于Select_full_range_join状态变量，但特定于语句。
SELECT_RANGE

类似于Select_range状态变量，但特定于语句。
SELECT_RANGE_CHECK

类似于Select_range_check状态变量，但特定于语句。
SELECT_SCAN

类似于Select_scan状态变量，但特定于语句。
SORT_MERGE_PASSES

类似于 Sort_merge_passes 状态变量，但特定于语句。
SORT_RANGE

类似于 Sort_range 状态变量，但特定于语句。
SORT_ROWS

类似于 Sort_rows 状态变量，但特定于语句。
SORT_SCAN

类似于 Sort_scan 状态变量，但特定于语句。
NO_INDEX_USED

如果语句执行了不使用索引的表扫描，则为 1，否则为 0。
NO_GOOD_INDEX_USED

如果服务器找不到适合语句的好索引，则为 1，否则为 0。有关更多信息，请参见第 10.8.2 节，“EXPLAIN 输出格式” 中 EXPLAIN 输出的 Range checked for each record 值的 Extra 列描述。

NESTING_EVENT_ID、NESTING_EVENT_TYPE、NESTING_EVENT_LEVEL

这三列与其他列一起用于为顶层（非嵌套）语句和嵌套语句（在存储过程中执行）提供以下信息。

对于顶层语句：

OBJECT_TYPE = NULL
OBJECT_SCHEMA = NULL
OBJECT_NAME = NULL
NESTING_EVENT_ID = the parent transaction EVENT_ID
NESTING_EVENT_TYPE = 'TRANSACTION'
NESTING_LEVEL = 0

对于嵌套语句：

OBJECT_TYPE = the parent statement object type
OBJECT_SCHEMA = the parent statement object schema
OBJECT_NAME = the parent statement object name
NESTING_EVENT_ID = the parent statement EVENT_ID
NESTING_EVENT_TYPE = 'STATEMENT'
NESTING_LEVEL = the parent statement NESTING_LEVEL plus one

STATEMENT_ID

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

当前线程在 CPU 上花费的时间，以皮秒表示。该列在 MySQL 8.0.28 中添加。
MAX_CONTROLLED_MEMORY

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

该列在 MySQL 8.0.31 中添加。
MAX_TOTAL_MEMORY

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

该列在 MySQL 8.0.31 中添加。
EXECUTION_ENGINE

查询执行引擎。该值为 PRIMARY 或 SECONDARY。用于 MySQL HeatWave 服务和 HeatWave，其中 PRIMARY 引擎为 InnoDB，SECONDARY 引擎为 HeatWave（RAPID）。对于 MySQL Community Edition Server、MySQL Enterprise Edition Server（本地）和没有 HeatWave 的 MySQL HeatWave 服务，该值始终为 PRIMARY。该列在 MySQL 8.0.29 中添加。

events_statements_current 表具有以下索引：

主键为 (THREAD_ID, EVENT_ID)。

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

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

29.12.6.2 events_statements_history 表

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

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

events_statements_history表具有与events_statements_current相同的列和索引。请参阅 Section 29.12.6.1, “events_statements_current 表”。

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

要了解三个events_statements_*xxx*事件表之间的关系，请参阅 Section 29.9, “当前和历史事件的性能模式表”。

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

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

29.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 表具有相同的列。请参见第 29.12.6.1 节，“events_statements_current 表”。与 events_statements_current 不同，events_statements_history_long 没有索引。

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

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

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

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

29.12.6.4 prepared_statements_instances 表

Performance Schema 为准备语句提供了仪表化，有两种协议：

二进制协议。通过 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

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

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：
```
PREPARE stmt FROM 'SELECT 1';
```
SQL_TEXT

带有?占位符标记的预处理语句文本。
OWNER_THREAD_ID，OWNER_EVENT_ID

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

对于由客户端会话创建的预处理语句，这些列为NULL。对于由存储过程创建的预处理语句，这些列指向存储过程。一个典型的用户错误是忘记释放预处理语句。这些列可用于查找泄漏预处理语句的存储过程：
```
SELECT
  OWNER_OBJECT_TYPE, OWNER_OBJECT_SCHEMA, OWNER_OBJECT_NAME,
  STATEMENT_NAME, SQL_TEXT
FROM performance_schema.prepared_statements_instances
WHERE OWNER_OBJECT_TYPE IS NOT NULL;
```
查询执行引擎。其值为PRIMARY或SECONDARY。用于 MySQL HeatWave 服务和 HeatWave，其中PRIMARY引擎为InnoDB，SECONDARY引擎为 HeatWave（RAPID）。对于 MySQL 社区版服务器、MySQL 企业版服务器（本地）和没有 HeatWave 的 MySQL HeatWave 服务，该值始终为PRIMARY。此列在 MySQL 8.0.29 中添加。
TIMER_PREPARE

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

语句在内部重新准备的次数（参见第 10.10.3 节，“准备语句和存储程序的缓存”）。重新准备的时间统计数据不可用，因为它被计算为语句执行的一部分，而不是作为单独的操作。
COUNT_EXECUTE, SUM_TIMER_EXECUTE, MIN_TIMER_EXECUTE, AVG_TIMER_EXECUTE, MAX_TIMER_EXECUTE

准备语句执行的聚合统计数据。
SUM_*xxx*

剩余的SUM_*xxx*列与语句摘要表相同（参见第 29.12.20.3 节，“语句摘要表”）。
MAX_CONTROLLED_MEMORY

报告了执行期间准备语句使用的受控内存的最大量。

此列在 MySQL 8.0.31 中添加。
MAX_TOTAL_MEMORY

报告了执行期间准备语句使用的最大内存量。

此列在 MySQL 8.0.31 中添加。

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表的统计列。

29.12.7 性能模式事务表

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

29.12.7.1 事件 _ 事务 _ 当前表

29.12.7.2 事件 _ 事务 _ 历史表

29.12.7.3 事件 _ 事务 _ 历史 _ 长表

性能模式对事务进行仪表化。在事件层次结构中，等待事件嵌套在阶段事件中，阶段事件嵌套在语句事件中，语句事件嵌套在事务事件中。

这些表存储事务事件：

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

以下部分描述了事务事件表。还有汇总表汇总有关事务事件的信息；参见第 29.12.20.5 节，“事务汇总表”。

有关三个事务事件表之间关系的更多信息，请参见第 29.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        | ENABLED | TIMED |
+-------------+---------+-------+
| transaction | YES     | YES   |
+-------------+---------+-------+
mysql> SELECT *
       FROM performance_schema.setup_consumers
       WHERE NAME LIKE 'events_transactions%';
+----------------------------------+---------+
| NAME                             | ENABLED |
+----------------------------------+---------+
| events_transactions_current      | YES     |
| events_transactions_history      | YES     |
| events_transactions_history_long | NO      |
+----------------------------------+---------+

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

启用：

[mysqld]
performance-schema-instrument='transaction=ON'
performance-schema-consumer-events-transactions-current=ON
performance-schema-consumer-events-transactions-history=ON
performance-schema-consumer-events-transactions-history-long=ON

禁用：

[mysqld]
performance-schema-instrument='transaction=OFF'
performance-schema-consumer-events-transactions-current=OFF
performance-schema-consumer-events-transactions-history=OFF
performance-schema-consumer-events-transactions-history-long=OFF

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

启用：

UPDATE performance_schema.setup_instruments
SET ENABLED = 'YES', TIMED = 'YES'
WHERE NAME = 'transaction';

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

禁用：

UPDATE performance_schema.setup_instruments
SET ENABLED = 'NO', TIMED = 'NO'
WHERE NAME = 'transaction';

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

为了仅收集特定事务事件表的事务事件，启用transaction工具，但仅启用与所需表对应的事务消费者。

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

事务边界

在 MySQL 服务器中，事务明确以以下语句开始：

START TRANSACTION | BEGIN | XA START | XA BEGIN

事务也会隐式开始。例如，当启用autocommit系统变量时，每个语句的开始都会启动一个新事务。

当禁用autocommit时，提交事务后的第一条语句标志着新事务的开始。直到提交为止，后续语句都属于该事务。

事务明确以以下语句结束：

COMMIT | ROLLBACK | XA COMMIT | XA ROLLBACK

事务也会隐式结束，通过 DDL 语句、锁定语句和服务器管理语句的执行。

在下面的讨论中，对START TRANSACTION的引用也适用于BEGIN，XA START和XA BEGIN。同样，对COMMIT和ROLLBACK的引用也适用于XA COMMIT和XA ROLLBACK。

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

对于显式启动的事务，事务事件在处理START TRANSACTION语句期间开始。
对于隐式启动的事务，事务事件从上一个事务结束后第一次使用事务引擎的语句开始。
对于任何事务，无论是显式还是隐式结束，事务事件在服务器在处理COMMIT或ROLLBACK期间转换出活动事务状态时结束。

这种方法有微妙的含义：

性能模式中的事务事件并不完全包括与相应的START TRANSACTION，COMMIT或ROLLBACK语句相关联的语句事件。事务事件与这些语句之间存在微小的时间重叠。
使用非事务引擎的语句对连接的事务状态没有影响。对于隐式事务，事务事件从第一个使用事务引擎的语句开始。这意味着仅在非事务表上操作的语句将被忽略，即使在START TRANSACTION之后也是如此。

举例说明，考虑以下情景：

1\. SET autocommit = OFF;
2\. CREATE TABLE t1 (a INT) ENGINE = InnoDB;
3\. START TRANSACTION;                       -- Transaction 1 START
4\. INSERT INTO t1 VALUES (1), (2), (3);
5\. CREATE TABLE t2 (a INT) ENGINE = MyISAM; -- Transaction 1 COMMIT
                                            -- (implicit; DDL forces commit)
6\. INSERT INTO t2 VALUES (1), (2), (3);     -- Update nontransactional table
7\. UPDATE t2 SET a = a + 1;                 -- ... and again
8\. INSERT INTO t1 VALUES (4), (5), (6);     -- Write to transactional table
                                            -- Transaction 2 START (implicit)
9\. COMMIT;                                  -- Transaction 2 COMMIT

从服务器的角度看，事务 1 在表t2创建时结束。事务 2 直到访问事务表时才开始，尽管在此期间更新了非事务表。

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

事务仪表化

三个属性定义了事务：

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

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

要选择性地检查事务历史记录，请使用事务事件表中的属性列：ACCESS_MODE，ISOLATION_LEVEL和AUTOCOMMIT。

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

事务和嵌套事件

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

一般来说，事务是在事务期间启动的所有事件的最高级父级，包括明确结束事务的语句，比如COMMIT和ROLLBACK。异常情况是隐式结束事务的语句，比如 DDL 语句，在这种情况下，必须在执行新语句之前提交当前事务。

事务和存储程序

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

存储过程

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

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

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

存储函数受限于不引起显式或隐式提交或回滚。存储函数事件可以存在于父事务事件中。
触发器

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

触发器不能发出导致事务显式或隐式提交或回滚的语句。
计划事件

计划事件体中语句的执行发生在一个新连接中。计划事件嵌套在父事务中不适用。

事务和保存点

保存点语句被记录为单独的语句事件。事务事件包括在事务期间发出的SAVEPOINT、ROLLBACK TO SAVEPOINT和RELEASE SAVEPOINT语句的单独计数器。

事务和错误

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

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

29.12.7.1 事件事务当前表

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

mysql> SELECT *
       FROM performance_schema.events_transactions_current LIMIT 1\G
*************************** 1\. row ***************************
                      THREAD_ID: 26
                       EVENT_ID: 7
                   END_EVENT_ID: NULL
                     EVENT_NAME: transaction
                          STATE: ACTIVE
                         TRX_ID: NULL
                           GTID: 3E11FA47-71CA-11E1-9E33-C80AA9429562:56
                            XID: NULL
                       XA_STATE: NULL
                         SOURCE: transaction.cc:150
                    TIMER_START: 420833537900000
                      TIMER_END: NULL
                     TIMER_WAIT: NULL
                    ACCESS_MODE: READ WRITE
                ISOLATION_LEVEL: REPEATABLE READ
                     AUTOCOMMIT: NO
           NUMBER_OF_SAVEPOINTS: 0
NUMBER_OF_ROLLBACK_TO_SAVEPOINT: 0
    NUMBER_OF_RELEASE_SAVEPOINT: 0
          OBJECT_INSTANCE_BEGIN: NULL
               NESTING_EVENT_ID: 6
             NESTING_EVENT_TYPE: STATEMENT

包含事务事件行的表中，events_transactions_current 是最基础的。其他包含事务事件行的表从当前事件逻辑派生而来。例如，events_transactions_history 和 events_transactions_history_long 表分别是最近已结束的事务事件的集合，每个线程最多一定数量的行和全局跨所有线程。

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

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

events_transactions_current 表具有以下列：

THREAD_ID，EVENT_ID

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

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

事件收集的仪器名称。这是来自 setup_instruments 表的 NAME 值。仪器名称可能有多个部分并形成层次结构，如第 29.6 节“性能模式仪器命名约定” 中讨论的那样。
STATE

当前事务状态。其值为ACTIVE（在START TRANSACTION或BEGIN之后）、COMMITTED（在COMMIT之后）或ROLLED BACK（在ROLLBACK之后）。
TRX_ID

未使用。
GTID

GTID 列包含gtid_next的值，可以是ANONYMOUS、AUTOMATIC或使用格式UUID:NUMBER的 GTID。对于使用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 事务标识符的元素。其格式如第 15.3.8.1 节，“XA Transaction SQL Statements”中所述。
XA_STATE

XA 事务的状态。其值为ACTIVE（在XA START之后）、IDLE（在XA END之后）、PREPARED（在XA PREPARE之后）、ROLLED BACK（在XA ROLLBACK之后）或COMMITTED（在XA COMMIT之后）。

在副本上，同一 XA 事务可以在不同线程上以不同状态出现在events_transactions_current表中。这是因为在 XA 事务准备完成后，它会从副本的应用程序线程中分离出来，并且可以由副本上的任何线程提交或回滚。events_transactions_current表显示了线程上最近监视的事务事件的当前状态，并且在线程空闲时不会更新此状态。因此，即使在被另一个线程处理后，XA 事务仍然可以在原始应用程序线程中以PREPARED状态显示。要明确识别仍处于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。

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

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

29.12.7.2 事件事务历史表

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

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

events_transactions_history 表与 events_transactions_current 表具有相同的列和索引。请参见第 29.12.7.1 节，“事件事务当前表”。

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

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

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

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

29.12.7.3 事件事务历史长表

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

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

events_transactions_history_long 表与events_transactions_current具有相同的列。请参阅第 29.12.7.1 节，“事件事务当前表”。与events_transactions_current不同，events_transactions_history_long没有索引。

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

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

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

29.12.8 性能模式连接表

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

29.12.8.1 账户表

29.12.8.2 主机表

29.12.8.3 用户表

当客户端连接到 MySQL 服务器时，它会使用特定的用户名和特定的主机。性能模式提供关于这些连接的统计信息，分别跟踪每个账户（用户和主机组合）以及每个用户名和主机名，使用以下表：

accounts：每个客户端账户的连接统计
hosts：每个客户端主机名的连接统计
users：每个客户端用户名称的连接统计

连接表中“账户”的含义类似于 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账户值，每行计算每个账户的一个连接。
hosts表有两行，分别为hosta和hostb，每行计算每个主机名的两个连接。
users 表有两行，分别为 user1 和 user2，每行计算每个用户名的两个连接。

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

当客户端断开连接时，性能模式将 CURRENT_CONNECTIONS 列中的值减一，并保持 TOTAL_CONNECTIONS 列不变。

TRUNCATE TABLE 允许连接表。它有以下效果：

对于没有当前连接的帐户、主机或用户（CURRENT_CONNECTIONS = 0 的行），将删除行。
未删除的行将被重置为仅计算当前连接数：对于 CURRENT_CONNECTIONS > 0 的行，TOTAL_CONNECTIONS 将被重置为 CURRENT_CONNECTIONS。
依赖连接表的汇总表将被隐式截断，如本节后面所述。

性能模式维护汇总表，按帐户、主机或用户聚合各种事件类型的连接统计信息。这些表的名称中包含 _summary_by_account、_summary_by_host 或 _summary_by_user。要识别它们，请使用以下查询：

mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
       WHERE TABLE_SCHEMA = 'performance_schema'
       AND TABLE_NAME REGEXP '_summary_by_(account|host|user)'
       ORDER BY TABLE_NAME;
+------------------------------------------------------+
| TABLE_NAME                                           |
+------------------------------------------------------+
| events_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                 |
+------------------------------------------------------+

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

等待事件汇总：第 29.12.20.1 节，“等待事件汇总表”
阶段事件汇总：第 29.12.20.2 节，“阶段汇总表”
语句事件汇总：第 29.12.20.3 节，“语句汇总表”
事务事件汇总：第 29.12.20.5 节，“事务汇总表”
内存事件汇总：第 29.12.20.10 节，“内存汇总表”
错误事件汇总：第 29.12.20.11 节，“错误汇总表”

允许对连接摘要表执行TRUNCATE TABLE。它会删除没有连接的帐户、主机或用户的行，并将剩余行的摘要列重置为零。此外，每个按帐户、主机、用户或线程汇总的摘要表在其依赖的连接表被截断时会被隐式截断。以下表格描述了连接表截断和隐式截断表之间的关系。

表 29.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会隐式截断按帐户、主机、用户或线程汇总的等待事件摘要表。

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

29.12.8.1 账户表

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

accounts表具有以下列。有关性能模式如何在此表中维护行的描述，包括TRUNCATE TABLE的影响，请参见第 29.12.8 节，“性能模式连接表”。

用户

连接的客户端用户名。对于内部线程或未能进行身份验证的用户会话，此处为NULL。
主机

客户端连接的主机。对于内部线程或未能进行身份验证的用户会话，此处为NULL。
当前连接数

该账户的当前连接数。
总连接数

该账户的总连接数。
最大会话受控内存

报告属于该账户的会话使用的最大受控内存量。

这一列是在 MySQL 8.0.31 中添加的。
最大会话总内存

报告属于该账户的会话使用的最大内存量。

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

accounts表具有以下索引：

主键为(用户, 主机)

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

29.12.8.2 主机表

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

hosts 表具有以下列。有关性能模式如何维护此表中的行的描述，包括TRUNCATE TABLE的影响，请参见第 29.12.8 节，“性能模式连接表”。

HOST

客户端连接的主机。对于内部线程或未能通过身份验证的用户会话，此值为NULL。
CURRENT_CONNECTIONS

主机的当前连接数。
TOTAL_CONNECTIONS

主机的总连接数。
MAX_SESSION_CONTROLLED_MEMORY

报告属于主机的会话使用的最大受控内存量。

该列在 MySQL 8.0.31 中添加。
MAX_SESSION_TOTAL_MEMORY

报告属于主机的会话使用的最大内存量。

该列在 MySQL 8.0.31 中添加。

hosts 表具有以下索引：

主键为 (HOST)

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

29.12.8.3 用户表

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

users 表具有以下列。有关性能模式如何维护此表中的行的描述，包括 TRUNCATE TABLE 的影响，请参见第 29.12.8 节，“性能模式连接表”。

USER

连接的客户端用户名。对于内部线程或未能通过身份验证的用户会话，此值为 NULL。
CURRENT_CONNECTIONS

用户的当前连接数。
TOTAL_CONNECTIONS

用户的总连接数。
MAX_SESSION_CONTROLLED_MEMORY

报告属于用户的会话使用的最大受控内存量。

此列在 MySQL 8.0.31 中添加。
MAX_SESSION_TOTAL_MEMORY

报告属于用户的会话使用的最大内存量。

此列在 MySQL 8.0.31 中添加。

users 表具有以下索引：

主键为 (USER)

29.12.9 性能模式连接属性表

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

29.12.9.1 session_account_connect_attrs 表

29.12.9.2 session_connect_attrs 表

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

这些性能模式表公开属性信息：

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

此外，写入审计日志的连接事件可能包括连接属性。请参阅第 8.4.5.4 节，“审计日志文件格式”。

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

可用连接属性
连接属性限制

可用连接属性

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

libmysqlclient客户端库设置这些属性：

_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）。

Connector/Python 8.0.17 及更高版本的实现定义了这些属性；某些值和属性取决于 Connector/Python 的实现（纯 Python 或 c-ext）：

_client_license: 连接器的许可证类型；GPL-2.0 或 Commercial。（仅限纯 Python）
_client_name: 设置为 mysql-connector-python（纯 Python）或 libmysql（c-ext）
_client_version: 连接器版本（纯 Python）或 mysqlclient 库版本（c-ext）。
_os: 带有连接器的操作系统（例如，Linux，Win64）。
_pid: 源机器上的进程标识符（例如，26955）
_platform: 机器平台（例如，x86_64）。
_source_host: 连接器连接的机器的主机名。
_connector_version: 连接器版本（例如，8.0.36）（仅限 c-ext）。
_connector_license: 连接器的许可证类型；GPL-2.0 或 Commercial（仅限 c-ext）。
_connector_name: 始终设置为 mysql-connector-python（仅限 c-ext）。

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，性能模式会向错误日志写入一条消息：
```
Connection attributes of length *N* were truncated
(*N* bytes lost)
for connection *N*, user *user_name*@*host_name*
(as *user_name*), auth: {yes|no}
```
  警告消息中的信息旨在帮助数据库管理员识别发生属性截断的客户端。
- 一个_truncated属性被添加到会话属性中，其值表示丢失了多少字节，如果属性缓冲区有足够的空间。这使得性能模式能够在连接属性表中公开每个连接的截断信息。这些信息可以在不必检查错误日志的情况下进行检查。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-session-account-connect-attrs-table.html

29.12.9.1 session_account_connect_attrs 表

应用程序可以在连接时提供键值连接属性以传递给服务器。有关常见属性的描述，请参见 Section 29.12.9, “Performance Schema Connection Attribute Tables”。

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

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

29.12.9.2 session_connect_attrs 表

应用程序可以在连接时提供键值连接属性，以传递给服务器。有关常见属性的描述，请参见第 29.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)

不允许对session_connect_attrs 表执行TRUNCATE TABLE。

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

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

性能模式提供了一个user_variables_by_thread表，用于公开用户定义的变量。这些变量是在特定会话中定义的，并且在名称前面带有@字符；参见第 11.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表。

29.12.11 性能模式复制表

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

29.12.11.1 复制连接配置表

29.12.11.2 复制连接状态表

29.12.11.3 复制异步连接故障转移表

29.12.11.4 复制异步连接故障转移管理表

29.12.11.5 复制应用程序配置表

29.12.11.6 复制应用程序状态表

29.12.11.7 按协调器复制应用程序状态表

29.12.11.8 按工作者复制应用程序状态表

29.12.11.9 全局复制应用程序过滤器表

29.12.11.10 复制应用程序过滤器表

29.12.11.11 复制组成员表

29.12.11.12 复制组成员统计表

29.12.11.13 复制组成员操作表

29.12.11.14 复制组配置版本表

29.12.11.15 复制组通信信息表

29.12.11.16 二进制日志事务压缩统计表

性能模式提供了暴露复制信息的表。这类似于SHOW REPLICA STATUS语句提供的信息，但以表格形式呈现更易访问，并具有可用性优势：

SHOW REPLICA STATUS输出对于视觉检查很有用，但对于程序化使用则不太方便。相比之下，使用性能模式表，关于复制状态的信息可以使用通用的SELECT查询进行搜索，包括复杂的WHERE条件、连接等。
查询结果可以保存在表中进行进一步分析，或分配给变量，从而在存储过程中使用。
复制表提供更好的诊断信息。对于多线程副本操作，SHOW REPLICA STATUS使用Last_SQL_Errno和Last_SQL_Error字段报告所有协调器和工作线程的错误，因此只有最近的错误可见，信息可能会丢失。复制表按线程基础存储错误，而不会丢失信息。
最后一次查看的事务在每个工作线程的复制表中可见。这是从SHOW REPLICA STATUS中无法获取的信息。
熟悉性能模式界面的开发人员可以通过向表中添加行来扩展复制表，以提供额外的信息。

复制表描述

性能模式提供以下与复制相关的表：

包含有关副本与源之间连接信息的表：
- replication_connection_configuration: 连接到源的配置参数
- replication_connection_status: 与源的当前连接状态
- replication_asynchronous_connection_failover: 异步连接故障转移机制的源列表
包含有关事务应用程序的一般（非线程特定）信息的表：
- 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: 提供有关组成员和他们参与的事务的统计信息。
更多信息请参见 Section 20.4, “监控组复制”。

当性能模式被禁用时，以下性能模式复制表仍然会被填充：

replication_connection_configuration
replication_connection_status
replication_asynchronous_connection_failover
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 REPLICA STATUS生成的列与复制表中出现相同信息的列之间的对应关系。

本介绍剩余部分将描述性能模式如何填充复制表以及SHOW REPLICA STATUS中的哪些字段在表中没有表示。

复制表的生命周期

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

在执行CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO之前，表格是空的。
在执行CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO之后，配置参数可以在表格中看到。此时，没有活动的复制线程，因此THREAD_ID列为NULL，SERVICE_STATE列的值为OFF。
在START REPLICA之后（或 MySQL 8.0.22 之前，START SLAVE），可以看到非NULL的THREAD_ID值。空闲或活动的线程具有SERVICE_STATE值为ON。连接到源的线程在建立连接时具有CONNECTING值，并且只要连接持续，之后为ON。
在STOP REPLICA之后，THREAD_ID列变为NULL，不再存在的线程的SERVICE_STATE列的值为OFF。
在STOP REPLICA或线程由于错误而停止后，表格将被保留。
replication_applier_status_by_worker 表仅在复制品以多线程模式运行时才非空。也就是说，如果 replica_parallel_workers 或 slave_parallel_workers 系统变量大于 0，则在执行 START REPLICA 时填充此表，并且行数显示工作线程数。

复制品状态信息不在复制表中

性能模式复制表中的信息与 SHOW REPLICA STATUS 中可用的信息略有不同，因为这些表面向全局事务标识符（GTIDs）的使用，而不是文件名和位置，并且它们代表服务器 UUID 值，而不是服务器 ID 值。由于这些差异，性能模式复制表中未保留或以不同方式表示几个 SHOW REPLICA 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 字段基于事件计数，而不是 GTIDs，并且不会被保留。
这些错误字段是 Last_SQL_Errno 和 Last_SQL_Error 的别名，因此不会被保留：
```
Last_Errno
Last_Error
```
在性能模式中，此错误信息可在 replication_applier_status_by_worker 表的 LAST_ERROR_NUMBER 和 LAST_ERROR_MESSAGE 列中找到（如果复制品是多线程，则还可在 replication_applier_status_by_coordinator 中找到）。这些表提供比 Last_Errno 和 Last_Error 更具体的每个线程的错误信息。

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

Replicate_Do_DB
Replicate_Ignore_DB
Replicate_Do_Table
Replicate_Ignore_Table
Replicate_Wild_Do_Table
Replicate_Wild_Ignore_Table

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

复制通道

复制性能模式表的第一列是 CHANNEL_NAME。这使得可以按照复制通道查看表。在非多源复制设置中，存在一个单一的默认复制通道。当在副本上使用多个复制通道时，可以按照复制通道过滤表以监视特定的复制通道。有关更多信息，请参见 Section 19.2.2, “Replication Channels” 和 Section 19.1.5.8, “Monitoring Multi-Source Replication”。

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

29.12.11.1 replication_connection_configuration 表

此表显示了复制品用于连接到源的配置参数。表中存储的参数可以通过CHANGE REPLICATION SOURCE TO语句（从 MySQL 8.0.23 开始）或CHANGE MASTER TO语句（在 MySQL 8.0.23 之前）在运行时更改。

与replication_connection_status表相比，replication_connection_configuration变化较少。它包含定义复制品如何连接到源以及在连接期间保持不变的值，而replication_connection_status包含在连接期间更改的值。

replication_connection_configuration表具有以下列。列描述指示从中获取列值的对应CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO选项，并且本节后面给出的表显示了replication_connection_configuration列和SHOW REPLICA STATUS列之间的对应关系。

通道名称

显示此行的复制通道。始终存在一个默认的复制通道，并且可以添加更多的复制通道。有关更多信息，请参见第 19.2.2 节，“复制通道”。
主机

复制品连接的源主机名。(CHANGE REPLICATION SOURCE TO 选项：SOURCE_HOST，CHANGE MASTER TO 选项：MASTER_HOST)
端口

用于连接到源的端口。(CHANGE REPLICATION SOURCE TO 选项：SOURCE_PORT，CHANGE MASTER TO 选项：MASTER_PORT)
用户

用于连接到源的复制用户帐户的用户名。（将复制源更改为选项：SOURCE_USER，更改主服务器为选项：MASTER_USER）
NETWORK_INTERFACE

副本绑定到的网络接口（如果有）。（将复制源更改为选项：SOURCE_BIND，更改主服务器为选项：MASTER_BIND）
AUTO_POSITION

如果使用 GTID 自动定位，则为 1；否则为 0。（将复制源更改为选项：SOURCE_AUTO_POSITION，更改主服务器为选项：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具有以下值：
- 如果允许与源的 SSL 连接，则为是
- 如果不允许与源的 SSL 连接，则为否
- 如果允许 SSL 连接但副本未启用 SSL 支持，则忽略
(将复制源更改为其他 SSL 列的选项：SOURCE_SSL_CA，SOURCE_SSL_CAPATH，SOURCE_SSL_CERT，SOURCE_SSL_CIPHER，SOURCE_SSL_CRL，SOURCE_SSL_CRLPATH，SOURCE_SSL_KEY，SOURCE_SSL_VERIFY_SERVER_CERT。

更改主服务器为其他 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

连接重试之间的秒数。（将复制源更改为选项：SOURCE_CONNECT_RETRY，更改主服务器为选项：MASTER_CONNECT_RETRY）
CONNECTION_RETRY_COUNT

在连接丢失的情况下，副本可以尝试重新连接到源的次数。（将复制源更改为选项：SOURCE_RETRY_COUNT，更改主服务器为选项：MASTER_RETRY_COUNT）
HEARTBEAT_INTERVAL

副本上的复制心跳��隔，以秒为单位。（将复制源更改为选项：SOURCE_HEARTBEAT_PERIOD，更改主服务器为选项：MASTER_HEARTBEAT_PERIOD）
TLS_VERSION

复制连接中允许副本使用的 TLS 协议版本列表。有关 TLS 版本信息，请参见第 8.3.2 节，“加密连接 TLS 协议和密码”。（将复制源更改为选项：SOURCE_TLS_VERSION，更改主服务器为选项：MASTER_TLS_VERSION）
TLS_CIPHERSUITES

允许副本使用的密码套件列表。有关 TLS 密码套件信息，请参见第 8.3.2 节，“加密连接 TLS 协议和密码”。（将复制源更改为选项：SOURCE_TLS_CIPHERSUITES，更改主服务器为选项：MASTER_TLS_CIPHERSUITES）
PUBLIC_KEY_PATH

指向包含源端所需用于 RSA 密钥对密码交换的公钥副本的文件的路径名。文件必须采用 PEM 格式。此列适用于使用sha256_password或caching_sha2_password认证插件进行身份验证的复制品。 (CHANGE REPLICATION SOURCE TO选项：SOURCE_PUBLIC_KEY_PATH，CHANGE MASTER TO选项：MASTER_PUBLIC_KEY_PATH)

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

是否从源端请求所需用于 RSA 密钥对密码交换的公钥。此列适用于使用caching_sha2_password认证插件进行身份验证的复制品。对于该插件，除非请求，否则源端不会发送公钥。 (CHANGE REPLICATION SOURCE TO选项：GET_SOURCE_PUBLIC_KEY，CHANGE MASTER TO选项：GET_MASTER_PUBLIC_KEY)

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

网络命名空间名称；如果连接使用默认（全局）命名空间，则为空。有关网络命名空间的信息，请参见第 7.1.14 节，“网络命名空间支持”。此列在 MySQL 8.0.22 中添加。
COMPRESSION_ALGORITHM

用于源端连接的允许压缩算法。 (CHANGE REPLICATION SOURCE TO选项：SOURCE_COMPRESSION_ALGORITHMS，CHANGE MASTER TO选项：MASTER_COMPRESSION_ALGORITHMS)

有关更多信息，请参见第 6.2.8 节，“连接压缩控制”。

此列在 MySQL 8.0.18 中添加。
ZSTD_COMPRESSION_LEVEL

用于使用zstd压缩算法的源端连接的压缩级别。 (CHANGE REPLICATION SOURCE TO选项：SOURCE_ZSTD_COMPRESSION_LEVEL，CHANGE MASTER TO选项：MASTER_ZSTD_COMPRESSION_LEVEL)

有关更多信息，请参见第 6.2.8 节，“连接压缩控制”。

此列在 MySQL 8.0.18 中添加。
SOURCE_CONNECTION_AUTO_FAILOVER

是否为此复制通道激活异步连接故障转移机制。 (CHANGE REPLICATION SOURCE TO选项：SOURCE_CONNECTION_AUTO_FAILOVER，CHANGE MASTER TO选项：SOURCE_CONNECTION_AUTO_FAILOVER)

有关更多信息，请参见第 19.4.9 节，“使用异步连接故障转移切换源和复制品”。

此列在 MySQL 8.0.22 中添加。
GTID_ONLY

表示此通道仅在事务队列和应用程序过程以及恢复中使用 GTIDs，并且不在复制元数据存储库中保留二进制日志和中继日志文件名和文件位置。 (CHANGE REPLICATION SOURCE TO 选项：GTID_ONLY，CHANGE MASTER TO 选项：GTID_ONLY)

有关更多信息，请参见第 20.4.1 节，“GTIDs 和组复制”。

此列在 MySQL 8.0.27 中添加。

replication_connection_configuration 表具有以下索引：

主键为 (CHANNEL_NAME)

TRUNCATE TABLE 不允许用于 replication_connection_configuration 表。

以下表显示了 replication_connection_configuration 列与 SHOW REPLICA STATUS 列之间的对应关系。

`replication_connection_configuration` 列	`SHOW REPLICA STATUS` 列
`CHANNEL_NAME`	`Channel_name`
`HOST`	`Source_Host`
`PORT`	`Source_Port`
`USER`	`Source_User`
`NETWORK_INTERFACE`	`Source_Bind`
`AUTO_POSITION`	`Auto_Position`
`SSL_ALLOWED`	`Source_SSL_Allowed`
`SSL_CA_FILE`	`Source_SSL_CA_File`
`SSL_CA_PATH`	`Source_SSL_CA_Path`
`SSL_CERTIFICATE`	`Source_SSL_Cert`
`SSL_CIPHER`	`Source_SSL_Cipher`
`SSL_KEY`	`Source_SSL_Key`
`SSL_VERIFY_SERVER_CERTIFICATE`	`Source_SSL_Verify_Server_Cert`
`SSL_CRL_FILE`	`Source_SSL_Crl`
`SSL_CRL_PATH`	`Source_SSL_Crlpath`
`CONNECTION_RETRY_INTERVAL`	`Source_Connect_Retry`
`CONNECTION_RETRY_COUNT`	`Source_Retry_Count`
`HEARTBEAT_INTERVAL`	无
`TLS_VERSION`	`Source_TLS_Version`
`PUBLIC_KEY_PATH`	`Source_public_key_path`
`GET_PUBLIC_KEY`	`Get_source_public_key`
`NETWORK_NAMESPACE`	`Network_Namespace`
`COMPRESSION_ALGORITHM`	[无]
`ZSTD_COMPRESSION_LEVEL`	[无]
`GTID_ONLY`	[无]
`replication_connection_configuration` 列	`SHOW REPLICA STATUS` 列

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

29.12.11.2 replication_connection_status 表

此表显示处理副本连接到源的 I/O 线程的当前状态，排队在中继日志中的最后一个事务的信息，以及当前正在排队在中继日志中的事务的信息。

与replication_connection_configuration表相比，replication_connection_status更频繁更改。它包含在连接期间更改的值，而replication_connection_configuration包含定义副本连接到源的值，在连接期间保持不变。

replication_connection_status表具有以下列：

CHANNEL_NAME

此行显示的复制通道。始终存在一个默认复制通道，并且可以添加更多复制通道。有关更多信息，请参见第 19.2.2 节，“复制通道”。
GROUP_NAME

如果此服务器是某个组的成员，则显示服务器所属组的名称。
SOURCE_UUID

源的server_uuid值。
THREAD_ID

I/O 线程 ID。
SERVICE_STATE

ON（线程存在且活动或空闲），OFF（线程不再存在），或CONNECTING（线程存在且正在连接到源）。
RECEIVED_TRANSACTION_SET

对应于此副本接收的所有事务的全局事务 ID（GTID）集。如果未使用 GTID，则为空。有关更多信息，请参见 GTID 集。
LAST_ERROR_NUMBER，LAST_ERROR_MESSAGE

导致 I/O 线程停止的最近错误的错误编号和错误消息。错误编号为 0，消息为空字符串表示“无错误”。如果LAST_ERROR_MESSAGE值不为空，则错误值也会出现在副本的错误日志中。

发出RESET MASTER或RESET REPLICA会重置这些列中显示的值。
LAST_ERROR_TIMESTAMP

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

一个时间戳，格式为'*YYYY-MM-DD hh:mm:ss*[.*fraction*]'，显示副本何时收到最近的心跳信号。
COUNT_RECEIVED_HEARTBEATS

一个副本自上次重新启动或重置以来接收的心跳信号总数，或自上次发出CHANGE REPLICATION SOURCE TO | 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

一个时间戳，格式为'*YYYY-MM-DD hh:mm:ss*[.*fraction*]'，显示上一个事务何时被此 I/O 线程放入中继日志队列中。
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

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

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

replication_connection_status表具有以下索引：

主键在(CHANNEL_NAME)
在(THREAD_ID)上的索引

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

`replication_connection_status`列	`SHOW REPLICA STATUS`列
`SOURCE_UUID`	`Master_UUID`
`THREAD_ID`	None
`SERVICE_STATE`	`Replica_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`

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-replication-asynchronous-connection-failover-table.html

29.12.11.3 复制异步连接故障转移表

此表为异步连接故障转移机制的每个复制通道保存副本的源列表。异步连接故障转移机制在副本到源的连接失败后，自动从适当的列表中向新源建立异步（源到副本）复制连接。当为由 Group Replication 管理的一组副本启用异步连接故障转移时，当它们加入时，源列表会广播到所有组成员，并且当列表发生变化时也会广播。

您可以使用asynchronous_connection_failover_add_source和asynchronous_connection_failover_delete_source函数设置和管理源列表，以添加和删除复制源服务器到复制通道的源列表。要添加和删除受管理的服务器组，请改用asynchronous_connection_failover_add_managed和asynchronous_connection_failover_delete_managed函数。

有关更多信息，请参见第 19.4.9 节，“使用异步连接故障转移切换源和副本”。

replication_asynchronous_connection_failover 表具有以下列：

通道名称

此复制源服务器所属源列表的复制通道。如果此通道与当前源的连接失败，则此复制源服务器是其潜在的新源之一。
主机

此复制源服务器的主机名。
端口

此复制源服务器的端口号。
网络命名空间

复制源服务器的网络命名空间。如果此值为空，则连接使用默认（全局）命名空间。
权重

在复制通道源列表中，此复制源服务器的优先级。权重范围为 1 到 100，100 为最高，50 为默认值。当异步连接故障转移机制激活时，通道源列表中备选源中设置最高权重的源将被选择用于第一次连接尝试。如果此尝试不起作用，则副本将按权重降序尝试所有列出的源，然后再从最高权重源开始。如果多个源具有相同的权重，则副本会随机排序它们。
MANAGED_NAME

服务器所属的受管理组的标识符。对于GroupReplication受管理服务，该标识符是group_replication_group_name系统变量的值。

replication_asynchronous_connection_failover 表具有以下索引：

主键为 (CHANNEL_NAME, HOST, PORT, NETWORK_NAMESPACE, MANAGED_NAME)

TRUNCATE TABLE 不允许用于 replication_asynchronous_connection_failover 表。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-replication-asynchronous-connection-failover-managed-table.html

29.12.11.4 复制异步连接故障转移管理表

此表保存由副本的异步连接故障转移机制使用的配置信息，用于处理受管理组，包括 Group Replication 拓扑。

当您将组成员添加到源列表并将其定义为受管理组的一部分时，异步连接故障转移机制会更新源列表，以使其与成员变化保持一致，自动添加和删除组成员，随着它们加入或离开。当为由 Group Replication 管理的一组副本启用异步连接故障转移时，当它们加入时，源列表会广播到所有组成员，并且当列表发生变化时也会广播。

异步连接故障转移机制会在源列表中另一个可用服务器具有更高优先级（权重）设置时切换连接。对于受管理的组，源的权重根据其是主服务器还是从服务器而分配。因此，假设您设置了受管理组以给主服务器分配更高的权重，给从服务器分配较低的权重，当主服务器更改时，新主服务器被分配更高的权重，因此副本切换到新主服务器的连接。异步连接故障转移机制还会在当前连接的受管理源服务器离开受管理组或不再是受管理组中的大多数时更改连接。有关更多信息，请参见第 19.4.9 节，“使用异步连接故障转移切换源和副本”。

replication_asynchronous_connection_failover_managed 表包含以下列：

CHANNEL_NAME

用于操作此受管理组的复制通道。
MANAGED_NAME

受管理组的标识符。对于GroupReplication受管理服务，标识符是group_replication_group_name系统变量的值。
MANAGED_TYPE

异步连接故障转移机制为该组提供的受管理服务类型。目前唯一可用的值是GroupReplication。
CONFIGURATION

此托管组的配置信息。对于GroupReplication托管服务，配置显示分配给组的主服务器和组的辅助服务器的权重。例如：{"Primary_weight": 80, "Secondary_weight": 60}
- Primary_weight: 介于 0 和 100 之间的整数。默认值为 80。
- Secondary_weight: 介于 0 和 100 之间的整数。默认值为 60。

replication_asynchronous_connection_failover_managed 表具有以下索引：

主键为(CHANNEL_NAME, MANAGED_NAME)。

TRUNCATE TABLE 不允许用于replication_asynchronous_connection_failover_managed 表。

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

29.12.11.5 复制 _applier_configuration 表

此表显示影响副本应用的事务的配置参数。表中存储的参数可以使用CHANGE REPLICATION SOURCE TO语句（从 MySQL 8.0.23 开始）或CHANGE MASTER TO语句（在 MySQL 8.0.23 之前）在运行时更改。

replication_applier_configuration 表具有以下列：

CHANNEL_NAME

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

复制品必须滞后源的秒数。 (CHANGE REPLICATION SOURCE TO 选项：SOURCE_DELAY，CHANGE MASTER TO 选项：MASTER_DELAY)。有关更多信息，请参见第 19.4.11 节，“延迟复制”。
PRIVILEGE_CHECKS_USER

为通道提供安全上下文的用户帐户（CHANGE REPLICATION SOURCE TO 选项：PRIVILEGE_CHECKS_USER，CHANGE MASTER TO 选项：PRIVILEGE_CHECKS_USER）。这是经过转义的，以便可以将其复制到 SQL 语句中以执行单个事务。有关更多信息，请参见第 19.3.3 节，“复制权限检查”。
REQUIRE_ROW_FORMAT

通道是否仅接受基于行的事件（CHANGE REPLICATION SOURCE TO 选项：REQUIRE_ROW_FORMAT，CHANGE MASTER TO 选项：REQUIRE_ROW_FORMAT）。有关更多信息，请参见第 19.3.3 节，“复制权限检查”。
REQUIRE_TABLE_PRIMARY_KEY_CHECK

通道是否始终需要主键，从不需要，或根据源的设置（CHANGE REPLICATION SOURCE TO 选项：REQUIRE_TABLE_PRIMARY_KEY_CHECK，CHANGE MASTER TO 选项：REQUIRE_TABLE_PRIMARY_KEY_CHECK）。有关更多信息，请参见第 19.3.3 节，“复制权限检查”。
ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS_TYPE

通道是否为尚未具有 GTID 的复制事务分配 GTID（CHANGE REPLICATION SOURCE TO 选项：ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS，CHANGE MASTER TO 选项：ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS）。OFF 表示不分配 GTID。LOCAL 表示分配包含副本自身 UUID（server_uuid 设置）的 GTID。UUID 表示分配包含手动设置 UUID 的 GTID。更多信息请参见 Section 19.1.3.6, “Replication From a Source Without GTIDs to a Replica With GTIDs”。
ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS_VALUE

用作分配给匿名事务的 GTIDs 的 UUID（CHANGE REPLICATION SOURCE TO 选项：ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS，CHANGE MASTER TO 选项：ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS）。更多信息请参见 Section 19.1.3.6, “Replication From a Source Without GTIDs to a Replica With GTIDs”。

replication_applier_configuration 表具有以下索引：

主键为 (CHANNEL_NAME)

TRUNCATE TABLE 不允许用于 replication_applier_configuration 表。

以下表格显示了 replication_applier_configuration 列与 SHOW REPLICA STATUS 列之间的对应关系。

`replication_applier_configuration` 列	`SHOW REPLICA STATUS` 列
`DESIRED_DELAY`	`SQL_Delay`

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

29.12.11.6 复制 _applier_status 表

该表显示副本上当前的一般事务执行状态。该表提供有关事务应用程序状态的一般方面的信息，这些信息与涉及的任何线程无关。线程特定的状态信息可在replication_applier_status_by_coordinator表中找到（如果副本是多线程的，则在replication_applier_status_by_worker中也有）。

replication_applier_status表具有以下列：

CHANNEL_NAME

显示此行所显示的复制通道。始终存在默认复制通道，并且可以添加更多复制通道。有关更多信息，请参见 Section 19.2.2，“复制通道”。
SERVICE_STATE

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

如果副本正在等待DESIRED_DELAY秒，以便自源应用事务以来经过，此字段包含剩余延迟秒数。在其他时间，此字段为NULL。（DESIRED_DELAY值存储在replication_applier_configuration表中。）有关更多信息，请参见 Section 19.4.11，“延迟复制”。
COUNT_TRANSACTIONS_RETRIES

显示由于复制 SQL 线程未能应用事务而进行的重试次数。给定事务的最大重试次数由系统变量replica_transaction_retries和slave_transaction_retries设置。replication_applier_status_by_worker表显示了单线程或多线程副本的事务重试的详细信息。

replication_applier_status表具有以下索引：

(CHANNEL_NAME)上的主键

TRUNCATE TABLE 不允许用于replication_applier_status表。

以下表格显示了replication_applier_status列与SHOW REPLICA STATUS列之间的对应关系。

`replication_applier_status` 列	`SHOW REPLICA STATUS` 列
`SERVICE_STATE`	无
`REMAINING_DELAY`	`SQL_Remaining_Delay`

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-replication-applier-status-by-coordinator-table.html

29.12.11.7 复制 _applier_status_by_coordinator 表

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

replication_applier_status_by_coordinator 表具有以下列：

CHANNEL_NAME

此行显示的复制通道。始终存在默认复制通道，并且可以添加更多复制通道。有关更多信息，请参见 Section 19.2.2, “Replication Channels”。
THREAD_ID

SQL/协调线程 ID。
SERVICE_STATE

ON（线程存在且活动或空闲）或OFF（线程已不存在）。
LAST_ERROR_NUMBER, LAST_ERROR_MESSAGE

导致 SQL/协调线程停止的最近错误的错误编号和错误消息。错误编号为 0，消息为空字符串表示“无错误”。如果LAST_ERROR_MESSAGE值不为空，则错误值也会出现在复制的错误日志中。

发出RESET MASTER或RESET REPLICA将重置这些列中显示的值。

所有显示在LAST_ERROR_NUMBER和LAST_ERROR_MESSAGE列中的错误代码和消息对应于服务器错误消息参考中列出的错误值。
LAST_ERROR_TIMESTAMP

以'*YYYY-MM-DD hh:mm:ss*[.*fraction*]'格式的时间戳，显示最近的 SQL/协调器错误发生的时间。
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 REPLICA STATUS列之间的对应关系。

`replication_applier_status_by_coordinator`列	`SHOW REPLICA STATUS`列
`THREAD_ID`	None
`SERVICE_STATE`	`Replica_SQL_Running`
`LAST_ERROR_NUMBER`	`Last_SQL_Errno`
`LAST_ERROR_MESSAGE`	`Last_SQL_Error`
`LAST_ERROR_TIMESTAMP`	`Last_SQL_Error_Timestamp`

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-replication-applier-status-by-worker-table.html

29.12.11.8 复制 _applier_status_by_worker 表

此表提供了在副本或组复制组成员上由应用程序线程处理的事务的详细信息。对于单线程副本，显示副本的单个应用程序线程的数据。对于多线程副本，分别显示每个应用程序线程的数据。多线程副本上的应用程序线程有时称为工作者。副本或组复制组成员上的应用程序线程数量由replica_parallel_workers或slave_parallel_workers系统变量设置，对于单线程副本，该变量设置为零。多线程副本还有一个协调器线程来管理应用程序线程，并且此线程的状态显示在replication_applier_status_by_coordinator表中。

所有与错误相关的列中显示的错误代码和消息对应于服务器错误消息参考中列出的错误值。

当关闭性能模式时，不会收集本地时间信息，因此显示应用事务的开始和结束时间戳的字段为零。此表中的开始时间戳指的是工作者开始应用第一个事件的时间，结束时间戳指的是应用事务的最后一个事件的时间。

当副本通过START REPLICA语句重新启动时，以APPLYING_TRANSACTION开头的列将被重置。在 MySQL 8.0.13 之前，这些列在单线程模式下运��的副本上不会被重置，只有在多线程副本上才会被重置。

replication_applier_status_by_worker表具有以下列：

CHANNEL_NAME

此行显示的复制通道。始终存在默认复制通道，并且可以添加更多复制通道。有关更多信息，请参见 Section 19.2.2, “Replication Channels”。
WORKER_ID

工作者标识符（与mysql.slave_worker_info表中的id列相同）。在STOP REPLICA之后，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 REPLICA将重置这些列中显示的值。
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

一个时间戳，格式为'*YYYY-MM-DD hh:mm:ss*[.*fraction*]'，显示此工作程序开始尝试应用当前正在应用的事务的时间。在 MySQL 8.0.13 之前，由于瞬时错误导致事务重试时，此时间戳会刷新，因此显示了应用事务的最近尝试的时间戳。
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 REPLICA STATUS列之间的对应关系。

`replication_applier_status_by_worker` 列	`SHOW REPLICA 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`

译文：dev.mysql.com/doc/refman/8.0/en/performance-schema-replication-applier-global-filters-table.html

29.12.11.9 复制 _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

复制过滤器配置的时间戳。

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

29.12.11.10 复制 _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语句配置的特定通道复制过滤器。
- STARTUP_OPTIONS_FOR_CHANNEL通过使用--replicate-*选项配置的特定通道复制过滤器。
ACTIVE_SINCE

配置复制过滤器的时间戳。
COUNTER

自配置以来复制过滤器已使用的次数。

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

29.12.11.11 The replication_group_members Table

此表显示复制组成员的网络和状态信息。显示的网络地址是用于连接客户端到组的地址，并且不应与由group_replication_local_address指定的成员内部组通信地址混淆。

replication_group_members表具有以下列：

CHANNEL_NAME

Group Replication 通道的名称。
MEMBER_ID

成员服务器 UUID。对于组中的每个成员，此值不同。这也作为一个键，因为对于每个成员都是唯一的。
MEMBER_HOST

此成员的网络地址（主机名或 IP 地址）。从成员的hostname变量中检索。这是客户端连接的地址，不同于用于内部组通信的 group_replication_local_address。
MEMBER_PORT

服务器正在侦听的端口。从成员的port变量中检索。
MEMBER_STATE

此成员的当前状态；可以是以下任何一种：
- ONLINE: 成员处于完全运作状态。
- RECOVERING: 服务器已加入正在检索数据的组。
- OFFLINE: 安装了组复制插件，但尚未启动。
- ERROR: 成员在应用事务或恢复阶段遇到错误，并且不参与组的事务。
- UNREACHABLE: 失败检测过程怀疑无法联系到此成员，因为组消息已超时。
参见Section 20.4.2, “Group Replication Server States”。
MEMBER_ROLE

成员在组中的角色，可以是PRIMARY或SECONDARY。
MEMBER_VERSION

成员的 MySQL 版本。
MEMBER_COMMUNICATION_STACK

用于组的通信堆栈，可以是XCOM通信堆栈或MYSQL通信堆栈。

此列在 MySQL 8.0.27 中添加。

replication_group_members表没有索引。

TRUNCATE TABLE语句不允许用于replication_group_members表。

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

29.12.11.12 复制组成员统计表

此表显示复制组成员的统计信息。仅在运行 Group Replication 时填充。

replication_group_member_stats表具有以下列：

CHANNEL_NAME

Group Replication 通道的名称
VIEW_ID

此组的当前视图标识符。
MEMBER_ID

成员服务器的 UUID。对于组中的每个成员，此值不同。这也作为一个键，因为对于每个成员它是唯一的。
COUNT_TRANSACTIONS_IN_QUEUE

在队列中等待冲突检测的事务数。一旦事务经过冲突检测，如果通过检测，它们将排队等待应用。
COUNT_TRANSACTIONS_CHECKED

已经检查冲突的事务数。
COUNT_CONFLICTS_DETECTED

未通过冲突检测检查的事务数。
COUNT_TRANSACTIONS_ROWS_VALIDATING

可用于认证的事务行数，但尚未被垃圾回收。可以认为是冲突检测数据库的当前大小，每个事务都会针对其进行认证。
TRANSACTIONS_COMMITTED_ALL_MEMBERS

已在复制组的所有成员上成功提交的事务，显示为 GTID Sets。这在固定时间间隔内更新。
LAST_CONFLICT_FREE_TRANSACTION

最后一个无冲突事务的事务标识符，已经经过检查。
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表。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-replication-group-member-actions-table.html

29.12.11.13 复制组成员操作表

此表列出了复制组成员操作的成员操作配置中包含的成员操作。仅在安装了组复制时才可用该表。您可以使用 group_replication_reset_member_actions() 函数重置成员操作配置。有关更多信息，请参见 20.5.1.5 节“配置成员操作”。

replication_group_member_actions 表具有以下列：

名称

成员操作的名称。
事件

触发成员操作的事件。
启用

成员操作当前是否已启用。可以使用 group_replication_enable_member_action() 函数启用成员操作，并使用 group_replication_disable_member_action() 函数禁用成员操作。
类型

成员操作的类型。INTERNAL 是由组复制插件提供的操作。
优先级

成员操作的优先级。具有较低优先级值的操作首先执行。
错误处理

如果在执行成员操作时发生错误，组复制将采取的操作。IGNORE 表示记录错误消息以指示成员操作失败，但不会采取进一步操作。CRITICAL 表示成员进入 ERROR 状态，并执行由 group_replication_exit_state_action 系统变量指定的操作。

replication_group_member_actions 表没有索引。

TRUNCATE TABLE 不允许用于 replication_group_member_actions 表。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-replication-group-configuration-version-table.html

29.12.11.14 复制组配置版本表

这个表显示了复制组成员操作配置的版本。只有在安装了组复制时才可用。每当使用group_replication_enable_member_action()和group_replication_disable_member_action()函数启用或禁用成员操作时，版本号会递增。您可以使用group_replication_reset_member_actions()函数重置成员操作配置，将其重置为默认设置，并将其版本号重置为 1。更多信息，请参见 Section 20.5.1.5, “Configuring Member Actions”。

replication_group_configuration_version表具有以下列：

名称

配置的名称。
版本

配置的版本号。

replication_group_configuration_version表没有索引。

对于replication_group_configuration_version表，不允许使用TRUNCATE TABLE。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-replication-group-communication-information-table.html

29.12.11.15 replication_group_communication_information 表

此表显示整个复制组的组配置选项。仅在安装了 Group Replication 时才可用。

replication_group_communication_information表具有以下列：

WRITE_CONCURRENCY

组可以并行执行的最大共识实例数。默认值为 10。请参阅 20.5.1.3 节，“使用 Group Replication 组写共识”。
PROTOCOL_VERSION

Group Replication 通信协议版本，确定使用的消息传递能力。这是为了适应您希望组支持的最旧 MySQL Server 版本而设置的。请参阅 20.5.1.4 节，“设置组的通信协议版本”。
WRITE_CONSENSUS_LEADERS_PREFERRED

Group Replication 已指示组通信引擎使用的领导者或领导者来驱动共识。对于使用group_replication_paxos_single_leader系统变量设置为ON且通信协议版本设置为 8.0.27 或更高版本的单主模式组，单一共识领导者是组的主。否则，所有组成员都被用作领导者，因此它们都在这里显示。请参阅 20.7.3 节，“单一共识领导者”。
WRITE_CONSENSUS_LEADERS_ACTUAL

组通信引擎正在使用的实际领导者或领导者来驱动共识。如果组使用单一共识领导者，并且主目前不健康，组通信会选择替代共识领导者。在这种情况下，此处指定的组成员可能与首选组成员不同。
WRITE_CONSENSUS_SINGLE_LEADER_CAPABLE

复制组是否能够使用单一一致性领导者。1 表示该组是在启用单一领导者的情况下启动的（group_replication_paxos_single_leader = ON），即使此后在该组成员上更改了 group_replication_paxos_single_leader 的值，仍然显示为 1。0 表示该组是在禁用单一领导者模式（group_replication_paxos_single_leader = OFF）启动的，或者具有不支持使用单一一致性领导者的 Group Replication 通信协议版本（低于 8.0.27）。此信息仅对处于 ONLINE 或 RECOVERING 状态的组成员返回。

replication_group_communication_information 表没有索引。

不允许对 replication_group_communication_information 表使用 TRUNCATE TABLE。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-binary-log-transaction-compression-stats-table.html

29.12.11.16 `binary_log_transaction_compression_stats`表

此表显示写入二进制日志和中继日志的交易有效负载的统计信息，并可用于计算启用二进制日志事务压缩的效果。有关二进制日志事务压缩的信息，请参见 Section 7.4.4.5, “Binary Log Transaction Compression”。

当服务器实例具有二进制日志，并且系统变量binlog_transaction_compression设置为ON时，才会填充binary_log_transaction_compression_stats表。统计数据涵盖了从服务器启动或表被截断时开始写入二进制日志和中继日志的所有交易。压缩的交易按使用的压缩算法分组，未压缩的交易与压缩算法为NONE一起分组，因此可以计算压缩比率。

binary_log_transaction_compression_stats表具有以下列：

LOG_TYPE

这些交易是否被写入了二进制日志或中继日志。
COMPRESSION_TYPE

用于压缩交易有效负载的压缩算法。NONE表示这些交易的有效负载未经压缩，在许多情况下是正确的（参见 Section 7.4.4.5, “Binary Log Transaction Compression”）。
TRANSACTION_COUNTER

使用此压缩类型写入此日志类型的交易数量。
COMPRESSED_BYTES

经过压缩并写入此日志类型的总字节数，计算压缩后的字节数。
UNCOMPRESSED_BYTES

此日志类型和此压缩类型在压缩前的总字节数。
COMPRESSION_PERCENTAGE

此日志类型和此压缩类型的压缩比率，以百分比表示。
FIRST_TRANSACTION_ID

使用此压缩类型写入此日志类型的第一笔交易的 ID。
FIRST_TRANSACTION_COMPRESSED_BYTES

经过压缩并写入第一笔交易的日志的总字节数，计算压缩后的字节数。
FIRST_TRANSACTION_UNCOMPRESSED_BYTES

第一笔交易在压缩前的总字节数。
FIRST_TRANSACTION_TIMESTAMP

第一笔交易写入日志时的时间戳。
LAST_TRANSACTION_ID

使用此压缩类型写入此日志类型的最近一笔交易的 ID。
LAST_TRANSACTION_COMPRESSED_BYTES

最近一笔交易在压缩后写入日志的总字节数，压缩后计算。
LAST_TRANSACTION_UNCOMPRESSED_BYTES

最近一笔交易在压缩前的总字节数。
LAST_TRANSACTION_TIMESTAMP

最近一笔交易被写入日志的时间戳。

binary_log_transaction_compression_stats 表没有索引。

TRUNCATE TABLE 允许用于 binary_log_transaction_compression_stats 表。

29.12.12 性能模式 NDB 集群表

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

29.12.12.1 ndb_sync_pending_objects 表

29.12.12.2 ndb_sync_excluded_objects 表

以下表格显示了所有与NDBCLUSTER存储引擎相关的性能模式表。

表 29.3 性能模式 NDB 表

表名	描述	引入版本
`ndb_sync_excluded_objects`	无法同步的 NDB 对象	8.0.21
`ndb_sync_pending_objects`	等待同步的 NDB 对象	8.0.21

从 NDB 8.0.16 开始，NDB 中的自动同步尝试检测并自动同步 NDB 集群内部字典与 MySQL 服务器数据字典之间的所有元数据不匹配。默认情况下，这是通过后台定期间隔（由 ndb_metadata_check_interval 系统变量确定）完成的，除非使用 ndb_metadata_check 禁用或通过设置 ndb_metadata_sync 覆盖。在 NDB 8.0.21 之前，用户可以获得关于此过程的唯一信息是以日志消息和对象计数的形式提供的（从 NDB 8.0.18 开始可用），作为状态变量 Ndb_metadata_detected_count、Ndb_metadata_synced_count 和 Ndb_metadata_excluded_count（在 NDB 8.0.22 之前，此变量名为 Ndb_metadata_blacklist_size）。从 NDB 8.0.21 开始，作为 NDB 集群中的 SQL 节点充当的 MySQL 服务器在这两个性能模式表中公开有关自动同步当前状态的更详细信息：

ndb_sync_pending_objects：显示了在NDB字典和 MySQL 数据字典之间检测到不匹配的NDB数据库对象的信息。当尝试同步这些对象时，NDB会将对象从等待同步的队列中移除，并从此表中移除，并尝试协调不匹配。如果由于临时错误导致对象同步失败，则会在下次NDB执行不匹配检测时重新添加到队列（和此表）；如果尝试由于永久错误而失败，则将对象添加到ndb_sync_excluded_objects表中。
ndb_sync_excluded_objects：显示了由于不可调和的不匹配导致自动同步失败的NDB数据库对象的信息；这些对象被列入黑名单，并且在进行手动干预之前不再考虑进行不匹配检测。

只有当 MySQL 启用了对NDBCLUSTER存储引擎的支持时，ndb_sync_pending_objects和ndb_sync_excluded_objects表才存在。

这些表在以下两个部分中有更详细的描述。

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

29.12.12.1 ndb_sync_pending_objects 表

这个表提供了关于已检测到不匹配并正在等待在NDB字典和 MySQL 数据字典之间同步的数据库对象的信息。

有关等待同步的NDB数据库对象的示例信息：

mysql> SELECT * FROM performance_schema.ndb_sync_pending_objects;
+-------------+------+----------------+
| SCHEMA_NAME | NAME |  TYPE          |
+-------------+------+----------------+
| NULL        | lg1  |  LOGFILE GROUP |
| NULL        | ts1  |  TABLESPACE    |
| db1         | NULL |  SCHEMA        |
| test        | t1   |  TABLE         |
| test        | t2   |  TABLE         |
| test        | t3   |  TABLE         |
+-------------+------+----------------+

ndb_sync_pending_objects表具有以下列：

SCHEMA_NAME: 等待同步的对象所在模式（数据库）的名称；对于表空间和日志文件组，此处为NULL。
NAME: 等待同步的对象的名称；如果对象是模式，则为NULL。
TYPE: 等待同步的对象的类型；可以是LOGFILE GROUP、TABLESPACE、SCHEMA或TABLE之一。

ndb_sync_pending_objects表是在 NDB 8.0.21 中添加的。

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

29.12.12.2 `ndb_sync_excluded_objects` 表

此表提供有关NDB数据库对象的信息，这些对象无法在 NDB Cluster 字典和 MySQL 数据字典之间自动同步。

有关NDB数据库对象的示例信息，这些对象无法与 MySQL 数据字典同步：

mysql> SELECT * FROM performance_schema.ndb_sync_excluded_objects\G
*************************** 1\. row ***************************
SCHEMA_NAME: NULL
       NAME: lg1
       TYPE: LOGFILE GROUP
     REASON: Injected failure
*************************** 2\. row ***************************
SCHEMA_NAME: NULL
       NAME: ts1
       TYPE: TABLESPACE
     REASON: Injected failure
*************************** 3\. row ***************************
SCHEMA_NAME: db1
       NAME: NULL
       TYPE: SCHEMA
     REASON: Injected failure
*************************** 4\. row ***************************
SCHEMA_NAME: test
       NAME: t1
       TYPE: TABLE
     REASON: Injected failure
*************************** 5\. row ***************************
SCHEMA_NAME: test
       NAME: t2
       TYPE: TABLE
     REASON: Injected failure
*************************** 6\. row ***************************
SCHEMA_NAME: test
       NAME: t3
       TYPE: TABLE
     REASON: Injected failure

ndb_sync_excluded_objects 表具有以下列：

SCHEMA_NAME：未能同步的对象所在的模式（数据库）的名称；对于表空间和日志文件组，此处为NULL
NAME：未能同步的对象的名称；如果对象是模式，则为NULL
TYPE：未能同步的对象的类型；可以是LOGFILE GROUP、TABLESPACE、SCHEMA或TABLE之一
REASON：排除（阻止列入列表）对象的原因；即，未能同步此对象的原因

可能的原因包括以下内容：
- 注入失败
- 确定对象是否存在于 NDB 中失败
- 确定对象是否存在于 DD 中失败
- 在 DD 中删除对象失败
- 获取分配给日志文件组的 undofiles 失败
- 获取对象 ID 和版本失败
- 在 DD 中安装对象失败
- 获取分配给表空间的数据文件失败
- 创建模式失败
- 确定对象是否为本地表失败
- 使表引用无效失败
- 设置 NDB 对象的数据库名称失败
- 获取表的额外元数据失败
- 迁移带有额外元数据版本 1 的表失败
- 从 DD 获取对象失败
- 在 NDB 字典中表的定义已更改
- 为表设置二进制日志记录失败
此列表可能不是详尽无遗的，并且可能会在未来的NDB版本中发生变化。

ndb_sync_excluded_objects 表在 NDB 8.0.21 中添加。

29.12.13 性能模式锁表

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

29.12.13.1 数据锁表

29.12.13.2 数据锁等待表

29.12.13.3 元数据锁表

29.12.13.4 表句柄表

性能模式通过这些表公开锁信息：

data_locks: 持有和请求的数据锁
data_lock_waits: 数据锁所有者和被这些所有者阻塞的数据锁请求者之间的关系
metadata_locks: 持有和请求的元数据锁
table_handles: 持有和请求的表锁

以下部分详细描述这些表。

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

29.12.13.1 数据锁表

data_locks表显示已持有和请求的数据锁。有关哪些锁请求被哪些持有的锁阻塞的信息，请参见 Section 29.12.13.2, “The data_lock_waits Table”。

示例数据锁信息：

mysql> SELECT * FROM performance_schema.data_locks\G
*************************** 1\. row ***************************
               ENGINE: INNODB
       ENGINE_LOCK_ID: 139664434886512:1059:139664350547912
ENGINE_TRANSACTION_ID: 2569
            THREAD_ID: 46
             EVENT_ID: 12
        OBJECT_SCHEMA: test
          OBJECT_NAME: t1
       PARTITION_NAME: NULL
    SUBPARTITION_NAME: NULL
           INDEX_NAME: NULL
OBJECT_INSTANCE_BEGIN: 139664350547912
            LOCK_TYPE: TABLE
            LOCK_MODE: IX
          LOCK_STATUS: GRANTED
            LOCK_DATA: NULL
*************************** 2\. row ***************************
               ENGINE: INNODB
       ENGINE_LOCK_ID: 139664434886512:2:4:1:139664350544872
ENGINE_TRANSACTION_ID: 2569
            THREAD_ID: 46
             EVENT_ID: 12
        OBJECT_SCHEMA: test
          OBJECT_NAME: t1
       PARTITION_NAME: NULL
    SUBPARTITION_NAME: NULL
           INDEX_NAME: GEN_CLUST_INDEX
OBJECT_INSTANCE_BEGIN: 139664350544872
            LOCK_TYPE: RECORD
            LOCK_MODE: X
          LOCK_STATUS: GRANTED
            LOCK_DATA: supremum pseudo-record

与大多数性能模式数据收集不同，没有用于控制是否收集数据锁信息或用于控制数据锁表大小的仪器。性能模式收集服务器中已经可用的信息，因此生成此信息不会产生内存或 CPU 开销，也不需要控制其收集的参数。

使用data_locks表来帮助诊断在高并发负载时发生的性能问题。对于InnoDB，请参阅 Section 17.15.2, “InnoDB INFORMATION_SCHEMA Transaction and Locking Information”中关于此主题的讨论。

data_locks表具有以下列：

ENGINE

持有或请求锁的存储引擎。
ENGINE_LOCK_ID

存储引擎持有或请求的锁的 ID。(ENGINE_LOCK_ID, ENGINE)值的元组是唯一的。

锁 ID 格式是内部的，并随时可能更改。应用程序不应依赖于锁 ID 具有特定格式。
ENGINE_TRANSACTION_ID

请求锁的事务的存储引擎内部 ID。这可以被视为锁的所有者，尽管锁可能仍处于挂起状态，实际上尚未被授予（LOCK_STATUS='WAITING'）。

如果事务尚未执行任何写操作（仍被视为只读），则该列包含用户不应尝试解释的内部数据。否则，该列是事务 ID。

对于InnoDB，要获取有关事务的详细信息，请将此列与INFORMATION_SCHEMA INNODB_TRX表的TRX_ID列连接。
THREAD_ID

创建锁的会话的线程 ID。要获取有关线程的详细信息，请将此列与性能模式threads表的THREAD_ID列连接。

THREAD_ID可以与EVENT_ID一起使用，以确定在内存中创建锁数据结构的事件。（如果数据结构用于存储多个锁，则此事件可能发生在此特定锁请求发生之前。）
EVENT_ID

导致锁定的性能模式事件。(THREAD_ID, EVENT_ID)值的元组在其他性能模式表中隐式标识父事件：
- events_waits_*xxx*表中的父等待事件
- events_stages_*xxx*表中的父阶段事件
- events_statements_*xxx*表中的父语句事件
- events_transactions_current表中的父事务事件
要获取有关父事件的详细信息，请将THREAD_ID和EVENT_ID列与适当的父事件表中同名的列进行连接。参见 Section 29.19.2, “Obtaining Parent Event Information”。
OBJECT_SCHEMA

包含被锁定表的模式。
OBJECT_NAME

被锁定表的名称。
PARTITION_NAME

被锁定的分区的名称，如果有的话；否则为NULL。
SUBPARTITION_NAME

被锁定的子分区的名称，如果有的话；否则为NULL。
INDEX_NAME

被锁定的索引的名称，如果有的话；否则为NULL。

在实践中，InnoDB总是创建一个索引（GEN_CLUST_INDEX），因此对于InnoDB表，INDEX_NAME不是NULL。
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和间隙锁的信息，请参阅 Section 17.7.1, “InnoDB Locking”。
LOCK_STATUS

锁请求的状态。

该值取决于存储引擎。对于InnoDB，允许的值是GRANTED（持有锁）和WAITING（正在等待锁）。
LOCK_DATA

如果有锁相关的数据，则显示该数据。该值取决于存储引擎。对于InnoDB，如果LOCK_TYPE是RECORD，则显示一个值，否则该值为NULL。对于放置在主键索引上的锁，显示被锁定记录的主键值。对于放置在辅助索引上的锁，显示附加的主键值。如果没有主键，LOCK_DATA显示所选唯一索引的键值或唯一的InnoDB内部行 ID 号，根据InnoDB聚簇索引使用规则（参见 Section 17.6.2.1, “Clustered and Secondary Indexes”）。对于在伪记录上放置的锁，LOCK_DATA报告“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表。

注意

在 MySQL 8.0.1 之前，类似于性能模式data_locks表中的信息可在INFORMATION_SCHEMA.INNODB_LOCKS表中找到，该表提供有关每个InnoDB事务请求但尚未获取的锁以及每个由阻止另一个事务的事务持有的锁的信息。INFORMATION_SCHEMA.INNODB_LOCKS已被弃用，并在 MySQL 8.0.1 中移除。应改用data_locks。

INNODB_LOCKS和data_locks之间的区别：

如果一个事务持有锁，INNODB_LOCKS仅在另一个事务正在等待时显示该锁。data_locks无论是否有事务在等待，都会显示该锁。
data_locks表没有与LOCK_SPACE、LOCK_PAGE或LOCK_REC对应的列。
INNODB_LOCKS 表需要全局 PROCESS 权限。data_locks 表需要通常的 Performance Schema 权限，在表上具有 SELECT 权限才能被选择。

以下表格显示了从 INNODB_LOCKS 列到 data_locks 列的映射。使用这些信息将应用程序从一个表迁移到另一个表。

表 29.4 从 INNODB_LOCKS 到 data_locks 列的映射

INNODB_LOCKS 列	data_locks 列
`LOCK_ID`	`ENGINE_LOCK_ID`
`LOCK_TRX_ID`	`ENGINE_TRANSACTION_ID`
`LOCK_MODE`	`LOCK_MODE`
`LOCK_TYPE`	`LOCK_TYPE`
`LOCK_TABLE`（合并的模式/表名）	`OBJECT_SCHEMA`（模式名），`OBJECT_NAME`（表名）
`LOCK_INDEX`	`INDEX_NAME`
`LOCK_SPACE`	无
`LOCK_PAGE`	无
`LOCK_REC`	无
`LOCK_DATA`	`LOCK_DATA`
INNODB_LOCKS 列	data_locks 列

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

29.12.13.2 数据锁等待表

data_lock_waits表实现了一个多对多的关系，显示了data_locks表中的哪些数据锁请求被data_locks表中的哪些持有数据锁所阻塞。在data_lock_waits表中，只有当持有的锁阻止某些锁请求时，data_locks中的持有锁才会出现。

这些信息可以帮助您了解会话之间的数据锁依赖关系。该表不仅展示了会话或事务正在等待的锁，还展示了当前持有该锁的会话或事务。

数据锁等待信息示例：

mysql> SELECT * FROM performance_schema.data_lock_waits\G
*************************** 1\. row ***************************
                          ENGINE: 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

与大多数性能模式数据收集不同，没有用于控制是否收集数据锁信息或用于控制数据锁表大小的系统变量。性能模式收集服务器中已经可用的信息，因此生成此信息不会产生内存或 CPU 开销，也不需要控制其收集的参数。

使用data_lock_waits表来帮助诊断在高并发负载时发生的性能问题。对于InnoDB，请参阅 Section 17.15.2, “InnoDB INFORMATION_SCHEMA Transaction and Locking Information”中关于此主题的讨论。

因为data_lock_waits表中的列与data_locks表中的列类似，所以这里的列描述是缩写的。有关更详细的列描述，请参阅 Section 29.12.13.1, “The data_locks Table”。

data_lock_waits表具有以下列：

ENGINE

请求锁的存储引擎。
REQUESTING_ENGINE_LOCK_ID

存储引擎请求的锁的 ID。要获取有关锁的详细信息，请将此列与data_locks表的ENGINE_LOCK_ID列进行连接。
REQUESTING_ENGINE_TRANSACTION_ID

请求锁的事务的存储引擎内部 ID。
REQUESTING_THREAD_ID

请求锁的会话的线程 ID。
REQUESTING_EVENT_ID

导致请求锁的会话中的锁请求的性能模式事件。
REQUESTING_OBJECT_INSTANCE_BEGIN

请求锁的内存地址。
BLOCKING_ENGINE_LOCK_ID

阻塞锁的 ID。要获取有关锁的详细信息，请将此列与 data_locks 表的 ENGINE_LOCK_ID 列进行连接。
BLOCKING_ENGINE_TRANSACTION_ID

持有阻塞锁的事务的存储引擎内部 ID。
BLOCKING_THREAD_ID

持有阻塞锁的会话的线程 ID。
BLOCKING_EVENT_ID

导致持有阻塞锁的会话中的性能模式事件。
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 表。

注意

在 MySQL 8.0.1 之前，类似于性能模式 data_lock_waits 表中的信息可在 INFORMATION_SCHEMA.INNODB_LOCK_WAITS 表中找到，该表提供有关每个被阻塞的 InnoDB 事务的信息，指示其请求的锁以及阻止该请求的任何锁。INFORMATION_SCHEMA.INNODB_LOCK_WAITS 已被弃用，并在 MySQL 8.0.1 中移除。应改用 data_lock_waits。

这两个表在所需的权限上有所不同：INNODB_LOCK_WAITS 表需要全局 PROCESS 权限。data_lock_waits 表需要通常的从表中选择的性能模式权限 SELECT。

下表显示了从 INNODB_LOCK_WAITS 列到 data_lock_waits 列的映射。使用此信息将应用程序从一个表迁移到另一个表。

表 29.5 从 INNODB_LOCK_WAITS 到 data_lock_waits 列的映射

INNODB_LOCK_WAITS 列	data_lock_waits 列
`REQUESTING_TRX_ID`	`REQUESTING_ENGINE_TRANSACTION_ID`
`REQUESTED_LOCK_ID`	`REQUESTING_ENGINE_LOCK_ID`
`BLOCKING_TRX_ID`	`BLOCKING_ENGINE_TRANSACTION_ID`
`BLOCKING_LOCK_ID`	`BLOCKING_ENGINE_LOCK_ID`

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

29.12.13.3 元数据锁表

MySQL 使用元数据锁定来管理对数据库对象的并发访问，并确保数据一致性；参见第 10.11.4 节，“元数据锁定”。元数据锁定不仅适用于表，还适用于模式、存储程序（过程、函数、触发器、计划事件）、表空间、使用GET_LOCK()函数获取的用户锁（参见第 14.14 节，“锁定函数”）以及使用第 7.6.9.1 节，“锁定服务”中描述的锁定服务获取的锁。

性能模式通过metadata_locks表公开元数据锁信息：

已被授予的锁（显示哪些会话拥有哪些当前元数据锁）。
已请求但尚未授予的锁（显示哪些会话正在等待哪些元数据锁）。
已被死锁检测器杀死的锁请求。
已超时并正在等待请求会话的锁请求被丢弃的锁请求。

此信息使您能够了解会话之间的元数据锁依赖关系。您不仅可以看到会话正在等待哪个锁，还可以看到哪个会话当前持有该锁。

metadata_locks表是只读的，不能更新。默认情况下，它是自动调整大小的；要配置表大小，请在服务器启动时设置performance_schema_max_metadata_locks系统变量。

元数据锁仪表化使用默认启用的wait/lock/metadata/sql/mdl工具。

要在服务器启动时控制元数据锁仪表化状态，请在您的my.cnf文件中使用以下行：

启用：

[mysqld]
performance-schema-instrument='wait/lock/metadata/sql/mdl=ON'

禁用：

[mysqld]
performance-schema-instrument='wait/lock/metadata/sql/mdl=OFF'

要在运行时控制元数据锁仪表化状态，请更新setup_instruments表：

启用：

UPDATE performance_schema.setup_instruments
SET ENABLED = 'YES', TIMED = 'YES'
WHERE NAME = 'wait/lock/metadata/sql/mdl';

禁用：

UPDATE 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状态值简洁明了，表示元数据锁子系统在进入锁获取操作或离开锁释放操作时通知感兴趣的存储引擎。

metadata_locks表具有以下列：

OBJECT_TYPE

元数据锁子系统中使用的锁类型。该值是GLOBAL、SCHEMA、TABLE、FUNCTION、PROCEDURE、TRIGGER（当前未使用）、EVENT、COMMIT、USER LEVEL LOCK、TABLESPACE、BACKUP LOCK或LOCKING SERVICE之一。

USER LEVEL LOCK的值表示使用GET_LOCK()获取的锁。LOCKING SERVICE的值表示使用第 7.6.9.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 表。

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

29.12.13.4 表句柄表

性能模式通过table_handles表公开表锁信息，以显示每个打开的表句柄当前生效的表锁。

table_handles表是只读的，不能更新。默认情况下自动调整大小；要配置表大小，请在服务器启动时设置performance_schema_max_table_handles系统变量。

表锁仪表化使用wait/lock/table/sql/handler工具，这是默认启用的。

要在服务器启动时控制表锁仪表化状态，请在my.cnf文件中使用以下行：

启用：

[mysqld]
performance-schema-instrument='wait/lock/table/sql/handler=ON'

禁用：

[mysqld]
performance-schema-instrument='wait/lock/table/sql/handler=OFF'

要在运行时控制表锁仪表化状态，请更新setup_instruments表：

启用：

UPDATE performance_schema.setup_instruments
SET ENABLED = 'YES', TIMED = 'YES'
WHERE NAME = 'wait/lock/table/sql/handler';

禁用：

UPDATE 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表。

29.12.14 性能模式系统变量表

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

29.12.14.1 性能模式 persisted_variables 表

29.12.14.2 性能模式 variables_info 表

MySQL 服务器维护许多指示其配置方式的系统变量（参见 Section 7.1.8, “服务器系统变量”）。系统变量信息可以在这些性能模式表中找到：

global_variables: 全局系统变量。只需要全局值的应用程序应该使用这个表。
session_variables: 当前会话的系统变量。想要获取自己会话的所有系统变量值的应用程序应该使用这个表。它包括会话的会话变量，以及没有会话对应的全局变量的值。
variables_by_thread: 每个活动会话的会话系统变量。想要了解特定会话的会话变量值的应用程序应该使用这个表。它只包括会话变量，通过线程 ID 标识。
persisted_variables: 提供一个 SQL 接口，用于存储持久化全局系统变量设置的mysqld-auto.cnf文件。参见 Section 29.12.14.1, “性能模式 persisted_variables 表”。
variables_info: 显示每个系统变量最近设置的来源以及其值范围。参见 Section 29.12.14.2, “性能模式 variables_info 表”。

查看这些表中敏感系统变量的值需要SENSITIVE_VARIABLES_OBSERVER权限。

会话变量表（session_variables、variables_by_thread）仅包含活动会话的信息，而不包括已终止会话。

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 状态变量大于零。

不支持对性能模式系统变量表使用 TRUNCATE TABLE。

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

29.12.14.1 性能模式 persisted_variables 表

persisted_variables表提供了一个 SQL 接口，用于存储持久化全局系统变量设置的mysqld-auto.cnf文件，使得可以使用SELECT语句在运行时检查文件内容。变量使用SET PERSIST或PERSIST_ONLY语句进行持久化；请参阅第 15.7.6.1 节，“变量赋值的 SET 语法”。该表中包含文件中每个持久化系统变量的一行。未持久化的变量不会出现在表中。

查看此表中敏感系统变量的值需要SENSITIVE_VARIABLES_OBSERVER权限。

关于持久化系统变量的信息，请参阅第 7.1.9.3 节，“持久化系统变量”。

假设mysqld-auto.cnf看起来像这样（稍作重新格式化）：

{
  "Version": 1,
  "mysql_server": {
    "max_connections": {
      "Value": "1000",
      "Metadata": {
        "Timestamp": 1.519921706e+15,
        "User": "root",
        "Host": "localhost"
      }
    },
    "autocommit": {
      "Value": "ON",
      "Metadata": {
        "Timestamp": 1.519921707e+15,
        "User": "root",
        "Host": "localhost"
      }
    }
  }
}

然后persisted_variables具有以下内容：

mysql> SELECT * FROM performance_schema.persisted_variables;
+-----------------+----------------+
| VARIABLE_NAME   | VARIABLE_VALUE |
+-----------------+----------------+
| autocommit      | ON             |
| max_connections | 1000           |
+-----------------+----------------+

persisted_variables表具有以下列：

变量名

在mysqld-auto.cnf中列出的变量名。
变量值

在mysqld-auto.cnf中列出的变量值。

persisted_variables具有以下索引：

在(变量名)上的主键

TRUNCATE TABLE不允许用于persisted_variables表。

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

29.12.14.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的详细信息，请参见 Section 6.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    |
| port          |
+---------------+

显示从持久存储设置的变量：

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 | STRONG         | 0         | 0         |
+--------------------------+----------------+-----------+-----------+

29.12.15 性能模式状态变量表

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

MySQL 服务器维护许多状态变量，提供关于其操作的信息（请参阅第 7.1.10 节，“服务器状态变量”）。状态变量信息在这些性能模式表中可用：

global_status：全局状态变量。只想要全局值的应用程序应该使用这个表。
session_status：当前会话的状态变量。想要获取自己会话的所有状态变量值的应用程序应该使用这个表。它包括会话变量以及没有会话对应的全局变量的值。
status_by_thread：每个活动会话的会话状态变量。想要了解特定会话的会话变量值的应用程序应该使用这个表。它仅包含会话变量，通过线程 ID 进行标识。

还有汇总表，提供按帐户、主机名和用户名聚合的状态变量信息。请参阅第 29.12.20.12 节，“状态变量汇总表”。

会话变量表(session_status, status_by_thread)仅包含活动会话的信息，而不包括已终止的会话。

性能模式仅为threads中INSTRUMENTED值为YES的线程收集全局状态变量的统计信息。会话状态变量的统计信息始终会被收集，不受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
WHERE 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 将所有活动会话的状态添加到全局状态变量中，重置所有活动会话的状态，并重置从断开的会话中聚合的账户、主机和用户状态值。

posted @ 2024-06-23 16:27 绝不原创的飞龙阅读(14) 评论(0) 编辑收藏举报

刷新页面返回顶部

登录后才能查看或发表评论，立即登录或者逛逛博客园首页

相关博文：

· MySQL-并发教程-全-

· MySQL8-中文参考-二十九-

· MySQL之锁、事务、优化、OLAP、OLTP

· MySQL-15.锁

· 《MySQL 进阶篇》二十：锁

阅读排行：
· 震惊！C++程序真的从main开始吗？99%的程序员都答错了
· 【硬核科普】Trae如何「偷看」你的代码？零基础破解AI编程运行原理
· 单元测试从入门到精通
· 上周热点回顾（3.3-3.9）
· Vue3状态管理终极指南：Pinia保姆级教程

公告

Github：@wizardforcel

简书：@布客飞龙

微博：@布客飞龙

赞助我：

昵称：绝不原创的飞龙
园龄： 5年2个月
粉丝： 69
关注： 0

+加关注

2025年3月

日

一

二

三

四

五

六

掠夺·扩张·投机·博弈

MySQL8 中文参考（四十八）

29.12.2.2 The setup_consumers Table

29.12.2.3 setup_instruments 表

29.12.2.4 setup_objects表

29.12.2.5 The setup_threads Table

29.12.3 性能模式实例表

29.12.3.1 cond_instances 表

29.12.3.2 文件实例表

29.12.3.3 mutex_instances 表

29.12.3.4 rwlock_instances表

29.12.3.5 The socket_instances Table

29.12.4 性能模式等待事件表

配置等待事件收集

29.12.4.1 events_waits_current 表

29.12.4.2 事件等待历史表

29.12.4.3 events_waits_history_long 表

29.12.5 性能模式阶段事件表

配置阶段事件收集

阶段事件进度信息

29.12.5.1 events_stages_current 表

29.12.5.2 events_stages_history 表

29.12.5.3 events_stages_history_long 表

29.12.6 性能模式语句事件表

配置语句事件收集

语句监控

29.12.6.1 events_statements_current 表

29.12.6.2 events_statements_history 表

29.12.6.3 events_statements_history_long 表

29.12.6.4 prepared_statements_instances 表

29.12.7 性能模式事务表

配置事务事件收集

事务边界

事务仪表化

事务和嵌套事件

事务和存储程序

事务和保存点

事务和错误

29.12.7.1 事件事务当前表

29.12.7.2 事件事务历史表

29.12.7.3 事件事务历史长表

29.12.8 性能模式连接表

29.12.8.1 账户表

29.12.8.2 主机表

29.12.8.3 用户表

29.12.9 性能模式连接属性表

可用连接属性

连接属性限制

29.12.9.1 session_account_connect_attrs 表

29.12.9.2 session_connect_attrs 表

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

29.12.11 性能模式复制表

复制表描述

复制表的生命周期

复制品状态信息不在复制表中

复制通道

29.12.11.1 replication_connection_configuration 表

29.12.11.2 replication_connection_status 表

29.12.11.3 复制异步连接故障转移表

29.12.11.4 复制异步连接故障转移管理表

29.12.11.5 复制 _applier_configuration 表

29.12.11.6 复制 _applier_status 表

29.12.11.7 复制 _applier_status_by_coordinator 表

29.12.11.8 复制 _applier_status_by_worker 表

29.12.11.9 复制 _applier_global_filters 表

29.12.11.10 复制 _applier_filters 表

29.12.11.11 The replication_group_members Table

29.12.11.12 复制组成员统计表

29.12.11.13 复制组成员操作表

29.12.11.14 复制组配置版本表

29.12.11.15 replication_group_communication_information 表

29.12.11.16 binary_log_transaction_compression_stats表

29.12.12 性能模式 NDB 集群表

29.12.12.1 ndb_sync_pending_objects 表

29.12.12.2 ndb_sync_excluded_objects 表

29.12.13 性能模式锁表

29.12.13.1 数据锁表

29.12.13.2 数据锁等待表

29.12.13.3 元数据锁表

29.12.13.4 表句柄表

29.12.2.4 `setup_objects`表

29.12.3.4 `rwlock_instances`表

29.12.5.2 `events_stages_history` 表

29.12.6.3 `events_statements_history_long` 表

29.12.11.16 `binary_log_transaction_compression_stats`表

29.12.12.2 `ndb_sync_excluded_objects` 表