MySQL8-中文参考-一百一十-

布客飞龙
102 阅读1小时+

MySQL8 中文参考（一百一十）

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

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

29.12.20.1 等待事件摘要表

性能模式维护表用于收集当前和最近的等待事件，并在摘要表中汇总这些信息。第 29.12.4 节，“性能模式等待事件表”描述了等待摘要的基础事件。请参阅该讨论以获取有关等待事件内容、当前和最近的等待事件表以及如何控制等待事件收集（默认情况下已禁用）的信息。

示例等待事件摘要信息：

mysql> SELECT *
       FROM performance_schema.events_waits_summary_global_by_event_name\G
...
*************************** 6\. row ***************************
    EVENT_NAME: wait/synch/mutex/sql/BINARY_LOG::LOCK_index
    COUNT_STAR: 8
SUM_TIMER_WAIT: 2119302
MIN_TIMER_WAIT: 196092
AVG_TIMER_WAIT: 264912
MAX_TIMER_WAIT: 569421
...
*************************** 9\. row ***************************
    EVENT_NAME: wait/synch/mutex/sql/hash_filo::lock
    COUNT_STAR: 69
SUM_TIMER_WAIT: 16848828
MIN_TIMER_WAIT: 0
AVG_TIMER_WAIT: 244185
MAX_TIMER_WAIT: 735345
...

每个等待事件摘要表都有一个或多个分组列，用于指示表如何聚合事件。事件名称指的是setup_instruments表中事件工具的名称：

  • events_waits_summary_by_account_by_event_name具有EVENT_NAME、USER和HOST列。每行总结了给定帐户（用户和主机组合）和事件名称的事件。

  • events_waits_summary_by_host_by_event_name具有EVENT_NAME和HOST列。每行总结了给定主机和事件名称的事件。

  • events_waits_summary_by_instance具有EVENT_NAME和OBJECT_INSTANCE_BEGIN列。每行总结了给定事件名称和对象的事件。如果一个工具用于创建多个实例，则每个实例都有一个唯一的OBJECT_INSTANCE_BEGIN值，并在此表中单独进行总结。

  • events_waits_summary_by_thread_by_event_name具有THREAD_ID和EVENT_NAME列。每行总结了给定线程和事件名称的事件。

  • events_waits_summary_by_user_by_event_name具有EVENT_NAME和USER列。每行总结了给定用户和事件名称的事件。

  • events_waits_summary_global_by_event_name具有一个EVENT_NAME列。每行总结了给定事件名称的事件。一个工具可能用于创建被检测对象的多个实例。例如，如果为每个连接创建一个互斥体的工具，则实例的数量与连接数量相同。工具的摘要行总结了所有这些实例。

每个等待事件摘要表都有这些包含聚合值的摘要列：

  • COUNT_STAR

    汇总事件的数量。此值包括所有事件，无论是定时的还是非定时的。

  • SUM_TIMER_WAIT

    汇总定时事件的总等待时间。此值仅针对定时事件计算，因为非定时事件的等待时间为 NULL。对于其他 *xxx*_TIMER_WAIT 值也是如此。

  • MIN_TIMER_WAIT

    汇总定时事件的最小等待时间。

  • AVG_TIMER_WAIT

    汇总定时事件的平均等待时间。

  • MAX_TIMER_WAIT

    汇总定时事件的最大等待时间。

等待事件汇总表具有以下索引：

  • events_waits_summary_by_account_by_event_name:

    • 主键在 (USER, HOST, EVENT_NAME)

  • events_waits_summary_by_host_by_event_name:

    • 主键在 (HOST, EVENT_NAME)

  • events_waits_summary_by_instance:

    • 主键在 (OBJECT_INSTANCE_BEGIN)

    • 在 (EVENT_NAME) 上的索引

  • events_waits_summary_by_thread_by_event_name:

    • 主键在 (THREAD_ID, EVENT_NAME)

  • events_waits_summary_by_user_by_event_name:

    • 主键在 (USER, EVENT_NAME)

  • events_waits_summary_global_by_event_name:

    • 主键在 (EVENT_NAME)

TRUNCATE TABLE 允许用于等待汇总表。它具有以下效果：

  • 对于不按帐户、主机或用户汇总的汇总表，截断会将汇总列重置为零，而不是删除行。

  • 对于按帐户、主机或用户汇总的汇总表，截断会删除没有连接的帐户、主机或用户的行，并将剩余行的汇总列重置为零。

此外，每个按帐户、主机、用户或线程汇总的等待汇总表在其依赖的连接表被截断或 events_waits_summary_global_by_event_name 被截断时会被隐式截断。有关详细信息，请参见 第 29.12.8 节，“性能模式连接表”。

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

29.12.20.2 阶段摘要表

性能模式维护用于收集当前和最近阶段事件的表，并在摘要表中聚合该信息。Section 29.12.5, “性能模式阶段事件表”描述了阶段摘要的基础事件。请参阅该讨论以获取有关阶段事件内容、当前和历史阶段事件表以及如何控制阶段事件收集（默认情况下已禁用）的信息。

示例阶段事件摘要信息：

mysql> SELECT *
       FROM performance_schema.events_stages_summary_global_by_event_name\G
...
*************************** 5\. row ***************************
    EVENT_NAME: stage/sql/checking permissions
    COUNT_STAR: 57
SUM_TIMER_WAIT: 26501888880
MIN_TIMER_WAIT: 7317456
AVG_TIMER_WAIT: 464945295
MAX_TIMER_WAIT: 12858936792
...
*************************** 9\. row ***************************
    EVENT_NAME: stage/sql/closing tables
    COUNT_STAR: 37
SUM_TIMER_WAIT: 662606568
MIN_TIMER_WAIT: 1593864
AVG_TIMER_WAIT: 17907891
MAX_TIMER_WAIT: 437977248
...

每个阶段摘要表都有一个或多个分组列，用于指示表如何聚合事件。事件名称指的是setup_instruments表中事件工具的名称：

  • events_stages_summary_by_account_by_event_name具有EVENT_NAME，USER和HOST列。每行总结了给定帐户（用户和主机组合）和事件名称的事件。

  • events_stages_summary_by_host_by_event_name具有EVENT_NAME和HOST列。每行总结了给定主机和事件名称的事件。

  • events_stages_summary_by_thread_by_event_name具有THREAD_ID和EVENT_NAME列。每行总结了给定线程和事件名称的事件。

  • events_stages_summary_by_user_by_event_name具有EVENT_NAME和USER列。每行总结了给定用户和事件名称的事件。

  • events_stages_summary_global_by_event_name具有一个EVENT_NAME列。每行总结了给定事件名称的事件。

每个阶段摘要表都有这些包含聚合值的摘要列：COUNT_STAR，SUM_TIMER_WAIT，MIN_TIMER_WAIT，AVG_TIMER_WAIT和MAX_TIMER_WAIT。这些列类似于等待事件摘要表中同名列的列（参见 Section 29.12.20.1, “等待事件摘要表”)，不同之处在于阶段摘要表聚合了来自events_stages_current而不是events_waits_current的事件。

阶段摘要表具有以下索引：

  • events_stages_summary_by_account_by_event_name：

    • 主键为 (USER, HOST, EVENT_NAME)

  • events_stages_summary_by_host_by_event_name：

    • 主键为 (HOST, EVENT_NAME)

  • events_stages_summary_by_thread_by_event_name：

    • 主键为 (THREAD_ID, EVENT_NAME)

  • events_stages_summary_by_user_by_event_name：

    • 主键为 (USER, EVENT_NAME)

  • events_stages_summary_global_by_event_name：

    • 主键为 (EVENT_NAME)

TRUNCATE TABLE 可用于阶段汇总表。它具有以下效果：

  • 对于不按帐户、主机或用户聚合的汇总表，截断会将汇总列重置为零，而不是删除行。

  • 对于按帐户、主机或用户聚合的汇总表，截断会删除没有连接的帐户、主机或用户的行，并将剩余行的汇总列重置为零。

此外，每个按帐户、主机、用户或线程聚合的阶段汇总表在其依赖的连接表被截断或截断 events_stages_summary_global_by_event_name 时会被隐式截断。有关详细信息，请参见 Section 29.12.8, “性能模式连接表”。

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

29.12.20.3 语句摘要表

Performance Schema 维护用于收集当前和最近语句事件的表，并在摘要表中聚合该信息。第 29.12.6 节，“Performance Schema 语句事件表” 描述了语句摘要的基础事件。查看该讨论以获取有关语句事件内容、当前和历史语句事件表以及如何控制语句事件收集的信息，默认情况下部分禁用。

示例语句事件摘要信息：

mysql> SELECT *
       FROM performance_schema.events_statements_summary_global_by_event_name\G
*************************** 1\. row ***************************
                 EVENT_NAME: statement/sql/select
                 COUNT_STAR: 54
             SUM_TIMER_WAIT: 38860400000
             MIN_TIMER_WAIT: 52400000
             AVG_TIMER_WAIT: 719600000
             MAX_TIMER_WAIT: 12631800000
              SUM_LOCK_TIME: 88000000
                 SUM_ERRORS: 0
               SUM_WARNINGS: 0
          SUM_ROWS_AFFECTED: 0
              SUM_ROWS_SENT: 60
          SUM_ROWS_EXAMINED: 120
SUM_CREATED_TMP_DISK_TABLES: 0
     SUM_CREATED_TMP_TABLES: 21
       SUM_SELECT_FULL_JOIN: 16
 SUM_SELECT_FULL_RANGE_JOIN: 0
           SUM_SELECT_RANGE: 0
     SUM_SELECT_RANGE_CHECK: 0
            SUM_SELECT_SCAN: 41
      SUM_SORT_MERGE_PASSES: 0
             SUM_SORT_RANGE: 0
              SUM_SORT_ROWS: 0
              SUM_SORT_SCAN: 0
          SUM_NO_INDEX_USED: 22
     SUM_NO_GOOD_INDEX_USED: 0
               SUM_CPU_TIME: 0
      MAX_CONTROLLED_MEMORY: 2028360
           MAX_TOTAL_MEMORY: 2853429
            COUNT_SECONDARY: 0
...

每个语句摘要表都有一个或多个分组列，指示表如何聚合事件。事件名称指的是setup_instruments 表中事件工具的名称：

  • events_statements_summary_by_account_by_event_name 包含 EVENT_NAME、USER 和 HOST 列。每行总结了给定帐户（用户和主机组合）和事件名称的事件。

  • events_statements_summary_by_digest 包含 SCHEMA_NAME 和 DIGEST 列。每行总结了每个模式和摘要值的事件。（DIGEST_TEXT 列包含相应的标准化语句摘要文本，但不是分组或摘要列。QUERY_SAMPLE_TEXT、QUERY_SAMPLE_SEEN 和 QUERY_SAMPLE_TIMER_WAIT 列也不是分组或摘要列；它们支持语句抽样。）

    表中的最大行数在服务器启动时自动调整大小。要明确设置此最大值，请在服务器启动时设置 performance_schema_digests_size 系统变量。

  • events_statements_summary_by_host_by_event_name 包含 EVENT_NAME 和 HOST 列。每行总结了给定主机和事件名称的事件。

  • events_statements_summary_by_program 包含 OBJECT_TYPE、OBJECT_SCHEMA 和 OBJECT_NAME 列。每行总结了给定存储程序（存储过程或函数、触发器或事件）的事件。

  • events_statements_summary_by_thread_by_event_name 包含 THREAD_ID 和 EVENT_NAME 列。每行总结了给定线程和事件名称的事件。

  • events_statements_summary_by_user_by_event_name具有EVENT_NAME和USER列。每一行总结了给定用户和事件名称的事件。

  • events_statements_summary_global_by_event_name具有一个EVENT_NAME列。每一行总结了给定事件名称的事件。

  • prepared_statements_instances具有一个OBJECT_INSTANCE_BEGIN列。每一行总结了给定准备语句的事件。

每个语句摘要表都有这些包含聚合值的摘要列（除非另有说明）：

  • COUNT_STAR、SUM_TIMER_WAIT、MIN_TIMER_WAIT、AVG_TIMER_WAIT、MAX_TIMER_WAIT

    这些列类似于等待事件摘要表中相同名称的列（参见第 29.12.20.1 节，“等待事件摘要表”），不同之处在于语句摘要表聚合了来自events_statements_current而不是events_waits_current的事件。

    prepared_statements_instances表没有这些列。

  • SUM_*xxx*

    对应于events_statements_current表中的*xxx*列的聚合。例如，语句摘要表中的SUM_LOCK_TIME和SUM_ERRORS列是events_statements_current表中LOCK_TIME和ERRORS列的聚合。

  • MAX_CONTROLLED_MEMORY

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

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

  • MAX_TOTAL_MEMORY

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

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

  • COUNT_SECONDARY

    查询在SECONDARY引擎上处理的次数。用于 MySQL HeatWave 服务和 HeatWave，其中PRIMARY引擎是InnoDB，SECONDARY引擎是 HeatWave（RAPID）。对于 MySQL 社区版服务器、MySQL 企业版服务器（本地）和没有 HeatWave 的 MySQL HeatWave 服务，查询始终在PRIMARY引擎上处理，这意味着在这些 MySQL 服务器上该值始终为 0。COUNT_SECONDARY列是在 MySQL 8.0.29 中添加的。

events_statements_summary_by_digest表具有以下额外的摘要列：

  • FIRST_SEEN，LAST_SEEN

    指示具有给定摘要值的语句何时首次看到和最近看到的时间戳。

  • QUANTILE_95：语句延迟的第 95 百分位数，单位为皮秒。这个百分位数是一个高估值，是从收集的直方图数据计算得出的。换句话说，对于给定的摘要，有 95%的语句延迟低于QUANTILE_95。

    要访问直方图数据，请使用第 29.12.20.4 节，“语句直方图摘要表”中描述的表。

  • QUANTILE_99：类似于QUANTILE_95，但针对第 99 百分位数。

  • QUANTILE_999：类似于QUANTILE_95，但针对 99.9 百分位数。

events_statements_summary_by_digest表包含以下列。这些既不是分组列也不是摘要列；它们支持语句抽样：

  • QUERY_SAMPLE_TEXT

    生成行中摘要值的样本 SQL 语句。此列使应用程序能够访问为给定摘要值而由服务器看到的实际语句。其中一个用途可能是对频繁出现的摘要相关的代表性语句运行EXPLAIN以检查执行计划。

    当QUERY_SAMPLE_TEXT列被赋值时，QUERY_SAMPLE_SEEN和QUERY_SAMPLE_TIMER_WAIT列也被赋值。

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

    有关语句抽样的信息，请参阅第 29.10 节，“性能模式语句摘要和抽样”。

  • QUERY_SAMPLE_SEEN

    指示QUERY_SAMPLE_TEXT列中的语句何时被看到的时间戳。

  • QUERY_SAMPLE_TIMER_WAIT

    QUERY_SAMPLE_TEXT列中样本语句的等待时间。

events_statements_summary_by_program表具有以下额外的摘要列：

  • COUNT_STATEMENTS, SUM_STATEMENTS_WAIT, MIN_STATEMENTS_WAIT, AVG_STATEMENTS_WAIT, MAX_STATEMENTS_WAIT

    关于存储程序执行期间调用的嵌套语句的统计信息。

prepared_statements_instances 表具有以下额外的摘要列：

  • COUNT_EXECUTE, SUM_TIMER_EXECUTE, MIN_TIMER_EXECUTE, AVG_TIMER_EXECUTE, MAX_TIMER_EXECUTE

    准备语句执行的聚合统计信息。

语句摘要表具有以下索引：

  • events_transactions_summary_by_account_by_event_name:

    • 主键为 (USER, HOST, EVENT_NAME)

  • events_statements_summary_by_digest:

    • 主键为 (SCHEMA_NAME, DIGEST)

  • events_transactions_summary_by_host_by_event_name:

    • 主键为 (HOST, EVENT_NAME)

  • events_statements_summary_by_program:

    • 主键为 (OBJECT_TYPE, OBJECT_SCHEMA, OBJECT_NAME)

  • events_statements_summary_by_thread_by_event_name:

    • 主键为 (THREAD_ID, EVENT_NAME)

  • events_transactions_summary_by_user_by_event_name:

    • 主键为 (USER, EVENT_NAME)

  • events_statements_summary_global_by_event_name:

    • 主键为 (EVENT_NAME)

允许对语句摘要表执行 TRUNCATE TABLE。其效果如下：

  • 对于 events_statements_summary_by_digest，它会删除行。

  • 对于其他未按帐户、主机或用户聚合的摘要表，截断会将摘要列重置为零，而不是删除行。

  • 对于其他按帐户、主机或用户聚合的摘要表，截断会删除没有连接的帐户、主机或用户的行，并将剩余行的摘要列重置为零。

此外，按账户、主机、用户或线程汇总的每个语句摘要表都是通过截断其依赖的连接表或截断events_statements_summary_global_by_event_name而隐式截断的。详情请参见第 29.12.8 节，“性能模式连接表”。

此外，截断events_statements_summary_by_digest隐式截断events_statements_histogram_by_digest，截断events_statements_summary_global_by_event_name隐式截断events_statements_histogram_global。

语句摘要聚合规则

如果启用了statements_digest消费者，则在语句完成时将聚合到events_statements_summary_by_digest中。聚合基于为语句计算的DIGEST值。

  • 如果已存在具有刚完成语句的摘要值的events_statements_summary_by_digest行，则将该语句的统计信息聚合到该行。LAST_SEEN列将更新为当前时间。

  • 如果没有行具有刚完成语句的摘要值，并且表未满，则为该语句创建一个新行。FIRST_SEEN和LAST_SEEN列将使用当前时间进行初始化。

  • 如果没有行具有刚完成语句的语句摘要值，并且表已满，则将刚完成语句的统计信息添加到一个特殊的“全捕获”行中，该行具有DIGEST = NULL，如有必要则创建。如果创建了该行，则FIRST_SEEN和LAST_SEEN列将使用当前时间进行初始化。否则，LAST_SEEN列将使用当前时间进行更新。

具有DIGEST = NULL的行是保留的，因为性能模式表由于内存限制具有最大大小。DIGEST = NULL行允许不匹配其他行的摘要即使摘要表已满也能计数，使用一个常见的“其他”桶。此行帮助您估计摘要是否具有代表性：

  • 一个 DIGEST = NULL 行，其 COUNT_STAR 值代表所有摘要的 5%，表明摘要汇总表非常具有代表性；其他行涵盖了所见语句的 95%。

  • 一个 DIGEST = NULL 行，其 COUNT_STAR 值代表所有摘要的 50%，表明摘要汇总表并不是非常具有代表性；其他行仅涵盖了所见语句的一半。很可能数据库管理员应该增加最大表大小，以便更多在 DIGEST = NULL 行中计数的行可以使用更具体的行进行计数。默认情况下，表是自动调整大小的，但如果此大小太小，请在服务器启动时将 performance_schema_digests_size 系统变量设置为较大的值。

存储程序仪表化行为

对于在 setup_objects 表中启用了仪表化的存储程序类型，events_statements_summary_by_program 维护存储程序的统计信息如下：

  • 当对象首次在服务器中使用时，将为该对象添加一行。

  • 当对象被删除时，对象的行将被移除。

  • 统计数据在对象的行中进行聚合，随着其执行而进行。

参见 第 29.4.3 节，“事件预过滤”。

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

29.12.20.4 语句直方图摘要表

性能模式维护语句事件摘要表，其中包含有关语句延迟的最小、最大和平均信息（参见第 29.12.20.3 节，“语句摘要表”）。这些表允许对系统性能进行高级评估。为了允许在更细粒度级别进行评估，性能模式还收集语句延迟的直方图数据。这些直方图提供了对延迟分布的额外见解。

第 29.12.6 节，“性能模式语句事件表”描述了语句摘要基于的事件。查看该讨论以获取有关语句事件内容、当前和历史语句事件表以及如何控制语句事件收集（默认情况下部分禁用）的信息。

示例语句直方图信息：

mysql> SELECT *
       FROM performance_schema.events_statements_histogram_by_digest
       WHERE SCHEMA_NAME = 'mydb' AND DIGEST = 'bb3f69453119b2d7b3ae40673a9d4c7c'
       AND COUNT_BUCKET > 0 ORDER BY BUCKET_NUMBER\G
*************************** 1\. row ***************************
           SCHEMA_NAME: mydb
                DIGEST: bb3f69453119b2d7b3ae40673a9d4c7c
         BUCKET_NUMBER: 42
      BUCKET_TIMER_LOW: 66069344
     BUCKET_TIMER_HIGH: 69183097
          COUNT_BUCKET: 1
COUNT_BUCKET_AND_LOWER: 1
       BUCKET_QUANTILE: 0.058824
*************************** 2\. row ***************************
           SCHEMA_NAME: mydb
                DIGEST: bb3f69453119b2d7b3ae40673a9d4c7c
         BUCKET_NUMBER: 43
      BUCKET_TIMER_LOW: 69183097
     BUCKET_TIMER_HIGH: 72443596
          COUNT_BUCKET: 1
COUNT_BUCKET_AND_LOWER: 2
       BUCKET_QUANTILE: 0.117647
*************************** 3\. row ***************************
           SCHEMA_NAME: mydb
                DIGEST: bb3f69453119b2d7b3ae40673a9d4c7c
         BUCKET_NUMBER: 44
      BUCKET_TIMER_LOW: 72443596
     BUCKET_TIMER_HIGH: 75857757
          COUNT_BUCKET: 2
COUNT_BUCKET_AND_LOWER: 4
       BUCKET_QUANTILE: 0.235294
*************************** 4\. row ***************************
           SCHEMA_NAME: mydb
                DIGEST: bb3f69453119b2d7b3ae40673a9d4c7c
         BUCKET_NUMBER: 45
      BUCKET_TIMER_LOW: 75857757
     BUCKET_TIMER_HIGH: 79432823
          COUNT_BUCKET: 6
COUNT_BUCKET_AND_LOWER: 10
       BUCKET_QUANTILE: 0.625000
...

例如，在第 3 行，这些值表明 23.52%的查询在 75.86 微秒以下运行：

BUCKET_TIMER_HIGH: 75857757
  BUCKET_QUANTILE: 0.235294

在第 4 行，这些值表明 62.50%的查询在 79.44 微秒以下运行：

BUCKET_TIMER_HIGH: 79432823
  BUCKET_QUANTILE: 0.625000

每个语句直方图摘要表都有一个或多个分组列，指示表如何聚合事件：

  • events_statements_histogram_by_digest有SCHEMA_NAME、DIGEST和BUCKET_NUMBER列：

    • SCHEMA_NAME和DIGEST列在events_statements_summary_by_digest表中标识语句摘要行。

    • 具有相同SCHEMA_NAME和DIGEST值的events_statements_histogram_by_digest行构成该模式/摘要组合的直方图。

    • 在给定的直方图中，BUCKET_NUMBER列指示桶号。

  • events_statements_histogram_global有一个BUCKET_NUMBER列。该表在全局范围内汇总模式名称和摘要值的延迟，使用单个直方图。BUCKET_NUMBER列指示此全局直方图中的桶号。

直方图由*N*个桶组成，每一行代表一个桶，桶号由BUCKET_NUMBER列指示。桶号从 0 开始。

每个语句直方图摘要表都有这些包含聚合值的摘要列：

  • BUCKET_TIMER_LOW, BUCKET_TIMER_HIGH

    一个桶计算具有在BUCKET_TIMER_LOW和BUCKET_TIMER_HIGH之间测量的皮秒延迟的语句：

    • 第一个桶（BUCKET_NUMBER = 0）的BUCKET_TIMER_LOW值为 0。

    • 桶（BUCKET_NUMBER = k）的BUCKET_TIMER_LOW值与前一个桶（BUCKET_NUMBER = *k*−1）的BUCKET_TIMER_HIGH值相同

    • 最后一个桶是一个捕获所有超过直方图中前一个桶的延迟的语句的桶。

  • COUNT_BUCKET

    在从BUCKET_TIMER_LOW到BUCKET_TIMER_HIGH之间具有延迟的语句数量。

  • COUNT_BUCKET_AND_LOWER

    在从 0 到BUCKET_TIMER_HIGH之间具有延迟的语句数量。

  • BUCKET_QUANTILE

    陷入此桶或更低桶的语句比例。根据定义，此比例对应于COUNT_BUCKET_AND_LOWER / SUM(COUNT_BUCKET)，并显示为一个便利列。

语句直方图摘要表具有以下索引：

  • events_statements_histogram_by_digest:

    • 在(SCHEMA_NAME, DIGEST, BUCKET_NUMBER)上的唯一索引

  • events_statements_histogram_global:

    • 在(BUCKET_NUMBER)上的主键

允许对语句直方图摘要表进行TRUNCATE TABLE。截断将COUNT_BUCKET和COUNT_BUCKET_AND_LOWER列设置为 0。

此外，截断events_statements_summary_by_digest 隐式截断了events_statements_histogram_by_digest ，截断events_statements_summary_global_by_event_name 隐式截断了events_statements_histogram_global。

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

29.12.20.5 事务摘要表

Performance Schema 维护用于收集当前和最近事务事件的表，并在摘要表中聚合该信息。第 29.12.7 节，“Performance Schema 事务表”描述了事务摘要的基础事件。请参阅该讨论以获取有关事务事件内容、当前和历史事务事件表以及如何控制事务事件收集（默认情况下已禁用）的信息。

事务事件摘要信息示例：

mysql> SELECT *
       FROM performance_schema.events_transactions_summary_global_by_event_name
       LIMIT 1\G
*************************** 1\. row ***************************
          EVENT_NAME: transaction
          COUNT_STAR: 5
      SUM_TIMER_WAIT: 19550092000
      MIN_TIMER_WAIT: 2954148000
      AVG_TIMER_WAIT: 3910018000
      MAX_TIMER_WAIT: 5486275000
    COUNT_READ_WRITE: 5
SUM_TIMER_READ_WRITE: 19550092000
MIN_TIMER_READ_WRITE: 2954148000
AVG_TIMER_READ_WRITE: 3910018000
MAX_TIMER_READ_WRITE: 5486275000
     COUNT_READ_ONLY: 0
 SUM_TIMER_READ_ONLY: 0
 MIN_TIMER_READ_ONLY: 0
 AVG_TIMER_READ_ONLY: 0
 MAX_TIMER_READ_ONLY: 0

每个事务摘要表都有一个或多个分组列，用于指示表如何聚合事件。事件名称指的是setup_instruments表中事件仪器的名称：

  • events_transactions_summary_by_account_by_event_name具有USER、HOST和EVENT_NAME列。每行总结了给定帐户（用户和主机组合）和事件名称的事件。

  • events_transactions_summary_by_host_by_event_name具有HOST和EVENT_NAME列。每行总结了给定主机和事件名称的事件。

  • events_transactions_summary_by_thread_by_event_name具有THREAD_ID和EVENT_NAME列。每行总结了给定线程和事件名称的事件。

  • events_transactions_summary_by_user_by_event_name具有USER和EVENT_NAME列。每行总结了给定用户和事件名称的事件。

  • events_transactions_summary_global_by_event_name具有一个EVENT_NAME列。每行总结了给定事件名称的事件。

每个事务摘要表都有这些包含聚合值的摘要列：

  • COUNT_STAR, SUM_TIMER_WAIT, MIN_TIMER_WAIT, AVG_TIMER_WAIT, MAX_TIMER_WAIT

    这些列类似于等待事件摘要表中同名列的列（参见第 29.12.20.1 节，“等待事件摘要表”），只是交易摘要表聚合了来自events_transactions_current而不是events_waits_current的事件。这些列总结了读写和只读事务。

  • COUNT_READ_WRITE, SUM_TIMER_READ_WRITE, MIN_TIMER_READ_WRITE, AVG_TIMER_READ_WRITE, MAX_TIMER_READ_WRITE

    这些类似于COUNT_STAR和*xxx*_TIMER_WAIT列，但仅总结了读写事务。事务访问模式指定事务是以读/写模式还是只读模式运行。

  • COUNT_READ_ONLY, SUM_TIMER_READ_ONLY, MIN_TIMER_READ_ONLY, AVG_TIMER_READ_ONLY, MAX_TIMER_READ_ONLY

    这些类似于COUNT_STAR和*xxx*_TIMER_WAIT列，但仅总结了只读事务。事务访问模式指定事务是以读/写模式还是只读模式运行。

交易摘要表具有以下索引：

  • events_transactions_summary_by_account_by_event_name:

    • 主键为(USER, HOST, EVENT_NAME)

  • events_transactions_summary_by_host_by_event_name:

    • 主键为(HOST, EVENT_NAME)

  • events_transactions_summary_by_thread_by_event_name:

    • 主键为(THREAD_ID, EVENT_NAME)

  • events_transactions_summary_by_user_by_event_name:

    • 主键为(USER, EVENT_NAME)

  • events_transactions_summary_global_by_event_name:

    • 主键为(EVENT_NAME)

TRUNCATE TABLE允许用于交易摘要表。它具有以下效果：

  • 对于未按帐户、主机或用户聚合的摘要表，截断将摘要列重置为零，而不是删除行。

  • 对于按帐户、主机或用户聚合的摘要表，截断将删除没有连接的帐户、主机或用户的行，并将剩余行的摘要列重置为零。

此外，按帐户、主机、用户或线程聚合的每个事务摘要表都会隐式地通过其依赖的连接表或events_transactions_summary_global_by_event_name的截断进行截断。详情请参见第 29.12.8 节“性能模式连接表”。

事务聚合规则

事务事件收集不考虑隔离级别、访问模式或自动提交模式。

服务器发起的所有非中止事务，包括空事务，都会进行事务事件收集。

读写事务通常比只读事务更消耗资源，因此事务摘要表包括独立的读写和只读事务的聚合列。

资源需求也可能随着事务隔离级别的不同而变化。然而，假设每台服务器只使用一个隔离级别，就不提供按隔离级别聚合的功能。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-objects-summary-global-by-type-table.html

29.12.20.6 对象等待摘要表

性能模式维护objects_summary_global_by_type表以聚合对象等待事件。

示例对象等待事件摘要信息：

mysql> SELECT * FROM performance_schema.objects_summary_global_by_type\G
...
*************************** 3\. row ***************************
   OBJECT_TYPE: TABLE
 OBJECT_SCHEMA: test
   OBJECT_NAME: t
    COUNT_STAR: 3
SUM_TIMER_WAIT: 263126976
MIN_TIMER_WAIT: 1522272
AVG_TIMER_WAIT: 87708678
MAX_TIMER_WAIT: 258428280
...
*************************** 10\. row ***************************
   OBJECT_TYPE: TABLE
 OBJECT_SCHEMA: mysql
   OBJECT_NAME: user
    COUNT_STAR: 14
SUM_TIMER_WAIT: 365567592
MIN_TIMER_WAIT: 1141704
AVG_TIMER_WAIT: 26111769
MAX_TIMER_WAIT: 334783032
...

objects_summary_global_by_type表具有这些分组列，用于指示表如何聚合事件：OBJECT_TYPE，OBJECT_SCHEMA和OBJECT_NAME。每行总结了给定对象的事件。

objects_summary_global_by_type具有与events_waits_summary_by_*xxx*表相同的摘要列。请参阅第 29.12.20.1 节，“等待事件摘要表”。

objects_summary_global_by_type表具有以下索引：

  • 主键为(OBJECT_TYPE, OBJECT_SCHEMA, OBJECT_NAME)

TRUNCATE TABLE允许用于对象摘要表。它将摘要列重置为零，而不是删除行。

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

29.12.20.7 文件 I/O 汇总表

性能模式维护文件 I/O 汇总表，汇总有关 I/O 操作的信息。

示例文件 I/O 事件汇总信息：

mysql> SELECT * FROM performance_schema.file_summary_by_event_name\G
...
*************************** 2\. row ***************************
               EVENT_NAME: wait/io/file/sql/binlog
               COUNT_STAR: 31
           SUM_TIMER_WAIT: 8243784888
           MIN_TIMER_WAIT: 0
           AVG_TIMER_WAIT: 265928484
           MAX_TIMER_WAIT: 6490658832
...
mysql> SELECT * FROM performance_schema.file_summary_by_instance\G
...
*************************** 2\. row ***************************
                FILE_NAME: /var/mysql/share/english/errmsg.sys
               EVENT_NAME: wait/io/file/sql/ERRMSG
               EVENT_NAME: wait/io/file/sql/ERRMSG
    OBJECT_INSTANCE_BEGIN: 4686193384
               COUNT_STAR: 5
           SUM_TIMER_WAIT: 13990154448
           MIN_TIMER_WAIT: 26349624
           AVG_TIMER_WAIT: 2798030607
           MAX_TIMER_WAIT: 8150662536
...

每个文件 I/O 汇总表都有一个或多个分组列，指示表如何聚合事件。事件名称指的是setup_instruments表中事件仪器的名称：

  • file_summary_by_event_name有一个EVENT_NAME列。每行总结了给定事件名称的事件。

  • file_summary_by_instance有FILE_NAME、EVENT_NAME和OBJECT_INSTANCE_BEGIN列。每行总结了给定文件和事件名称的事件。

每个文件 I/O 汇总表都有以下包含聚合值的汇总列。一些列更通用，其值与更细粒度列的值之和相同。通过这种方式，高级别的聚合可以直接使用，无需用户定义的视图来汇总较低级别的列。

  • COUNT_STAR、SUM_TIMER_WAIT、MIN_TIMER_WAIT、AVG_TIMER_WAIT、MAX_TIMER_WAIT

    这些列汇总所有 I/O 操作。

  • COUNT_READ、SUM_TIMER_READ、MIN_TIMER_READ、AVG_TIMER_READ、MAX_TIMER_READ、SUM_NUMBER_OF_BYTES_READ

    这些列汇总所有读操作，包括FGETS、FGETC、FREAD和READ。

  • COUNT_WRITE、SUM_TIMER_WRITE、MIN_TIMER_WRITE、AVG_TIMER_WRITE、MAX_TIMER_WRITE、SUM_NUMBER_OF_BYTES_WRITE

    这些列汇总所有写操作，包括FPUTS、FPUTC、FPRINTF、VFPRINTF、FWRITE和PWRITE。

  • COUNT_MISC、SUM_TIMER_MISC、MIN_TIMER_MISC、AVG_TIMER_MISC、MAX_TIMER_MISC

    这些列汇总所有其他 I/O 操作，包括CREATE、DELETE、OPEN、CLOSE、STREAM_OPEN、STREAM_CLOSE、SEEK、TELL、FLUSH、STAT、FSTAT、CHSIZE、RENAME和SYNC。这些操作没有字节计数。

文件 I/O 汇总表具有以下索引：

  • file_summary_by_event_name:

    • 主键在(EVENT_NAME)

  • file_summary_by_instance:

    • 主键在(OBJECT_INSTANCE_BEGIN)

    • 索引在(FILE_NAME)

    • 索引在(EVENT_NAME)

TRUNCATE TABLE允许用于文件 I/O 汇总表。它将汇总列重置为零，而不是删除行。

MySQL 服务器使用多种技术来避免通过缓存从文件中读取的信息进行 I/O 操作，因此可能会出现您预期会导致 I/O 事件的语句实际上并未执行 I/O 操作。您可以通过刷新缓存或重新启动服务器来确保发生 I/O 操作以重置其状态。

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

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

以下部分描述了表 I/O 和锁等待摘要表：

  • 按索引使用汇总的表 I/O 等待摘要：每个索引的表 I/O 等待

  • 按表汇总的表 I/O 等待摘要：每个表的表 I/O 等待

  • 按表汇总的表锁等待摘要：每个表的表锁等待

29.12.20.8.1 按表汇总的表 I/O 等待摘要表

按表汇总的表 I/O 等待摘要表汇总了所有表 I/O 等待事件，由wait/io/table/sql/handler工具生成。按表进行分组。

按表汇总的表 I/O 等待摘要表具有以下分组列，用于指示表如何汇总事件：OBJECT_TYPE、OBJECT_SCHEMA和OBJECT_NAME。这些列的含义与events_waits_current表中的含义相同。它们标识适用于哪个表的行。

按表汇总的表 I/O 等待摘要具有以下包含汇总值的摘要列。如列描述中所示，一些列更为通用，其值与更细粒度列的值之和相同。例如，汇总所有写入的列包含聚合插入、更新和删除的相应列的总和。通过这种方式，高级别的聚合直接可用，无需用户定义的视图来汇总低级别列���

  • COUNT_STAR, SUM_TIMER_WAIT, MIN_TIMER_WAIT, AVG_TIMER_WAIT, MAX_TIMER_WAIT

    这些列汇总了所有 I/O 操作。它们与相应的*xxx*_READ和*xxx*_WRITE列的总和相同。

  • COUNT_READ, SUM_TIMER_READ, MIN_TIMER_READ, AVG_TIMER_READ, MAX_TIMER_READ

    这些列汇总了所有读操作。它们与相应的*xxx*_FETCH列的总和相同。

  • COUNT_WRITE, SUM_TIMER_WRITE, MIN_TIMER_WRITE, AVG_TIMER_WRITE, MAX_TIMER_WRITE

    这些列汇总了所有写操作。它们与相应的*xxx*_INSERT、*xxx*_UPDATE和*xxx*_DELETE列的总和��同。

  • COUNT_FETCH, SUM_TIMER_FETCH, MIN_TIMER_FETCH, AVG_TIMER_FETCH, MAX_TIMER_FETCH

    这些列汇总了所有提取操作。

  • COUNT_INSERT, SUM_TIMER_INSERT, MIN_TIMER_INSERT, AVG_TIMER_INSERT, MAX_TIMER_INSERT

    这些列汇总了所有插入操作。

  • COUNT_UPDATE, SUM_TIMER_UPDATE, MIN_TIMER_UPDATE, AVG_TIMER_UPDATE, MAX_TIMER_UPDATE

    这些列汇总了所有更新操作。

  • COUNT_DELETE, SUM_TIMER_DELETE, MIN_TIMER_DELETE, AVG_TIMER_DELETE, MAX_TIMER_DELETE

    这些列汇总了所有删除操作。

table_io_waits_summary_by_table表具有以下索引：

  • (OBJECT_TYPE, OBJECT_SCHEMA, OBJECT_NAME)上的唯一索引

TRUNCATE TABLE允许用于表 I/O 汇总表。它将汇总列重置为零，而不是删除行。截断此表还会截断table_io_waits_summary_by_index_usage表。

29.12.20.8.2 table_io_waits_summary_by_index_usage 表

table_io_waits_summary_by_index_usage表汇总了所有表索引 I/O 等待事件，由wait/io/table/sql/handler工具生成。分组是按表索引进行的。

table_io_waits_summary_by_index_usage的列几乎与table_io_waits_summary_by_table相同。唯一的区别是额外的分组列INDEX_NAME，对应于记录表 I/O 等待事件时使用的索引名称：

  • PRIMARY的值表示表 I/O 使用了主索引。

  • NULL的值表示表 I/O 未使用索引。

  • 插入计入INDEX_NAME = NULL。

table_io_waits_summary_by_index_usage 表具有这些索引：

  • 在 (OBJECT_TYPE, OBJECT_SCHEMA, OBJECT_NAME, INDEX_NAME) 上的唯一索引

对于表 I/O 摘要表，允许 TRUNCATE TABLE。它将摘要列重置为零，而不是删除行。此表也通过截断 table_io_waits_summary_by_table 表而被截断。更改表的索引结构的 DDL 操作可能会导致每个索引的统计信息被重置。

29.12.20.8.3 table_lock_waits_summary_by_table 表

table_lock_waits_summary_by_table 表聚合了所有表锁等待事件，由 wait/lock/table/sql/handler 工具生成。分组是按表进行的。

此表包含有关内部和外部锁的信息：

  • 内部锁对应于 SQL 层中的锁。目前通过调用 thr_lock() 实现。在事件行中，这些锁由 OPERATION 列区分，该列具有以下值之一：

    read normal
read with shared locks
read high priority
read no insert
write allow write
write concurrent insert
write delayed
write low priority
write normal

  • 外部锁对应于存储引擎层中的锁。目前通过调用 handler::external_lock() 实现。在事件行中，这些锁由 OPERATION 列区分，该列具有以下值之一：

    read external
write external

table_lock_waits_summary_by_table 表具有这些分组列，用于指示表如何聚合事件：OBJECT_TYPE、OBJECT_SCHEMA 和 OBJECT_NAME。这些列的含义与 events_waits_current 表中的含义相同。它们标识适用于哪个表的行。

table_lock_waits_summary_by_table 包含以下汇总列，其中包含聚合值。 如列描述中所示，某些列更一般，其值与更细粒度列的值之和相同。 例如，聚合所有锁的列包含聚合读锁和写锁的相应列之和。 通过这种方式，高级别的聚合可直接使用，无需用户定义的视图来汇总较低级别的列。

  • COUNT_STAR, SUM_TIMER_WAIT, MIN_TIMER_WAIT, AVG_TIMER_WAIT, MAX_TIMER_WAIT

    这些列聚合所有锁操作。 它们与相应的 *xxx*_READ 和 *xxx*_WRITE 列的和相同。

  • COUNT_READ, SUM_TIMER_READ, MIN_TIMER_READ, AVG_TIMER_READ, MAX_TIMER_READ

    这些列聚合所有读锁操作。 它们与相应的 *xxx*_READ_NORMAL, *xxx*_READ_WITH_SHARED_LOCKS, *xxx*_READ_HIGH_PRIORITY, 和 *xxx*_READ_NO_INSERT 列的和相同。

  • COUNT_WRITE, SUM_TIMER_WRITE, MIN_TIMER_WRITE, AVG_TIMER_WRITE, MAX_TIMER_WRITE

    这些列聚合所有写锁操作。 它们与相应的 *xxx*_WRITE_ALLOW_WRITE, *xxx*_WRITE_CONCURRENT_INSERT, *xxx*_WRITE_LOW_PRIORITY, 和 *xxx*_WRITE_NORMAL 列的和相同。

  • COUNT_READ_NORMAL, SUM_TIMER_READ_NORMAL, MIN_TIMER_READ_NORMAL, AVG_TIMER_READ_NORMAL, MAX_TIMER_READ_NORMAL

    这些列聚合内部读锁。

  • COUNT_READ_WITH_SHARED_LOCKS, SUM_TIMER_READ_WITH_SHARED_LOCKS, MIN_TIMER_READ_WITH_SHARED_LOCKS, AVG_TIMER_READ_WITH_SHARED_LOCKS, MAX_TIMER_READ_WITH_SHARED_LOCKS

    这些列聚合内部读锁。

  • COUNT_READ_HIGH_PRIORITY, SUM_TIMER_READ_HIGH_PRIORITY, MIN_TIMER_READ_HIGH_PRIORITY, AVG_TIMER_READ_HIGH_PRIORITY, MAX_TIMER_READ_HIGH_PRIORITY

    这些列聚合内部读锁。

  • COUNT_READ_NO_INSERT, SUM_TIMER_READ_NO_INSERT, MIN_TIMER_READ_NO_INSERT, AVG_TIMER_READ_NO_INSERT, MAX_TIMER_READ_NO_INSERT

    这些列聚合内部读锁。

  • COUNT_READ_EXTERNAL, SUM_TIMER_READ_EXTERNAL, MIN_TIMER_READ_EXTERNAL, AVG_TIMER_READ_EXTERNAL, MAX_TIMER_READ_EXTERNAL

    这些列聚合外部读锁。

  • COUNT_WRITE_ALLOW_WRITE, SUM_TIMER_WRITE_ALLOW_WRITE, MIN_TIMER_WRITE_ALLOW_WRITE, AVG_TIMER_WRITE_ALLOW_WRITE, MAX_TIMER_WRITE_ALLOW_WRITE

    这些列聚合内部写锁。

  • COUNT_WRITE_CONCURRENT_INSERT, SUM_TIMER_WRITE_CONCURRENT_INSERT, MIN_TIMER_WRITE_CONCURRENT_INSERT, AVG_TIMER_WRITE_CONCURRENT_INSERT, MAX_TIMER_WRITE_CONCURRENT_INSERT

    这些列聚合内部写锁。

  • COUNT_WRITE_LOW_PRIORITY, SUM_TIMER_WRITE_LOW_PRIORITY, MIN_TIMER_WRITE_LOW_PRIORITY, AVG_TIMER_WRITE_LOW_PRIORITY, MAX_TIMER_WRITE_LOW_PRIORITY

    这些列聚合了内部写锁。

  • COUNT_WRITE_NORMAL, SUM_TIMER_WRITE_NORMAL, MIN_TIMER_WRITE_NORMAL, AVG_TIMER_WRITE_NORMAL, MAX_TIMER_WRITE_NORMAL

    这些列聚合了内部写锁。

  • COUNT_WRITE_EXTERNAL, SUM_TIMER_WRITE_EXTERNAL, MIN_TIMER_WRITE_EXTERNAL, AVG_TIMER_WRITE_EXTERNAL, MAX_TIMER_WRITE_EXTERNAL

    这些列聚合了外部写锁。

table_lock_waits_summary_by_table 表具有以下索引：

  • (OBJECT_TYPE, OBJECT_SCHEMA, OBJECT_NAME) 上的唯一索引

截断表 允许用于表锁摘要表。它将摘要列重置为零，而不是删除行。

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

29.12.20.9 套接字汇总表

这些套接字汇总表聚合计时器和字节计数信息，用于套接字操作：

  • socket_summary_by_event_name：聚合由wait/io/socket/*工具生成的计时器和字节计数统计信息，适用于所有套接字 I/O 操作，每个套接字工具。

  • socket_summary_by_instance：聚合由wait/io/socket/*工具生成的计时器和字节计数统计信息，适用于所有套接字 I/O 操作，每个套接字实例。当连接终止时，对应于其的socket_summary_by_instance中的行将被删除。

套接字汇总表不会聚合由idle事件生成的等待，而套接字在等待来自客户端的下一个请求时。对于idle事件的聚合，使用等待事件汇总表；参见第 29.12.20.1 节，“等待事件汇总表”。

每个套接字汇总表都有一个或多个分组列，指示表如何聚合事件。事件名称指的是setup_instruments表中事件工具的名称：

  • socket_summary_by_event_name有一个EVENT_NAME列。每行汇总给定事件名称的事件。

  • socket_summary_by_instance有一个OBJECT_INSTANCE_BEGIN列。每行汇总给定对象的事件。

每个套接字汇总表都有这些包含聚合值的汇总列：

  • COUNT_STAR, SUM_TIMER_WAIT, MIN_TIMER_WAIT, AVG_TIMER_WAIT, MAX_TIMER_WAIT

    这些列聚合所有操作。

  • COUNT_READ, SUM_TIMER_READ, MIN_TIMER_READ, AVG_TIMER_READ, MAX_TIMER_READ, SUM_NUMBER_OF_BYTES_READ

    这些列聚合所有接收操作（RECV，RECVFROM和RECVMSG）。

  • COUNT_WRITE, SUM_TIMER_WRITE, MIN_TIMER_WRITE, AVG_TIMER_WRITE, MAX_TIMER_WRITE, SUM_NUMBER_OF_BYTES_WRITE

    这些列聚合所有发送操作（SEND，SENDTO和SENDMSG）。

  • COUNT_MISC, SUM_TIMER_MISC, MIN_TIMER_MISC, AVG_TIMER_MISC, MAX_TIMER_MISC

    这些列聚合所有其他套接字操作，如CONNECT，LISTEN，ACCEPT，CLOSE和SHUTDOWN。这些操作没有字节计数。

socket_summary_by_instance表还具有一个EVENT_NAME列，指示套接字的类别：client_connection、server_tcpip_socket、server_unix_socket。可以根据此列进行分组，例如将客户端活动与服务器监听套接字的活动隔离开来。

套接字摘要表具有以下索引：

  • socket_summary_by_event_name:

    • 主键为(EVENT_NAME)

  • socket_summary_by_instance:

    • 主键为(OBJECT_INSTANCE_BEGIN)

    • 索引为(EVENT_NAME)

允许对套接字摘要表执行TRUNCATE TABLE。除了events_statements_summary_by_digest之外，它将摘要列重置为零，而不是删除行。

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

29.12.20.10 内存摘要表

性能模式仪表盘记录内存使用情况并汇总内存使用统计信息，详细说明以下因素：

  • 使用的内存类型（各种缓存，内部缓冲区等）

  • 执行内存操作的线程，帐户，用户，主机

性能模式仪表盘记录了内存使用的以下方面。

  • 使用的内存大小

  • 操作计数

  • 低水位和高水位

内存大小有助于理解或调整服务器的内存消耗。

操作计数有助于理解或调整服务器对内存分配器施加的整体压力，这对性能有影响。一百万次分配一个字节不同于一次分配一百万字节；跟踪两种大小和计数可以揭示差异。

低水位和高水位对于检测工作负载峰值、整体���作负载稳定性和可能的内存泄漏至关重要。

内存摘要表不包含时间信息，因为内存事件没有时间。

有关收集内存使用数据的信息，请参阅内存仪表行为。

示例内存事件摘要信息：

mysql> SELECT *
       FROM performance_schema.memory_summary_global_by_event_name
       WHERE EVENT_NAME = 'memory/sql/TABLE'\G
*************************** 1\. row ***************************
                  EVENT_NAME: memory/sql/TABLE
                 COUNT_ALLOC: 1381
                  COUNT_FREE: 924
   SUM_NUMBER_OF_BYTES_ALLOC: 2059873
    SUM_NUMBER_OF_BYTES_FREE: 1407432
              LOW_COUNT_USED: 0
          CURRENT_COUNT_USED: 457
             HIGH_COUNT_USED: 461
    LOW_NUMBER_OF_BYTES_USED: 0
CURRENT_NUMBER_OF_BYTES_USED: 652441
   HIGH_NUMBER_OF_BYTES_USED: 669269

每个内存摘要表都有一个或多个分组列，指示表如何聚合事件。事件名称指的是setup_instruments表中事件仪表的名称：

每个内存摘要表都有这些包含聚合值的摘要列：

  • COUNT_ALLOC，COUNT_FREE

    内存分配和内存释放函数调用次数的聚合数。

  • SUM_NUMBER_OF_BYTES_ALLOC，SUM_NUMBER_OF_BYTES_FREE

    已分配和释放内存块的聚合大小。

  • CURRENT_COUNT_USED

    尚未释放的当前分配块的聚合数量。这是一个便利列，等于 COUNT_ALLOC - COUNT_FREE。

  • CURRENT_NUMBER_OF_BYTES_USED

    尚未释放的当前分配内存块的聚合大小。这是一个便利列，等于 SUM_NUMBER_OF_BYTES_ALLOC - SUM_NUMBER_OF_BYTES_FREE。

  • LOW_COUNT_USED，HIGH_COUNT_USED

    与CURRENT_COUNT_USED列对应的低水位和高水位标记。

  • LOW_NUMBER_OF_BYTES_USED，HIGH_NUMBER_OF_BYTES_USED

    与CURRENT_NUMBER_OF_BYTES_USED列对应的低水位和高水位标记。

内存摘要表具有以下索引：

  • memory_summary_by_account_by_event_name:

    • 主键为(USER, HOST, EVENT_NAME)

  • memory_summary_by_host_by_event_name:

    • 主键为(HOST, EVENT_NAME)

  • memory_summary_by_thread_by_event_name:

    • 主键为(THREAD_ID, EVENT_NAME)

  • memory_summary_by_user_by_event_name:

    • 主键为(USER, EVENT_NAME)

  • memory_summary_global_by_event_name:

    • 主键为(EVENT_NAME)

TRUNCATE TABLE 允许用于内存摘要表。其效果如下：

  • 一般来说，截断会重置统计数据的基线，但不会改变服务器状态。也就是说，截断内存表不会释放内存。

  • COUNT_ALLOC 和 COUNT_FREE 通过减少相同值来重置为新基线。

  • 同样，SUM_NUMBER_OF_BYTES_ALLOC 和 SUM_NUMBER_OF_BYTES_FREE 重置为新基线。

  • LOW_COUNT_USED 和 HIGH_COUNT_USED 重置为 CURRENT_COUNT_USED。

  • LOW_NUMBER_OF_BYTES_USED 和 HIGH_NUMBER_OF_BYTES_USED 重置为 CURRENT_NUMBER_OF_BYTES_USED。

此外，每个按帐户、主机、用户或线程聚合的内存摘要表在其依赖的连接表被截断或memory_summary_global_by_event_name 被截断时会被隐式截断。详情请参见第 29.12.8 节，“性能模式连接表”。

内存工具行为

内存工具在setup_instruments表中列出，并具有形式为memory/*code_area*/*instrument_name*的名称。内存工具默认启用。

以memory/performance_schema/前缀命名的工具公开了性能模式内部缓冲区分配了多少内存。memory/performance_schema/工具是内置的，始终启用，并且无法在启动时或运行时禁用。内置内存工具仅在memory_summary_global_by_event_name表中显示。

要在服务器启动时控制内存工具状态，请在您的my.cnf文件中使用以下行：

  • 启用：

    [mysqld]
performance-schema-instrument='memory/%=ON'

  • 禁用：

    [mysqld]
performance-schema-instrument='memory/%=OFF'

要在运行时控制内存工具状态，请更新setup_instruments表中相关工具的ENABLED列：

  • 启用：

    UPDATE performance_schema.setup_instruments
SET ENABLED = 'YES'
WHERE NAME LIKE 'memory/%';

  • 禁用：

    UPDATE performance_schema.setup_instruments
SET ENABLED = 'NO'
WHERE NAME LIKE 'memory/%';

对于内存工具，setup_instruments中的TIMED列被忽略，因为内存操作不计时。

当服务器中的线程执行已被工具化的内存分配时，适用以下规则：

  • 如果线程未被工具化或内存工具未启用，则分配的内存块不会被工具化。

  • 否则（即线程和工具均已启用），分配的内存块将被工具化。

对于释放，适用以下规则：

  • 如果内存分配操作已被工具化，则无论当前工具或线程启用状态如何，相应的释放操作都会被工具化。

  • 如果内存分配操作未被工具化，则无论当前工具或线程启用状态如何，相应的释放操作都不会被工具化。

对于每个线程的统计信息，适用以下规则。

当分配大小为*N*的工具化内存块时，性能模式将对内存摘要表列进行以下更新：

  • COUNT_ALLOC：增加 1

  • CURRENT_COUNT_USED：增加 1

  • HIGH_COUNT_USED：如果CURRENT_COUNT_USED是新的最大值，则增加

  • SUM_NUMBER_OF_BYTES_ALLOC：增加*N*

  • CURRENT_NUMBER_OF_BYTES_USED：增加*N*

  • HIGH_NUMBER_OF_BYTES_USED：如果CURRENT_NUMBER_OF_BYTES_USED是新的最大值，则增加

当工具化的内存块被释放时，性能模式将对内存摘要表列进行以下更新：

  • COUNT_FREE：增加 1

  • CURRENT_COUNT_USED：减少 1

  • LOW_COUNT_USED：如果CURRENT_COUNT_USED是新的最小值，则减少

  • SUM_NUMBER_OF_BYTES_FREE：增加*N*

  • CURRENT_NUMBER_OF_BYTES_USED：减少*N*

  • LOW_NUMBER_OF_BYTES_USED：如果CURRENT_NUMBER_OF_BYTES_USED是新的最小值，则减少

对于更高级别的聚合（全局、按账户、按用户、按主机），低水位和高水位的规则与预期相同。

  • LOW_COUNT_USED 和 LOW_NUMBER_OF_BYTES_USED 是较低的估计值。性能模式报告的值保证小于或等于运行时实际使用的内存的最低计数或大小。

  • HIGH_COUNT_USED 和 HIGH_NUMBER_OF_BYTES_USED 是较高的估计值。性能模式报告的值保证大于或等于运行时实际使用的内存的最高计数或大小。

对于除memory_summary_global_by_event_name之外的摘要表中的较低估计值，如果内存所有权在线程之间转移，则值可能为负。

这里是一个估算计算的示例；但请注意，估算实现可能会发生变化：

线程 1 在执行过程中使用的内存范围为 1MB 到 2MB，如memory_summary_by_thread_by_event_name表的 LOW_NUMBER_OF_BYTES_USED 和 HIGH_NUMBER_OF_BYTES_USED 列所报告的那样。

线程 2 在执行过程中使用的内存范围为 10MB 到 12MB，如同报告的那样。

当这两个线程属于同一用户账户时，每个账户摘要估计该账户在 11MB 到 14MB 的内存范围内。也就是说，较高级别聚合的 LOW_NUMBER_OF_BYTES_USED 是每个 LOW_NUMBER_OF_BYTES_USED 的总和（假设最坏情况）。同样，较高级别聚合的 HIGH_NUMBER_OF_BYTES_USED 是每个 HIGH_NUMBER_OF_BYTES_USED 的总和（假设最坏情况）。

11MB 是一个较低的估计值，只有当两个线程同时达到低使用标记时才会发生。

14MB 是一个较高的估计值，只有当两个线程同时达到高使用标记时才会发生。

该账户的实际内存使用量可能在 11.5MB 到 13.5MB 的范围内。

对于容量规划，报告最坏情况实际上是期望的行为，因为它展示了当会话不相关时可能发生的情况，这通常是情况。

dev.mysql.com/doc/refman/8.0/en/performance-schema-error-summary-tables.html

29.12.20.11 错误摘要表

性能模式维护了用于聚合关于服务器错误（和警告）的统计信息的摘要表。有关服务器错误的列表，请参见服务器错误消息参考。

错误信息的收集由默认启用的 error 仪器控制。不收集时间信息。

每个错误摘要表都有三列用于标识错误：

  • ERROR_NUMBER 是数字错误值。该值是唯一的。

  • ERROR_NAME 是与 ERROR_NUMBER 值对应的符号错误名称。该值是唯一的。

  • SQLSTATE 是与 ERROR_NUMBER 值对应的 SQLSTATE 值。该值不一定是唯一的。

例如，如果 ERROR_NUMBER 是 1050，ERROR_NAME 是 ER_TABLE_EXISTS_ERROR，SQLSTATE 是 42S01。

示例错误事件摘要信息：

mysql> SELECT *
       FROM performance_schema.events_errors_summary_global_by_error
       WHERE SUM_ERROR_RAISED <> 0\G
*************************** 1\. row ***************************
     ERROR_NUMBER: 1064
       ERROR_NAME: ER_PARSE_ERROR
        SQL_STATE: 42000
 SUM_ERROR_RAISED: 1
SUM_ERROR_HANDLED: 0
       FIRST_SEEN: 2016-06-28 07:34:02
        LAST_SEEN: 2016-06-28 07:34:02
*************************** 2\. row ***************************
     ERROR_NUMBER: 1146
       ERROR_NAME: ER_NO_SUCH_TABLE
        SQL_STATE: 42S02
 SUM_ERROR_RAISED: 2
SUM_ERROR_HANDLED: 0
       FIRST_SEEN: 2016-06-28 07:34:05
        LAST_SEEN: 2016-06-28 07:36:18
*************************** 3\. row ***************************
     ERROR_NUMBER: 1317
       ERROR_NAME: ER_QUERY_INTERRUPTED
        SQL_STATE: 70100
 SUM_ERROR_RAISED: 1
SUM_ERROR_HANDLED: 0
       FIRST_SEEN: 2016-06-28 11:01:49
        LAST_SEEN: 2016-06-28 11:01:49

每个错误摘要表都有一个或多个分组列，指示表如何聚合错误：

  • events_errors_summary_by_account_by_error 有 USER、HOST 和 ERROR_NUMBER 列。每行总结了给定帐户（用户和主机组合）和错误的事件。

  • events_errors_summary_by_host_by_error 有 HOST 和 ERROR_NUMBER 列。每行总结了给定主机和错误的事件。

  • events_errors_summary_by_thread_by_error 有 THREAD_ID 和 ERROR_NUMBER 列。每行总结了给定线程和错误的事件。

  • events_errors_summary_by_user_by_error 有 USER 和 ERROR_NUMBER 列。每行总结了给定用户和错误的事件。

  • events_errors_summary_global_by_error 有一个 ERROR_NUMBER 列。每行总结了给定错误的事件。

每个错误摘要表都有包含聚合值的这些摘要列：

  • SUM_ERROR_RAISED

    此列聚合错误发生的次数。

  • SUM_ERROR_HANDLED

    此列聚合了通过 SQL 异常处理程序处理的错误次数。

  • FIRST_SEEN、LAST_SEEN

    时间戳指示错误首次出现和最近出现的时间。

每个错误摘要表中的NULL行用于聚合超出仪表化错误范围的所有错误的统计信息。例如，如果 MySQL Server 错误范围从*M到N，并且引发了一个不在该范围内的编号为Q*的错误，则该错误将在NULL行中聚合。NULL行是具有ERROR_NUMBER=0，ERROR_NAME=NULL和SQLSTATE=NULL的行。

错误摘要表具有以下索引：

  • events_errors_summary_by_account_by_error:

    • 主键为 (USER, HOST, ERROR_NUMBER)

  • events_errors_summary_by_host_by_error:

    • 主键为 (HOST, ERROR_NUMBER)

  • events_errors_summary_by_thread_by_error:

    • 主键为 (THREAD_ID, ERROR_NUMBER)

  • events_errors_summary_by_user_by_error:

    • 主键为 (USER, ERROR_NUMBER)

  • events_errors_summary_global_by_error:

    • 主键为 (ERROR_NUMBER)

允许对错误摘要表执行TRUNCATE TABLE。它具有以下效果：

  • 对于未按帐户、主机或用户聚合的摘要表，截断将摘要列重置为零或NULL，而不是删除行。

  • 对于按帐户、主机或用户聚合的摘要表，截断将删除没有连接的帐户、主机或用户的行，并将剩余行的摘要列重置为零或NULL。

此外，通过截断依赖的连接表或截断events_errors_summary_global_by_error来隐式截断每个按帐户、主机、用户或线程聚合的错误摘要表。有关详细信息，请参见第 29.12.8 节“性能模式连接表”。

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

29.12.20.12 状态变量摘要表

Performance Schema 使状态变量信息在第 29.12.15 节“Performance Schema 状态变量表”中描述的表中可用。它还使聚合状态变量信息在此处描述的摘要表中可用。每个状态变量摘要表都有一个或多个分组列，用于指示表如何聚合状态值：

  • status_by_account具有USER，HOST和VARIABLE_NAME列，用于按帐户总结状态变量。

  • status_by_host具有HOST和VARIABLE_NAME列，用于按客户端连接的主机总结状态变量。

  • status_by_user具有USER和VARIABLE_NAME列，用于按客户端用户名称总结状态变量。

每个状态变量摘要表都有包含聚合值的此摘要列：

  • VARIABLE_VALUE

    活��和终止会话的聚合状态变量值。

状态变量摘要表具有以下索引：

这些表中“帐户”的含义类似于 MySQL 授予表中mysql系统数据库中的含义，即该术语指的是用户和主机值的组合。它们的区别在于，对于授予表，帐户的主机部分可以是模式，而对于 Performance Schema 表，主机值始终是特定的非模式主机名。

当会话终止时，会收集帐户状态。会话状态计数器将添加到全局状态计数器和相应的帐户状态计数器中。如果未收集帐户统计信息，则会话状态将添加到主机和用户状态中，如果已收集主机和用户状态。

如果分别将performance_schema_accounts_size、performance_schema_hosts_size和performance_schema_users_size系统变量设置为 0，则不会收集帐户、主机和用户统计信息。

性能模式支持以下状态变量摘要表的TRUNCATE TABLE；在所有情况下，活动会话的状态不受影响：

  • status_by_account: 将来自已终止会话的帐户状态聚合到用户和主机状态中，然后重置帐户状态。

  • status_by_host: 重置来自已终止会话的主机状态的聚合状态。

  • status_by_user: 重置来自已终止会话的用户状态。

FLUSH STATUS 将所有活动会话的会话状态添加到全局状态变量中，重置所有活动会话的状态，并重置从断开会话中聚合的帐户、主机和用户状态值。

29.12.21 性能模式杂项表

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

29.12.21.1 component_scheduler_tasks 表

29.12.21.2 error_log 表

29.12.21.3 host_cache 表

29.12.21.4 innodb_redo_log_files 表

29.12.21.5 log_status 表

29.12.21.6 performance_timers 表

29.12.21.7 processlist 表

29.12.21.8 threads 表

29.12.21.9 tls_channel_status 表

29.12.21.10 user_defined_functions 表

以下各节描述了不属于前述各节讨论的表类别的表：

  • component_scheduler_tasks: 每个计划任务的当前状态。

  • error_log: 写入错误日志的最新事件。

  • host_cache: 内部主机缓存的信息。

  • innodb_redo_log_files: InnoDB 重做日志文件的信息。

  • log_status: 用于备份目的的服务器日志信息。

  • performance_timers: 可用的事件计时器。

  • processlist: 有关服务器进程的信息。

  • threads: 有关服务器线程的信息。

  • tls_channel_status: 连接接口的 TLS 上下文属性。

  • user_defined_functions: 组件、插件或CREATE FUNCTION语句注册的可加载函数。

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

29.12.21.1 组件调度器任务表

component_scheduler_tasks表为每个预定任务包含一行。每行包含关于应用程序、组件和插件可以实现的任务的进行中进展的信息，可选地使用scheduler组件（参见第 7.5.5 节，“调度器组件”）。例如，audit_log服务器插件利用scheduler组件定期运行其内存缓存的刷新：

mysql> select * from performance_schema.component_scheduler_tasks\G
*************************** 1\. row ***************************
            NAME: plugin_audit_log_flush_scheduler
          STATUS: WAITING
         COMMENT: Registered by the audit log plugin. Does a periodic refresh of the audit log 
                  in-memory rules cache by calling audit_log_flush
INTERVAL_SECONDS: 100
       TIMES_RUN: 5
    TIMES_FAILED: 0 1 row in set (0.02 sec)

component_scheduler_tasks表具有以下列：

  • NAME

    在注册时提供的名称。

  • STATUS

    值为：

    • 如果任务处于活动状态并正在执行，则为RUNNING。

    • 如果任务处于空闲状态并等待后台线程接手或等待下一次运行时间到来，则为WAITING。

  • COMMENT

    由应用程序、组件或插件提供的编译时注释。在前面的示例中，MySQL 企业审计使用名为audit_log的服务器插件提供注释。

  • INTERVAL_SECONDS

    以秒为单位运行任务的时间，由应用程序、组件或插件提供。MySQL 企业审计允许您使用audit_log_flush_interval_seconds系统变量指定此值。

  • TIMES_RUN

    每次任务成功运行时递增的计数器。它会循环。

  • TIMES_FAILED

    每次任务执行失败时递增的计数器。它会循环。

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

29.12.21.2 错误日志表

MySQL 服务器维护的日志之一是错误日志，用于写入诊断消息（参见 Section 7.4.2, “错误日志”）。通常，服务器将诊断写入服务器主机上的文件或系统日志服务。从 MySQL 8.0.22 开始，根据错误日志配置，服务器还可以将最近的错误事件写入性能模式error_log表。因此，授予SELECT权限给error_log表，使客户端和应用程序可以使用 SQL 查询访问错误日志内容，从而使 DBA 能够提供对日志的访问，而无需在服务器主机上允许直接文件系统访问。

error_log表支持基于其更结构化列的专注查询。它还包括错误消息的完整文本，以支持更自由形式的分析。

表实现使用固定大小的内存环形缓冲区，旧事件会根据需要自动丢弃以为新事件腾出空间。

示例error_log内容：

mysql> SELECT * FROM performance_schema.error_log\G
*************************** 1\. row ***************************
    LOGGED: 2020-08-06 09:25:00.338624
 THREAD_ID: 0
      PRIO: System
ERROR_CODE: MY-010116
 SUBSYSTEM: Server
      DATA: mysqld (mysqld 8.0.23) starting as process 96344
*************************** 2\. row ***************************
    LOGGED: 2020-08-06 09:25:00.363521
 THREAD_ID: 1
      PRIO: System
ERROR_CODE: MY-013576
 SUBSYSTEM: InnoDB
      DATA: InnoDB initialization has started.
...
*************************** 65\. row ***************************
    LOGGED: 2020-08-06 09:25:02.936146
 THREAD_ID: 0
      PRIO: Warning
ERROR_CODE: MY-010068
 SUBSYSTEM: Server
      DATA: CA certificate /var/mysql/sslinfo/cacert.pem is self signed.
...
*************************** 89\. row ***************************
    LOGGED: 2020-08-06 09:25:03.112801
 THREAD_ID: 0
      PRIO: System
ERROR_CODE: MY-013292
 SUBSYSTEM: Server
      DATA: Admin interface ready for connections, address: '127.0.0.1' port: 33062

error_log表具有以下列。如描述中所示，除了DATA列外，所有列都对应于底层错误事件结构的字段，该结构在 Section 7.4.2.3, “错误事件字段”中有描述。

  • LOGGED

    事件时间戳，精确到微秒。LOGGED对应于错误事件的time字段，尽管可能存在某些潜在差异：

    要在与错误日志文件中显示的相同时区中显示LOGGED值，请首先设置会话时区如下：

    SET @@session.time_zone = @@global.log_timestamps;

    如果log_timestamps值为UTC，并且您的系统未安装命名时区支持（参见 Section 7.1.15, “MySQL Server Time Zone Support”），请像这样设置时区：

    SET @@session.time_zone = '+00:00';

  • THREAD_ID

    MySQL 线程 ID。THREAD_ID对应于错误事件的thread字段。

    在性能模式中，error_log表中的THREAD_ID列与threads表的PROCESSLIST_ID列最相似：

    • 对于前台线程，THREAD_ID和PROCESSLIST_ID表示连接标识符。这与INFORMATION_SCHEMA PROCESSLIST表中的ID列中显示的值相同，在SHOW PROCESSLIST输出中显示的Id列中显示，并在线程内由CONNECTION_ID()函数返回。

    • 对于后台线程，THREAD_ID为 0，PROCESSLIST_ID为NULL。

    除了error_log之外，许多性能模式表都有一个名为THREAD_ID的列，但在这些表中，THREAD_ID列是性能模式内部分配的值。

  • PRIO

    事件优先级。允许的值为System、Error、Warning、Note。PRIO列基于错误事件的label字段，该字段本身基于底层数字prio字段值。

  • ERROR_CODE

    数字事件错误代码。ERROR_CODE对应于错误事件的error_code字段。

  • SUBSYSTEM

    事件发生的子系统。SUBSYSTEM对应于错误事件的subsystem字段。

  • DATA

    错误事件的文本表示。此值的格式取决于生成error_log行的日志接收组件生成的格式。例如，如果日志接收组件是log_sink_internal或log_sink_json，DATA值分别表示传统格式或 JSON 格式的错误事件。（参见 Section 7.4.2.9, “Error Log Output Format”.）

    因为错误日志可以重新配置以更改提供行给error_log表的日志接收组件，并且不同的接收组件生成不同的输出格式，所以在不同时间写入error_log表的行可能具有不同的DATA格式。

error_log表具有以下索引：

  • 在(LOGGED)上的主键

  • 在(THREAD_ID)上的索引

  • 在(PRIO)上的索引

  • 在(ERROR_CODE)上的索引

  • 在(SUBSYSTEM)上的索引

不允许对error_log表进行TRUNCATE TABLE操作。

error_log表的实现和配置

性能模式error_log表由写入表中的错误日志事件的错误日志接收组件填充，同时还写入格式化的错误事件到错误日志中。日志接收器通过性能模式支持有两个部分：

  • 日志接收组件可以在发生时将新的错误事件写入error_log表。

  • 日志接收组件可以提供用于提取先前编写的错误消息的解析器。这使得服务器实例能够读取前一个实例写入错误日志文件的消息，并将它们存储在error_log表中。前一个实例在关闭期间写入的消息可能有助于诊断关闭发生的原因。

目前，传统格式的log_sink_internal和 JSON 格式的log_sink_json接收器支持将新事件写入error_log表，并提供解析器用于读取先前编写的错误日志文件。

log_error_services系统变量控制着哪些日志组件用于错误日志记录。其值是一个管道，当发生错误事件时，按从左到右的顺序执行日志过滤器和日志接收组件。log_error_services的值与填充error_log表相关如下：

  • 在启动时，服务器检查log_error_services的值，并从中选择最左边满足以下条件的日志接收器：

    • 支持error_log表并提供解析器的接收器。

    • 如果没有，支持error_log表但不提供解析器的接收器。

    如果没有日志接收器满足这些条件，则error_log表保持为空。否则，如果接收器提供解析器并且日志配置使先前写入的错误日志文件可以被找到，则服务器使用接收器解析器读取文件的最后部分，并将其中包含的旧事件写入表中。然后，接收器会在事件发生时将新的错误事件写入表中。

  • 在运行时，如果log_error_services的值发生变化，服务器会再次检查它，这次寻找支持error_log表的最左边启用的日志接收器，无论它是否提供解析器。

    如果不存在这样的日志接收器，则不会将其他错误事件写入error_log表。否则，新配置的接收器会在事件发生时将新的错误事件写入表中。

任何影响写入错误日志的配置都会影响error_log表的内容。这包括诸如详细程度、消息抑制和消息过滤等设置。它还适用于从先前日志文件中启动时读取的信息。例如，在先前配置为低详细程度的服务器实例中未写入的消息，在当前配置为更高详细程度的实例读取文件时不会变得可用。

error_log表是一个固定大小的内存中的环形缓冲区的视图，旧事件会根据需要自动丢弃以腾出空间给新事件。如下表所示，几个状态变量提供有关进行中的error_log操作的信息。

状态变量含义
Error_log_buffered_bytes表中使用的字节
Error_log_buffered_events表中存在的事件
Error_log_expired_events从表中丢弃的事件
Error_log_latest_write最后写入表的时间

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

29.12.21.3 主机缓存表

MySQL 服务器维护一个内存中的主机缓存，其中包含客户端主机名和 IP 地址信息，并用于避免域名系统（DNS）查找。host_cache表公开了此缓存的内容。host_cache_size系统变量控制主机缓存的大小，以及host_cache表的大小。有关主机缓存的操作和配置信息，请参见第 7.1.12.3 节，“DNS 查找和主机缓存”。

因为host_cache表公开了主机缓存的内容，可以使用SELECT语句进行检查。这可能有助于诊断连接问题的原因。

host_cache表具有以下列：

  • IP

    以字符串形式表示连接到服务器的客户端的 IP 地址。

  • HOST

    客户端 IP 的解析 DNS 主机名，如果名称未知则为NULL。

  • HOST_VALIDATED

    客户端 IP 的 IP 到主机名到 IP DNS 解析是否成功。如果HOST_VALIDATED为YES，则HOST列用作对应于 IP 的主机名，以避免额外调用 DNS。当HOST_VALIDATED为NO时，将尝试为每个连接尝试进行 DNS 解析，直到最终以有效结果或永久错误完成。此信息使服务器能够在临时 DNS 故障期间避免缓存错误或缺失的主机名，这将永久地对客户端产生负面影响。

  • SUM_CONNECT_ERRORS

    被视为“阻塞”的连接错误数量（根据max_connect_errors系统变量进行评估）。仅计算协议握手错误，并且仅适用于通过验证的主机（HOST_VALIDATED = YES）。

    一旦给定主机的SUM_CONNECT_ERRORS达到max_connect_errors的值，来自该主机的新连接将被阻止。SUM_CONNECT_ERRORS值可以超过max_connect_errors的值，因为在主机未被阻止的情况下，可以同时发生来自主机的多个连接尝试。任何一个或全部都可能失败，独立地增加SUM_CONNECT_ERRORS，可能超过max_connect_errors的值。

    假设max_connect_errors为 200，对于给定主机的SUM_CONNECT_ERRORS为 199。如果有 10 个客户端同时尝试从该主机连接，由于SUM_CONNECT_ERRORS尚未达到 200，它们中的任何一个都不会被阻止。如果其中五个客户端发生阻止错误，对于每个客户端，SUM_CONNECT_ERRORS会增加一个，导致SUM_CONNECT_ERRORS值为 204。另外五个客户端成功连接且不被阻止，因为当它们的连接尝试开始时，SUM_CONNECT_ERRORS的值尚未达到 200。当SUM_CONNECT_ERRORS达到 200 后，从该主机发起的新连接将被阻止。

  • COUNT_HOST_BLOCKED_ERRORS

    因为SUM_CONNECT_ERRORS超过max_connect_errors系统变量值而被阻止的连接数量。

  • COUNT_NAMEINFO_TRANSIENT_ERRORS

    IP 到主机名 DNS 解析过程中的瞬时错误次数。

  • COUNT_NAMEINFO_PERMANENT_ERRORS

    IP 到主机名 DNS 解析过程中的永久错误次数。

  • COUNT_FORMAT_ERRORS

    主机名格式错误的数量。MySQL 不会对mysql.user系统表中Host列值与完全由数字组成的主机名进行匹配，例如1.2.example.com。而是使用客户端 IP 地址。关于为什么不进行这种匹配的原因，请参见 Section 8.2.4, “Specifying Account Names”。

  • COUNT_ADDRINFO_TRANSIENT_ERRORS

    主机名到 IP 反向 DNS 解析过程中出现的瞬时错误次数。

  • COUNT_ADDRINFO_PERMANENT_ERRORS

    主机名到 IP 反向 DNS 解析过程中的永久错误次数。

  • COUNT_FCRDNS_ERRORS

    前向确认反向 DNS 错误的数量。当 IP 到主机名到 IP DNS 解析产生一个与客户端原始 IP 地址不匹配的 IP 地址时，就会发生这些错误。

  • COUNT_HOST_ACL_ERRORS

    出现的错误次数，因为没有用户被允许从客户端主机连接。在这种情况下，服务器返回ER_HOST_NOT_PRIVILEGED，甚至不要求用户名或密码。

  • COUNT_NO_AUTH_PLUGIN_ERRORS

    由于请求不可用的身份验证插件而导致的错误数量。例如，如果插件从未加载或加载尝试失败，则插件可能不可用。

  • COUNT_AUTH_PLUGIN_ERRORS

    身份验证插件报告的错误数量。

    身份验证插件可以报告不同的错误代码以指示失败的根本原因。根据错误类型，将递增以下列之一：COUNT_AUTHENTICATION_ERRORS、COUNT_AUTH_PLUGIN_ERRORS、COUNT_HANDSHAKE_ERRORS。新的返回代码是现有插件 API 的可选扩展。未知或意外的插件错误计入COUNT_AUTH_PLUGIN_ERRORS列。

  • COUNT_HANDSHAKE_ERRORS

    在协议层面检测到的错误数量。

  • COUNT_PROXY_USER_ERRORS

    当代理用户 A 被代理到另一个不存在的用户 B 时检测到的错误数量。

  • COUNT_PROXY_USER_ACL_ERRORS

    当代理用户 A 被代理到另一个存在但 A 没有PROXY权限的用户 B 时检测到的错误数量。

  • COUNT_AUTHENTICATION_ERRORS

    由于身份验证失败导致的错误数量。

  • COUNT_SSL_ERRORS

    由于 SSL 问题导致的错误数量。

  • COUNT_MAX_USER_CONNECTIONS_ERRORS

    由于超出每用户连接配额而导致的错误数量。请参阅 Section 8.2.21, “Setting Account Resource Limits”。

  • COUNT_MAX_USER_CONNECTIONS_PER_HOUR_ERRORS

    由于超出每小时每用户连接配额而导致的错误数量。请参阅 Section 8.2.21, “Setting Account Resource Limits”。

  • COUNT_DEFAULT_DATABASE_ERRORS

    与默认数据库相关的错误数量。例如，数据库不存在或用户没有访问权限。

  • COUNT_INIT_CONNECT_ERRORS

    由于init_connect系统变量值中语句执行失败而导致的错误数量。

  • COUNT_LOCAL_ERRORS

    与服务器实现本地的与网络、身份验证或授权无关的错误数量。例如，内存不足情况属于此类别。

  • COUNT_UNKNOWN_ERRORS

    在此表中其他未被其他列考虑的未知错误数量。该列保留用于将来使用，以防必须报告新的错误条件，并且如果需要保留host_cache表的向后兼容性和结构。

  • FIRST_SEEN

    在IP列中看到的客户端首次连接尝试的时间戳。

  • LAST_SEEN

    在IP列中看到的客户端最近连接尝试的时间戳。

  • FIRST_ERROR_SEEN

    客户端在IP列中首次出现错误的时间戳。

  • LAST_ERROR_SEEN

    在IP列中记录客户端最近出现错误的时间戳。

host_cache表具有以下索引：

  • (IP)上的主键

  • (HOST)上的索引

对于host_cache表，允许使用TRUNCATE TABLE语句。需要对该表具有DROP权限。清空表会刷新主机缓存，具有刷新主机缓存中描述的效果。

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-innodb-redo-log-files-table.html

29.12.21.4 innodb_redo_log_files表

innodb_redo_log_files表包含每个活动的InnoDB重做日志文件的一行。此表在 MySQL 8.0.30 中引入。

innodb_redo_log_files表具有以下列：

  • FILE_ID

    重做日志文件的 ID。该值对应于重做日志文件编号。

  • FILE_NAME

    重做日志文件的路径和文件名。

  • START_LSN

    重做日志文件中第一个块的日志序列号。

  • END_LSN

    最后一个块后的日志序列号在重做日志文件中。

  • SIZE_IN_BYTES

    文件中重做日志数据的大小，以字节为单位。数据大小从END_LSN到开始>START_LSN进行测量。由于文件头（2048 字节）不包括在此列报告的值中，因此磁盘上的重做日志文件大小略大。

  • IS_FULL

    重做日志文件是否已满。值为 0 表示文件中有空闲空间。值为 1 表示文件已满。

  • CONSUMER_LEVEL

    保留以供将来使用。

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

29.12.21.5 log_status表

log_status表提供的信息使在线备份工具能够复制所需的日志文件，而不会在复制过程中锁定这些资源。

当查询log_status表时，服务器会阻止记录和相关的管理更改，只需足够的时间来填充表，然后释放资源。log_status表通知在线备份应该复制到源二进制日志和gtid_executed记录的哪个点，以及每个复制通道的中继日志。它还为各个存储引擎提供相关信息，例如InnoDB存储引擎的最后日志序列号（LSN）和最后一个检查点的 LSN。

log_status表具有以下列：

  • SERVER_UUID

    该服务器实例的服务器 UUID。这是只读系统变量server_uuid的生成唯一值。

  • LOCAL

    来自源的日志位置状态信息，以单个具有以下键的 JSON 对象提供：

    binary_log_file

    当前二进制日志文件的名称。

    binary_log_position

    访问log_status表时的当前二进制日志位置。

    gtid_executed

    在访问log_status表时全局服务器变量gtid_executed的当前值。此信息与binary_log_file和binary_log_position键一致。

  • REPLICATION

    一个包含以下信息的通道的 JSON 数组：

    channel_name

    复制通道的名称。默认复制通道的名称为空字符串（“”）。

    relay_log_file

    复制通道的当前中继日志文件的名称。

    relay_log_pos

    访问log_status表时的当前中继日志位置。

  • STORAGE_ENGINES

    从各个存储引擎提供的相关信息，以每个适用存储引擎的一个键的 JSON 对象。

log_status表没有索引。

访问log_status表需要BACKUP_ADMIN权限以及SELECT权限。

TRUNCATE TABLE不允许用于log_status表。

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

29.12.21.6 The performance_timers Table

performance_timers 表显示了可用的事件计时器：

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

如果与特定计时器名称相关联的值为 NULL，则该计时器在您的平台上不受支持。有关事件计时发生的解释，请参见 Section 29.4.1, “Performance Schema Event Timing”。

performance_timers 表具有以下列：

  • TIMER_NAME

    计时器名称。

  • TIMER_FREQUENCY

    每秒的计时器单位数。对于循环计时器，频率通常与 CPU 速度有关。例如，在一个具有 2.4GHz 处理器的系统上，CYCLE 可能接近 2400000000。

  • TIMER_RESOLUTION

    指示计时器值增加的计时器单位数。如果计时器的分辨率为 10，则每次增加 10。

  • TIMER_OVERHEAD

    通过调用计时器 20 次进行初始化并选择最小值，性能模式确定获得给定计时器的一个计时所需的最小周期数。总开销实际上是这个值的两倍，因为在每个事件的开始和结束时，仪器会调用计时器。计时器代码仅在计时事件时调用，因此此开销不适用于非计时事件。

performance_timers 表没有索引。

TRUNCATE TABLE 不允许用于 performance_timers 表。

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

29.12.21.7 进程列表表

MySQL 进程列表指示服务器内执行的一组线程当前正在执行的操作。processlist 表是进程信息的一个来源。有关此表与其他来源的比较，请参见进程信息的来源。

processlist 表可以直接查询。如果您拥有 PROCESS 权限，您可以看到所有线程，甚至属于其他用户的线程。否则（没有 PROCESS 权限），非匿名用户可以访问有关自己线程的信息，但不能访问其他用户的线程，匿名用户无法访问线程信息。

注意

如果启用了 performance_schema_show_processlist 系统变量，则 processlist 表还作为 SHOW PROCESSLIST 语句底层的替代实现的基础。有关详细信息，请参见本节后面的内容。

processlist 表包含每个服务器进程的一行：

mysql> SELECT * FROM performance_schema.processlist\G
*************************** 1\. row ***************************
     ID: 5
   USER: event_scheduler
   HOST: localhost
     DB: NULL
COMMAND: Daemon
   TIME: 137
  STATE: Waiting on empty queue
   INFO: NULL
*************************** 2\. row ***************************
     ID: 9
   USER: me
   HOST: localhost:58812
     DB: NULL
COMMAND: Sleep
   TIME: 95
  STATE:
   INFO: NULL
*************************** 3\. row ***************************
     ID: 10
   USER: me
   HOST: localhost:58834
     DB: test
COMMAND: Query
   TIME: 0
  STATE: executing
   INFO: SELECT * FROM performance_schema.processlist
...

processlist 表具有以下列：

  • ID

    连接标识符。这是在 SHOW PROCESSLIST 语句的 Id 列中显示的相同值，在性能模式 threads 表的 PROCESSLIST_ID 列中显示，并在线程内由 CONNECTION_ID() 函数返回。

  • USER

    发出语句的 MySQL 用户。system user的值指的是服务器生成的用于内部处理任务的非客户端线程，例如延迟行处理程序线程或在副本主机上使用的 I/O 或 SQL 线程。对于system user，在Host列中没有指定主机。unauthenticated user指的是已经与客户端连接关联但客户端用户尚未进行身份验证的线程。event_scheduler指的是监视计划事件的线程（参见 Section 27.4, “Using the Event Scheduler”）。

    注意

    system user的USER值与SYSTEM_USER权限是不同的。前者指的是内部线程。后者区分系统用户和常规用户帐户类别（参见 Section 8.2.11, “Account Categories”）。

  • HOST

    发出语句的客户端主机名（除了system user外，没有主机名）。对于 TCP/IP 连接，主机名以*host_name*:*client_port*格式报告，以便更容易确定哪个客户端在执行什么操作。

  • DB

    线程的默认数据库，如果没有选择任何数据库，则为NULL。

  • COMMAND

    线程代表客户端执行的命令类型，或者如果会话处于空闲状态，则为Sleep。有关线程命令的描述，请参见 Section 10.14, “Examining Server Thread (Process) Information” Information")。此列的值对应于客户端/服务器协议的COM_*xxx*命令和Com_*xxx*状态变量。参见 Section 7.1.10, “Server Status Variables”。

  • TIME

    线程在当前状态下已经持续的时间（以秒为单位）。对于副本 SQL 线程，该值是最后一个复制事件的时间戳与副本主机实际时间之间的秒数。参见 Section 19.2.3, “Replication Threads”。

  • STATE

    指示线程正在执行的操作、事件或状态。有关STATE值的描述，请参见 Section 10.14, “Examining Server Thread (Process) Information” Information")。

    大多数状态对应非常快速的操作。如果一个线程在特定状态下停留了很多秒，可能存在需要调查的问题。

  • INFO

    线程正在执行的语句，如果未执行任何语句则为NULL。该语句可能是发送到服务器的语句，或者如果该语句执行其他语句，则为最内层语句。例如，如果CALL语句执行一个正在执行SELECT语句的存储过程，则INFO值显示SELECT语句。

  • EXECUTION_ENGINE

    查询执行引擎。该值可以是PRIMARY或SECONDARY。用于 MySQL HeatWave 服务和 HeatWave，其中PRIMARY引擎是InnoDB，SECONDARY引擎是 HeatWave（RAPID）。对于 MySQL 社区版服务器、MySQL 企业版服务器（本地）以及没有 HeatWave 的 MySQL HeatWave 服务，该值始终为PRIMARY。此列在 MySQL 8.0.29 中添加。

processlist表具有以下索引：

  • 主键为(ID)

TRUNCATE TABLE不允许用于processlist表。

如前所述，如果启用了performance_schema_show_processlist系统变量，则processlist表作为其他进程信息源的替代实现的基础：

  • SHOW PROCESSLIST语句。

  • mysqladmin processlist命令（使用SHOW PROCESSLIST语句）。

默认的SHOW PROCESSLIST实现在持有全局互斥锁的同时从线程管理器中遍历活动线程。这会对性能产生负面影响，特别是在繁忙系统上。另一种SHOW PROCESSLIST实现基于性能模式processlist表。该实现从性能模式而不是线程管理器查询活动线程数据，并且不需要互斥锁。

MySQL 配置会影响processlist表的内容如下：

  • 最低要求配置：

    • MySQL 服务器必须配置并构建为启用线程仪表。这是默认情况；可以使用DISABLE_PSI_THREAD CMake选项进行控制。

    • 性能模式必须在服务器启动时启用。这是默认情况；可以使用performance_schema系统变量来控制。

    在满足该配置的情况下，performance_schema_show_processlist启用或禁用替代的SHOW PROCESSLIST实现。如果未满足最低配置要求，processlist表（因此SHOW PROCESSLIST）可能无法返回所有数据。

  • 推荐配置：

    • 为了避免一些线程被忽略：

      • 将performance_schema_max_thread_instances系统变量设置为默认值或至少设置为与max_connections系统变量一样大。

      • 将performance_schema_max_thread_classes系统变量设置为默认值。

    • 为了避免一些STATE列值为空，请将performance_schema_max_stage_classes系统变量设置为默认值。

    这些配置参数的默认值为-1，这会导致性能模式在服务器启动时自动调整它们的大小。使用指定的参数设置，processlist表（因此SHOW PROCESSLIST）会生成完整的进程信息。

前述配置参数会影响processlist表的内容。然而，对于给定的配置，processlist的内容不受performance_schema_show_processlist设置的影响。

替代的进程列表实现不适用于INFORMATION_SCHEMA的PROCESSLIST表或 MySQL 客户端/服务器协议的COM_PROCESS_INFO命令。

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

29.12.21.8 线程表

threads表包含每个服务器线程的一行。每行包含有关线程的信息，并指示是否为其启用了监控和历史事件记录：

mysql> SELECT * FROM performance_schema.threads\G
*************************** 1\. row ***************************
            THREAD_ID: 1
                 NAME: thread/sql/main
                 TYPE: BACKGROUND
       PROCESSLIST_ID: NULL
     PROCESSLIST_USER: NULL
     PROCESSLIST_HOST: NULL
       PROCESSLIST_DB: mysql
  PROCESSLIST_COMMAND: NULL
     PROCESSLIST_TIME: 418094
    PROCESSLIST_STATE: NULL
     PROCESSLIST_INFO: NULL
     PARENT_THREAD_ID: NULL
                 ROLE: NULL
         INSTRUMENTED: YES
              HISTORY: YES
      CONNECTION_TYPE: NULL
         THREAD_OS_ID: 5856
       RESOURCE_GROUP: SYS_default
     EXECUTION_ENGINE: PRIMARY
    CONTROLLED_MEMORY: 1456
MAX_CONTROLLED_MEMORY: 67480
         TOTAL_MEMORY: 1270430
     MAX_TOTAL_MEMORY: 1307317
     TELEMETRY_ACTIVE: NO
...

当性能模式初始化时，它基于当时存在的线程填充threads表。此后，每次服务器创建线程时都会添加新行。

新线程的INSTRUMENTED和HISTORY列值由setup_actors表的内容确定。有关如何使用setup_actors表来控制这些列的信息，请参阅 Section 29.4.6, “Pre-Filtering by Thread”.

从threads表中删除行是在线程结束时发生的。对于与客户端会话关联的线程，当会话结束时会发生删除。如果客户端启用了自动重新连接，并且会话在断开连接后重新连接，则会话将与具有不同PROCESSLIST_ID值的threads表中的新行相关联。新线程的初始INSTRUMENTED和HISTORY值可能与原始线程的值不同：setup_actors表可能已经发生了变化，如果在初始化行之后更改了原始线程的INSTRUMENTED或HISTORY值，则该更改不会传递到新线程。

您可以启用或禁用线程监控（即线程执行的事件是否被检测）和历史事件记录。要控制新前台线程的初始INSTRUMENTED和HISTORY值，请使用setup_actors表。要控制现有线程的这些方面，请设置threads表行的INSTRUMENTED和HISTORY列。（有关线程监控和历史事件记录发生条件的更多信息，请参阅INSTRUMENTED和HISTORY列的描述。）

与具有PROCESSLIST_前缀名称的threads表列进行比较，以及其他进程信息来源，请参阅进程信息来源。

重要

除了threads表之外的线程信息来源，只有当前用户具有PROCESS权限时，才会显示其他用户的线程信息。对于threads表并非如此；对于具有表的SELECT权限的任何用户，都会显示所有行。不应授予对threads表的SELECT权限的用户，不应该能够通过访问该表来查看其他用户的线程。

threads表具有以下列：

  • THREAD_ID

    唯一线程标识符。

  • 名称

    与服务器中的线程仪表代码相关联的名称。例如，thread/sql/one_connection对应于负责处理用户连接的代码中的线程函数，而thread/sql/main代表服务器的main()函数。

  • 类型

    线程类型，可以是FOREGROUND或BACKGROUND。用户连接线程是前台线程。与内部服务器活动相关的线程是后台线程。例如，内部InnoDB线程，“binlog dump”线程向副本发送信息，以及复制 I/O 和 SQL 线程。

  • PROCESSLIST_ID

    对于前台线程（与用户连接相关），这是连接标识符。这与INFORMATION_SCHEMA PROCESSLIST表的ID列中显示的值相同，在SHOW PROCESSLIST输出中显示，在线程内部由CONNECTION_ID()函数返回。

    对于后台线程（与用户连接无关），PROCESSLIST_ID为NULL，因此值不是唯一的。

  • PROCESSLIST_USER

    与前台线程关联的用户，对于后台线程为NULL。

  • PROCESSLIST_HOST

    与前台线程关联的客户端的主机名，对于后台线程为NULL。

    与INFORMATION_SCHEMA PROCESSLIST表的HOST列或SHOW PROCESSLIST输出的Host列不同，PROCESSLIST_HOST列不包括 TCP/IP 连接的端口号。要从性能模式获取此信息，请启用套接字检测（默认情况下未启用），并检查socket_instances表：

    mysql> SELECT NAME, ENABLED, TIMED
       FROM performance_schema.setup_instruments
       WHERE NAME LIKE 'wait/io/socket%';
+----------------------------------------+---------+-------+
| NAME                                   | ENABLED | TIMED |
+----------------------------------------+---------+-------+
| wait/io/socket/sql/server_tcpip_socket | NO      | NO    |
| wait/io/socket/sql/server_unix_socket  | NO      | NO    |
| wait/io/socket/sql/client_connection   | NO      | NO    |
+----------------------------------------+---------+-------+
3 rows in set (0.01 sec)

mysql> UPDATE performance_schema.setup_instruments
       SET ENABLED='YES'
       WHERE NAME LIKE 'wait/io/socket%';
Query OK, 3 rows affected (0.00 sec)
Rows matched: 3  Changed: 3  Warnings: 0

mysql> SELECT * FROM performance_schema.socket_instances\G
*************************** 1\. row ***************************
           EVENT_NAME: wait/io/socket/sql/client_connection
OBJECT_INSTANCE_BEGIN: 140612577298432
            THREAD_ID: 31
            SOCKET_ID: 53
                   IP: ::ffff:127.0.0.1
                 PORT: 55642
                STATE: ACTIVE
...

  • PROCESSLIST_DB

    线程的默认数据库，如果没有选择任何数据库，则为NULL。

  • PROCESSLIST_COMMAND

    对于前台线程，线程代表客户端执行的命令类型，如果会话空闲，则为Sleep。有关线程命令的描述，请参见 Section 10.14, “Examining Server Thread (Process) Information” Information")。此列的值对应于客户端/服务器协议的COM_*xxx*命令和Com_*xxx*状态变量。请参见 Section 7.1.10, “Server Status Variables”

    后台线程不代表客户端执行命令，因此此列可能为NULL。

  • PROCESSLIST_TIME

    线程处于当前状态的秒数。对于复制 SQL 线程，该值是最后一个复制事件的时间戳和复制主机的实际时间之间的秒数。参见 Section 19.2.3, “Replication Threads”。

  • PROCESSLIST_STATE

    表示线程正在执行的操作、事件或状态。有关PROCESSLIST_STATE值的描述，请参见 Section 10.14, “Examining Server Thread (Process) Information” Information")。如果值为NULL，则线程可能对应于空闲客户端会话或其正在执行的工作未使用阶段进行检测。

    大多数状态对应非常快速的操作。如果一个线程在某个状态停留了很多秒，可能存在需要调查的问题。

  • PROCESSLIST_INFO

    线程正在执行的语句，如果不执行任何语句，则为NULL。该语句可能是发送到服务器的语句，或者如果语句执行其他语句，则是最内部的语句。例如，如果CALL语句执行正在执行SELECT语句的存储过程，则PROCESSLIST_INFO值显示SELECT语句。

  • PARENT_THREAD_ID

    如果此线程是子线程（由另一个线程生成），则这是生成线程的THREAD_ID值。

  • ROLE

    未使用。

  • INSTRUMENTED

    是否对线程执行的事件进行仪器化。该值为YES或NO。

    • 对于前台线程，初始的INSTRUMENTED值取决于与线程关联的用户帐户是否与setup_actors表中的任何行匹配。匹配基于PROCESSLIST_USER和PROCESSLIST_HOST列的值。

      如果线程生成了子线程，则再次为为子线程创建的threads表行进行匹配。

    • 对于后台线程，默认情况下INSTRUMENTED为YES。不会查询setup_actors，因为后台线程没有关联的用户。

    • 对于任何线程，其INSTRUMENTED值可以在线程的生命周期内更改。

    要发生对线程执行的事件的监视，必须满足以下条件：

    • setup_consumers表中的thread_instrumentation消费者必须为YES。

    • threads.INSTRUMENTED列必须为YES。

    • 仅对那些在setup_instruments表中的ENABLED列设置为YES的仪器产生的线程事件进行监视。

  • HISTORY

    是否记录线程的历史事件。该值为YES或NO。

    • 对于前台线程，初始的HISTORY值取决于与线程关联的用户帐户是否与setup_actors表中的任何行匹配。匹配基于PROCESSLIST_USER和PROCESSLIST_HOST列的值。

      如果线程生成了子线程，则再次为为子线程创建的threads表行进行匹配。

    • 对于后台线程，默认情况下HISTORY为YES。不会查询setup_actors，因为后台线程没有关联的用户。

    • 对于任何线程，其HISTORY值可以在线程的生命周期内更改。

    要发生对线程的历史事件记录，必须满足以下条件：

    • 必须启用setup_consumers表中适当的与历史相关的消费者。例如，在events_waits_history和events_waits_history_long表中等待事件记录需要相应的events_waits_history和events_waits_history_long消费者为YES。

    • threads.HISTORY列必须为YES。

    • 仅对那些在setup_instruments表中ENABLED列设置为YES的仪器产生的线程事件进行记录。

  • CONNECTION_TYPE

    用于建立连接的协议，或者对于后台线程为NULL。允许的值为TCP/IP（未加密建立的 TCP/IP 连接），SSL/TLS（加密建立的 TCP/IP 连接），Socket（Unix 套接字文件连接），Named Pipe（Windows 命名管道连接）和Shared Memory（Windows 共享内存连接）。

  • THREAD_OS_ID

    如果有的话，由底层操作系统定义的线程或任务标识符：

    • 当 MySQL 线程在其生命周期内与相同的操作系统线程关联时，THREAD_OS_ID包含操作系统线程 ID。

    • 当 MySQL 线程在其生命周期内未与相同的操作系统线程关联时，THREAD_OS_ID包含NULL。这在使用线程池插件时（参见 Section 7.6.3, “MySQL Enterprise Thread Pool”）的用户会话中很常见。

    对于 Windows，THREAD_OS_ID对应于在 Process Explorer 中可见的线程 ID（technet.microsoft.com/en-us/sysinternals/bb896653.aspx）。

    对于 Linux，THREAD_OS_ID对应于gettid()函数的值。例如，可以使用perf或ps -L命令，或在proc文件系统（/proc/*[pid]*/task/*[tid]*）中公开此值。有关更多信息，请参阅perf-stat(1)，ps(1)和proc(5)手册页。

  • RESOURCE_GROUP

    资源组标签。如果当前平台或服务器配置不支持资源组，则此值为NULL（请参阅 Resource Group Restrictions）。

  • EXECUTION_ENGINE

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

  • CONTROLLED_MEMORY

    线程使用的受控内存量。

    此列在 MySQL 8.0.31 版本中添加。

  • MAX_CONTROLLED_MEMORY

    线程执行期间看到的 CONTROLLED_MEMORY 的最大值。

    此列在 MySQL 8.0.31 版本中添加。

  • TOTAL_MEMORY

    线程使用的当前内存量，无论是否受控。

    此列在 MySQL 8.0.31 版本中添加。

  • MAX_TOTAL_MEMORY

    线程执行期间看到的 TOTAL_MEMORY 的最大值。

    此列在 MySQL 8.0.31 版本中添加。

  • TELEMETRY_ACTIVE

    线程是否附加了活动的遥测会话。值为 YES 或 NO。

    此列在 MySQL 8.0.33 版本中添加。

threads 表具有以下索引：

  • 在 (THREAD_ID) 上的主键

  • 在 (NAME) 上的索引

  • 在 (PROCESSLIST_ID) 上的索引

  • 在 (PROCESSLIST_USER, PROCESSLIST_HOST) 上的索引

  • 在 (PROCESSLIST_HOST) 上的索引

  • 在 (THREAD_OS_ID) 上的索引

  • 在 (RESOURCE_GROUP) 上的索引

TRUNCATE TABLE 不允许用于 threads 表。

avatar
文章
阅读
粉丝