原文：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选择*
FROM Performance_schema.events_waits_summary_global_by_event_name\\G
.
************************************** 6\\.行******** ********** * **********
EVENT_NAME:等待/同步/互斥/sql/BINARY_LOG:LOCK_index
COUNT_STAR: 8
SUM_TIMER_WAIT: 2119302
最小定时器等待： 196092
AVG_TIMER_WAIT: 264912
MAX_TIMER_WAIT: 569421
.
************************** 9\\行****************** ** * *********
EVENT_NAME: 等待/同步/互斥/sql/hash_filo: 锁
COUNT_STAR: 69
SUM_TIMER_WAIT: 16848828
MIN_TIMER_WAIT: 0
AVG_TIMER_WAIT: 244185
最大定时器等待： 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_等待
总结已安排事件的总等待时间。非定时事件的等待时间为NULL，因此仅针对定时事件计算该值。这同样适用于其他*xxx*_TIMER_WAIT 值。
MIN_TIMER_WAIT
总结预定事件的最短等待时间。
AVG_TIMER_等待
总结预定事件的平均等待时间。
最大定时器等待时间
总结已安排事件的最长等待时间。
等待事件汇总表有以下索引：
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 被截断时，按帐户、主机、用户或线程进行汇总的每个等待摘要表都会被隐式截断。有关详细信息，请参阅性能模式联接表。
原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-stage-summary-tables.html
29.12.20.2 阶段摘要表
性能模式维护收集当前和最近阶段事件的表，并将这些信息聚合到摘要表中。第29.12.5 节“性能模式阶段事件表”描述了构成阶段摘要基础的事件。有关阶段事件内容、当前和过去阶段事件表以及如何控制阶段事件收集（默认情况下禁用）的信息，请参阅此讨论。
舞台活动摘要信息示例：
mysql选择*
FROM Performance_schema.events_stages_summary_global_by_event_name\\G
.
************************** 5\\行****************** * * * *********
EVENT_NAME: 阶段/SQL/权限检查
COUNT_STAR: 57
SUM_TIMER_WAIT: 26501888880
最小定时器等待： 7317456
AVG_TIMER_WAIT: 464945295
MAX_TIMER_WAIT: 12858936792
.
************************** 9\\行****************** ** * *********
EVENT_NAME: 阶段/SQL/表结束
COUNT_STAR: 37
SUM_TIMER_WAIT: 662606568
最小定时器等待： 1593864
AVG_TIMER_WAIT: 17907891
最大定时器等待： 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 的聚合值。这些列与等待事件摘要表中的同名列类似（请参阅第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 被截断时，按帐户、主机、用户或线程聚合的每个阶段摘要表也会被隐式截断。有关详细信息，请参阅性能模式联接表。
原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-statement-summary-tables.html
29.12.20.3 语句摘要表
性能模式维护收集当前和最近的语句事件的表，并将这些信息聚合到汇总表中。第29.12.6 节“性能模式语句事件表”描述了语句摘要背后的事件。有关什么是语句事件、当前和过去的语句事件表以及如何控制语句事件收集（默认情况下部分禁用）的信息，请参阅此讨论。
语句事件的摘要信息示例：
mysql选择*
FROM Performance_schema.events_statements_summary_global_by_event_name\\G
************************** 1\\. 行****************** * **********
EVENT_NAME: 语句/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
最大控制内存： 2028360
最大总内存： 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 列。每行都用特定事件名称汇总事件。
prepare_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 中的事件。
prepare_statements_instances 表没有这些列。
总和_*xxx*
对应于events_statements_current 表的*xxx* 列的聚合。例如，语句摘要表中的SUM_LOCK_TIME 和SUM_ERRORS 列是events_statements_current 表中的LOCK_TIME 和ERRORS 列的聚合。
最大控制内存
报告语句在执行期间使用的最大控制内存量。
此列是在MySQL 8.0.31 中添加的。
最大总内存
报告执行期间语句使用的最大内存量。
此列是在MySQL 8.0.31 中添加的。
COUNT_SECONDARY
SECONDARY 引擎处理查询的次数。由MySQL HeatWave 服务和HeatWave 使用。 PRIMARY 引擎是InnoDB，SECONDARY 引擎是HeatWave (RAPID)。对于MySQL 社区版服务器、MySQL 企业版服务器（本地）和不带HeatWave 的MySQL HeatWave 服务，查询始终由PRIMARY 引擎处理。这意味着这些MySQL 服务器的值将始终为0。 MySQL 8.0.29 中添加了COUNT_SECONDARY 列。
events_statements_summary_by_digest 表具有以下附加摘要列：
FIRST_SEEN、最后_SEEN
时间戳，指示首次和最后一次显示具有特定摘要值的语句的时间。
QUANTILE_95：语句等待时间的第95 个百分位（以皮秒为单位）。该百分位数是一个较高的估计值，是根据收集的直方图数据计算得出的。这意味着对于给定的摘要，95% 的语句的延迟低于QUANTILE_95。
要访问直方图数据，请使用语句直方图摘要表中描述的表格。
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 表具有以下附加摘要列：
计数语句、总语句等待、最小语句等待、平均语句等待、最大语句等待
有关存储程序执行期间调用的嵌套语句的统计信息。
prepare_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表中事件仪表的名称：
按帐户按事件名称汇总的内存摘要具有USER，HOST和EVENT_NAME列。每行总结了给定帐户（用户和主机组合）和事件名称的事件。
按主机按事件名称汇总的内存摘要具有HOST和EVENT_NAME列。每行总结了给定主机和事件名称的事件。
按线程按事件名称汇总的内存摘要具有THREAD_ID和EVENT_NAME列。每行总结了给定线程和事件名称的事件。
按用户按事件名称汇总的内存摘要具有USER和EVENT_NAME列。每行总结了给定用户和事件名称的事件。
按事件名称全局汇总的内存摘要具有EVENT_NAME列。每行总结了给定事件名称的事件。
每个内存摘要表都有这些包含聚合值的摘要列：
COUNT_ALLOC，COUNT_FREE
内存分配和内存释放函数调用次数的聚合数。
SUM_NUMBER_OF_BYTES_ALLOC，SUM_NUMBER_OF_BYTES_FREE
已分配和释放内存块的聚合大小。
CURRENT_COUNT_USED
尚未释放的当前分配块的聚合数量。这是一个便利列，等于 COUNT_ALLOC – COUNT_FREE。
CURRENT_NUMBER_OF_BYTES_USED
尚未释放的当前分配内存块的聚合大小。这是一个便利列，等于 SUM_NUMBER_OF_BYTES_ALLOC – SUM_NUMBER_OF_BYTES_FREE。
LOW_COUNT_USED，HIGH_COUNT_USED
与CURRENT_COUNT_USED列对应的低水位和高水位标记。
LOW_NUMBER_OF_BYTES_USED，HIGH_NUMBER_OF_BYTES_USED
与CURRENT_NUMBER_OF_BYTES_USED列对应的低水位和高水位标记。
内存摘要表具有以下索引：
memory_summary_by_account_by_event_name:
主键为(USER, HOST, EVENT_NAME) memory_summary_by_host_by_event_name:
主键为(HOST, EVENT_NAME) memory_summary_by_thread_by_event_name:
主键为(THREAD_ID, EVENT_NAME) memory_summary_by_user_by_event_name:
主键为(USER, EVENT_NAME) memory_summary_global_by_event_name:
主键为(EVENT_NAME)
TRUNCATE TABLE 允许用于内存摘要表。其效果如下：
一般来说，截断会重置统计数据的基线，但不会改变服务器状态。也就是说，截断内存表不会释放内存。
COUNT_ALLOC 和 COUNT_FREE 通过减少相同值来重置为新基线。
同样，SUM_NUMBER_OF_BYTES_ALLOC 和 SUM_NUMBER_OF_BYTES_FREE 重置为新基线。
LOW_COUNT_USED 和 HIGH_COUNT_USED 重置为 CURRENT_COUNT_USED。
LOW_NUMBER_OF_BYTES_USED 和 HIGH_NUMBER_OF_BYTES_USED 重置为 CURRENT_NUMBER_OF_BYTES_USED。
此外，每个按帐户、主机、用户或线程聚合的内存摘要表在其依赖的连接表被截断或memory_summary_global_by_event_name 被截断时会被隐式截断。详情请参见第 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
活��和终止会话的聚合状态变量值。
状态变量摘要表具有以下索引：
status_by_account:
主键为(USER, HOST, VARIABLE_NAME) status_by_host:
主键为(HOST, VARIABLE_NAME) status_by_user:
主键为(USER, VARIABLE_NAME)
这些表中“帐户”的含义类似于 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字段，尽管可能存在某些潜在差异：
错误日志中的time值根据log_timestamps系统变量设置显示；参见早期启动日志输出格式。
LOGGED列使用TIMESTAMP数据类型存储值，其中值以 UTC 存储，但在检索时以当前会话时区显示；参见Section 13.2.2, “日期、时间和时间戳类型”。
要在与错误日志文件中显示的相同时区中显示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 表。
#以上关于MySQL8 中文参考（一百一十）的相关内容来源网络仅供参考，相关信息请以官方公告为准！
原创文章，作者：CSDN，如若转载，请注明出处：https://www.sudun.com/ask/92504.html
