MySQL8 中文参考（一百零八）（mysql8.0中文）

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

原文：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 节“当前和过去事件的性能模式表”。

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

events_statements_current 表具有以下列：

线程_ID、事件_ID

与事件关联的线程以及事件启动时线程的当前事件号。 THREAD_ID 和EVENT_ID 值组合起来唯一标识该行。没有两行具有相同的值对。

END_EVENT_ID

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

活动名称

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

对于SQL语句，EVENT_NAME值最初是statement/com/Query，直到语句被解析，然后可选地如第29.12.6节“性能模式语句事件表”中所述更改为更合适的值。

酱

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

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 节“性能模式事件时序”。

锁定时间

等待表锁的时间。该值以微秒为单位测量，但已标准化为皮秒，以便于与其他性能模式计时器进行比较。

SQL_文本

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

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

消化

语句摘要SHA-256 值。表示为64 个十六进制字符的字符串。如果statements_digest 消费者为否，则为NULL。有关语句汇总的更多信息，请参阅性能架构语句汇总和采样。

DIGEST_TEXT

规范化的语句摘要文本。如果statements_digest 消费者为否，则为NULL。有关语句汇总的更多信息，请参阅性能架构语句汇总和采样。

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

消息文本

来自语句诊断区域的语句错误消息。

错误

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

警告

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

ROWS_AFFECTED

受语句影响的行数。请参阅mysql_affected_rows() 了解“受影响”的含义。

ROWS_SENT

语句返回的行数。

ROWS_EXAMINED

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

CREATED_TMP_DISK_TABLES

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

CREATED_TMP_TABLES

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

选择_FULL_JOIN

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

SELECT_FULL_RANGE_JOIN

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

选择范围

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

选择范围检查

与select_range_check 状态变量类似，但特定于语句。

选择扫描

与select_scan 状态变量类似，但特定于语句。

SORT_MERGE_PASSES

与sort_merge_passes 状态变量类似，但特定于语句。

排序范围

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

排序_行

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

排序扫描

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

NO_INDEX_USED

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

NO_GOOD_INDEX_USED

如果服务器找不到该语句的合适索引，则为1，否则为0。有关详细信息，请参阅EXPLAIN 输出格式中对EXPLAIN 输出中的每个记录值检查的附加列范围的描述。

NESTING_EVENT_ID、NESTING_EVENT_TYPE、NESTING_EVENT_LEVEL

这三列以及其他列提供有关顶级（非嵌套）语句和嵌套语句（在存储过程中执行）的以下信息：

对于顶层声明：

对象类型=空

对象架构=NULL

对象名称=NULL

NESTING_EVENT_ID=父事务的EVENT_ID

NESTING_EVENT_TYPE=\’交易\’

嵌套级别=0

对于嵌套语句：

OBJECT_TYPE=父语句的对象类型

OBJECT_SCHEMA=父语句的对象模式

OBJECT_NAME=父语句的对象名称

NESTING_EVENT_ID=父语句的EVENT_ID

NESTING_EVENT_TYPE=\’声明\’

NESTING_LEVEL=父语句NESTING_LEVEL 加1

语句_ID

由服务器在SQL 级别维护的查询ID。这些ID 是使用自动递增的全局计数器生成的，因此该值特定于服务器实例。此列是在MySQL 8.0.14 中添加的。

CPU时间

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

最大控制内存

报告语句在执行期间使用的最大控制内存量。

此列是在MySQL 8.0.31 中添加的。

最大总内存

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

此列是在MySQL 8.0.31 中添加的。

运行引擎

查询执行引擎。值为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）。

events_statements_current 表上允许TRUNCATE TABLE。删除一行。

原文：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 相同的列和索引。请参阅events_statements_current 表。

events_statements_history 表上允许TRUNCATE TABLE。删除一行。

要了解三个events_statements_*xxx* 事件表之间的关系，请参见第29.9 节“当前和过去事件的性能模式表”。

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

原文：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 表相同的列。请参阅events_statements_current 表。与events_statements_current 不同，events_statements_history_long 没有索引。

events_statements_history_long 表上允许TRUNCATE TABLE。删除一行。

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

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

原文：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_PREPAREmysql_stmt_execute()COM_STMT_EXECUTEmysql_stmt_close()COM_STMT_CLOSE 文本协议。通过SQL 语句访问并映射到下表中列出的底层服务器命令。

SQL 语句对应的服务器命令PREPARESQLCOM_PREPAREXECUTESQLCOM_EXECUTEDEALLOCATE PREPARE、DROP PREPARESQLCOM_DEALLOCATE PREPARE

Performance Schema 的准备好的语句工具涵盖了这两种协议。以下讨论描述服务器命令，而不是C API 函数或SQL 语句。

有关准备好的语句的信息可以在prepared_statements_instances 表中找到。该表允许您检查服务器使用的准备好的语句并提供有关它们的汇总统计信息。您可以在启动服务器时通过设置Performance_schema_max_prepared_statements_instances 系统变量来控制该表的大小。

收集准备好的语句信息取决于下表中列出的语句工具。这些工具默认启用。要更改这些，请更新setup_instruments 表。

toolsservercommandstatement/com/PrepareCOM_STMT_PREPAREstatement/com/ExecuteCOM_STMT_EXECUTEstatement/sql/prepare_sqlSQLCOM_PREPAREstatement/sql/execute_sqlSQLCOM_EXECUTE

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

准备声明

COM_STMT_PREPARE 或SQLCOM_PREPARE 命令在服务器上创建准备好的语句。成功检测语句后，新行将添加到prepared_statements_instances 表中。如果无法检测语句，则Performance_schema_prepared_statements_lost 状态变量会递增。

执行准备好的语句

在已检测的Prepared Statement 实例上运行COM_STMT_EXECUTE 或SQLCOM_PREPARE 命令会更新Prepared_statements_instances 表中的相应行。

发布准备好的声明

在已检测的Prepared Statement 实例上运行COM_STMT_CLOSE 或SQLCOM_DEALLOCATE_PREPARE 命令会删除相应的Prepared_statements_instances 表行。为了避免资源泄漏，即使禁用上述准备好的语句检测，也会发生删除。

prepare_statements_instances 表具有以下列：

OBJECT_INSTANCE_BEGIN

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

语句_ID

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

STATMENT_NAME

对于二进制协议，此列为NULL。对于文本协议，此列是用户分配的外部语句名称。例如，在以下SQL 语句中，准备好的语句的名称是stmt。

从“SELECT 1”准备stmt。

SQL_文本

准备好的语句的文本标记为？

OWNER_THREAD_ID、OWNER_EVENT_ID

这些列指示创建准备好的语句的事件。

OWNER_OBJECT_TYPE、OWNER_OBJECT_SCHEMA、OWNER_OBJECT_NAME

对于客户端会话创建的准备好的语句，这些列为NULL。对于由存储过程创建的准备好的语句，这些列指向存储过程。典型的用户错误是忘记发布准备好的语句。您可以使用这些列来查找泄漏准备好的语句的存储过程。

选择

OWNER_OBJECT_TYPE、OWNER_OBJECT_SCHEMA、OWNER_OBJECT_NAME、

语句名称、SQL_TEXT

FROM Performanceschema.prepared_statements_instances

其中OWNER_OBJECT_TYPE 不为NULL。

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

定时器_准备

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

COUNT_REPREPARE

内部重新准备语句的次数（请参见第10.10.3 节“准备语句和存储过程缓存”）。重新准备时间统计信息不可用，因为它们是作为语句执行的一部分而不是作为单独的操作来计算的。

COUNT_EXECUTE、SUM_TIMER_EXECUTE、MIN_TIMER_EXECUTE、AVG_TIMER_EXECUTE、MAX_TIMER_EXECUTE

有关准备好的语句执行的汇总统计信息。

总和_*xxx*

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

最大控制内存

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

此列是在MySQL 8.0.31 中添加的。

最大总内存

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

此列是在MySQL 8.0.31 中添加的。

prepare_statements_instances 表具有以下索引：

主键（OBJECT_INSTANCE_BEGIN）

(STATMENT_ID) 的索引

(STATMENT_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.1event_transaction_current_table

29.12.7.2 事件_交易_历史表

29.12.7.3 Event_Transaction_History_LongTable

性能模式衡量事务。在事件层次结构中，等待事件嵌套在阶段事件中，阶段事件嵌套在语句事件中，语句事件嵌套在事务事件中。

这些表存储事务事件。

events_transactions_current: 每个线程的当前事务事件。

events_transactions_history: 每个线程完成的最近事务事件。

events_transactions_history_long: 全局（跨所有线程）完成的最近事务事件。

下一节描述事务事件表。还有一个汇总表，汇总有关交易事件的信息。请参见第29.12.20.5 节“交易汇总表”。

有关三个事务事件表之间关系的更多信息，请参阅当前事件和过去事件的性能架构表。

配置交易事件集合

交易边界

交易衡量

事务和嵌套事件

事务和存储过程

事务和保存点

交易和错误

配置事务事件收集

您可以通过设置相关工具和消费者的状态来控制是否收集交易事件。

setup_instruments 表包含一个名为transaction 的工具。使用此工具可以启用或禁用单个事务事件类的收集。

setup_consumers 表包含与当前和过去的交易事件表名称相对应的消费者值。使用这些消费者来过滤您的交易事件集合。

默认情况下启用事务工具以及events_transactions_current 和events_transactions_history 事务使用者。

mysql 选择名称、启用、定时

来自Performance_schema.setup_instruments

WHERE NAME=\’交易\’;

+————-+———-+———-+

| 有效名称|

+-

————+———+——-+
| 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_NAMEChannel_nameHOSTSource_HostPORTSource_PortUSERSource_UserNETWORK_INTERFACESource_BindAUTO_POSITIONAuto_PositionSSL_ALLOWEDSource_SSL_AllowedSSL_CA_FILESource_SSL_CA_FileSSL_CA_PATHSource_SSL_CA_PathSSL_CERTIFICATESource_SSL_CertSSL_CIPHERSource_SSL_CipherSSL_KEYSource_SSL_KeySSL_VERIFY_SERVER_CERTIFICATESource_SSL_Verify_Server_CertSSL_CRL_FILESource_SSL_CrlSSL_CRL_PATHSource_SSL_CrlpathCONNECTION_RETRY_INTERVALSource_Connect_RetryCONNECTION_RETRY_COUNTSource_Retry_CountHEARTBEAT_INTERVAL无TLS_VERSIONSource_TLS_VersionPUBLIC_KEY_PATHSource_public_key_pathGET_PUBLIC_KEYGet_source_public_keyNETWORK_NAMESPACENetwork_NamespaceCOMPRESSION_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_UUIDMaster_UUIDTHREAD_IDNoneSERVICE_STATEReplica_IO_RunningRECEIVED_TRANSACTION_SETRetrieved_Gtid_SetLAST_ERROR_NUMBERLast_IO_ErrnoLAST_ERROR_MESSAGELast_IO_ErrorLAST_ERROR_TIMESTAMPLast_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_DELAYSQL_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_DELAYSQL_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_IDNoneSERVICE_STATEReplica_SQL_RunningLAST_ERROR_NUMBERLast_SQL_ErrnoLAST_ERROR_MESSAGELast_SQL_ErrorLAST_ERROR_TIMESTAMPLast_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_NUMBERLast_SQL_ErrnoLAST_ERROR_MESSAGELast_SQL_ErrorLAST_ERROR_TIMESTAMPLast_SQL_Error_Timestamp

#以上关于MySQL8 中文参考（一百零八）的相关内容来源网络仅供参考，相关信息请以官方公告为准！