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

布客飞龙
80 阅读49分钟

MySQL8 中文参考（一百零九）

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

译文：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_IDENGINE_LOCK_ID
LOCK_TRX_IDENGINE_TRANSACTION_ID
LOCK_MODELOCK_MODE
LOCK_TYPELOCK_TYPE
LOCK_TABLE（合并的模式/表名）OBJECT_SCHEMA（模式名），OBJECT_NAME（表名）
LOCK_INDEXINDEX_NAME
LOCK_SPACE无
LOCK_PAGE无
LOCK_REC无
LOCK_DATALOCK_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_IDREQUESTING_ENGINE_TRANSACTION_ID
REQUESTED_LOCK_IDREQUESTING_ENGINE_LOCK_ID
BLOCKING_TRX_IDBLOCKING_ENGINE_TRANSACTION_ID
BLOCKING_LOCK_IDBLOCKING_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 将所有活动会话的状态添加到全局状态变量中，重置所有活动会话的状态，并重置从断开的会话中聚合的账户、主机和用户状态值。

29.12.16 性能模式线程池表

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

29.12.16.1 线程组状态表

29.12.16.2 线程组统计表

29.12.16.3 线程状态表

注意

此处描述的性能模式表自 MySQL 8.0.14 版本起可用。在 MySQL 8.0.14 之前，请改用相应的INFORMATION_SCHEMA表；请参阅第 28.5 节，“INFORMATION_SCHEMA 线程池表”。

以下部分描述了与线程池插件相关的性能模式表（参见第 7.6.3 节，“MySQL 企业线程池”）。它们提供有关线程池操作的信息：

  • tp_thread_group_state：关于线程池线程组状态的信息。

  • tp_thread_group_stats：线程组统计信息。

  • tp_thread_state：关于线程池线程状态的信息。

这些表中的行代表时间的快照。在tp_thread_state的情况下，线程组的所有行组成一个时间快照。因此，MySQL 服务器在生成快照时持有线程组的互斥锁。但它不会同时持有所有线程组的互斥锁，以防止针对tp_thread_state的语句阻塞整个 MySQL 服务器。

性能模式线程池表由线程池插件实现，并在加载和卸载该插件时加载和卸载（参见第 7.6.3.2 节，“线程池安装”）。表不需要特殊配置步骤。但是，表依赖于启用线程池插件。如果加载了线程池插件但未启用，则不会创建表。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-tp-thread-group-state-table.html

29.12.16.1 The tp_thread_group_state Table

注意

此处描述的性能模式表在 MySQL 8.0.14 版本中可用。在 MySQL 8.0.14 之前，请改用相应的 INFORMATION_SCHEMA 表；参见 Section 28.5.2, “The INFORMATION_SCHEMA TP_THREAD_GROUP_STATE Table”。

tp_thread_group_state 表中每个线程组都有一行。每行提供有关组的当前状态的信息。

tp_thread_group_state 表具有以下列：

  • TP_GROUP_ID

    线程组 ID。这是表中的唯一键。

  • CONSUMER THREADS

    消费者线程的数量。如果活动线程变得停滞或阻塞，最多有一个线程准备开始执行。

  • RESERVE_THREADS

    保留状态中的线程数。这意味着直到需要唤醒新线程且没有消费者线程时才会启动它们。当线程组创建的线程多于正常操作所需的线程时，大多数线程都会进入此状态。通常，线程组需要额外的线程一小段时间，然后一段时间内不再需要它们。在这种情况下，它们进入保留状态，并保持直到再次需要。它们占用一些��外的内存资源，但不占用额外的计算资源。

  • CONNECT_THREAD_COUNT

    处理或等待处理连接初始化和身份验证的线程数。每个线程组最多可以有四个连接线程；这些线程在一段不活动时间后会过期。

  • CONNECTION_COUNT

    使用此线程组的连接数。

  • QUEUED_QUERIES

    高优先级队列中等待的语句数量。

  • QUEUED_TRANSACTIONS

    低优先级队列中等待的语句数量。这些是尚未开始的事务的初始语句，因此它们也代表排队的事务。

  • STALL_LIMIT

    线程组的thread_pool_stall_limit 系统变量的值。这对于所有线程组都是相同的值。

  • PRIO_KICKUP_TIMER

    线程组的thread_pool_prio_kickup_timer 系统变量的值。这对于所有线程组都是相同的值。

  • ALGORITHM

    线程组的thread_pool_algorithm 系统变量的值。这对于所有线程组都是相同的值。

  • 线程计数

    作为线程组的一部分启动的线程数。

  • 活动线程计数

    在执行语句的活动线程数。

  • 停滞线程计数

    线程组中停滞语句的数量。停滞的语句可能正在执行，但从线程池的角度来看，它们停滞不前。长时间运行的语句很快就会进入这个类别。

  • 等待线程编号

    如果有一个线程处理线程组中语句的轮询，这指定了该线程组内的线程编号。这个线程可能正在执行语句。

  • 最老的排队

    最老的排队语句等待执行的毫秒数。

  • 线程组中的最大线程 ID

    线程组中线程的最大线程 ID。当从tp_thread_state表中选择线程时，这与MAX(TP_THREAD_NUMBER)相同。也就是说，这两个查询是等效的：

    SELECT TP_GROUP_ID, MAX_THREAD_IDS_IN_GROUP
FROM tp_thread_group_state;

SELECT TP_GROUP_ID, MAX(TP_THREAD_NUMBER)
FROM tp_thread_state GROUP BY TP_GROUP_ID;

tp_thread_group_state表具有以下索引：

  • (TP_GROUP_ID)上的唯一索引

不允许对tp_thread_group_state表进行TRUNCATE TABLE。

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

29.12.16.2 The tp_thread_group_stats Table

注意

此处描述的性能模式表在 MySQL 8.0.14 版本中可用。在 MySQL 8.0.14 之前，请改用相应的 INFORMATION_SCHEMA 表；请参阅第 28.5.3 节，“INFORMATION_SCHEMA TP_THREAD_GROUP_STATS 表”。

tp_thread_group_stats 表报告每个线程组的统计信息。每个组有一行。

tp_thread_group_stats 表具有以下列：

  • TP_GROUP_ID

    线程组 ID。这是表内的唯一键。

  • CONNECTIONS_STARTED

    开始的连接数量。

  • CONNECTIONS_CLOSED

    连接关闭的次数。

  • QUERIES_EXECUTED

    执行的语句数量。当语句开始执行时，此数字会递增，而不是在语句执行完成时。

  • QUERIES_QUEUED

    接收到的排队等待执行的语句数量。这不包括线程组能够立即开始执行而无需排队的语句，这可能发生在第 7.6.3.3 节，“线程池操作”中描述的条件下。

  • THREADS_STARTED

    启动的线程数量。

  • PRIO_KICKUPS

    根据 thread_pool_prio_kickup_timer 系统变量的值，已从低优先级队列移至高优先级队列的语句数量。如果此数字快速增加，请考虑增加该变量的值。快速增加的计数器意味着优先级系统未能阻止事务过早启动。对于 InnoDB，这很可能意味着由于太多并发事务而导致性能下降。

  • STALLED_QUERIES_EXECUTED

    由于执行时间超过 thread_pool_stall_limit 系统变量的值而被定义为停滞的语句数量。

  • BECOME_CONSUMER_THREAD

    已分配消费者线程角色的次数。

  • BECOME_RESERVE_THREAD

    已分配保留线程角色的次数。

  • BECOME_WAITING_THREAD

    线程被分配等待线程角色的次数。当语句被排队时，即使在正常操作中，这种情况也经常发生，因此在负载高的系统中，语句排队的情况下，这个值的快速增加是正常的。

  • WAKE_THREAD_STALL_CHECKER

    检查线程决定唤醒或创建线程以处理某些语句或处理等待线程角色的次数。

  • SLEEP_WAITS

    THD_WAIT_SLEEP等待的次数。当线程进入睡眠状态时（例如，通过调用SLEEP()函数）会发生这种情况。

  • DISK_IO_WAITS

    THD_WAIT_DISKIO等待的次数。当线程执行磁盘 I/O 时，很可能不会命中文件系统缓存。这种等待发生在缓冲池读取和写入数据到磁盘时，而不是正常的文件读取和写入时。

  • ROW_LOCK_WAITS

    THD_WAIT_ROW_LOCK等待另一个事务释放行锁的次数。

  • GLOBAL_LOCK_WAITS

    THD_WAIT_GLOBAL_LOCK等待全局锁释放的次数。

  • META_DATA_LOCK_WAITS

    THD_WAIT_META_DATA_LOCK等待元数据锁释放的次数。

  • TABLE_LOCK_WAITS

    THD_WAIT_TABLE_LOCK等待表被解锁以便语句访问的次数。

  • USER_LOCK_WAITS

    THD_WAIT_USER_LOCK等待用户线程构造的特殊锁的次数。

  • BINLOG_WAITS

    THD_WAIT_BINLOG_WAITS等待二进制日志释放的次数。

  • GROUP_COMMIT_WAITS

    THD_WAIT_GROUP_COMMIT等待的次数。当组提交必须等待其他方完成事务的一部分时会发生这种情况。

  • FSYNC_WAITS

    THD_WAIT_SYNC等待文件同步操作的次数。

tp_thread_group_stats表具有以下索引：

  • 在(TP_GROUP_ID)上的唯一索引

TRUNCATE TABLE不允许用于tp_thread_group_stats表。

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

29.12.16.3 tp_thread_state 表

注意

此处描述的性能模式表可在 MySQL 8.0.14 及更高版本中使用。在 MySQL 8.0.14 之前，请改用相应的INFORMATION_SCHEMA表；参见 Section 28.5.4, “INFORMATION_SCHEMA TP_THREAD_STATE 表”。

tp_thread_state表每个由线程池创建的用于处理连接的线程都有一行。

tp_thread_state表具有以下列：

  • TP_GROUP_ID

    线程组 ID。

  • TP_THREAD_NUMBER

    线程在其线程组内的 ID。TP_GROUP_ID和TP_THREAD_NUMBER一起在表中提供唯一键。

  • PROCESS_COUNT

    该线程当前正在执行的语句所使用的 10ms 间隔。0 表示没有语句正在执行，1 表示在第一个 10ms 内，依此类推。

  • WAIT_TYPE

    线程的等待类型。NULL表示线程未被阻塞。否则，线程被thd_wait_begin()调用阻塞，值指定等待类型。tp_thread_group_stats表的*xxx*_WAIT列累积每种等待类型的计数。

    WAIT_TYPE值是描述等待类型的字符串，如下表所示。

    表 29.6 tp_thread_state 表 WAIT_TYPE 值

    等待类型含义
    THD_WAIT_SLEEP等待睡眠
    THD_WAIT_DISKIO等待磁盘 IO
    THD_WAIT_ROW_LOCK等待行锁
    THD_WAIT_GLOBAL_LOCK等待全局锁
    THD_WAIT_META_DATA_LOCK等待元数据锁
    THD_WAIT_TABLE_LOCK等待表锁
    THD_WAIT_USER_LOCK等待用户锁
    THD_WAIT_BINLOG等待 binlog
    THD_WAIT_GROUP_COMMIT等待组提交
    THD_WAIT_SYNC等待 fsync
    等待类型含义

  • TP_THREAD_TYPE

    线程的类型。此列中显示的值是CONNECTION_HANDLER_WORKER_THREAD、LISTENER_WORKER_THREAD、QUERY_WORKER_THREAD或TIMER_WORKER_THREAD之一。

    此列是在 MySQL 8.0.32 中添加的。

  • THREAD_ID

    此线程的唯一标识符。该值与性能模式threads表的THREAD_ID列中使用的值相同。

    此列是在 MySQL 8.0.32 中添加的。

tp_thread_state表具有以下索引：

  • (TP_GROUP_ID, TP_THREAD_NUMBER)上的唯一索引

TRUNCATE TABLE 不允许用于 tp_thread_state 表。

29.12.17 性能模式防火墙表

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

29.12.17.1 firewall_groups 表

29.12.17.2 firewall_group_allowlist 表

29.12.17.3 firewall_membership 表

注意

此处描述的性能模式表在 MySQL 8.0.23 版本中可用。在 MySQL 8.0.23 之前，请改用相应的 INFORMATION_SCHEMA 表；请参阅 MySQL 企业防火墙表。

以下各节描述了与 MySQL 企业防火墙相关的性能模式表（请参阅 第 8.4.7 节，“MySQL 企业防火墙”）。它们提供有关防火墙操作的信息：

  • firewall_groups: 关于防火墙组配置文件的信息。

  • firewall_group_allowlist: 注册防火墙组配置文件的允许列表规则。

  • firewall_membership: 注册防火墙组配置文件的成员（帐户）。

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

29.12.17.1 防火墙组表

firewall_groups 表提供了对 MySQL 企业防火墙内存数据缓存的视图。它列出了注册的防火墙组配置文件的名称和操作模式。它与提供防火墙数据持久存储的 mysql.firewall_groups 系统表一起使用；请参阅 MySQL 企业防火墙表。

firewall_groups 表具有以下列：

  • 名称

    组配置文件名称。

  • 模式

    配置文件的当前操作模式。允许的模式值为 OFF、DETECTING、PROTECTING 和 RECORDING。有关其含义的详细信息，请参阅 防火墙概念。

  • 用户主机

    组配置文件的训练账户，在配置文件处于 RECORDING 模式时使用。数值为 NULL，或格式为 *user_name*@*host_name* 的非NULL账户：

    • 如果数值为 NULL，防火墙记录允许来自任何组成员账户的语句。

    • 如果数值为非NULL，防火墙记录仅允许来自指定账户（应为组成员）的语句。

firewall_groups 表没有索引。

不允许对 firewall_groups 表使用 TRUNCATE TABLE。

firewall_groups 表在 MySQL 8.0.23 中添加。

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

29.12.17.2 The firewall_group_allowlist Table

firewall_group_allowlist 表提供了对 MySQL Enterprise Firewall 内存数据缓存的视图。它列出了已注册防火墙组配置文件的允许规则。它与提供防火墙数据持久存储的 mysql.firewall_group_allowlist 系统表一起使用；请参阅 MySQL Enterprise Firewall Tables。

firewall_group_allowlist 表包含以下列：

  • NAME

    组配置文件名称。

  • RULE

    表示配置文件可接受语句模式的规范化语句。配置文件允许列表是其规则的并集。

firewall_group_allowlist 表没有索引。

TRUNCATE TABLE 不允许用于 firewall_group_allowlist 表。

firewall_group_allowlist 表在 MySQL 8.0.23 中添加。

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

29.12.17.3 The firewall_membership Table

firewall_membership 表提供了一个查看 MySQL Enterprise Firewall 内存数据缓存的视图。它列出了注册防火墙组个人资料的成员（账户）。它与提供防火墙数据持久存储的 mysql.firewall_membership 系统表一起使用；参见 MySQL Enterprise Firewall Tables。

firewall_membership 表有以下列：

  • GROUP_ID

    组个人资料名称。

  • MEMBER_ID

    一个属于个人资料的账户名称。

firewall_membership 表没有索引。

TRUNCATE TABLE 不允许用于 firewall_membership 表。

firewall_membership 表在 MySQL 8.0.23 中添加。

29.12.18 Performance Schema Keyring Tables

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

29.12.18.1 The keyring_component_status Table

29.12.18.2 The keyring_keys table

以下各节描述了与 MySQL 密钥环相关的性能模式表（参见 Section 8.4.4, “The MySQL Keyring”）。它们提供有关密钥环操作的信息：

  • keyring_component_status: 关于正在使用的密钥环组件的信息。

  • keyring_keys: MySQL 密钥环中密钥的元数据。

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

29.12.18.1 密钥环组件状态表

keyring_component_status 表（自 MySQL 8.0.24 起可用）提供有关正在使用的密钥环组件属性的状态信息，如果已安装密钥环组件。如果未安装密钥环组件（例如，如果未使用密钥环，或者配置为使用密钥环插件而不是密钥环组件管理密钥库），则表为空。

没有固定的属性集。每个密钥环组件可以自由定义自己的属性集。

示例 keyring_component_status 内容：

mysql> SELECT * FROM performance_schema.keyring_component_status;
+---------------------+-------------------------------------------------+
| STATUS_KEY          | STATUS_VALUE                                    |
+---------------------+-------------------------------------------------+
| Component_name      | component_keyring_file                          |
| Author              | Oracle Corporation                              |
| License             | GPL                                             |
| Implementation_name | component_keyring_file                          |
| Version             | 1.0                                             |
| Component_status    | Active                                          |
| Data_file           | /usr/local/mysql/keyring/component_keyring_file |
| Read_only           | No                                              |
+---------------------+-------------------------------------------------+

keyring_component_status 表具有以下列：

  • STATUS_KEY

    状态项名称。

  • STATUS_VALUE

    状态项值。

keyring_component_status 表没有索引。

TRUNCATE TABLE 不允许用于 keyring_component_status 表。

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

29.12.18.2 密钥环键表

MySQL 服务器支持一个密钥环，使内部服务器组件和插件能够安全地存储敏感信息以供以后检索。参见 第 8.4.4 节，“MySQL 密钥环”。

截至 MySQL 8.0.16，keyring_keys 表公开密钥环中密钥的元数据。密钥元数据包括密钥 ID、密钥所有者和后端密钥 ID。keyring_keys 表 不 公开任何敏感的密钥环数据，如密钥内容。

keyring_keys 表包含以下列：

  • KEY_ID

    密钥标识符。

  • KEY_OWNER

    密钥的所有者。

  • BACKEND_KEY_ID

    密钥环后端使用的密钥 ID。

keyring_keys 表没有索引。

截断表 不允许用于 keyring_keys 表。

29.12.19 性能模式克隆表

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

29.12.19.1 克隆状态表

29.12.19.2 克隆进度表

注意

这里描述的性能模式表在 MySQL 8.0.17 版本中可用。

以下部分描述了与克隆插件相关的性能模式表（参见第 7.6.7 节，“克隆插件”）。这些表提供有关克隆操作的信息。

  • clone_status: 当前或最近执行的克隆操作的状态信息。

  • clone_progress: 当前或最近执行的克隆操作的进度信息。

性能模式克隆表由克隆插件实现，并在加载和卸载该插件时加载和卸载（参见第 7.6.7.1 节，“安装克隆插件”）。表不需要特殊配置步骤。但是，表依赖于克隆插件的启用。如果加载了克隆插件但未启用，则不会创建表。

性能模式克隆插件表仅在接收端 MySQL 服务器实例上使用。数据在服务器关闭和重启时持久化。

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

29.12.19.1 克隆状态表

注意

此处描述的性能模式表自 MySQL 8.0.17 起可用。

clone_status表仅显示当前或最后执行的克隆操作的状态。该表只包含一行数据，或为空。

clone_status表包含以下列：

  • ID

    当前 MySQL 服务器实例中的唯一克隆操作标识符。

  • PID

    执行克隆操作的会话的进程列表 ID。

  • STATE

    克隆操作的当前状态。值包括Not Started、In Progress、Completed和Failed。

  • BEGIN_TIME

    克隆操作开始时的时间戳格式为'*YYYY-MM-DD hh:mm:ss*[.*fraction`*]'。

  • END_TIME

    克隆操作完成时的时间戳格式为'*YYYY-MM-DD hh:mm:ss*[.*fraction`*]'。如果操作尚未结束，则报告 NULL。

  • SOURCE

    源 MySQL 服务器地址以'HOST:PORT'格式显示。对于本地克隆操作，该列显示'LOCAL INSTANCE'。

  • DESTINATION

    正在进行克隆的目录。

  • ERROR_NO

    克隆操作失败时报告的错误编号。

  • ERROR_MESSAGE

    克隆操作失败时的错误消息字符串。

  • BINLOG_FILE

    数据被克隆到的二进制日志文件的名称。

  • BINLOG_POSITION

    数据被克隆到的二进制日志文件偏移量。

  • GTID_EXECUTED

    最后一个克隆事务的 GTID 值。

clone_status表是只读的。不允许 DDL，包括TRUNCATE TABLE。

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

29.12.19.2 clone_progress 表

注意

此处描述的性能模式表自 MySQL 8.0.17 起可用。

clone_progress 表仅显示当前或最近执行的克隆操作的进度信息。

克隆操作的阶段包括 DROP DATA、FILE COPY、PAGE_COPY、REDO_COPY、FILE_SYNC、RESTART 和 RECOVERY。每个阶段都会生成一条记录。因此，表中只包含七行数据，或为空。

clone_progress 表具有以下列：

  • ID

    当前 MySQL 服务器实例中的唯一克隆操作标识符。

  • STAGE

    当前克隆阶段的名称。阶段包括 DROP DATA、FILE COPY、PAGE_COPY、REDO_COPY、FILE_SYNC、RESTART 和 RECOVERY。

  • STATE

    当前克隆阶段的当前状态。状态包括 Not Started、In Progress 和 Completed。

  • BEGIN_TIME

    以'*YYYY-MM-DD hh:mm:ss*[.*fraction*]'格式的时间戳，显示克隆阶段何时开始。如果阶段尚未开始，则报告 NULL。

  • END_TIME

    以'*YYYY-MM-DD hh:mm:ss*[.*fraction*]'格式的时间戳，显示克隆阶段何时完成。如果阶段尚未结束，则报告 NULL。

  • THREADS

    阶段中使用的并发线程数。

  • ESTIMATE

    当前阶段的估计数据量，以字节为单位。

  • DATA

    当前状态下传输的数据量，以字节为单位。

  • NETWORK

    当前状态下传输的网络数据量，以字节为单位。

  • DATA_SPEED

    数据传输的当前实际速度，以每秒字节计。此值可能与由clone_max_data_bandwidth定义的请求的最大数据传输速率不同。

  • NETWORK_SPEED

    当前网络传输速度，以每秒字节计。

clone_progress 表是只读的。不允许 DDL，包括TRUNCATE TABLE。

29.12.20 性能模式摘要表

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

29.12.20.1 等待事件摘要表

29.12.20.2 阶段摘要表

29.12.20.3 语句摘要表

29.12.20.4 语句直方图摘要表

29.12.20.5 事务摘要表

29.12.20.6 对象等待摘要表

29.12.20.7 文件 I/O 摘要表

29.12.20.8 表 I/O 和锁等待摘要表

29.12.20.9 套接字摘要表

29.12.20.10 内存摘要表

29.12.20.11 错误摘要表

29.12.20.12 状态变量摘要表

摘要表提供了随时间终止事件的聚合信息。此组中的表以不同方式总结事件数据。

每个摘要表都有分组列，用于确定如何对数据进行聚合，并包含聚合值的摘要列。通常，以类似方式总结事件的表具有类似的摘要列集，并且仅在用于确定如何聚合事件的分组列方面有所不同。

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

等待事件摘要

表 29.7 性能模式等待事件摘要表

表名描述
events_waits_summary_by_account_by_event_name每个帐户和事件名称的等待事件
events_waits_summary_by_host_by_event_name每个主机名和事件名称的等待事件
events_waits_summary_by_instance每个实例的等待事件
events_waits_summary_by_thread_by_event_name每个线程和事件名称的等待事件
events_waits_summary_by_user_by_event_name按用户名称和事件名统计等待事件
events_waits_summary_global_by_event_name按事件名统计等待事件

阶段摘要

表 29.8 性能模式阶段事件摘要表

表名描述
events_stages_summary_by_account_by_event_name按账户和事件名统计阶段事件
events_stages_summary_by_host_by_event_name按主机名和事件名统计阶段事件
events_stages_summary_by_thread_by_event_name按线程和事件名统计阶段等待
events_stages_summary_by_user_by_event_name按用户名称和事件名统计阶段事件
events_stages_summary_global_by_event_name按事件名统计阶段等待

语句摘要

表 29.9 性能模式语句事件摘要表

表名描述
events_statements_histogram_by_digest按模式和摘要值统计语句直方图
events_statements_histogram_global全局汇总的语句直方图
events_statements_summary_by_account_by_event_name按账户和事件名统计语句事件
events_statements_summary_by_digest按模式和摘要值统计语句事件
events_statements_summary_by_host_by_event_name按主机名和事件名统计语句事件
events_statements_summary_by_program按存储程序统计语句事件
events_statements_summary_by_thread_by_event_name按线程和事件名统计语句事件
events_statements_summary_by_user_by_event_name按用户名称和事件名统计语句事件
events_statements_summary_global_by_event_name按事件名称分类的语句事件
prepared_statements_instances准备语句实例和统计信息
表名描述

事务摘要

表 29.10 性能模式事务事件摘要表

表名描述
events_transactions_summary_by_account_by_event_name按帐户和事件名称分类的事务事件
events_transactions_summary_by_host_by_event_name按主机名和事件名称分类的事务事件
events_transactions_summary_by_thread_by_event_name按线程和事件名称分类的事务事件
events_transactions_summary_by_user_by_event_name按用户名和事件名称分类的事务事件
events_transactions_summary_global_by_event_name按事件名称分类的事务事件

对象等待摘要

表 29.11 性能模式对象事件摘要表

表名描述
objects_summary_global_by_type对象摘要

文件 I/O 摘要

表 29.12 性能模式文件 I/O 事件摘要表

表名描述
file_summary_by_event_name按事件名称分类的文件事件
file_summary_by_instance按文件实例分类的文件事件

表 I/O 和锁等待摘要

表 29.13 性能模式表 I/O 和锁等待事件摘要表

表名描述
table_io_waits_summary_by_index_usage按索引分类的表 I/O 等待
table_io_waits_summary_by_table按表分类的表 I/O 等待
table_lock_waits_summary_by_table每个表的表锁等待

套接字摘要

表 29.14 性能模式套接字事件摘要表

表名称描述
socket_summary_by_event_name每个事件名称的套接字等待和 I/O
socket_summary_by_instance每个实例的套接字等待和 I/O

内存摘要

表 29.15 性能模式内存操作摘要表

表名称描述
memory_summary_by_account_by_event_name每个帐户和事件名称的内存操作
memory_summary_by_host_by_event_name每个主机和事件名称的内存操作
memory_summary_by_thread_by_event_name每个线程和事件名称的内存操作
memory_summary_by_user_by_event_name每个用户和事件名称的内存操作
memory_summary_global_by_event_name每个事件名称的全局内存操作

错误摘要

表 29.16 性能模式错误摘要表

表名称描述
events_errors_summary_by_account_by_error每个帐户和错误代码的错误
events_errors_summary_by_host_by_error每个主机和错误代码的错误
events_errors_summary_by_thread_by_error每个线程和错误代码的错误
events_errors_summary_by_user_by_error每个用户和错误代码的错误
events_errors_summary_global_by_error每个错误代码的错误

状态变量摘要

表 29.17 性能模式错误状态变量摘要表

表名称描述
status_by_account每个帐户的会话状态变量
status_by_host每个主机名称的会话状态变量
status_by_user每个用户名称的会话状态变量
avatar
文章
阅读
粉丝