MySQL8-中文参考-四十七-

MySQL8 中文参考（四十七）

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

28.4.4 INFORMATION_SCHEMA INNODB_BUFFER_POOL_STATS 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-innodb-buffer-pool-stats-table.html

INNODB_BUFFER_POOL_STATS 表提供了与 SHOW ENGINE INNODB STATUS 输出中提供的缓冲池信息相同的信息。也可以使用 InnoDB 缓冲池服务器状态变量获取相同的信息。

在缓冲池中使页面“年轻”或“非年轻”的概念是指在缓冲池数据结构的头部和尾部之间转移它们的过程。标记为“年轻”的页面需要更长时间才会从缓冲池中移除，而标记为“非年轻”的页面则更接近被驱逐的位置。

有关使用信息和示例，请参见 Section 17.15.5, “InnoDB INFORMATION_SCHEMA Buffer Pool Tables”。

INNODB_BUFFER_POOL_STATS 表包含以下列：

POOL_ID

缓冲池 ID。这是用于区分多个缓冲池实例的标识符。
POOL_SIZE

InnoDB 缓冲池大小（以页面为单位）。
FREE_BUFFERS

InnoDB 缓冲池中的空闲页面数。
DATABASE_PAGES

InnoDB 缓冲池中包含数据的页面数。这个数字包括脏页和干净页。
OLD_DATABASE_PAGES

old 缓冲池子列表中的页面数。
MODIFIED_DATABASE_PAGES

修改（脏）数据库页面数。
PENDING_DECOMPRESS

等待解压的页面数。
PENDING_READS

等待读取的页面数。
PENDING_FLUSH_LRU

LRU 中等待刷新的页面数。
PENDING_FLUSH_LIST

刷新列表中等待刷新的页面数。
PAGES_MADE_YOUNG

标记为年轻的页面数。
PAGES_NOT_MADE_YOUNG

未被标记为年轻的页面数。
PAGES_MADE_YOUNG_RATE

每秒标记为年轻的页面数（自上次打印以来标记为年轻的页面数 / 经过的时间）。
PAGES_MADE_NOT_YOUNG_RATE

每秒未被标记为年轻的页面数（自上次打印以来未被标记为年轻的页面数 / 经过的时间）。
NUMBER_PAGES_READ

读取的页面数。
NUMBER_PAGES_CREATED

创建的页面数。
NUMBER_PAGES_WRITTEN

写入的页面数。
PAGES_READ_RATE

每秒读取的页面数（自上次打印以来读取的页面数 / 经过的时间）。
PAGES_CREATE_RATE

每秒创建的页面数量（自上次打印以来创建的页面/经过的时间）。
PAGES_WRITTEN_RATE

每秒写入的页面数量（自上次打印以来写入的页面/经过的时间）。
NUMBER_PAGES_GET

逻辑读请求的数量。
HIT_RATE

缓冲池命中率。
YOUNG_MAKE_PER_THOUSAND_GETS

每千次获取的页面变为年轻页面的数量。
NOT_YOUNG_MAKE_PER_THOUSAND_GETS

每千次获取未变为年轻页面的数量。
NUMBER_PAGES_READ_AHEAD

预读取的页面数量。
NUMBER_READ_AHEAD_EVICTED

由预读取后台线程读入InnoDB缓冲池的页面数量，随后在没有被查询访问的情况下被驱逐。
READ_AHEAD_RATE

每秒的预读取速率（自上次打印以来的预读取页面/经过的时间）。
READ_AHEAD_EVICTED_RATE

每秒未访问的预读取页面被驱逐的数量（自上次打印以来未访问的预读取页面/经过的时间）。
LRU_IO_TOTAL

总 LRU I/O。
LRU_IO_CURRENT

当前间隔的 LRU I/O。
UNCOMPRESS_TOTAL

解压缩的页面总数。
UNCOMPRESS_CURRENT

当前间隔内解压缩的页面数量。

示例。

mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_BUFFER_POOL_STATS\G
*************************** 1\. row ***************************
                         POOL_ID: 0
                       POOL_SIZE: 8192
                    FREE_BUFFERS: 1
                  DATABASE_PAGES: 8085
              OLD_DATABASE_PAGES: 2964
         MODIFIED_DATABASE_PAGES: 0
              PENDING_DECOMPRESS: 0
                   PENDING_READS: 0
               PENDING_FLUSH_LRU: 0
              PENDING_FLUSH_LIST: 0
                PAGES_MADE_YOUNG: 22821
            PAGES_NOT_MADE_YOUNG: 3544303
           PAGES_MADE_YOUNG_RATE: 357.62602199870594
       PAGES_MADE_NOT_YOUNG_RATE: 0
               NUMBER_PAGES_READ: 2389
            NUMBER_PAGES_CREATED: 12385
            NUMBER_PAGES_WRITTEN: 13111
                 PAGES_READ_RATE: 0
               PAGES_CREATE_RATE: 0
              PAGES_WRITTEN_RATE: 0
                NUMBER_PAGES_GET: 33322210
                        HIT_RATE: 1000
    YOUNG_MAKE_PER_THOUSAND_GETS: 18
NOT_YOUNG_MAKE_PER_THOUSAND_GETS: 0
         NUMBER_PAGES_READ_AHEAD: 2024
       NUMBER_READ_AHEAD_EVICTED: 0
                 READ_AHEAD_RATE: 0
         READ_AHEAD_EVICTED_RATE: 0
                    LRU_IO_TOTAL: 0
                  LRU_IO_CURRENT: 0
                UNCOMPRESS_TOTAL: 0
              UNCOMPRESS_CURRENT: 0

注意事项。

此表主要用于专家级性能监控，或者在开发与 MySQL 性能相关的扩展时使用。
您必须具有PROCESS权限才能查询此表。
使用INFORMATION_SCHEMA COLUMNS表或SHOW COLUMNS语句查看有关此表的列的其他信息，包括数据类型和默认值。

28.4.5 INFORMATION_SCHEMA INNODB_CACHED_INDEXES 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-innodb-cached-indexes-table.html

INNODB_CACHED_INDEXES 表报告了每个索引在 InnoDB 缓冲池中缓存的索引页数。

有关相关用法信息和示例，请参见 Section 17.15.5, “InnoDB INFORMATION_SCHEMA Buffer Pool Tables”。

INNODB_CACHED_INDEXES 表具有以下列：

SPACE_ID

表空间 ID。
INDEX_ID

索引的标识符。索引标识符在实例中的所有数据库中是唯一的。
N_CACHED_PAGES

在 InnoDB 缓冲池中缓存的索引页数。

示例

此查询返回特定索引在 InnoDB 缓冲池中缓存的索引页数：

mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_CACHED_INDEXES WHERE INDEX_ID=65\G
*************************** 1\. row ***************************
      SPACE_ID: 4294967294
      INDEX_ID: 65
N_CACHED_PAGES: 45

此查询使用 INNODB_INDEXES 和 INNODB_TABLES 表来解析每个 INDEX_ID 值的表名和索引名，返回在 InnoDB 缓冲池中缓存的每个索引的索引页数。

SELECT
  tables.NAME AS table_name,
  indexes.NAME AS index_name,
  cached.N_CACHED_PAGES AS n_cached_pages
FROM
  INFORMATION_SCHEMA.INNODB_CACHED_INDEXES AS cached,
  INFORMATION_SCHEMA.INNODB_INDEXES AS indexes,
  INFORMATION_SCHEMA.INNODB_TABLES AS tables
WHERE
  cached.INDEX_ID = indexes.INDEX_ID
  AND indexes.TABLE_ID = tables.TABLE_ID;

注意

您必须具有 PROCESS 权限才能查询此表。
使用 INFORMATION_SCHEMA COLUMNS 表或 SHOW COLUMNS 语句查看有关此表的列的其他信息，包括数据类型和默认值。

28.4.6 INFORMATION_SCHEMA INNODB_CMP 和 INNODB_CMP_RESET 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-innodb-cmp-table.html

INNODB_CMP和INNODB_CMP_RESET表提供与压缩InnoDB表相关操作的状态信息。

INNODB_CMP和INNODB_CMP_RESET表具有以下列：

PAGE_SIZE

压缩页面的大小（以字节为单位）。
COMPRESS_OPS

一个大小为PAGE_SIZE的 B 树页面被压缩的次数。每当创建一个空页面或未压缩修改日志的空间用尽时，页面就会被压缩。
COMPRESS_OPS_OK

一个大小为PAGE_SIZE的 B 树页面成功压缩的次数。此计数永远不应超过COMPRESS_OPS。
COMPRESS_TIME

用于尝试压缩大小为PAGE_SIZE的 B 树页面所用的总时间（以秒为单位）。
UNCOMPRESS_OPS

一个大小为PAGE_SIZE的 B 树页面被解压的次数。每当压缩失败或在缓冲池中不存在未压缩页面时首次访问��，B 树页面就会被解压。
UNCOMPRESS_TIME

用于解压大小为PAGE_SIZE的 B 树页面所用的总时间（以秒为单位）。

示例

mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_CMP\G
*************************** 1\. row ***************************
      page_size: 1024
   compress_ops: 0
compress_ops_ok: 0
  compress_time: 0
 uncompress_ops: 0
uncompress_time: 0
*************************** 2\. row ***************************
      page_size: 2048
   compress_ops: 0
compress_ops_ok: 0
  compress_time: 0
 uncompress_ops: 0
uncompress_time: 0
*************************** 3\. row ***************************
      page_size: 4096
   compress_ops: 0
compress_ops_ok: 0
  compress_time: 0
 uncompress_ops: 0
uncompress_time: 0
*************************** 4\. row ***************************
      page_size: 8192
   compress_ops: 86955
compress_ops_ok: 81182
  compress_time: 27
 uncompress_ops: 26828
uncompress_time: 5
*************************** 5\. row ***************************
      page_size: 16384
   compress_ops: 0
compress_ops_ok: 0
  compress_time: 0
 uncompress_ops: 0
uncompress_time: 0

注意

使用这些表来衡量数据库中InnoDB表压缩的有效性。
您必须具有PROCESS权限才能查询此表。
使用INFORMATION_SCHEMA``COLUMNS表或SHOW COLUMNS语句查看有关此表的列的其他信息，包括数据类型和默认值。
有关使用信息，请参见第 17.9.1.4 节，“在运行时监视 InnoDB 表压缩”和第 17.15.1.3 节，“使用压缩信息模式表”。有关InnoDB表压缩的一般信息，请参见第 17.9 节，“InnoDB 表和页面压缩”。

28.4.7 INFORMATION_SCHEMA INNODB_CMPMEM 和 INNODB_CMPMEM_RESET 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-innodb-cmpmem-table.html

INNODB_CMPMEM和INNODB_CMPMEM_RESET表提供有关InnoDB缓冲池内压缩页的状态信息。

INNODB_CMPMEM和INNODB_CMPMEM_RESET表具有以下列：

PAGE_SIZE

字节中的块大小。此表的每个记录描述此大小的块。
BUFFER_POOL_INSTANCE

缓冲池实例的唯一标识符。
PAGES_USED

当前正在使用的大小为PAGE_SIZE的块数。
PAGES_FREE

当前可用于分配的大小为PAGE_SIZE的块数。此列显示内存池中的外部碎片。理想情况下，这些数字应最多为 1。
RELOCATION_OPS

大小为PAGE_SIZE的块已重新定位的次数。当尝试形成更大的释放块时，伙伴系统可以重新定位已分配的“伙伴邻居”块。从INNODB_CMPMEM_RESET表中读取会重置此计数。
RELOCATION_TIME

用于重新定位大小为PAGE_SIZE的块所用的总微秒数。从表INNODB_CMPMEM_RESET中读取会重置此计数。

示例

mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_CMPMEM\G
*************************** 1\. row ***************************
           page_size: 1024
buffer_pool_instance: 0
          pages_used: 0
          pages_free: 0
      relocation_ops: 0
     relocation_time: 0
*************************** 2\. row ***************************
           page_size: 2048
buffer_pool_instance: 0
          pages_used: 0
          pages_free: 0
      relocation_ops: 0
     relocation_time: 0
*************************** 3\. row ***************************
           page_size: 4096
buffer_pool_instance: 0
          pages_used: 0
          pages_free: 0
      relocation_ops: 0
     relocation_time: 0
*************************** 4\. row ***************************
           page_size: 8192
buffer_pool_instance: 0
          pages_used: 7673
          pages_free: 15
      relocation_ops: 4638
     relocation_time: 0
*************************** 5\. row ***************************
           page_size: 16384
buffer_pool_instance: 0
          pages_used: 0
          pages_free: 0
      relocation_ops: 0
     relocation_time: 0

注意

使用这些表来衡量数据库中InnoDB表的压缩效果。
您必须具有PROCESS权限才能查询此表。
使用INFORMATION_SCHEMA COLUMNS表或SHOW COLUMNS语句查看有关此表的列的其他信息，包括数据类型和默认值。
查看使用信息，请参阅第 17.9.1.4 节，“在运行时监视 InnoDB 表压缩”和第 17.15.1.3 节，“使用压缩信息模式表”。有关InnoDB表压缩的一般信息，请参阅第 17.9 节，“InnoDB 表和页压缩”。

28.4.8 The INFORMATION_SCHEMA INNODB_CMP_PER_INDEX and INNODB_CMP_PER_INDEX_RESET Tables

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-innodb-cmp-per-index-table.html

INNODB_CMP_PER_INDEX 和 INNODB_CMP_PER_INDEX_RESET 表提供与压缩 InnoDB表和索引相关的操作的状态信息，针对每个数据库、表和索引的组合分别提供统计信息，以帮助您评估特定表的压缩性能和实用性。

对于压缩的InnoDB表，表数据和所有二级索引都被压缩。在这种情况下，表数据被视为另一个索引，恰好包含所有列：聚簇索引。

INNODB_CMP_PER_INDEX 和 INNODB_CMP_PER_INDEX_RESET 表具有以下列：

DATABASE_NAME

包含适用表的模式（数据库）。
TABLE_NAME

监控压缩统计信息的表。
INDEX_NAME

用于监控压缩统计信息的索引。
COMPRESS_OPS

尝试的压缩操作次数。每当创建一个空页面或未压缩修改日志的空间用尽时，就会对页面进行压缩。
COMPRESS_OPS_OK

成功的压缩操作次数。从COMPRESS_OPS值中减去以获取压缩失败的次数。除以COMPRESS_OPS值以获取压缩失败的百分比。
COMPRESS_TIME

用于在此索引��压缩数据的总时间（以秒为单位）。
UNCOMPRESS_OPS

执行的解压操作次数。每当压缩失败或在缓冲池中第一次访问压缩页面且未压缩页面不存在时，压缩的InnoDB页面就会被解压。
UNCOMPRESS_TIME

用于在此索引中解压数据的总时间（以秒为单位）。

示例

mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_CMP_PER_INDEX\G
*************************** 1\. row ***************************
  database_name: employees
     table_name: salaries
     index_name: PRIMARY
   compress_ops: 0
compress_ops_ok: 0
  compress_time: 0
 uncompress_ops: 23451
uncompress_time: 4
*************************** 2\. row ***************************
  database_name: employees
     table_name: salaries
     index_name: emp_no
   compress_ops: 0
compress_ops_ok: 0
  compress_time: 0
 uncompress_ops: 1597
uncompress_time: 0

注意事项

使用这些表来衡量特定表、索引或两者的 InnoDB 表压缩效果。
您必须具有 PROCESS 权限才能查询这些表。
使用 INFORMATION_SCHEMA COLUMNS 表或 SHOW COLUMNS 语句查看有关这些表的列的其他信息，包括数据类型和默认值。
由于为每个索引收集单独的测量数据会带来很大的性能开销，INNODB_CMP_PER_INDEX 和 INNODB_CMP_PER_INDEX_RESET 统计数据默认不会被收集。在执行想要监视的压缩表操作之前，您必须启用 innodb_cmp_per_index_enabled 系统变量。
有关使用信息，请参阅 Section 17.9.1.4, “Monitoring InnoDB Table Compression at Runtime” 和 Section 17.15.1.3, “Using the Compression Information Schema Tables”。有关 InnoDB 表压缩的一般信息，请参阅 Section 17.9, “InnoDB Table and Page Compression”。

28.4.9 INFORMATION_SCHEMA INNODB_COLUMNS 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-innodb-columns-table.html

INNODB_COLUMNS 表提供关于 InnoDB 表列的元数据。

有关相关用法信息和示例，请参见第 17.15.3 节，“InnoDB INFORMATION_SCHEMA Schema Object Tables”。

INNODB_COLUMNS 表具有以下列：

TABLE_ID

表示与列关联的表的标识符；与 INNODB_TABLES.TABLE_ID 相同的值。
NAME

列的名称。这些名称可以是大写或小写，取决于 lower_case_table_names 设置。列没有特殊的系统保留名称。
POS

列在表中的序数位置，从 0 开始顺序递增。当删除列时，剩余列将重新排序，使序列没有间隙。虚拟生成列的 POS 值编码列序号和列的序数位置。有关更多信息，请参见第 28.4.29 节，“INFORMATION_SCHEMA INNODB_VIRTUAL 表” 中的 POS 列描述。
MTYPE

代表“主类型”。列类型的数字标识符。1 = VARCHAR，2 = CHAR，3 = FIXBINARY，4 = BINARY，5 = BLOB，6 = INT，7 = SYS_CHILD，8 = SYS，9 = FLOAT，10 = DOUBLE，11 = DECIMAL，12 = VARMYSQL，13 = MYSQL，14 = GEOMETRY。
PRTYPE

InnoDB 的“精确类型”，一个二进制值，其中位表示 MySQL 数据类型、字符集代码和可为 null。
LEN

列长度，例如 INT 为 4，BIGINT 为 8。对于多字节字符集中的字符列，此长度值是以字节表示定义所需的最大长度，例如 VARCHAR(*N*)；也就是说，它可能是 2**N*，3**N*，依此类推，取决于字符编码。
HAS_DEFAULT

一个布尔值，指示使用 ALTER TABLE ... ADD COLUMN 和 ALGORITHM=INSTANT 立即添加的列是否具有默认值。所有立即添加的列都有默认值，这使得此列成为指示列是否立即添加的指示器。
DEFAULT_VALUE

使用ALTER TABLE ... ADD COLUMN立即添加的列的初始默认值，使用ALGORITHM=INSTANT。如果默认值为NULL或未指定，默认情况下此列报告NULL。显式指定的非NULL默认值以内部二进制格式显示。对列默认值的后续修改不会更改此列报告的值。

示例

mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_COLUMNS where TABLE_ID = 71\G
*************************** 1\. row ***************************
     TABLE_ID: 71
         NAME: col1
          POS: 0
        MTYPE: 6
       PRTYPE: 1027
          LEN: 4
  HAS_DEFAULT: 0
DEFAULT_VALUE: NULL
*************************** 2\. row ***************************
     TABLE_ID: 71
         NAME: col2
          POS: 1
        MTYPE: 2
       PRTYPE: 524542
          LEN: 10
  HAS_DEFAULT: 0
DEFAULT_VALUE: NULL
*************************** 3\. row ***************************
     TABLE_ID: 71
         NAME: col3
          POS: 2
        MTYPE: 1
       PRTYPE: 524303
          LEN: 10
  HAS_DEFAULT: 0
DEFAULT_VALUE: NULL

注意事项

您必须具有PROCESS权限才能查询此表。
使用INFORMATION_SCHEMA COLUMNS表或SHOW COLUMNS语句查看有关此表的列的其他信息，包括数据类型和默认值。

28.4.10 The INFORMATION_SCHEMA INNODB_DATAFILES Table

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-innodb-datafiles-table.html

INNODB_DATAFILES表提供了InnoDB file-per-table 和 general 表空间的数据文件路径信息。

有关使用信息和示例，请参见第 17.15.3 节，“InnoDB INFORMATION_SCHEMA Schema Object Tables”。

注意

INFORMATION_SCHEMA FILES表报告了InnoDB表空间类型的元数据，包括 file-per-table 表空间、general 表空间、系统表空间、全局临时表空间和撤销表空间。

INNODB_DATAFILES表具有以下列：

SPACE

表空间 ID。
PATH

表空间数据文件路径。如果在 MySQL 数据目录之外的位置创建了 file-per-table 表空间，则路径值是完全限定的目录路径。否则，路径是相对于数据目录的。

示例

mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_DATAFILES WHERE SPACE = 57\G
*************************** 1\. row ***************************
SPACE: 57
 PATH: ./test/t1.ibd

注意

您必须具有PROCESS权限才能查询此表。
使用INFORMATION_SCHEMA COLUMNS表或SHOW COLUMNS语句查看有关此表的列的其他信息，包括数据类型和默认值。

28.4.11 INFORMATION_SCHEMA INNODB_FIELDS 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-innodb-fields-table.html

INNODB_FIELDS表提供有关InnoDB索引的关键列（字段）的元数据。

有关相关用法信息和示例，请参见第 17.15.3 节，“InnoDB INFORMATION_SCHEMA 模式对象表”。

INNODB_FIELDS表具有以下列：

INDEX_ID

与此关键字段相关联的索引的标识符；与INNODB_INDEXES.INDEX_ID相同的值。
NAME

表中原始列的名称；与INNODB_COLUMNS.NAME相同的值。
POS

关键字段在索引中的顺序位置，从 0 开始递增。当删除列时，剩余列将重新排序，以确保序列没有间隙。

示例

mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_FIELDS WHERE INDEX_ID = 117\G
*************************** 1\. row ***************************
INDEX_ID: 117
    NAME: col1
     POS: 0

注意事项

您必须具有PROCESS权限才能查询此表。
使用INFORMATION_SCHEMA COLUMNS表或SHOW COLUMNS语句查看有关此表的列的其他信息，包括数据类型和默认值。

28.4.12 INFORMATION_SCHEMA INNODB_FOREIGN 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-innodb-foreign-table.html

INNODB_FOREIGN 表提供关于 InnoDB 外键的元数据。

有关相关用法信息和示例，请参见第 17.15.3 节，“InnoDB INFORMATION_SCHEMA Schema Object Tables”。

INNODB_FOREIGN 表包含以下列：

ID

外键索引的名称（不是数值），前面是模式（数据库）名称（例如，test/products_fk）。
FOR_NAME

在这个外键关系中的子表的名称。
REF_NAME

在这个外键关系中的父表的名称。
N_COLS

外键索引中的列数。
TYPE

一个包含有关外键列信息的位标志集合，通过 OR 运算在一起。0 = ON DELETE/UPDATE RESTRICT，1 = ON DELETE CASCADE，2 = ON DELETE SET NULL，4 = ON UPDATE CASCADE，8 = ON UPDATE SET NULL，16 = ON DELETE NO ACTION，32 = ON UPDATE NO ACTION。

示例

mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_FOREIGN\G
*************************** 1\. row ***************************
      ID: test/fk1
FOR_NAME: test/child
REF_NAME: test/parent
  N_COLS: 1
    TYPE: 1

注意

您必须具有PROCESS 权限才能查询此表。
使用 INFORMATION_SCHEMA 的 COLUMNS 表或 SHOW COLUMNS 语句查看有关此表的列的其他信息，包括数据类型和默认值。

28.4.13 `INFORMATION_SCHEMA` `INNODB_FOREIGN_COLS` 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-innodb-foreign-cols-table.html

INNODB_FOREIGN_COLS 表提供关于InnoDB外键列的状态信息。

有关使用信息和示例，请参见第 17.15.3 节，“InnoDB INFORMATION_SCHEMA 模式对象表”。

INNODB_FOREIGN_COLS 表具有以下列：

ID

与此索引键字段关联的外键索引；与INNODB_FOREIGN.ID相同的值。
FOR_COL_NAME

子表中关联列的名称。
REF_COL_NAME

父表中关联列的名称。
POS

此键字段在外键索引中的顺序位置，从 0 开始。

示例

mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_FOREIGN_COLS WHERE ID = 'test/fk1'\G
*************************** 1\. row ***************************
          ID: test/fk1
FOR_COL_NAME: parent_id
REF_COL_NAME: id
         POS: 0

注意

您必须具有PROCESS权限才能查询此表。
使用INFORMATION_SCHEMA COLUMNS 表或SHOW COLUMNS语句查看有关此表的列的其他信息，包括数据类型和默认值。

28.4.14 INNODB_FT_BEING_DELETED 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-innodb-ft-being-deleted-table.html

INNODB_FT_BEING_DELETED 表提供了 INNODB_FT_DELETED 表的快照；仅在 OPTIMIZE TABLE 维护操作期间使用。运行 OPTIMIZE TABLE 时，INNODB_FT_BEING_DELETED 表被清空，并且 DOC_ID 值从 INNODB_FT_DELETED 表中删除。由于 INNODB_FT_BEING_DELETED 的内容通常具有较短的生命周期，因此此表对于监视或调试具有有限的实用性。有关在具有 FULLTEXT 索引的表上运行 OPTIMIZE TABLE 的信息，请参见第 14.9.6 节，“调整 MySQL 全文搜索”。

此表最初为空。在查询之前，请将 innodb_ft_aux_table 系统变量的值设置为包含 FULLTEXT 索引的表的名称（包括数据库名称）（例如，test/articles）。输出类似于为 INNODB_FT_DELETED 表提供的示例。

有关相关用法信息和示例，请参见第 17.15.4 节，“InnoDB INFORMATION_SCHEMA FULLTEXT 索引表”。

INNODB_FT_BEING_DELETED 表包含以下列：

DOC_ID

正在删除过程中的行的文档 ID。此值可能反映您为基础表定义的 ID 列的值，或者当表不包含适当列时，可以是InnoDB生成的序列值。在执行文本搜索时，此值用于在通过 OPTIMIZE TABLE 语句物理删除FULLTEXT索引中已删除行的数据之前，跳过INNODB_FT_INDEX_TABLE 表中的行。有关更多信息，请参见优化 InnoDB 全文索引。

注意

使用INFORMATION_SCHEMA COLUMNS 表或 SHOW COLUMNS 语句查看有关此表的列的其他信息，包括数据类型和默认值。
您必须具有PROCESS权限才能查询此表。
有关InnoDB FULLTEXT搜索的更多信息，请参见 Section 17.6.2.4, “InnoDB Full-Text Indexes”，以及 Section 14.9, “Full-Text Search Functions”。

28.4.15 INFORMATION_SCHEMA INNODB_FT_CONFIG 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-innodb-ft-config-table.html

INNODB_FT_CONFIG 表提供有关InnoDB表的FULLTEXT索引和相关处理的元数据。

这个表最初是空的。在查询之前，将innodb_ft_aux_table系统变量的值设置为包含FULLTEXT索引的表的名称（包括数据库名称）（例如，test/articles）。

有关相关用法信息和示例，请参见 Section 17.15.4，“InnoDB INFORMATION_SCHEMA FULLTEXT Index Tables”。

INNODB_FT_CONFIG 表具有以下列：

KEY

指定包含FULLTEXT索引的InnoDB表的元数据项的名称。

此列的值可能会更改，具体取决于性能调整和调试InnoDB全文处理的需求。关键名称及其含义包括：
- optimize_checkpoint_limit：运行OPTIMIZE TABLE后停止的秒数。
- synced_doc_id：下一个要发行的DOC_ID。
- stopword_table_name：用户定义的停用词表的database/table名称。如果没有用户定义的停用词表，则VALUE列为空。
- use_stopword：指示是否使用停用词表，该表在创建FULLTEXT索引时定义。
VALUE

与相应KEY列关联的值，反映InnoDB表的FULLTEXT索引的某个方面的限制或当前值。

示例

mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_FT_CONFIG;
+---------------------------+-------------------+
| KEY                       | VALUE             |
+---------------------------+-------------------+
| optimize_checkpoint_limit | 180               |
| synced_doc_id             | 0                 |
| stopword_table_name       | test/my_stopwords |
| use_stopword              | 1                 |
+---------------------------+-------------------+

注意

此表仅用于内部配置。不用于统计信息目的。
您必须具有PROCESS权限才能查询此表。
使用INFORMATION_SCHEMA COLUMNS 表或SHOW COLUMNS语句查看有关此表的列的其他信息，包括数据类型和默认值。
有关InnoDB FULLTEXT搜索的更多信息，请参见 Section 17.6.2.4，“InnoDB Full-Text Indexes”，以及 Section 14.9，“Full-Text Search Functions”。

28.4.16 INFORMATION_SCHEMA INNODB_FT_DEFAULT_STOPWORD 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-innodb-ft-default-stopword-table.html

INNODB_FT_DEFAULT_STOPWORD表保存了在InnoDB表上创建FULLTEXT索引时默认使用的停用词列表。有关默认InnoDB停用词列表以及如何定义自己的停用词列表的信息，请参见第 14.9.4 节，“Full-Text Stopwords”。

有关使用信息和示例，请参见第 17.15.4 节，“InnoDB INFORMATION_SCHEMA FULLTEXT Index Tables”。

INNODB_FT_DEFAULT_STOPWORD表具有以下列：

value

作为InnoDB表上FULLTEXT索引的默认停用词使用的单词。如果使用innodb_ft_server_stopword_table或innodb_ft_user_stopword_table系统变量覆盖默认停用词处理，则不使用此单词。

示例

mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_FT_DEFAULT_STOPWORD;
+-------+
| value |
+-------+
| a     |
| about |
| an    |
| are   |
| as    |
| at    |
| be    |
| by    |
| com   |
| de    |
| en    |
| for   |
| from  |
| how   |
| i     |
| in    |
| is    |
| it    |
| la    |
| of    |
| on    |
| or    |
| that  |
| the   |
| this  |
| to    |
| was   |
| what  |
| when  |
| where |
| who   |
| will  |
| with  |
| und   |
| the   |
| www   |
+-------+
36 rows in set (0.00 sec)

注意

您必须具有PROCESS权限才能查询此表。
使用INFORMATION_SCHEMA COLUMNS表或SHOW COLUMNS语句查看有关此表的列的其他信息，包括数据类型和默认值。
有关InnoDB FULLTEXT搜索的更多信息，请参见第 17.6.2.4 节，“InnoDB Full-Text Indexes”和第 14.9 节，“Full-Text Search Functions”。

28.4.17 INFORMATION_SCHEMA INNODB_FT_DELETED 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-innodb-ft-deleted-table.html

INNODB_FT_DELETED表存储从InnoDB表的FULLTEXT索引中删除的行。为了避免在InnoDB FULLTEXT索引的 DML 操作期间进行昂贵的索引重组，新删除单词的信息被单独存储，当进行文本搜索时被过滤出搜索结果，并且只有在为InnoDB表发出OPTIMIZE TABLE时才从主搜索索引中删除。有关更多信息，请参见优化 InnoDB 全文索引。

这个表最初是空的。在查询之前，将innodb_ft_aux_table系统变量的值设置为包含FULLTEXT索引的表的名称（包括数据库名称）（例如，test/articles）。

有关相关用法信息和示例，请参见 Section 17.15.4, “InnoDB INFORMATION_SCHEMA FULLTEXT Index Tables”。

INNODB_FT_DELETED表具有以下列：

DOC_ID

新删除行的文档 ID。这个值可能反映您为基础表定义的 ID 列的值，或者当表不包含合适的列时，它可以是InnoDB生成的序列值。在执行文本搜索时，此值用于跳过在INNODB_FT_INDEX_TABLE表中为已删除行物理删除FULLTEXT索引数据之前的行，通过OPTIMIZE TABLE语句。有关更多信息，请参见优化 InnoDB 全文索引。

示例

mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_FT_DELETED;
+--------+
| DOC_ID |
+--------+
|      6 |
|      7 |
|      8 |
+--------+

注意

你必须拥有PROCESS权限才能查询这个表。
使用INFORMATION_SCHEMA COLUMNS表或SHOW COLUMNS语句查看关于这个表的列的额外信息，包括数据类型和默认值。
关于InnoDB的FULLTEXT搜索的更多信息，请参阅 Section 17.6.2.4, “InnoDB Full-Text Indexes”和 Section 14.9, “Full-Text Search Functions”。

28.4.18 INFORMATION_SCHEMA INNODB_FT_INDEX_CACHE 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-innodb-ft-index-cache-table.html

INNODB_FT_INDEX_CACHE 表提供了关于FULLTEXT索引中新插入行的标记信息。为了避免在 DML 操作期间进行昂贵的索引重组，新索引单词的信息被单独存储，并且仅在运行OPTIMIZE TABLE、服务器关闭或缓存大小超过由innodb_ft_cache_size或innodb_ft_total_cache_size系统变量定义的限制时，才与主搜索索引合并。

这个表最初是空的。在查询之前，将innodb_ft_aux_table系统变量的值设置为包含FULLTEXT索引的表的名称（包括数据库名称）（例如，test/articles）。

有关相关用法信息和示例，请参见第 17.15.4 节，“InnoDB INFORMATION_SCHEMA FULLTEXT Index Tables”。

INNODB_FT_INDEX_CACHE 表具有以下列：

WORD

从新插入行的文本中提取的一个单词。
FIRST_DOC_ID

这个单词在FULLTEXT索引中首次出现的文档 ID。
LAST_DOC_ID

这个单词在FULLTEXT索引中最后一次出现的文档 ID。
DOC_COUNT

这个单词在FULLTEXT索引中出现的行数。同一个单词可以在缓存表中出现多次，每次都对应DOC_ID和POSITION值的组合。
DOC_ID

新插入行的文档 ID。这个值可能反映了您为基础表定义的 ID 列的值，或者当表不包含合适的列时，它可以是InnoDB生成的序列值。
POSITION

这个单词在由DOC_ID值标识的相关文档中的特定实例的位置。该值不代表绝对位置；它是添加到该单词上一个实例的POSITION的偏移量。

注意

此表最初为空。在查询之前，请将innodb_ft_aux_table系统变量的值设置为包含FULLTEXT索引的表的名称（包括数据库名称）（例如test/articles）。以下示例演示了如何使用innodb_ft_aux_table系统变量来显示指定表的FULLTEXT索引的信息。

mysql> USE test;

mysql> CREATE TABLE articles (
         id INT UNSIGNED AUTO_INCREMENT NOT NULL PRIMARY KEY,
         title VARCHAR(200),
         body TEXT,
         FULLTEXT (title,body)
       ) ENGINE=InnoDB;

mysql> INSERT INTO articles (title,body) VALUES
       ('MySQL Tutorial','DBMS stands for DataBase ...'),
       ('How To Use MySQL Well','After you went through a ...'),
       ('Optimizing MySQL','In this tutorial we show ...'),
       ('1001 MySQL Tricks','1\. Never run mysqld as root. 2\. ...'),
       ('MySQL vs. YourSQL','In the following database comparison ...'),
       ('MySQL Security','When configured properly, MySQL ...');

mysql> SET GLOBAL innodb_ft_aux_table = 'test/articles';

mysql> SELECT WORD, DOC_COUNT, DOC_ID, POSITION
       FROM INFORMATION_SCHEMA.INNODB_FT_INDEX_CACHE LIMIT 5;
+------------+-----------+--------+----------+
| WORD       | DOC_COUNT | DOC_ID | POSITION |
+------------+-----------+--------+----------+
| 1001       |         1 |      4 |        0 |
| after      |         1 |      2 |       22 |
| comparison |         1 |      5 |       44 |
| configured |         1 |      6 |       20 |
| database   |         2 |      1 |       31 |
+------------+-----------+--------+----------+

您必须具有PROCESS权限才能查询此表。
使用INFORMATION_SCHEMA COLUMNS表或SHOW COLUMNS语句查看有关此表的列的其他信息，包括数据类型和默认值。
关于InnoDB FULLTEXT搜索的更多信息，请参阅 Section 17.6.2.4, “InnoDB Full-Text Indexes”和 Section 14.9, “Full-Text Search Functions”。

28.4.19 INFORMATION_SCHEMA INNODB_FT_INDEX_TABLE 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-innodb-ft-index-table-table.html

INNODB_FT_INDEX_TABLE表提供了关于用于处理针对InnoDB表的FULLTEXT索引的文本搜索的倒排索引的信息。

此表最初为空。在查询之前，请将innodb_ft_aux_table系统变量的值设置为包含FULLTEXT索引的表的名称（包括数据库名称）（例如，test/articles）。

有关相关用法信息和示例，请参见 Section 17.15.4，“InnoDB INFORMATION_SCHEMA FULLTEXT Index Tables”。

INNODB_FT_INDEX_TABLE表具有以下列：

WORD

从FULLTEXT的文本中提取的一个单词。
FIRST_DOC_ID

此单词在FULLTEXT索引中首次出现的文档 ID。
LAST_DOC_ID

此单词在FULLTEXT索引中出现的最后一个文档 ID。
DOC_COUNT

此单词在FULLTEXT索引中出现的行数。同一个单词可以在缓存表中出现多次，每次对应不同的DOC_ID和POSITION值组合。
DOC_ID

包含该单词的行的文档 ID。此值可能反映您为基础表定义的 ID 列的值，或者当表不包含合适的列时，它可以是InnoDB生成的序列值。
POSITION

该单词在由DOC_ID值标识的相关文档中的特定实例的位置。

注意事项

这个表最初是空的。在查询之前，将innodb_ft_aux_table系统变量的值设置为包含FULLTEXT索引的表的名称（包括数据库名称）（例如，test/articles）。以下示例演示了如何使用innodb_ft_aux_table系统变量显示指定表的FULLTEXT索引信息。在新插入行的信息出现在INNODB_FT_INDEX_TABLE之前，必须将FULLTEXT索引缓存刷新到磁盘。这可以通过在启用innodb_optimize_fulltext_only系统变量的情况下对带有索引的表运行OPTIMIZE TABLE操作来实现。（示例在最后再次禁用该变量，因为它只打算暂时启用。）

mysql> USE test;

mysql> CREATE TABLE articles (
         id INT UNSIGNED AUTO_INCREMENT NOT NULL PRIMARY KEY,
         title VARCHAR(200),
         body TEXT,
         FULLTEXT (title,body)
       ) ENGINE=InnoDB;

mysql> INSERT INTO articles (title,body) VALUES
       ('MySQL Tutorial','DBMS stands for DataBase ...'),
       ('How To Use MySQL Well','After you went through a ...'),
       ('Optimizing MySQL','In this tutorial we show ...'),
       ('1001 MySQL Tricks','1\. Never run mysqld as root. 2\. ...'),
       ('MySQL vs. YourSQL','In the following database comparison ...'),
       ('MySQL Security','When configured properly, MySQL ...');

mysql> SET GLOBAL innodb_optimize_fulltext_only=ON;

mysql> OPTIMIZE TABLE articles;
+---------------+----------+----------+----------+
| Table         | Op       | Msg_type | Msg_text |
+---------------+----------+----------+----------+
| test.articles | optimize | status   | OK       |
+---------------+----------+----------+----------+

mysql> SET GLOBAL innodb_ft_aux_table = 'test/articles';

mysql> SELECT WORD, DOC_COUNT, DOC_ID, POSITION
       FROM INFORMATION_SCHEMA.INNODB_FT_INDEX_TABLE LIMIT 5;
+------------+-----------+--------+----------+
| WORD       | DOC_COUNT | DOC_ID | POSITION |
+------------+-----------+--------+----------+
| 1001       |         1 |      4 |        0 |
| after      |         1 |      2 |       22 |
| comparison |         1 |      5 |       44 |
| configured |         1 |      6 |       20 |
| database   |         2 |      1 |       31 |
+------------+-----------+--------+----------+

mysql> SET GLOBAL innodb_optimize_fulltext_only=OFF;

你必须拥有PROCESS权限才能查询这个表。
使用INFORMATION_SCHEMA COLUMNS表或SHOW COLUMNS语句查看有关这个表的列的其他信息，包括数据类型和默认值。
有关InnoDB FULLTEXT搜索的更多信息，请参见 Section 17.6.2.4, “InnoDB Full-Text Indexes”，以及 Section 14.9, “Full-Text Search Functions”。

28.4.20 The INFORMATION_SCHEMA INNODB_INDEXES Table

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-innodb-indexes-table.html

INNODB_INDEXES 表提供关于 InnoDB 索引的元数据。

有关使用信息和示例，请参见第 17.15.3 节，“InnoDB INFORMATION_SCHEMA Schema Object Tables”。

INNODB_INDEXES 表具有以下列：

INDEX_ID

索引的标识符。索引标识符在实例中的所有数据库中是唯一的。
NAME

索引的名称。大多数由 InnoDB 隐式创建的索引具有一致的名称，但索引名称不一定是唯一的。例如：主键索引的 PRIMARY，表示主键的索引的 GEN_CLUST_INDEX，以及外键约束的 ID_IND、FOR_IND 和 REF_IND。
TABLE_ID

表示与索引关联的表的标识符；与 INNODB_TABLES.TABLE_ID 相同的值。
TYPE

从位级信息派生的数字值，用于标识索引类型。0 = 非唯一二级索引；1 = 自动生成的聚簇索引 (GEN_CLUST_INDEX)；2 = 唯一非聚簇索引；3 = 聚簇索引；32 = 全文索引；64 = 空间索引；128 = 虚拟生成列上的二级索引。
N_FIELDS

索引键中的列数。对于 GEN_CLUST_INDEX 索引，此值为 0，因为该索引是使用人工值而不是真实表列创建的。
PAGE_NO

索引 B 树的根页码。对于全文索引，PAGE_NO 列未使用，并设置为 -1 (FIL_NULL)，因为全文索引是在几个 B 树（辅助表）中布局的。
SPACE

表所在表空间的标识符。0 表示 InnoDB 系统表空间。任何其他数字表示以每表一个文件模式创建的单独 .ibd 文件的表。在 TRUNCATE TABLE 语句之后，此标识符保持不变。因为表的所有索引都位于与表相同的表空间中，所以此值不一定是唯一的。
MERGE_THRESHOLD

索引页面的合并阈值值。如果索引页面中的数据量低于MERGE_THRESHOLD值，当删除一行或通过更新操作缩短一行时，InnoDB会尝试将索引页面与相邻的索引页面合并。默认阈值值为 50%。有关更多信息，请参见第 17.8.11 节，“配置索引页面合并阈值”。

示例

mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_INDEXES WHERE TABLE_ID = 34\G
*************************** 1\. row ***************************
       INDEX_ID: 39
           NAME: GEN_CLUST_INDEX
       TABLE_ID: 34
           TYPE: 1
       N_FIELDS: 0
        PAGE_NO: 3
          SPACE: 23
MERGE_THRESHOLD: 50
*************************** 2\. row ***************************
       INDEX_ID: 40
           NAME: i1
       TABLE_ID: 34
           TYPE: 0
       N_FIELDS: 1
        PAGE_NO: 4
          SPACE: 23
MERGE_THRESHOLD: 50

注意

您必须具有PROCESS权限才能查询此表。
使用INFORMATION_SCHEMA COLUMNS表或SHOW COLUMNS语句查看有关此表的列的其他信息，包括数据类型和默认值。

28.4.21 INFORMATION_SCHEMA INNODB_METRICS 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-innodb-metrics-table.html

INNODB_METRICS表提供各种InnoDB性能信息，补充了InnoDB性能模式表的特定关注领域。通过简单的查询，您可以检查系统的整体健康状况。通过更详细的查询，您可以诊断性能瓶颈、资源短缺和应用程序问题等问题。

每个监视器代表InnoDB源代码中的一个点，用于收集计数器信息。每个计数器可以启动、停止和重置。您还可以针对它们的共同模块名称执行这些操作的一组计数器。

默认情况下，收集的数据相对较少。要启动、停止和重置计数器，请设置以下系统变量之一innodb_monitor_enable、innodb_monitor_disable、innodb_monitor_reset或innodb_monitor_reset_all，使用计数器的名称、模块的名称、使用“%”字符进行名称的通配符匹配，或者特殊关键字all。

有关使用信息，请参见第 17.15.6 节，“InnoDB INFORMATION_SCHEMA Metrics Table”。

INNODB_METRICS表具有以下列：

NAME

计数器的唯一名称。
SUBSYSTEM

应用于InnoDB的指标方面。
COUNT

自计数器启用以来的值。
MAX_COUNT

自计数器启用以来的最大值。
MIN_COUNT

自计数器启用以来的最小值。
AVG_COUNT

自计数器启用以来的平均值。
COUNT_RESET

自上次重置以来的计数器值。（_RESET列就像秒表上的圈数计数器：您可以测量某个时间间隔内的活动，而累积数据仍然可在COUNT、MAX_COUNT等中找到。）
MAX_COUNT_RESET

自上次重置以来的最大计数器值。
MIN_COUNT_RESET

自上次重置以来的最小计数器值。
AVG_COUNT_RESET

自上次重置以来的平均计数器值。
TIME_ENABLED

上次启动的时间戳。
TIME_DISABLED

上次停止的时间戳。
TIME_ELAPSED

自计数器启动以来经过的秒数。
TIME_RESET

上次重置的时间戳。
STATUS

计数器是否仍在运行（enabled）或已��止（disabled）。
TYPE

该项目是累积计数器，还是测量某些资源的当前值。
COMMENT

计数器描述。

示例

mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_METRICS WHERE NAME='dml_inserts'\G
*************************** 1\. row ***************************
           NAME: dml_inserts
      SUBSYSTEM: dml
          COUNT: 3
      MAX_COUNT: 3
      MIN_COUNT: NULL
      AVG_COUNT: 0.046153846153846156
    COUNT_RESET: 3
MAX_COUNT_RESET: 3
MIN_COUNT_RESET: NULL
AVG_COUNT_RESET: NULL
   TIME_ENABLED: 2014-12-04 14:18:28
  TIME_DISABLED: NULL
   TIME_ELAPSED: 65
     TIME_RESET: NULL
         STATUS: enabled
           TYPE: status_counter
        COMMENT: Number of rows inserted

笔记

您必须具有PROCESS权限才能查询此表。
使用INFORMATION_SCHEMA COLUMNS表或SHOW COLUMNS语句查看有关此表的列的其他信息，包括数据类型和默认值。
事务计数器COUNT的值可能与性能模式EVENTS_TRANSACTIONS_SUMMARY表中报告的事务事件数量不同。 InnoDB仅计算其执行的事务，而性能模式收集由服务器发起的所有未中止事务的事件，包括空事务。

28.4.22 The INFORMATION_SCHEMA INNODB_SESSION_TEMP_TABLESPACES Table

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-innodb-session-temp-tablespaces-table.html

INNODB_SESSION_TEMP_TABLESPACES表提供有关用于内部和用户创建的临时表的会话临时表空间的元数据。此表在 MySQL 8.0.13 中添加。

INNODB_SESSION_TEMP_TABLESPACES表具有以下列：

ID

进程或会话 ID。
空间

表空间 ID。为会话临时表空间保留了 40 万个空间 ID 范围。每次服务器启动时都会重新创建会话临时表空间。在关闭服务器时，空间 ID 不会持久化，并且可能会被重用。
路径

表空间数据文件路径。会话临时表空间具有ibt文件扩展名。
大小

表空间的大小，以字节为单位。
状态

表空间的状态。ACTIVE表示该表空间当前被会话使用。INACTIVE表示该表空间在可用会话临时表空间池中。
目的

表空间的目的。INTRINSIC表示该表空间用于优化内部临时表，由优化器使用。SLAVE表示该表空间用于在复制从库上存储用户创建的临时表。USER表示该表空间用于用户创建的临时表。NONE表示该表空间未被使用。

示例

mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_SESSION_TEMP_TABLESPACES;
+----+------------+----------------------------+-------+----------+-----------+
| ID | SPACE      | PATH                       | SIZE  | STATE    | PURPOSE   |
+----+------------+----------------------------+-------+----------+-----------+
|  8 | 4294566162 | ./#innodb_temp/temp_10.ibt | 81920 | ACTIVE   | INTRINSIC |
|  8 | 4294566161 | ./#innodb_temp/temp_9.ibt  | 98304 | ACTIVE   | USER      |
|  0 | 4294566153 | ./#innodb_temp/temp_1.ibt  | 81920 | INACTIVE | NONE      |
|  0 | 4294566154 | ./#innodb_temp/temp_2.ibt  | 81920 | INACTIVE | NONE      |
|  0 | 4294566155 | ./#innodb_temp/temp_3.ibt  | 81920 | INACTIVE | NONE      |
|  0 | 4294566156 | ./#innodb_temp/temp_4.ibt  | 81920 | INACTIVE | NONE      |
|  0 | 4294566157 | ./#innodb_temp/temp_5.ibt  | 81920 | INACTIVE | NONE      |
|  0 | 4294566158 | ./#innodb_temp/temp_6.ibt  | 81920 | INACTIVE | NONE      |
|  0 | 4294566159 | ./#innodb_temp/temp_7.ibt  | 81920 | INACTIVE | NONE      |
|  0 | 4294566160 | ./#innodb_temp/temp_8.ibt  | 81920 | INACTIVE | NONE      |
+----+------------+----------------------------+-------+----------+-----------+

注意

您必须具有PROCESS权限才能查询此表。
使用INFORMATION_SCHEMA COLUMNS表或SHOW COLUMNS语句查看有关此表的列的其他信息，包括数据类型和默认值。

28.4.23 INFORMATION_SCHEMA INNODB_TABLES 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-innodb-tables-table.html

INNODB_TABLES表提供关于InnoDB表的元数据。

有关相关用法信息和示例，请参见第 17.15.3 节，“InnoDB INFORMATION_SCHEMA 模式对象表”。

INNODB_TABLES表具有以下列：

TABLE_ID

InnoDB表的标识符。此值在实例中的所有数据库中是唯一的。
NAME

表的名称，前面加上适当的模式（数据库）名称（例如，test/t1）。数据库和用户表的名称与它们最初定义时的大小写相同，可能受到lower_case_table_names设置的影响。
FLAG

代表表格式和存储特性的位级信息的数值。
N_COLS

表中的列数。报告的数字包括InnoDB创建的三个隐藏列（DB_ROW_ID、DB_TRX_ID和DB_ROLL_PTR）。报告的数字还包括虚拟生成列（如果存在）。
SPACE

表所在表空间的标识符。0 表示InnoDB系统表空间。任何其他数字表示文件表空间或通用表空间。在TRUNCATE TABLE语句之后，此标识符保持不变。对于文件表空间，此标识符在实例中的所有数据库中对表是唯一的。
ROW_FORMAT

表的行格式（Compact、Redundant、Dynamic或Compressed）。
ZIP_PAGE_SIZE

压缩页大小。仅适用于行格式为Compressed的表。
SPACE_TYPE

表所属的表空间类型。可能的值包括系统表空间的System，通用表空间的General和每个表的文件表空间的Single。使用CREATE TABLE或ALTER TABLE TABLESPACE=innodb_system分配给系统表空间的表具有SPACE_TYPE为General。有关更多信息，请参见CREATE TABLESPACE。
INSTANT_COLS

在使用ALTER TABLE ... ADD COLUMN和ALGORITHM=INSTANT添加第一个瞬时列之前存在的列数。自 MySQL 8.0.29 起，不再使用此列，但继续显示在 MySQL 8.0.29 之前瞬时添加列的表的信息。
TOTAL_ROW_VERSIONS

表的行版本数量。初始值为 0。通过增加或删除列的ALTER TABLE ... ALGORITHM=INSTANT操作来递增该值。当具有瞬时添加或删除列的表由于表重建的ALTER TABLE或OPTIMIZE TABLE操作而重建时，该值将重置为 0。有关更多信息，请参见列操作。

示例

mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_TABLES WHERE TABLE_ID = 214\G
*************************** 1\. row ***************************
          TABLE_ID: 1064
              NAME: test/t1
              FLAG: 33
            N_COLS: 6
             SPACE: 3
        ROW_FORMAT: Dynamic
     ZIP_PAGE_SIZE: 0
        SPACE_TYPE: Single
      INSTANT_COLS: 0
TOTAL_ROW_VERSIONS: 3

注意

您必须具有PROCESS权限才能查询此表。
使用INFORMATION_SCHEMA COLUMNS表或SHOW COLUMNS语句查看有关此表的列的其他信息，包括数据类型和默认值。

28.4.24 `INFORMATION_SCHEMA INNODB_TABLESPACES` 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-innodb-tablespaces-table.html

INNODB_TABLESPACES 表提供关于 InnoDB 文件表空间、通用表空间和撤销表空间的元数据。

有关相关用法信息和示例，请参见第 17.15.3 节，“InnoDB INFORMATION_SCHEMA Schema Object Tables”。

注意

INFORMATION_SCHEMA FILES 表报告了 InnoDB 表空间类型的元数据，包括文件表空间、通用表空间、系统表空间、全局临时表空间和撤销表空间。

INNODB_TABLESPACES 表具有以下列：

SPACE

表空间 ID。
NAME

模式（数据库）和表名。
FLAG

代表表空间格式和存储特性的位级信息的数值。
ROW_FORMAT

表空间行格式（Compact or Redundant，Dynamic 或 Compressed，或 Undo）。此列中的数据是从数据文件中的表空间标志信息解释而来。

无法从此标志信息确定表空间行格式是 Redundant 还是 Compact，这就是为什么可能的 ROW_FORMAT 值之一是 Compact or Redundant。
PAGE_SIZE

表空间页大小。此列中的数据是从 .ibd 文件中的表空间标志信息解释而来。
ZIP_PAGE_SIZE

表空间 zip 页大小。此列中的数据是从 .ibd 文件中的表空间标志信息解释而来。
SPACE_TYPE

表空间类型。可能的值包括通用表空间的 General，文件表空间的 Single，系统表空间的 System，以及撤销表空间的 Undo。
FS_BLOCK_SIZE

文件系统块大小，用于空洞打孔的单位大小。此列与 InnoDB 透明页压缩功能相关。
FILE_SIZE

文件的表面大小，表示文件的最大未压缩大小。此列与 InnoDB 透明页压缩功能相关。
ALLOCATED_SIZE

文件的实际大小，即在磁盘上分配的空间。此列与InnoDB的透明页压缩功能有关。
AUTOEXTEND_SIZE

表空间的自动扩展大小。此列在 MySQL 8.0.23 中添加。
SERVER_VERSION

创建表空间的 MySQL 版本，或导入表空间的 MySQL 版本，或最后一次主要 MySQL 版本升级的版本。该值不会受到发行系列升级的影响，例如从 MySQL 8.0.x升级到 8.0.y。该值可以被视为表空间的“创建”标记或“认证”标记。
SPACE_VERSION

表空间版本，用于跟踪表空间格式的更改。
ENCRYPTION

表空间是否加密。此列在 MySQL 8.0.13 中添加。
STATE

表空间状态。此列在 MySQL 8.0.14 中添加。

对于每个表和通用表空间，状态包括：
- normal：表空间正常且活动。
- discarded：表空间被ALTER TABLE ... DISCARD TABLESPACE语句丢弃。
- corrupted：表空间被InnoDB标识为损坏。
对于撤销表空间，状态包括：
- active：撤销表空间中的回滚段可以分配给新事务。
- inactive：撤销表空间中的回滚段不再被新事务使用。截断过程正在进行中。撤销表空间要么被清理线程隐式选择，要么通过ALTER UNDO TABLESPACE ... SET INACTIVE语句被设置为不活动。
- empty：撤销表空间被截断，不再活动。可以通过ALTER UNDO TABLESPACE ... SET INACTIVE语句将其删除或重新激活。

示例

mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_TABLESPACES WHERE SPACE = 26\G
*************************** 1\. row ***************************
         SPACE: 26
          NAME: test/t1
          FLAG: 0
    ROW_FORMAT: Compact or Redundant
     PAGE_SIZE: 16384
 ZIP_PAGE_SIZE: 0
    SPACE_TYPE: Single
 FS_BLOCK_SIZE: 4096
     FILE_SIZE: 98304
ALLOCATED_SIZE: 65536
AUTOEXTEND_SIZE: 0
SERVER_VERSION: 8.0.23
 SPACE_VERSION: 1
    ENCRYPTION: N
         STATE: normal

注意

您必须具有PROCESS权限才能查询此表。
使用INFORMATION_SCHEMA的COLUMNS表或SHOW COLUMNS语句查看有关此表的列的其他信息，包括数据类型和默认值。

28.4.25 The INFORMATION_SCHEMA INNODB_TABLESPACES_BRIEF Table

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-innodb-tablespaces-brief-table.html

INNODB_TABLESPACES_BRIEF表为每个表、通用、撤销和系统表空间提供了文件表空间的空间 ID、名称、路径、标志和空间类型元数据。

INNODB_TABLESPACES提供相同的元数据，但加载速度较慢，因为表提供的其他元数据，如FS_BLOCK_SIZE、FILE_SIZE和ALLOCATED_SIZE，必须动态加载。

空间和路径元数据也由INNODB_DATAFILES表提供。

INNODB_TABLESPACES_BRIEF表具有以下列：

SPACE

表空间 ID。
NAME

表空间名称。对于每个表的文件表空间，名称采用schema/table_name的形式。
PATH

表空间数据文件路径。如果在 MySQL 数据目录之外创建了 file-per-table 表空间，则路径值是完全限定的目录路径。否则，路径是相对于数据目录的。
FLAG

代表表空间格式和存储特性的位级信息的数值。
SPACE_TYPE

表空间类型。可能的值包括General表示InnoDB通用表空间，Single表示InnoDB每个表的文件表空间，System表示InnoDB系统表空间。

示例

mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_TABLESPACES_BRIEF WHERE SPACE = 7;
+-------+---------+---------------+-------+------------+
| SPACE | NAME    | PATH          | FLAG  | SPACE_TYPE |
+-------+---------+---------------+-------+------------+
| 7     | test/t1 | ./test/t1.ibd | 16417 | Single     |
+-------+---------+---------------+-------+------------+

笔记

您必须具有PROCESS权限才能查询此表。
使用INFORMATION_SCHEMA COLUMNS表或SHOW COLUMNS语句查看有关此表列的其他信息，包括数据类型和默认值。

28.4.26 INFORMATION_SCHEMA INNODB_TABLESTATS 视图

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-innodb-tablestats-table.html

INNODB_TABLESTATS 表提供了关于 InnoDB 表的低级状态信息的视图。这些数据由 MySQL 优化器使用，以计算在查询 InnoDB 表时要使用哪个索引。这些信息源自内存数据结构，而不是存储在磁盘上的数据。没有相应的内部 InnoDB 系统表。

如果自上次服务器重启以来已打开并且尚未从表缓存中过期的话，InnoDB 表将在此视图中表示。始终在此视图中表示具有持久统计信息的表。

仅对修改索引列的 DELETE 或 UPDATE 操作更新表统计信息。仅修改非索引列的操作不会更新统计信息。

ANALYZE TABLE 清除表统计信息，并将 STATS_INITIALIZED 列设置为 Uninitialized。下次访问表时将重新收集统计信息。

有关相关用法信息和示例，请参见第 17.15.3 节，“InnoDB INFORMATION_SCHEMA Schema Object Tables”。

INNODB_TABLESTATS 表具有以下列：

TABLE_ID

表的标识符，可用于查看可用统计信息的表；与 INNODB_TABLES.TABLE_ID 相同的值。
NAME

表的名称；与 INNODB_TABLES.NAME 相同的值。
STATS_INITIALIZED

如果已经收集了统计信息，则值为 Initialized，否则为 Uninitialized。
NUM_ROWS

表中当前估计的行数。每次 DML 操作后更新。如果未提交事务正在向表中插入或删除数据，则该值可��不准确。
CLUST_INDEX_SIZE

存储聚簇索引的磁盘上的页数，该索引按主键顺序保存 InnoDB 表数据。如果尚未为表收集统计信息，则此值可能为 null。
OTHER_INDEX_SIZE

存储表的所有辅助索引的磁盘上的页数。如果尚未为表收集统计信息，则此值可能为 null。
MODIFIED_COUNTER

被 DML 操作修改的行数，如 INSERT、UPDATE、DELETE，还有外键级联操作。每次重新计算表统计信息时，此列将被重置。
AUTOINC

任何基于自增操作的下一个要发行的数字。AUTOINC 值变化的速率取决于自增数已被请求多少次以及每次请求被授予多少个数字。
REF_COUNT

当这个计数器达到零时，表元数据可以从表缓存中驱逐出去。

示例

mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_TABLESTATS where TABLE_ID = 71\G
*************************** 1\. row ***************************
         TABLE_ID: 71
             NAME: test/t1
STATS_INITIALIZED: Initialized
         NUM_ROWS: 1
 CLUST_INDEX_SIZE: 1
 OTHER_INDEX_SIZE: 0
 MODIFIED_COUNTER: 1
          AUTOINC: 0
        REF_COUNT: 1

注意

这个表主要用于专家级性能监控，或者在开发与 MySQL 相关的性能扩展时使用。
你必须拥有PROCESS权限才能查询这个表。
使用 INFORMATION_SCHEMA COLUMNS 表或 SHOW COLUMNS 语句查看关于这个表的列的额外信息，包括数据类型和默认值。

28.4.27 INFORMATION_SCHEMA INNODB_TEMP_TABLE_INFO 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-innodb-temp-table-info-table.html

INNODB_TEMP_TABLE_INFO表提供有关在InnoDB实例中活动的用户创建的InnoDB临时表的信息。它不提供有关优化器使用的内部InnoDB临时表的信息。INNODB_TEMP_TABLE_INFO表在首次查询时创建，仅存在于内存中，不会持久保存到磁盘。

有关用法信息和示例，请参见第 17.15.7 节，“InnoDB INFORMATION_SCHEMA 临时表信息表”。

INNODB_TEMP_TABLE_INFO表具有以下列：

TABLE_ID

临时表的表 ID。
NAME

临时表的名称。
N_COLS

临时表中的列数。该数字包括InnoDB创建的三个隐藏列（DB_ROW_ID、DB_TRX_ID和DB_ROLL_PTR）。
SPACE

临时表所在的临时表空间的 ID。

示例

mysql> CREATE TEMPORARY TABLE t1 (c1 INT PRIMARY KEY) ENGINE=INNODB;

mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_TEMP_TABLE_INFO\G
*************************** 1\. row ***************************
TABLE_ID: 97
    NAME: #sql8c88_43_0
  N_COLS: 4
   SPACE: 76

注意

此表主要用于专家级别的监视。
您必须具有PROCESS权限才能查询此表。
使用INFORMATION_SCHEMA COLUMNS表或SHOW COLUMNS语句查看有关此表列的其他信息，包括数据类型和默认值。

28.4.28 INFORMATION_SCHEMA INNODB_TRX 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-innodb-trx-table.html

INNODB_TRX表提供有关当前在InnoDB内部执行的每个事务的信息，包括事务是否正在等待锁定，事务开始时间以及事务正在执行的 SQL 语句（如果有）。

用法信息，请参见第 17.15.2.1 节，“使用 InnoDB 事务和锁定信息”。

INNODB_TRX表具有以下列：

TRX_ID

一个在InnoDB内部唯一的事务 ID 号。这些 ID 不会为只读和非锁定的事务创建。详情请参见第 10.5.3 节，“优化 InnoDB 只读事务”。
TRX_WEIGHT

事务的权重，反映（但不一定是准确的）事务修改的行数和被事务锁定的行数。为了解决死锁，InnoDB选择具有最小权重的事务作为“受害者”进行回滚。已更改非事务表的事务被认为比其他事务更重，无论修改和锁定的行数如何。
TRX_STATE

事务执行状态。允许的值为RUNNING、LOCK WAIT、ROLLING BACK和COMMITTING。
TRX_STARTED

事务开始时间。
TRX_REQUESTED_LOCK_ID

事务当前正在等待的锁的 ID，如果TRX_STATE为LOCK WAIT；否则为NULL。要获取有关锁的详细信息，请将此列与性能模式data_locks表的ENGINE_LOCK_ID列连接。
TRX_WAIT_STARTED

事务开始等待锁的时间，如果TRX_STATE为LOCK WAIT；否则为NULL。
TRX_MYSQL_THREAD_ID

MySQL 线程 ID。要获取有关线程的详细信息，请将此列与INFORMATION_SCHEMA PROCESSLIST表的ID列连接，但请参见第 17.15.2.3 节，“InnoDB 事务和锁定信息的持久性和一致性”。
TRX_QUERY

正在被事务执行的 SQL 语句。
TRX_OPERATION_STATE

事务的当前操作，如果有的话；否则为NULL。
TRX_TABLES_IN_USE

在处理当前事务的 SQL 语句时使用的InnoDB表的数量。
TRX_TABLES_LOCKED

当前 SQL 语句在哪些InnoDB表上有行锁。（因为这些是行锁，而不是表锁，所以尽管某些行被锁定，表通常仍然可以被多个事务读取和写入。）
TRX_LOCK_STRUCTS

事务保留的锁数。
TRX_LOCK_MEMORY_BYTES

此事务在内存中锁结构所占用的总大小。
TRX_ROWS_LOCKED

此事务锁定的行数的近似值。该值可能包括物理上存在但对事务不可见的删除标记行。
TRX_ROWS_MODIFIED

这个事务中修改和插入的行数。
TRX_CONCURRENCY_TICKETS

表示当前事务在被交换出之前可以完成多少工作的值，由innodb_concurrency_tickets系统变量指定。
TRX_ISOLATION_LEVEL

当前事务的隔离级别。
TRX_UNIQUE_CHECKS

当前事务是否打开或关闭唯一性检查。例如，在大量数据加载期间可能会关闭它们。
TRX_FOREIGN_KEY_CHECKS

当前事务是否打开或关闭外键检查。例如，在大量数据加载期间可能会关闭它们。
TRX_LAST_FOREIGN_KEY_ERROR

如果有的话，最后一个外键错误的详细错误消息；否则为NULL。
TRX_ADAPTIVE_HASH_LATCHED

当前事务是否锁定自适应哈希索引。当自适应哈希索引搜索系统被分区时，单个事务不会锁定整个自适应哈希索引。自适应哈希索引分区由innodb_adaptive_hash_index_parts控制，默认设置为 8。
TRX_ADAPTIVE_HASH_TIMEOUT

是否立即放弃自适应哈希索引的搜索锁，还是在 MySQL 的调用之间保留它。当没有自适应哈希索引争用时，此值保持为零，并且语句保留锁直到完成。在争用时，它倒计时到零，并且语句在每次行查找后立即释放锁。当自适应哈希索引搜索系统被分区（由innodb_adaptive_hash_index_parts控制）时，该值保持为 0。
TRX_IS_READ_ONLY

值为 1 表示事务是只读的。
TRX_AUTOCOMMIT_NON_LOCKING

值为 1 表示事务是一个不使用FOR UPDATE或LOCK IN SHARED MODE子句的SELECT语句，并且在启用autocommit的情况下执行，因此事务仅包含此一个语句。当此列和TRX_IS_READ_ONLY都为 1 时，InnoDB会优化事务以减少与更改表数据的事务相关的开销。
TRX_SCHEDULE_WEIGHT

由内容感知事务调度（CATS）算法分配给等待锁的事务的事务调度权重。该值相对于其他事务的值。较高的值具有更大的权重。仅为处于LOCK WAIT状态的事务计算值，如TRX_STATE列所报告的那样。对于不等待锁的事务，将报告 NULL 值。TRX_SCHEDULE_WEIGHT值与由不同算法为不同目的计算的TRX_WEIGHT值不同。

示例

mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX\G
*************************** 1\. row ***************************
                    trx_id: 1510
                 trx_state: RUNNING
               trx_started: 2014-11-19 13:24:40
     trx_requested_lock_id: NULL
          trx_wait_started: NULL
                trx_weight: 586739
       trx_mysql_thread_id: 2
                 trx_query: DELETE FROM employees.salaries WHERE salary > 65000
       trx_operation_state: updating or deleting
         trx_tables_in_use: 1
         trx_tables_locked: 1
          trx_lock_structs: 3003
     trx_lock_memory_bytes: 450768
           trx_rows_locked: 1407513
         trx_rows_modified: 583736
   trx_concurrency_tickets: 0
       trx_isolation_level: REPEATABLE READ
         trx_unique_checks: 1
    trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
 trx_adaptive_hash_latched: 0
 trx_adaptive_hash_timeout: 10000
          trx_is_read_only: 0
trx_autocommit_non_locking: 0
       trx_schedule_weight: NULL

注意事项

使用此表格帮助诊断在高并发负载时发生的性能问题。其内容如 Section 17.15.2.3, “InnoDB 事务和锁信息的持久性和一致性”所述更新。
您必须具有PROCESS权限才能查询此表。
使用INFORMATION_SCHEMA COLUMNS表或SHOW COLUMNS语句查看有关此表的列的其他信息，包括数据类型和默认值。

28.4.29 INFORMATION_SCHEMA INNODB_VIRTUAL 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-innodb-virtual-table.html

INNODB_VIRTUAL表提供关于InnoDB虚拟生成列和虚拟生成列所基于的列的元数据。

每个虚拟生成列所基于的列在INNODB_VIRTUAL表中都会出现一行。

INNODB_VIRTUAL表具有以下列：

TABLE_ID

表示与虚拟列关联的表的标识符；与INNODB_TABLES.TABLE_ID相同的值。
POS

虚拟生成列的位置值。该值很大，因为它编码了列序号和序号位置。用于计算该值的公式使用位操作：
```
((*n*th virtual generated column for the InnoDB instance + 1) << 16)
+ the ordinal position of the virtual generated column
```
例如，如果InnoDB实例中的第一个虚拟生成列是表中的第三列，则公式为((0 + 1) << 16) + 2。InnoDB实例中的第一个虚拟生成列始终为编号 0。作为表中的第三列，虚拟生成列的序号位置为 2。序号位置从 0 开始计数。
BASE_POS

虚拟生成列所基于的列的序号位置。

示例

mysql> CREATE TABLE `t1` (
         `a` int(11) DEFAULT NULL,
         `b` int(11) DEFAULT NULL,
         `c` int(11) GENERATED ALWAYS AS (a+b) VIRTUAL,
         `h` varchar(10) DEFAULT NULL
       ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_VIRTUAL
       WHERE TABLE_ID IN
         (SELECT TABLE_ID FROM INFORMATION_SCHEMA.INNODB_TABLES
          WHERE NAME LIKE "test/t1");
+----------+-------+----------+
| TABLE_ID | POS   | BASE_POS |
+----------+-------+----------+
|       98 | 65538 |        0 |
|       98 | 65538 |        1 |
+----------+-------+----------+

注意

如果将常量值分配给虚拟生成列，如下表所示，列的条目不会出现在INNODB_VIRTUAL表中。要出现条目，虚拟生成列必须有基本列。
```
CREATE TABLE `t1` (
  `a` int(11) DEFAULT NULL,
  `b` int(11) DEFAULT NULL,
  `c` int(11) GENERATED ALWAYS AS (5) VIRTUAL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
```
但是，这样的列的元数据确实出现在INNODB_COLUMNS表中。
您必须拥有PROCESS权限才能查询此表。
使用INFORMATION_SCHEMA``COLUMNS表或SHOW COLUMNS语句查看有关此表的列的其他信息，包括数据类型和默认值。

28.5 INFORMATION_SCHEMA 线程池表

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

28.5.1 INFORMATION_SCHEMA 线程池表参考

28.5.2 INFORMATION_SCHEMA TP_THREAD_GROUP_STATE 表

28.5.3 INFORMATION_SCHEMA TP_THREAD_GROUP_STATS 表

28.5.4 INFORMATION_SCHEMA TP_THREAD_STATE 表

注意

截至 MySQL 8.0.14，INFORMATION_SCHEMA线程池表也可作为性能模式表使用（参见第 29.12.16 节，“性能模式线程池表”：关于线程池线程组状态的信息

TP_THREAD_GROUP_STATS：线程组统计信息
TP_THREAD_STATE：关于线程池线程状态的信息

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

INFORMATION_SCHEMA线程池表由各个插件实现，是否加载一个插件的决定可以独立于其他插件（参见[第 7.6.3.2 节，“线程池安装”](thread-pool-installation.html "7.6.3.2 Thread Pool Installation"））。但是，所有表的内容取决于启用线程池插件。如果启用了表插件但未启用线程池插件，则该表变为可见并且可以访问，但为空。

28.5.1 INFORMATION_SCHEMA 线程池表参考

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-thread-pool-table-reference.html

以下表格总结了INFORMATION_SCHEMA线程池表。更详细的信息，请参阅各个表的描述。

表 28.7 INFORMATION_SCHEMA 线程池表

表名	描述
`TP_THREAD_GROUP_STATE`	线程池线程组状态
`TP_THREAD_GROUP_STATS`	线程池线程组统计
`TP_THREAD_STATE`	线程池线程信息

28.5.2 INFORMATION_SCHEMA TP_THREAD_GROUP_STATE 表

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

注意

从 MySQL 8.0.14 开始，线程池INFORMATION_SCHEMA表也可以作为性能模式表使用。（参见 Section 29.12.16, “Performance Schema Thread Pool Tables”.）INFORMATION_SCHEMA表已被弃用；预计它们将在将来的 MySQL 版本中被移除。应用程序应该从旧表过渡到新表。例如，如果一个应用程序使用这个查询：

SELECT * FROM INFORMATION_SCHEMA.TP_THREAD_GROUP_STATE;

应用程序应该使用这个查询：

SELECT * FROM performance_schema.tp_thread_group_state;

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

关于INFORMATION_SCHEMA TP_THREAD_GROUP_STATE表中列的描述，请参见 Section 29.12.16.1, “The tp_thread_group_state Table”. 性能模式tp_thread_group_state表具有相同的列。

28.5.3 INFORMATION_SCHEMA TP_THREAD_GROUP_STATS 表

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

注意

从 MySQL 8.0.14 开始，线程池INFORMATION_SCHEMA表也可以作为性能模式表使用。（参见 Section 29.12.16, “性能模式线程池表”.）INFORMATION_SCHEMA表已被弃用；预计它们将在 MySQL 的未来版本中被移除。应用程序应该从旧表过渡到新表。例如，如果一个应用程序使用这个查询：

SELECT * FROM INFORMATION_SCHEMA.TP_THREAD_GROUP_STATS;

应用程序应该改用这个查询：

SELECT * FROM performance_schema.tp_thread_group_stats;

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

要了解INFORMATION_SCHEMA TP_THREAD_GROUP_STATS表中的列的描述，请参阅 Section 29.12.16.2, “tp_thread_group_stats 表”.性能模式tp_thread_group_stats表具有相同的列。

28.5.4 `INFORMATION_SCHEMA TP_THREAD_STATE` 表

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

注意

从 MySQL 8.0.14 开始，线程池 INFORMATION_SCHEMA 表也可以作为性能模式表使用。（参见第 29.12.16 节，“性能模式线程池表”。）INFORMATION_SCHEMA 表已被弃用；预计它们将在未来的 MySQL 版本中被移除。应用程序应该从旧表过渡到新表。例如，如果一个应用程序使用以下查询：

SELECT * FROM INFORMATION_SCHEMA.TP_THREAD_STATE;

应用程序应该使用以下查询：

SELECT * FROM performance_schema.tp_thread_state;

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

要了解 INFORMATION_SCHEMA TP_THREAD_STATE 表中的列的描述，请参阅第 29.12.16.3 节，“tp_thread_state 表”。性能模式 tp_thread_state 表具有相同的列。

28.6 INFORMATION_SCHEMA 连接控制表

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

28.6.1 INFORMATION_SCHEMA 连接控制表参考

28.6.2 INFORMATION_SCHEMA CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS 表

以下部分描述了与 CONNECTION_CONTROL 插件相关的 INFORMATION_SCHEMA 表。

28.6.1 INFORMATION_SCHEMA 连接控制表参考

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-connection-control-table-reference.html

以下表格总结了INFORMATION_SCHEMA连接控制表。更详细的信息，请参阅各个表的描述。

表 28.8 INFORMATION_SCHEMA 连接控制表

表名	描述
`CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS`	每个账户当前连续失败连接尝试的次数

28.6.2 INFORMATION_SCHEMA CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS 表

原文：dev.mysql.com/doc/refman/8.0/en/information-schema-connection-control-failed-login-attempts-table.html

该表提供有关每个帐户（用户/主机组合）的当前连续失败连接尝试次数的信息。

CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS具有以下列：

USERHOST

表示已经失败连接尝试的帐户的用户/主机组合，格式为'*user_name*'@'*host_name*'。
FAILED_ATTEMPTS

USERHOST值的当前连续失败连接尝试次数。这计算所有失败尝试，无论是否延迟。服务器为其响应添加延迟的尝试次数是FAILED_ATTEMPTS值与connection_control_failed_connections_threshold系统变量值之间的差异。

注：

必须激活CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS插件才能使用此表，并且必须激活CONNECTION_CONTROL插件，否则表内容始终为空。请参阅 Section 8.4.2, “The Connection-Control Plugins”。
该表仅包含对于已经有一个或多个连续失败连接尝试而没有随后成功尝试的帐户的行。当帐户成功连接时，其失败连接计数将重置为零，并且服务器将删除与该帐户对应的任何行。
在运行时为connection_control_failed_connections_threshold系统变量分配一个值会将所有累积的失败连接计数器重置为零，导致表变为空。

28.7 INFORMATION_SCHEMA MySQL Enterprise Firewall 表

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

28.7.1 INFORMATION_SCHEMA 防火墙表参考

28.7.2 INFORMATION_SCHEMA MYSQL_FIREWALL_USERS 表

28.7.3 INFORMATION_SCHEMA MYSQL_FIREWALL_WHITELIST 表

以下各节描述了与 MySQL Enterprise Firewall 相关的 INFORMATION_SCHEMA 表（参见第 8.4.7 节，“MySQL Enterprise Firewall”）。它们提供了对防火墙内存数据缓存的视图。只有在适当的防火墙插件启用时，这些表才可用。

28.7.1 INFORMATION_SCHEMA 防火墙表参考

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

以下表格总结了INFORMATION_SCHEMA防火墙表。更详细信息，请参阅各个表的描述。

表 28.9 INFORMATION_SCHEMA 防火墙表

表名	描述	已弃用
`MYSQL_FIREWALL_USERS`	账户配置文件的防火墙内存数据	8.0.26
`MYSQL_FIREWALL_WHITELIST`	账户配置文件的防火墙内存数据允许列表	8.0.26

28.7.2 INFORMATION_SCHEMA MYSQL_FIREWALL_USERS 表

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

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

MYSQL_FIREWALL_USERS 表包含以下列：

USERHOST

账户配置文件名称。每个账户名称的格式为 *user_name*@*host_name*。
MODE

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

截至 MySQL 8.0.26，此表已被弃用，并可能在未来的 MySQL 版本中移除。请参阅将账户配置文件迁移到组配置文件。

28.7.3 INFORMATION_SCHEMA MYSQL_FIREWALL_WHITELIST 表

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

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

MYSQL_FIREWALL_WHITELIST 表具有以下列：

USERHOST

帐户配置文件名称。每个帐户名称的格式为*user_name*@*host_name*。
RULE

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

截至 MySQL 8.0.26，此表已被弃用，并可能在将来的 MySQL 版本中删除。请参阅将帐户配置文件迁移到组配置文件。

28.8 `SHOW` 语句的扩展

原文：dev.mysql.com/doc/refman/8.0/en/extended-show.html

一些扩展到 SHOW 语句伴随着 INFORMATION_SCHEMA 的实现：

SHOW 可以用于获取关于 INFORMATION_SCHEMA 本身结构的信息。
几个 SHOW 语句接受一个提供更灵活性的 WHERE 子句，用于指定要显示哪些行。

INFORMATION_SCHEMA 是一个信息数据库，因此其名称包含在 SHOW DATABASES 的输出中。类似地，SHOW TABLES 可以与 INFORMATION_SCHEMA 一起使用以获取其表的列表：

mysql> SHOW TABLES FROM INFORMATION_SCHEMA;
+---------------------------------------+
| Tables_in_INFORMATION_SCHEMA          |
+---------------------------------------+
| CHARACTER_SETS                        |
| COLLATIONS                            |
| COLLATION_CHARACTER_SET_APPLICABILITY |
| COLUMNS                               |
| COLUMN_PRIVILEGES                     |
| ENGINES                               |
| EVENTS                                |
| FILES                                 |
| KEY_COLUMN_USAGE                      |
| PARTITIONS                            |
| PLUGINS                               |
| PROCESSLIST                           |
| REFERENTIAL_CONSTRAINTS               |
| ROUTINES                              |
| SCHEMATA                              |
| SCHEMA_PRIVILEGES                     |
| STATISTICS                            |
| TABLES                                |
| TABLE_CONSTRAINTS                     |
| TABLE_PRIVILEGES                      |
| TRIGGERS                              |
| USER_PRIVILEGES                       |
| VIEWS                                 |
+---------------------------------------+

SHOW COLUMNS 和 DESCRIBE 可以显示关于各个 INFORMATION_SCHEMA 表中列的信息。

SHOW 语句接受一个 LIKE 子句来限制显示的行，也允许使用 WHERE 子句来指定所选行必须满足的更一般条件：

SHOW CHARACTER SET
SHOW COLLATION
SHOW COLUMNS
SHOW DATABASES
SHOW FUNCTION STATUS
SHOW INDEX
SHOW OPEN TABLES
SHOW PROCEDURE STATUS
SHOW STATUS
SHOW TABLE STATUS
SHOW TABLES
SHOW TRIGGERS
SHOW VARIABLES

如果存在 WHERE 子句，则将其针对 SHOW 语句显示的列名进行评估。例如，SHOW CHARACTER SET 语句产生以下输出列：

mysql> SHOW CHARACTER SET;
+----------+-----------------------------+---------------------+--------+
| Charset  | Description                 | Default collation   | Maxlen |
+----------+-----------------------------+---------------------+--------+
| big5     | Big5 Traditional Chinese    | big5_chinese_ci     |      2 |
| dec8     | DEC West European           | dec8_swedish_ci     |      1 |
| cp850    | DOS West European           | cp850_general_ci    |      1 |
| hp8      | HP West European            | hp8_english_ci      |      1 |
| koi8r    | KOI8-R Relcom Russian       | koi8r_general_ci    |      1 |
| latin1   | cp1252 West European        | latin1_swedish_ci   |      1 |
| latin2   | ISO 8859-2 Central European | latin2_general_ci   |      1 |
...

要在 SHOW CHARACTER SET 中使用 WHERE 子句，您需要引用那些列名。例如，以下语句显示了默认排序包含字符串 'japanese' 的字符集的信息：

mysql> SHOW CHARACTER SET WHERE `Default collation` LIKE '%japanese%';
+---------+---------------------------+---------------------+--------+
| Charset | Description               | Default collation   | Maxlen |
+---------+---------------------------+---------------------+--------+
| ujis    | EUC-JP Japanese           | ujis_japanese_ci    |      3 |
| sjis    | Shift-JIS Japanese        | sjis_japanese_ci    |      2 |
| cp932   | SJIS for Windows Japanese | cp932_japanese_ci   |      2 |
| eucjpms | UJIS for Windows Japanese | eucjpms_japanese_ci |      3 |
+---------+---------------------------+---------------------+--------+

此语句显示了多字节字符集：

mysql> SHOW CHARACTER SET WHERE Maxlen > 1;
+---------+---------------------------------+---------------------+--------+
| Charset | Description                     | Default collation   | Maxlen |
+---------+---------------------------------+---------------------+--------+
| big5    | Big5 Traditional Chinese        | big5_chinese_ci     |      2 |
| cp932   | SJIS for Windows Japanese       | cp932_japanese_ci   |      2 |
| eucjpms | UJIS for Windows Japanese       | eucjpms_japanese_ci |      3 |
| euckr   | EUC-KR Korean                   | euckr_korean_ci     |      2 |
| gb18030 | China National Standard GB18030 | gb18030_chinese_ci  |      4 |
| gb2312  | GB2312 Simplified Chinese       | gb2312_chinese_ci   |      2 |
| gbk     | GBK Simplified Chinese          | gbk_chinese_ci      |      2 |
| sjis    | Shift-JIS Japanese              | sjis_japanese_ci    |      2 |
| ucs2    | UCS-2 Unicode                   | ucs2_general_ci     |      2 |
| ujis    | EUC-JP Japanese                 | ujis_japanese_ci    |      3 |
| utf16   | UTF-16 Unicode                  | utf16_general_ci    |      4 |
| utf16le | UTF-16LE Unicode                | utf16le_general_ci  |      4 |
| utf32   | UTF-32 Unicode                  | utf32_general_ci    |      4 |
| utf8mb3 | UTF-8 Unicode                   | utf8mb3_general_ci  |      3 |
| utf8mb4 | UTF-8 Unicode                   | utf8mb4_0900_ai_ci  |      4 |
+---------+---------------------------------+---------------------+--------+

第二十九章 MySQL 性能模式

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

29.1 Performance Schema 快速入门

29.2 Performance Schema 构建配置

29.3 Performance Schema 启动配置

29.4 Performance Schema 运行时配置

29.4.1 Performance Schema 事件定时

29.4.2 Performance Schema 事件过滤

29.4.3 事件预过滤

29.4.4 按仪器进行预过滤

29.4.5 按对象进行预过滤

29.4.6 按线程进行预过滤

29.4.7 按消费者进行预过滤

29.4.8 示例消费者配置

29.4.9 命名仪器或消费者以进行过滤操作

29.4.10 确定什么被仪器化

29.5 Performance Schema 查询

29.6 Performance Schema 仪器命名约定

29.7 Performance Schema 状态监控

29.8 Performance Schema 原子和分子事件

29.9 Performance Schema 当前和历史事件表

29.10 Performance Schema 语句摘要和抽样

29.11 Performance Schema 通用表特性

29.12 Performance Schema 表描述

29.12.1 Performance Schema 表参考

29.12.2 Performance Schema 设置表

29.12.3 Performance Schema 实例表

29.12.4 Performance Schema 等待事件表

29.12.5 Performance Schema 阶段事件表

29.12.6 Performance Schema 语句事件表

29.12.7 Performance Schema 事务表

29.12.8 Performance Schema 连接表

29.12.9 Performance Schema 连接属性表

29.12.10 Performance Schema User-Defined Variable Tables

29.12.11 Performance Schema Replication Tables

29.12.12 性能模式 NDB 集群表

29.12.13 Performance Schema Lock Tables

29.12.14 性能模式系统变量表

29.12.15 性能模式状态变量表

29.12.16 性能模式线程池表

29.12.17 性能模式防火墙表

29.12.18 Performance Schema Keyring Tables

29.12.19 性能模式克隆表

29.12.20 性能模式摘要表

29.12.21 Performance Schema Miscellaneous Tables

29.13 性能模式选项和变量参考

29.14 性能模式命令选项

29.15 性能模式系统变量

29.16 Performance Schema Status Variables

29.17 The Performance Schema Memory-Allocation Model

29.18 性能模式和插件

29.19 使用性能模式诊断问题

29.19.1 使用性能模式进行查询分析

29.19.2 获取父事件信息

29.20 性能模式的限制

MySQL 性能模式是用于监视 MySQL 服务器在低级别执行的功能。性能模式具有以下特点：

性能模式提供了一种在运行时检查服务器内部执行的方式。它是使用PERFORMANCE_SCHEMA存储引擎和performance_schema数据库实现的。性能模式主要关注性能数据。这与INFORMATION_SCHEMA不同，后者用于元数据的检查。
Performance Schema 监视服务器事件。一个“事件”是服务器执行需要时间的任何操作，并且已经被仪器化以便收集时间信息。一般来说，事件可以是函数调用，等待操作系统，SQL 语句执行的阶段（如解析或排序），或整个语句或一组语句。事件收集提供了关于同步调用（如互斥锁）、文件和表 I/O、表锁等服务器和几个存储引擎的信息。
Performance Schema 事件与写入服务器二进制日志的事件（描述数据修改）和事件调度程序事件（存储程序的一种类型）是不同的。
Performance Schema 事件特定于给定的 MySQL 服务器实例。Performance Schema 表被视为服务器本地的，对它们的更改不会被复制或写入二进制日志。
当前事件可用，以及事件历史和摘要。这使您能够确定仪器化活动被执行的次数以及所花费的时间。事件信息可用于显示特定线程的活动，或与特定对象（如互斥锁或文件）相关联的活动。
PERFORMANCE_SCHEMA存储引擎使用服务器源代码中的“仪器化点”收集事件数据。
收集的事件存储在performance_schema数据库的表中。这些表可以像其他表一样使用SELECT语句进行查询。
Performance Schema 配置可以通过通过 SQL 语句更新performance_schema数据库中的表来动态修改。配置更改会立即影响数据收集。
Performance Schema 中的表是使用内存而不使用持久性磁盘存储的表。内容在服务器启动时重新填充，并在服务器关闭时丢弃。
监控在 MySQL 支持的所有平台上都可用。

可能存在一些限制：计时器类型可能因平台而异。适用于存储引擎的仪器可能并非所有存储引擎都实现。每个第三方引擎的仪器化是引擎维护者的责任。另请参阅 Section 29.20, “Restrictions on Performance Schema”。
数据收集通过修改服务器源代码以添加仪器实现。与其他功能（如复制或事件调度程序）不同，Performance Schema 没有与之关联的单独线程。

Performance Schema 旨在在对服务器性能影响最小的情况下提供有关服务器执行的有用信息。实现遵循以下设计目标：

激活性能模式不会改变服务器行为。例如，它不会导致线程调度发生变化，也不会导致查询执行计划（如EXPLAIN所示）发生变化。
服务器监控持续进行，几乎没有额外开销。激活性能模式不会使服务器无法使用。
解析器保持不变。没有新的关键字或语句。
即使性能模式在内部失败，服务器代码的执行仍然正常进行。
当在事件收集初始阶段或稍后在事件检索期间执行处理时有选择时，优先考虑使收集更快。这是因为收集是持续进行的，而检索是按需进行的，甚至可能根本不会发生。
大多数性能模式表都有索引，这使得优化器可以访问除全表扫描之外的执行计划。有关更多信息，请参见第 10.2.4 节，“优化性能模式查询”。
添加新的仪表点很容易。
仪表化是有版本的。如果仪表化实现发生变化，先前仪表化的代码仍然可以正常工作。这有利于第三方插件的开发人员，因为不需要升级每个插件以与最新性能模式更改保持同步。

注意

MySQL sys模式是一组对象，提供方便访问性能模式收集的数据。sys模式默认安装。有关使用说明，请参见第三十章，“MySQL sys 模式”。

29.1 性能模式快速入门

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

本节简要介绍了性能模式，并提供了示例以展示如何使用它。有关更多示例，请参见第 29.19 节“使用性能模式诊断问题”。

性能模式默认启用。要显式启用或禁用它，请使用将服务器启动时performance_schema变量设置为适当值。例如，在服务器的my.cnf文件中使用以下行：

[mysqld]
performance_schema=ON

当服务器启动时，它会查看performance_schema并尝试初始化性能模式。要验证初始化是否成功，请使用以下语句：

mysql> SHOW VARIABLES LIKE 'performance_schema';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| performance_schema | ON    |
+--------------------+-------+

ON的值表示性能模式成功初始化并准备就绪。OFF的值表示发生了一些错误。请检查服务器错误日志以获取有关出现问题的信息。

性能模式被实现为一个存储引擎，因此您可以在信息模式ENGINES表或SHOW ENGINES语句的输出中看到它：

mysql> SELECT * FROM INFORMATION_SCHEMA.ENGINES
       WHERE ENGINE='PERFORMANCE_SCHEMA'\G
*************************** 1\. row ***************************
      ENGINE: PERFORMANCE_SCHEMA
     SUPPORT: YES
     COMMENT: Performance Schema
TRANSACTIONS: NO
          XA: NO
  SAVEPOINTS: NO 
mysql> SHOW ENGINES\G
...
      Engine: PERFORMANCE_SCHEMA
     Support: YES
     Comment: Performance Schema
Transactions: NO
          XA: NO
  Savepoints: NO
...

PERFORMANCE_SCHEMA存储引擎在performance_schema数据库中操作表。您可以将performance_schema设置为默认数据库，这样对其表的引用就不需要用数据库名称限定：

mysql> USE performance_schema;

性能模式表存储在performance_schema数据库中。关于该数据库及其表结构的信息可以像获取其他数据库信息一样，通过从INFORMATION_SCHEMA数据库中选择或使用SHOW语句。例如，使用以下语句之一查看存在哪些性能模式表：

mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
       WHERE TABLE_SCHEMA = 'performance_schema';
+------------------------------------------------------+
| TABLE_NAME                                           |
+------------------------------------------------------+
| accounts                                             |
| cond_instances                                       |
...
| events_stages_current                                |
| events_stages_history                                |
| events_stages_history_long                           |
| events_stages_summary_by_account_by_event_name       |
| events_stages_summary_by_host_by_event_name          |
| events_stages_summary_by_thread_by_event_name        |
| events_stages_summary_by_user_by_event_name          |
| events_stages_summary_global_by_event_name           |
| events_statements_current                            |
| events_statements_history                            |
| events_statements_history_long                       |
...
| file_instances                                       |
| file_summary_by_event_name                           |
| file_summary_by_instance                             |
| host_cache                                           |
| hosts                                                |
| memory_summary_by_account_by_event_name              |
| memory_summary_by_host_by_event_name                 |
| memory_summary_by_thread_by_event_name               |
| memory_summary_by_user_by_event_name                 |
| memory_summary_global_by_event_name                  |
| metadata_locks                                       |
| mutex_instances                                      |
| objects_summary_global_by_type                       |
| performance_timers                                   |
| replication_connection_configuration                 |
| replication_connection_status                        |
| replication_applier_configuration                    |
| replication_applier_status                           |
| replication_applier_status_by_coordinator            |
| replication_applier_status_by_worker                 |
| rwlock_instances                                     |
| session_account_connect_attrs                        |
| session_connect_attrs                                |
| setup_actors                                         |
| setup_consumers                                      |
| setup_instruments                                    |
| setup_objects                                        |
| socket_instances                                     |
| socket_summary_by_event_name                         |
| socket_summary_by_instance                           |
| table_handles                                        |
| table_io_waits_summary_by_index_usage                |
| table_io_waits_summary_by_table                      |
| table_lock_waits_summary_by_table                    |
| threads                                              |
| users                                                |
+------------------------------------------------------+

mysql> SHOW TABLES FROM performance_schema;
+------------------------------------------------------+
| Tables_in_performance_schema                         |
+------------------------------------------------------+
| accounts                                             |
| cond_instances                                       |
| events_stages_current                                |
| events_stages_history                                |
| events_stages_history_long                           |
...

随着额外的仪器化实施的进行，性能模式表的数量会随时间增加。

performance_schema数据库的名称是小写的，其中的表名也是小写的。查询应该使用小写指定名称。

要查看单个表的结构，请使用SHOW CREATE TABLE：

mysql> SHOW CREATE TABLE performance_schema.setup_consumers\G
*************************** 1\. row ***************************
       Table: setup_consumers
Create Table: CREATE TABLE `setup_consumers` (
  `NAME` varchar(64) NOT NULL,
  `ENABLED` enum('YES','NO') NOT NULL,
  PRIMARY KEY (`NAME`)
) ENGINE=PERFORMANCE_SCHEMA DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

表结构也可以通过选择诸如INFORMATION_SCHEMA.COLUMNS之类的表或使用诸如SHOW COLUMNS之类的语句来获取。

performance_schema数据库中的表可以根据其信息类型进行分组：当前事件、事件历史和摘要、对象实例以及设置（配置）信息。以下示例说明了这些表的一些用途。有关每个组中表的详细信息，请参阅第 29.12 节“性能模式表描述”。

最初，并非所有仪器和消费者都被启用，因此性能模式不会收集所有事件。要打开所有这些并启用事件计时，执行两个语句（行数可能因 MySQL 版本而异）：

mysql> UPDATE performance_schema.setup_instruments
       SET ENABLED = 'YES', TIMED = 'YES';
Query OK, 560 rows affected (0.04 sec)
mysql> UPDATE performance_schema.setup_consumers
       SET ENABLED = 'YES';
Query OK, 10 rows affected (0.00 sec)

要查看服务器当前正在执行的操作，请查看events_waits_current表。它包含每个线程的一行，显示每个线程的最近监视事件：

mysql> SELECT *
       FROM performance_schema.events_waits_current\G
*************************** 1\. row ***************************
            THREAD_ID: 0
             EVENT_ID: 5523
         END_EVENT_ID: 5523
           EVENT_NAME: wait/synch/mutex/mysys/THR_LOCK::mutex
               SOURCE: thr_lock.c:525
          TIMER_START: 201660494489586
            TIMER_END: 201660494576112
           TIMER_WAIT: 86526
                SPINS: NULL
        OBJECT_SCHEMA: NULL
          OBJECT_NAME: NULL
           INDEX_NAME: NULL
          OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 142270668
     NESTING_EVENT_ID: NULL
   NESTING_EVENT_TYPE: NULL
            OPERATION: lock
      NUMBER_OF_BYTES: NULL
                FLAGS: 0
...

此事件表示线程 0 正在等待 86,526 皮秒来获取THR_LOCK::mutex上的锁，这是mysys子系统中的一个互斥体。前几列提供以下信息：

ID 列指示事件来自哪个线程以及事件编号。
EVENT_NAME指示被检测的内容，SOURCE指示包含被检测代码的源文件。
计时器列显示事件开始和结束的时间以及持续时间。如果事件仍在进行中，则TIMER_END和TIMER_WAIT值为NULL。计时器值是近似值，以皮秒表示。有关计时器和事件时间收集的信息，请参阅第 29.4.1 节“性能模式事件计时”。

历史表包含与当前事件表相同类型的行，但具有更多行，并显示服务器“最近”而不是“当前”正在执行的操作。events_waits_history和events_waits_history_long表分别包含每个线程的最近 10 个事件和最近 10,000 个事件。例如，要查看线程 13 生成的最近事件的信息，请执行以下操作：

mysql> SELECT EVENT_ID, EVENT_NAME, TIMER_WAIT
       FROM performance_schema.events_waits_history
       WHERE THREAD_ID = 13
       ORDER BY EVENT_ID;
+----------+-----------------------------------------+------------+
| EVENT_ID | EVENT_NAME                              | TIMER_WAIT |
+----------+-----------------------------------------+------------+
|       86 | wait/synch/mutex/mysys/THR_LOCK::mutex  |     686322 |
|       87 | wait/synch/mutex/mysys/THR_LOCK_malloc  |     320535 |
|       88 | wait/synch/mutex/mysys/THR_LOCK_malloc  |     339390 |
|       89 | wait/synch/mutex/mysys/THR_LOCK_malloc  |     377100 |
|       90 | wait/synch/mutex/sql/LOCK_plugin        |     614673 |
|       91 | wait/synch/mutex/sql/LOCK_open          |     659925 |
|       92 | wait/synch/mutex/sql/THD::LOCK_thd_data |     494001 |
|       93 | wait/synch/mutex/mysys/THR_LOCK_malloc  |     222489 |
|       94 | wait/synch/mutex/mysys/THR_LOCK_malloc  |     214947 |
|       95 | wait/synch/mutex/mysys/LOCK_alarm       |     312993 |
+----------+-----------------------------------------+------------+

当向历史表添加新事件时，如果表已满，则会丢弃旧事件。

摘要表提供了随时间汇总所有事件的信息。此组中的表以不同方式汇总事件数据。要查看哪些仪器执行次数最多或等待时间最长，请根据COUNT_STAR或SUM_TIMER_WAIT列对events_waits_summary_global_by_event_name表进行排序，这两列分别对应于所有事件计算的COUNT(*)或SUM(TIMER_WAIT)值：

mysql> SELECT EVENT_NAME, COUNT_STAR
       FROM performance_schema.events_waits_summary_global_by_event_name
       ORDER BY COUNT_STAR DESC LIMIT 10;
+---------------------------------------------------+------------+
| EVENT_NAME                                        | COUNT_STAR |
+---------------------------------------------------+------------+
| wait/synch/mutex/mysys/THR_LOCK_malloc            |       6419 |
| wait/io/file/sql/FRM                              |        452 |
| wait/synch/mutex/sql/LOCK_plugin                  |        337 |
| wait/synch/mutex/mysys/THR_LOCK_open              |        187 |
| wait/synch/mutex/mysys/LOCK_alarm                 |        147 |
| wait/synch/mutex/sql/THD::LOCK_thd_data           |        115 |
| wait/io/file/myisam/kfile                         |        102 |
| wait/synch/mutex/sql/LOCK_global_system_variables |         89 |
| wait/synch/mutex/mysys/THR_LOCK::mutex            |         89 |
| wait/synch/mutex/sql/LOCK_open                    |         88 |
+---------------------------------------------------+------------+

mysql> SELECT EVENT_NAME, SUM_TIMER_WAIT
       FROM performance_schema.events_waits_summary_global_by_event_name
       ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;
+----------------------------------------+----------------+
| EVENT_NAME                             | SUM_TIMER_WAIT |
+----------------------------------------+----------------+
| wait/io/file/sql/MYSQL_LOG             |     1599816582 |
| wait/synch/mutex/mysys/THR_LOCK_malloc |     1530083250 |
| wait/io/file/sql/binlog_index          |     1385291934 |
| wait/io/file/sql/FRM                   |     1292823243 |
| wait/io/file/myisam/kfile              |      411193611 |
| wait/io/file/myisam/dfile              |      322401645 |
| wait/synch/mutex/mysys/LOCK_alarm      |      145126935 |
| wait/io/file/sql/casetest              |      104324715 |
| wait/synch/mutex/sql/LOCK_plugin       |       86027823 |
| wait/io/file/sql/pid                   |       72591750 |
+----------------------------------------+----------------+

这些结果显示THR_LOCK_malloc互斥锁“热门”，无论是使用频率还是线程等待尝试获取它的时间量。

注意

THR_LOCK_malloc互斥锁仅在调试构建中使用。在生产构建中，它不是热门，因为它不存在。

实例表记录了被仪器化的对象类型。当服务器使用被仪器化的对象时，会产生一个事件。这些表提供事件名称和解释说明或状态信息。例如，file_instances表列出了文件 I/O 操作的仪器实例及其关联文件：

mysql> SELECT *
       FROM performance_schema.file_instances\G
*************************** 1\. row ***************************
 FILE_NAME: /opt/mysql-log/60500/binlog.000007
EVENT_NAME: wait/io/file/sql/binlog
OPEN_COUNT: 0
*************************** 2\. row ***************************
 FILE_NAME: /opt/mysql/60500/data/mysql/tables_priv.MYI
EVENT_NAME: wait/io/file/myisam/kfile
OPEN_COUNT: 1
*************************** 3\. row ***************************
 FILE_NAME: /opt/mysql/60500/data/mysql/columns_priv.MYI
EVENT_NAME: wait/io/file/myisam/kfile
OPEN_COUNT: 1
...

设置表用于配置和显示监控特性。例如，setup_instruments列出了可以收集事件的一组仪器，并显示哪些已启用：

mysql> SELECT NAME, ENABLED, TIMED
       FROM performance_schema.setup_instruments;
+---------------------------------------------------+---------+-------+
| NAME                                              | ENABLED | TIMED |
+---------------------------------------------------+---------+-------+
...
| stage/sql/end                                     | NO      | NO    |
| stage/sql/executing                               | NO      | NO    |
| stage/sql/init                                    | NO      | NO    |
| stage/sql/insert                                  | NO      | NO    |
...
| statement/sql/load                                | YES     | YES   |
| statement/sql/grant                               | YES     | YES   |
| statement/sql/check                               | YES     | YES   |
| statement/sql/flush                               | YES     | YES   |
...
| wait/synch/mutex/sql/LOCK_global_read_lock        | YES     | YES   |
| wait/synch/mutex/sql/LOCK_global_system_variables | YES     | YES   |
| wait/synch/mutex/sql/LOCK_lock_db                 | YES     | YES   |
| wait/synch/mutex/sql/LOCK_manager                 | YES     | YES   |
...
| wait/synch/rwlock/sql/LOCK_grant                  | YES     | YES   |
| wait/synch/rwlock/sql/LOGGER::LOCK_logger         | YES     | YES   |
| wait/synch/rwlock/sql/LOCK_sys_init_connect       | YES     | YES   |
| wait/synch/rwlock/sql/LOCK_sys_init_slave         | YES     | YES   |
...
| wait/io/file/sql/binlog                           | YES     | YES   |
| wait/io/file/sql/binlog_index                     | YES     | YES   |
| wait/io/file/sql/casetest                         | YES     | YES   |
| wait/io/file/sql/dbopt                            | YES     | YES   |
...

要了解如何解释仪器名称，请参见第 29.6 节，“性能模式仪器命名约定”。

要控制是否为仪器收集事件，请将其ENABLED值设置为YES或NO。例如：

mysql> UPDATE performance_schema.setup_instruments
       SET ENABLED = 'NO'
       WHERE NAME = 'wait/synch/mutex/sql/LOCK_mysql_create_db';

性能模式使用收集的事件来更新performance_schema数据库中的表，这些表充当事件信息的“消费者”。setup_consumers表列出了可用的消费者以及哪些已启用：

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

要控制性能模式是否将消费者作为事件信息的目的地，请设置其ENABLED值。

要了解有关设置表及如何使用它们来控制事件收集的更多信息，请参见第 29.4.2 节，“性能模式事件过滤”。

有一些杂项表不属于前述任何组。例如，performance_timers列出了可用的事件计时器及其特性。有关计时器的信息，请参见第 29.4.1 节，“性能模式事件计时”。

29.2 性能模式构建配置

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

性能模式是强制性的，并且始终在编译中。可以排除性能模式仪表的某些部分。例如，要排除阶段和语句仪表，可以执行以下操作：

$> cmake . \
        -DDISABLE_PSI_STAGE=1 \
        -DDISABLE_PSI_STATEMENT=1

更多信息，请参阅第 2.8.7 节，“MySQL 源配置选项”中DISABLE_PSI_*XXX* CMake 选项的描述。

如果您在之前没有配置性能模式（或者使用缺失或过时表的旧版本性能模式）的情况下安装 MySQL，那么在安装 MySQL 时可能会出现以下错误日志中的消息：

[ERROR] Native table 'performance_schema'.'events_waits_history'
has the wrong structure
[ERROR] Native table 'performance_schema'.'events_waits_history_long'
has the wrong structure
...

要解决这个问题，请执行 MySQL 升级过程。参见第三章，升级 MySQL。

因为性能模式在构建时配置到服务器中，所以在SHOW ENGINES的输出中会出现PERFORMANCE_SCHEMA的行。这意味着性能模式是可用的，而不是已启用。要启用它，必须在服务器启动时执行，如下一节所述。

29.3 性能模式启动配置

dev.mysql.com/doc/refman/8.0/en/performance-schema-startup-configuration.html

要使用 MySQL 性能模式，必须在服务器启动时启用，以便进行事件收集。

性能模式默认启用。要显式启用或禁用它，请使用将服务器启动时performance_schema变量设置为适当值。例如，在服务器my.cnf文件中使用以下行：

[mysqld]
performance_schema=ON

如果服务器在性能模式初始化期间无法分配任何内部缓冲区，则性能模式会禁用自身，并将performance_schema设置为OFF，服务器将在没有仪器的情况下运行。

性能模式还允许在服务器启动时配置仪器和消费者。

要在服务器启动时控制仪器，请使用以下形式的选项：

--performance-schema-instrument='*instrument_name*=*value*'

这里，instrument_name是一个仪器名称，例如wait/synch/mutex/sql/LOCK_open，value是以下值之一：

OFF、FALSE或0：禁用仪器
ON、TRUE或1：启用并计时仪器
COUNTED：启用并计数（而不是计时）仪器

每个--performance-schema-instrument选项只能指定一个仪器名称，但可以给出多个选项的实例以配置多个仪器。此外，仪器名称中允许使用模式以配置与模式匹配的仪器。要将所有条件同步仪器配置为启用和计数，请使用此选项：

--performance-schema-instrument='wait/synch/cond/%=COUNTED'

要禁用所有仪器，请使用此选项：

--performance-schema-instrument='%=OFF'

例外：memory/performance_schema/%仪器是内置的，无法在启动时禁用。

较长的仪器名称字符串优先于较短的模式名称，无论顺序如何。有关指定模式以选择仪器的信息，请参阅第 29.4.9 节，“用于过滤操作的命名仪器或消费者”。

未识别的仪器名称将被忽略。后来安装的插件可能会创建该仪器，届时名称将被识别并配置。

要在服务器启动时控制消费者，请使用以下形式的选项：

--performance-schema-consumer-*consumer_name*=*value*

这里，consumer_name是一个消费者名称，例如events_waits_history，value是以下值之一：

OFF、FALSE或0：不为消费者收集事件
ON、TRUE或1：为消费者收集事件

例如，要启用events_waits_history消费者，请使用此选项：

--performance-schema-consumer-events-waits-history=ON

可以通过检查 setup_consumers 表找到允许的消费者名称。不允许使用模式。setup_consumers 表中的消费者名称使用下划线，但对于在启动时设置的消费者，名称中的破折号和下划线是等效的。

Performance Schema 包括几个提供配置信息的系统变量：

mysql> SHOW VARIABLES LIKE 'perf%';
+--------------------------------------------------------+---------+
| Variable_name                                          | Value   |
+--------------------------------------------------------+---------+
| performance_schema                                     | ON      |
| performance_schema_accounts_size                       | 100     |
| performance_schema_digests_size                        | 200     |
| performance_schema_events_stages_history_long_size     | 10000   |
| performance_schema_events_stages_history_size          | 10      |
| performance_schema_events_statements_history_long_size | 10000   |
| performance_schema_events_statements_history_size      | 10      |
| performance_schema_events_waits_history_long_size      | 10000   |
| performance_schema_events_waits_history_size           | 10      |
| performance_schema_hosts_size                          | 100     |
| performance_schema_max_cond_classes                    | 80      |
| performance_schema_max_cond_instances                  | 1000    |
...

performance_schema 变量为 ON 或 OFF，表示 Performance Schema 是否已启用或已禁用。其他变量表示表大小（行数）或内存分配值。

注意

启用 Performance Schema 后，Performance Schema 实例的数量会影响服务器的内存占用，可能在很大程度上。Performance Schema 会自动调整许多参数，仅在需要时使用内存；请参见 Section 29.17, “The Performance Schema Memory-Allocation Model”。

要更改 Performance Schema 系统变量的值，请在服务器启动时设置它们。例如，将以下行放入 my.cnf 文件中以更改等待事件的历史表大小：

[mysqld]
performance_schema
performance_schema_events_waits_history_size=20
performance_schema_events_waits_history_long_size=15000

Performance Schema 在服务器启动时会自动调整一些参数的值，如果它们没有被显式设置。例如，它会以这种方式调整控制事件等待表大小的参数。Performance Schema 会逐步分配内存，根据实际服务器负载来调整内存使用量，而不是在服务器启动时分配所有需要的内存。因此，许多调整参数根本不需要设置。要查看哪些参数是自动调整或自动缩放的，请使用 mysqld --verbose --help 并查看选项描述，或参见 Section 29.15, “Performance Schema System Variables”。

对于每个未在服务器启动时设置的自动调整参数，Performance Schema 根据以下系统值的值确定如何设置其值，这些值被视为关于如何配置 MySQL 服务器的“提示”：

max_connections
open_files_limit
table_definition_cache
table_open_cache

要覆盖给定参数的自动调整或自动缩放，请在启动时将其设置为非 -1 的值。在这种情况下，Performance Schema 将其分配为指定的值。

在运行时，SHOW VARIABLES 显示自动调整参数设置的实际值。自动缩放参数显示为 -1。

如果性能模式被禁用，其自动调整大小和自动缩放参数仍设置为−1，SHOW VARIABLES显示−1。

29.4 性能模式运行时配置

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

29.4.1 性能模式事件定时

29.4.2 性能模式事件过滤

29.4.3 事件预过滤

29.4.4 按仪器预过滤

29.4.5 按对象预过滤

29.4.6 按线程预过滤

29.4.7 按消费者预过滤

29.4.8 示例消费者配置

29.4.9 为过滤操作命名仪器或消费者

29.4.10 确定什么被仪器化

特定的性能模式功能可以在运行时启用，以控制发生哪些类型的事件收集。

性能模式设置表包含有关监控配置的信息：

mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
       WHERE TABLE_SCHEMA = 'performance_schema'
       AND TABLE_NAME LIKE 'setup%';
+-------------------+
| TABLE_NAME        |
+-------------------+
| setup_actors      |
| setup_consumers   |
| setup_instruments |
| setup_objects     |
| setup_threads     |
+-------------------+

您可以检查这些表的内容，以获取有关性能模式监控特性的信息。如果您拥有UPDATE权限，可以通过修改设置表来改变性能模式的操作，从而影响监控的方式。有关这些表的更多详细信息，请参阅第 29.12.2 节，“性能模式设置表”。

setup_instruments和setup_consumers表列出了可以收集事件的仪器和实际收集事件信息的消费者类型。其他设置表可以进一步修改监控配置。第 29.4.2 节，“性能模式事件过滤”讨论了如何修改这些表以影响事件收集。

如果有必须在运行时使用 SQL 语句进行性能模式配置更改，并且希望这些更改在每次服务器启动时生效，请将这些语句放入一个文件中，并使用init_file系统变量设置文件名来启动服务器。如果您有多个监控配置，每个配置都针对不同类型的监控，比如常规服务器健康监控、事件调查、应用行为故障排除等，这种策略也很有用。将每个监控配置的语句放入各自的文件中，并在启动服务器时将适当的文件指定为init_file的值。

29.4.1 性能模式事件计时

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

事件是通过添加到服务器源代码的仪器来收集的。仪器计时事件，这就是性能模式提供事件持续时间的方式。还可以配置仪器不收集计时信息。本节讨论可用计时器及其特性，以及事件中计时值的表示方式。

性能模式计时器

性能模式计时器在精度和开销量上有所不同。要查看可用的计时器及其特性，请查看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，则该计时器在您的平台上不受支持。

列的含义如下：

TIMER_NAME列显示可用计时器的名称。CYCLE指的是基于 CPU（处理器）周期计数器的计时器。
TIMER_FREQUENCY表示每秒的计时器单位数。对于循环计时器，频率通常与 CPU 速度有关。显示的值是在一个 2.4GHz 处理器系统上获得的。其他计时器基于固定的秒分数。
TIMER_RESOLUTION表示计时器值每次增加的计时器单位数。如果计时器的分辨率为 10，那么每次增加 10。
TIMER_OVERHEAD是获取给定计时器的一个计时所需的最小周期数。每个事件的开销是显示值的两倍，因为计时器在事件开始和结束时被调用。

性能模式将计时器分配如下：

等待计时器使用CYCLE。
空闲、阶段、语句和事务计时器在支持NANOSECOND计时器的平台上使用NANOSECOND，否则使用MICROSECOND。

在服务器启动时，性能模式会验证构建时关于计时器分配的假设是否正确，并在计时器不可用时显示警告。

对于计时等待事件，最重要的标准是减少开销，可能会牺牲计时器的准确性，因此使用CYCLE计时器是最好的选择。

语句（或阶段）执行所需的时间通常比执行单个等待所需的时间大几个数量级。为了计时语句，最重要的标准是要有一个准确的测量，不受处理器频率变化的影响，因此使用不基于循环的计时器是最好的。语句的默认计时器是NANOSECOND。与CYCLE计时器相比的额外“开销”并不显著，因为由于调用计时器两次（一次在语句开始时，一次在语句结束时）引起的开销与执行语句本身所用的 CPU 时间相比，数量级要小得多。在这里使用CYCLE计时器没有好处，只有缺点。

循环计数器提供的精度取决于处理器速度。如果处理器运行速度为 1 GHz（十亿个周期/秒）或更高，则循环计数器提供亚纳秒级精度。使用循环计数器比获取实际的当天时间要便宜得多。例如，标准的gettimeofday()函数可能需要数百个周期，这对于可能每秒发生数千次或数百万次的数据收集来说是不可接受的开销。

循环计数器也有缺点：

最终用户希望看到墙钟单位的时间，例如秒的分数。从循环到秒的转换可能很昂贵。因此，转换是一个快速且相当粗糙的乘法运算。
处理器的循环速率可能会发生变化，例如当笔记本电脑进入节能模式或当 CPU 减速以减少热量产生时。如果处理器的循环速率波动，从循环到实时单位的转换可能会出现错误。
根据处理器或操作系统的不同，循环计数器可能不可靠或不可用。例如，在奔腾处理器上，指令是RDTSC（汇编语言而不是 C 指令），理论上操作系统可以阻止用户模式程序使用它。
与乱序执行或多处理器同步相关的一些处理器细节可能导致计数器看起来快或慢多达 1000 个周期。

MySQL 在 x386（Windows，macOS，Linux，Solaris 和其他 Unix 变种），PowerPC 和 IA-64 上使用循环计数器。

Performance Schema 事件中的计时器表示

Performance Schema 表中存储当前事件和历史事件的行有三列用于表示时间信息：TIMER_START和TIMER_END表示事件开始和结束的时间，TIMER_WAIT表示事件持续时间。

setup_instruments 表具有一个 ENABLED 列，用于指示要收集事件的仪器。该表还有一个 TIMED 列，用于指示哪些仪器是定时的。如果一个仪器未启用，则不会产生事件。如果启用的仪器未定时，则由仪器产生的事件的 TIMER_START、TIMER_END 和 TIMER_WAIT 计时器值为 NULL。这反过来导致在汇总表（总和、最小值、最大值和平均值）中计算聚合时间值时忽略这些值。

在事件内部，事件中的时间以事件定时开始时的计时器给定的单位存储。当从性能模式表中检索事件时，时间以皮秒（万亿分之一秒）显示，以将它们归一化为标准单位，而不管选择了哪个计时器。

计时器基线（“零时间点”）发生在服务器启动期间的性能模式初始化。事件中的 TIMER_START 和 TIMER_END 值表示自基线以来的皮秒数。TIMER_WAIT 值是以皮秒为单位的持续时间。

事件中的皮秒值是近似值。它们的准确性受到与从一个单位转换到另一个单位相关的常见误差形式的影响。如果使用 CYCLE 计时器并且处理器速率变化，可能会出现漂移。因此，查看事件的 TIMER_START 值作为自服务器启动以来经过的时间的准确度测量是不合理的。另一方面，使用 TIMER_START 或 TIMER_WAIT 值在 ORDER BY 子句中对事件按开始时间或持续时间排序是合理的。

事件中选择皮秒而不是微秒等值具有性能基础。一个实现目标是以统一的时间单位显示结果，而不管计时器是什么。在理想世界中，这个时间单位看起来像一个挂钟单位，并且相当精确；换句话说，微秒。但是要将周期或纳秒转换为微秒，就需要对每个仪器执行除法。在许多平台上，除法是昂贵的。乘法不昂贵，所以这就是所使用的。因此，时间单位是最高可能的 TIMER_FREQUENCY 值的整数倍，使用足够大的乘数来确保没有主要的精度损失。结果是时间单位是“皮秒”。这种精度是虚假的，但这个决定使得开销最小化。

当等待、阶段、语句或事务事件正在执行时，相应的当前事件表显示当前事件的定时信息：

events_waits_current
events_stages_current
events_statements_current
events_transactions_current

为了能够确定尚未完成的事件运行了多长时间，计时器列设置如下：

TIMER_START 已填充。
TIMER_END 已填充，显示当前计时器值。
TIMER_WAIT 已填充，显示到目前为止经过的时间（TIMER_END − TIMER_START）。

尚未完成的事件具有END_EVENT_ID值为NULL。要评估到目前为止事件经过的时间，使用TIMER_WAIT列。因此，要识别尚未完成且到目前为止已经花费超过N皮秒的事件，监控应用程序可以在查询中使用这个表达式：

WHERE END_EVENT_ID IS NULL AND TIMER_WAIT > *N*

事件识别如上所述，假设相应的仪器ENABLED和TIMED设置为YES，并且相关的消费者已启用。

29.4.2 性能模式事件过滤

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

事件以生产者/消费者方式进行处理：

仪器化代码是事件的来源并产生要收集的事件。setup_instruments表列出了可以收集事件的仪器，它们是否已启用以及（对于已启用的仪器）是否收集计时信息：

mysql> SELECT NAME, ENABLED, TIMED
       FROM performance_schema.setup_instruments;
+---------------------------------------------------+---------+-------+
| NAME                                              | ENABLED | TIMED |
+---------------------------------------------------+---------+-------+
...
| wait/synch/mutex/sql/LOCK_global_read_lock        | YES     | YES   |
| wait/synch/mutex/sql/LOCK_global_system_variables | YES     | YES   |
| wait/synch/mutex/sql/LOCK_lock_db                 | YES     | YES   |
| wait/synch/mutex/sql/LOCK_manager                 | YES     | YES   |
...

setup_instruments表提供了对事件生成最基本的控制形式。为了根据被监视的对象或线程类型进一步细化事件生成，可以使用其他表，如第 29.4.3 节“事件预过滤”中所述。

性能模式表是事件的目的地并消耗事件。setup_consumers表列出了可以发送事件信息的消费者类型以及它们是否已启用：

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

过滤可以在性能监控的不同阶段进行：

预过滤。 这是通过修改性能模式配置，以便只从生产者收集某些类型的事件，并且收集的事件仅更新某些消费者。为此，启用或禁用仪器或消费者。预过滤由性能模式执行，并具有适用于所有用户的全局效果。

使用预过滤的原因：
- 减少开销。即使启用了所有仪器，性能模式的开销也应该很小，但也许你想进一步减少它。或者你不关心计时事件，想要禁用计时代码以消除计时开销。
- 为了避免将你不感兴趣的事件填充到当前事件或历史表中。预过滤为启用的仪器类型的行实例留下更多“空间”在这些表中。如果只启用了文件仪器并进行了预过滤，那么不会为非文件仪器收集行。通过后过滤，会收集非文件事件，为文件事件留下较少的行。
- 避免维护某些类型的事件表。如果禁用了一个消费者，服务器就不会花时间维护该消费者的目的地。例如，如果你不关心事件历史，可以禁用历史表消费者以提高性能。
后过滤。 这涉及在从性能模式表中选择信息的查询中使用WHERE子句，以指定您想要查看哪些可用事件。后过滤是基于每个用户进行的，因为个别用户选择感兴趣的可用事件。

使用后过滤的原因：
- 避免为个别用户做出关于哪些事件信息感兴趣的决定。
- 当事先不知道要施加的预过滤限制时，可以使用性能模式来调查性能问题。

以下各节提供有关预过滤的更多详细信息，并提供有关在过滤操作中命名仪器或消费者的指南。有关编写查询以检索信息（后过滤）的信息，请参见第 29.5 节，“性能模式查询”。

29.4.3 事件预过滤

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

预过滤由性能模式执行，并具有适用于所有用户的全局效果。预过滤可以应用于事件处理的生产者或消费者阶段：

要在生产者阶段配置预过滤，可以使用多个表：
- setup_instruments 指示可用的仪器。在此表中禁用的仪器不会产生任何事件，而不管其他与生产相关的设置表的内容如何。在此表中启用的仪器被允许产生事件，取决于其他表的内容。
- setup_objects 控制性能模式是否监视特定表和存储程序对象。
- threads 指示每个服务器线程是否启用监视。
- setup_actors 确定新前台线程的初始监视状态。
要在消费者阶段配置预过滤，请修改setup_consumers表。这确定事件发送到的目的地。setup_consumers还隐含影响事件产生。如果某个事件未发送到任何目的地（即，从未被消费），性能模式不会产生它。

对任何这些表的修改立即影响监视，但有一个例外，即对setup_actors表的修改仅影响创建修改后的前台线程，而不影响现有线程。

当您更改监视配置时，性能模式不会刷新历史表。已经收集的事件会保留在当前事件和历史表中，直到被新事件替换。如果禁用仪器，您可能需要等待一段时间，直到它们的事件被新的感兴趣的事件替换。或者，使用TRUNCATE TABLE清空历史表。

在进行仪表化更改后，您可能希望截断摘要表。通常，效果是将摘要列重置为 0 或NULL，而不是删除行。这使您能够清除收集的值并重新开始聚合。例如，在您进行运行时配置更改后，这可能很有用。个别摘要表部分中会注意到此截断行为的异常情况。

以下部分描述如何使用特定表格来控制性能模式的预过滤。

29.4.4 按工具进行预过滤

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

setup_instruments 表列出了可用的工具：

mysql> SELECT NAME, ENABLED, TIMED
       FROM performance_schema.setup_instruments;
+---------------------------------------------------+---------+-------+
| NAME                                              | ENABLED | TIMED |
+---------------------------------------------------+---------+-------+
...
| stage/sql/end                                     | NO      | NO    |
| stage/sql/executing                               | NO      | NO    |
| stage/sql/init                                    | NO      | NO    |
| stage/sql/insert                                  | NO      | NO    |
...
| statement/sql/load                                | YES     | YES   |
| statement/sql/grant                               | YES     | YES   |
| statement/sql/check                               | YES     | YES   |
| statement/sql/flush                               | YES     | YES   |
...
| wait/synch/mutex/sql/LOCK_global_read_lock        | YES     | YES   |
| wait/synch/mutex/sql/LOCK_global_system_variables | YES     | YES   |
| wait/synch/mutex/sql/LOCK_lock_db                 | YES     | YES   |
| wait/synch/mutex/sql/LOCK_manager                 | YES     | YES   |
...
| wait/synch/rwlock/sql/LOCK_grant                  | YES     | YES   |
| wait/synch/rwlock/sql/LOGGER::LOCK_logger         | YES     | YES   |
| wait/synch/rwlock/sql/LOCK_sys_init_connect       | YES     | YES   |
| wait/synch/rwlock/sql/LOCK_sys_init_slave         | YES     | YES   |
...
| wait/io/file/sql/binlog                           | YES     | YES   |
| wait/io/file/sql/binlog_index                     | YES     | YES   |
| wait/io/file/sql/casetest                         | YES     | YES   |
| wait/io/file/sql/dbopt                            | YES     | YES   |
...

要控制工具是否启用，请将其ENABLED列设置为YES或NO。要配置是否为已启用工具收集计时信息，请将其TIMED值设置为YES或NO。设置TIMED列会影响 Performance Schema 表内容，如第 29.4.1 节“性能模式事件计时”中所述。

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

setup_instruments 表提供了对事件生成最基本的控制形式。为了根据被监视的对象或线程类型进一步细化事件生成，可以使用其他表，如第 29.4.3 节“事件预过滤”中所述。

以下示例演示了对setup_instruments表可能的操作。这些更改，像其他预过滤操作一样，会影响所有用户。其中一些查询使用LIKE运算符和模式匹配工具名称。有关指定模式以选择工具的更多信息，请参阅第 29.4.9 节“为过滤操作命名工具或消费者”。

禁用所有工具：

UPDATE performance_schema.setup_instruments
SET ENABLED = 'NO';

现在不再收集任何事件。

禁用所有文件工具，并将它们添加到当前禁用工具集中：

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

仅禁用文件工具，启用所有其他工具：

UPDATE performance_schema.setup_instruments
SET ENABLED = IF(NAME LIKE 'wait/io/file/%', 'NO', 'YES');

启用除了mysys库中的工具之外的所有工具：

UPDATE performance_schema.setup_instruments
SET ENABLED = CASE WHEN NAME LIKE '%/mysys/%' THEN 'YES' ELSE 'NO' END;

禁用特定工具：

UPDATE performance_schema.setup_instruments
SET ENABLED = 'NO'
WHERE NAME = 'wait/synch/mutex/mysys/TMPDIR_mutex';

要切换工具的状态，“翻转”其ENABLED值：

UPDATE performance_schema.setup_instruments
SET ENABLED = IF(ENABLED = 'YES', 'NO', 'YES')
WHERE NAME = 'wait/synch/mutex/mysys/TMPDIR_mutex';

禁用所有事件的计时：

UPDATE performance_schema.setup_instruments
SET TIMED = 'NO';

29.4.5 对象预过滤

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

setup_objects表控制性能模式监视特定表格和存储程序对象。初始setup_objects内容如下：

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

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

OBJECT_TYPE列指示行适用的对象类型。TABLE过滤影响表格 I/O 事件(wait/io/table/sql/handler仪器)和表格锁事件(wait/lock/table/sql/handler仪器)。

OBJECT_SCHEMA和OBJECT_NAME列应包含文字模式或对象名称，或'%'以匹配任何名称。

ENABLED列指示是否监视匹配对象，TIMED指示是否收集时间信息。设置TIMED列会影响性能模式表内容，如第 29.4.1 节“性能模式事件定时”中所述。

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

当性能模式在setup_objects中查找匹配时，它首先尝试找到更具体的匹配。对于匹配给定OBJECT_TYPE的行，性能模式按照以下顺序检查行：

行中的OBJECT_SCHEMA='*文字*'和OBJECT_NAME='*文字*'。
行中的OBJECT_SCHEMA='*文字*'和OBJECT_NAME='%'。
表格中的OBJECT_SCHEMA='%'和OBJECT_NAME='%'。

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

对于与表相关的事件，性能模式将 setup_objects 的内容与 setup_instruments 结合起来，以确定是否启用仪器以及是否计时启用的仪器：

对于与 setup_objects 中的行匹配的表，只有在 setup_instruments 和 setup_objects 中的 ENABLED 都是 YES 时，表仪器才会产生事件。
两个表中的 TIMED 值被合并，只有当两个值都是 YES 时才收集时间信息。

对于存储过程对象，性能模式直接从 setup_objects 行中获取 ENABLED 和 TIMED 列。不会将值与 setup_instruments 结合。

假设 setup_objects 包含适用于 db1、db2 和 db3 的以下 TABLE 行：

+-------------+---------------+-------------+---------+-------+
| OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | ENABLED | TIMED |
+-------------+---------------+-------------+---------+-------+
| TABLE       | db1           | t1          | YES     | YES   |
| TABLE       | db1           | t2          | NO      | NO    |
| TABLE       | db2           | %           | YES     | YES   |
| TABLE       | db3           | %           | NO      | NO    |
| TABLE       | %             | %           | YES     | YES   |
+-------------+---------------+-------------+---------+-------+

如果 setup_instruments 中与对象相关的仪器具有 ENABLED 值为 NO，则不会监视对象的事件。如果 ENABLED 值为 YES，则根据相关 setup_objects 行中的 ENABLED 值进行事件监视：

db1.t1 事件被监视
db1.t2 事件不被监视
db2.t3 事件被监视
db3.t4 事件不被监视
db4.t5 事件被监视

类似的逻辑也适用于从 setup_instruments 和 setup_objects 表中合并 TIMED 列以确定是否收集事件时间信息。

如果一个持久表和一个临时表具有相同的名称，则对 setup_objects 行进行匹配的方式对两者都是相同的。不可能为一个表启用监视而不为另一个表启用。但是，每个表都是单独进行仪器化的。

29.4.6 通过线程进行预过滤

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

threads表包含每个服务器线程的一行。每行包含有关线程的信息，并指示是否为其启用了监视。要使性能模式监视线程，必须满足以下条件：

setup_consumers表中的thread_instrumentation消费者必须为YES。
threads.INSTRUMENTED列必须为YES。
仅对在setup_instruments表中启用的工具产生的线程事件进行监视。

threads表还指示每个服务器线程是否执行历史事件记录。这包括等待、阶段、语句和事务事件，并影响到这些表的记录：

events_waits_history
events_waits_history_long
events_stages_history
events_stages_history_long
events_statements_history
events_statements_history_long
events_transactions_history
events_transactions_history_long

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

必须启用setup_consumers表中适当的与历史相关的消费者。例如，在events_waits_history和events_waits_history_long表中等待事件记录需要相应的events_waits_history和events_waits_history_long消费者为YES。
threads.HISTORY列必须为YES。
仅对在setup_instruments表中启用的工具产生的线程事件进行记录。

对于前台线程（由客户端连接产生），threads表行中INSTRUMENTED和HISTORY列的初始值取决于与线程关联的用户帐户是否与setup_actors表中的任何行匹配。这些值来自匹配的setup_actors表行的ENABLED和HISTORY列。

对于后台线程，没有关联的用户。INSTRUMENTED和HISTORY默认为YES，不会查询setup_actors。

初始setup_actors内容如下所示：

mysql> SELECT * FROM performance_schema.setup_actors;
+------+------+------+---------+---------+
| HOST | USER | ROLE | ENABLED | HISTORY |
+------+------+------+---------+---------+
| %    | %    | %    | YES     | YES     |
+------+------+------+---------+---------+

HOST和USER列应包含文字主机或用户名，或'%'以匹配任何名称。

ENABLED和HISTORY列指示是否为匹配的线程启用仪表化和历史事件记录，受先前描述的其他条件的约束。

当性能模式在setup_actors中为每个新前台线程检查匹配时，首先尝试找到更具体的匹配，使用USER和HOST列（ROLE未使用）：

具有USER='*literal*'和HOST='*literal*'的行。
具有USER='*literal*'和HOST='%'的行。
具有USER='%'和HOST='*literal*'的行。
具有USER='%'和HOST='%'的行。

匹配顺序很重要，因为不同匹配的setup_actors行可以具有不同的USER和HOST值。这使得可以根据ENABLED和HISTORY列的值，基于主机、用户或帐户（用户和主机组合）有选择地应用仪表化和历史事件记录：

当最佳匹配是ENABLED=YES的行时，线程的INSTRUMENTED值变为YES。当最佳匹配是HISTORY=YES的行时，线程的HISTORY值变为YES。
当最佳匹配是ENABLED=NO的行时，线程的INSTRUMENTED值变为NO。当最佳匹配是HISTORY=NO的行时，线程的HISTORY值变为NO。
当找不到匹配时，线程的INSTRUMENTED和HISTORY值变为NO。

在setup_actors行中，ENABLED和HISTORY列可以独立设置为YES或NO。这意味着您可以单独启用仪表化，而不考虑是否收集历史事件。

默认情况下，对所有新前台线程启用监视和历史事件收集，因为setup_actors表最初包含HOST和USER都为'%'的行。要执行更有限的匹配，例如仅为某些前台线程启用监视，必须更改此行，因为它匹配任何连接，并添加更具体的HOST/USER组合的行。

假设您修改setup_actors如下：

UPDATE performance_schema.setup_actors
SET ENABLED = 'NO', HISTORY = 'NO'
WHERE HOST = '%' AND USER = '%';
INSERT INTO performance_schema.setup_actors
(HOST,USER,ROLE,ENABLED,HISTORY)
VALUES('localhost','joe','%','YES','YES');
INSERT INTO performance_schema.setup_actors
(HOST,USER,ROLE,ENABLED,HISTORY)
VALUES('hosta.example.com','joe','%','YES','NO');
INSERT INTO performance_schema.setup_actors
(HOST,USER,ROLE,ENABLED,HISTORY)
VALUES('%','sam','%','NO','YES');

UPDATE语句更改默认匹配以禁用仪表化和历史事件收集。INSERT语句为更具体的匹配添加行。

现在性能模式确定如何设置新连接线程的INSTRUMENTED和HISTORY值如下：

如果joe从本地主机连接，则连接与第一行插入的行匹配。线程的INSTRUMENTED和HISTORY值变为YES。
如果joe从hosta.example.com连接，则连接与第二行插入的行匹配。线程的INSTRUMENTED值变为YES，HISTORY值变为NO。
如果joe从任何其他主机连接，则没有匹配。线程的INSTRUMENTED和HISTORY值变为NO。
如果sam从任何主机连接，则连接与第三行插入的行匹配。线程的INSTRUMENTED值变为NO，HISTORY值变为YES。
对于任何其他连接，HOST和USER设置为'%'的行匹配。此行现在的ENABLED和HISTORY设置为NO，因此线程的INSTRUMENTED和HISTORY值变为NO。

对setup_actors表的修改仅影响在修改后创建的前台线程，而不影响现有线程。要影响现有线程，请修改threads表行的INSTRUMENTED和HISTORY列。

29.4.7 按消费者进行预过滤

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

setup_consumers表列出了可用的消费者类型以及哪些已启用：

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

修改setup_consumers表以影响消费者阶段的预过滤，并确定事件发送的目的地。要启用或禁用一个消费者，将其ENABLED值设置为YES或NO。

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

如果禁用一个消费者，服务器将不再花时间维护该消费者的目的地。例如，如果你不关心历史事件信息，可以禁用历史消费者：

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

setup_consumers表中的消费者设置形成从高级到低级的层次结构。以下原则适用：

与消费者关联的目的地只有在性能模式检查了消费者并且消费者已启用时才会接收事件。
一个消费者只有在它所依赖的所有消费者（如果有的话）都启用时才会被选中。
如果一个消费者未被选中，或者被选中但被禁用，依赖它的其他消费者也不会被选中。
依赖消费者可能有自己的依赖消费者。
如果一个事件不会被发送到任何目的地，性能模式就不会产生它。

以下列表描述了可用的消费者值。有关几种代表性消费者配置及其对仪表化的影响的讨论，请参见第 29.4.8 节，“示例消费者配置”。

全局和线程消费者
等待事件消费者
阶段事件消费者
语句事件消费者
事务事件消费者
语句摘要消费者

全局和线程消费者

global_instrumentation 是最高级别的消费者。如果 global_instrumentation 为 NO，它会禁用全局仪器。所有其他设置都是较低级别的，不会被检查；它们设置为什么并不重要。不会维护全局或每个线程的信息，也不会在当前事件或事件历史表中收集任何个别事件。如果 global_instrumentation 为 YES，性能模式会维护全局状态的信息，并且还会检查 thread_instrumentation 消费者。
thread_instrumentation 只有在 global_instrumentation 为 YES 时才会被检查。否则，如果 thread_instrumentation 为 NO，它会禁用线程特定的仪器，并且所有更低级别的设置都会被忽略。不会为每个线程维护任何信息，也不会在当前事件或事件历史表中收集任何个别事件。如果 thread_instrumentation 为 YES，性能模式会维护线程特定信息，并且还会检查 events_*xxx*_current 消费者。

等待事件消费者

这些消费者要求 global_instrumentation 和 thread_instrumentation 都为 YES，否则不会被检查。如果被检查，它们的作用如下：

如果 events_waits_current 为 NO，则会禁用在 events_waits_current 表中个别等待事件的收集。如果 YES，则会启用等待事件的收集，并且性能模式��检查 events_waits_history 和 events_waits_history_long 消费者。
如果 event_waits_current 为 NO，则不会检查 events_waits_history。否则，events_waits_history 的值为 NO 或 YES 会禁用或启用在 events_waits_history 表中等待事件的收集。
如果 event_waits_current 为 NO，则不会检查 events_waits_history_long。否则，events_waits_history_long 的值为 NO 或 YES 会禁用或启用在 events_waits_history_long 表中等待事件的收集。

阶段事件消费者

这些消费者要求 global_instrumentation 和 thread_instrumentation 都为 YES，否则不会被检查。如果被检查，它们的作用如下：

如果 events_stages_current 为 NO，则会禁用在 events_stages_current 表中个别阶段事件的收集。如果 YES，则会启用阶段事件的收集，并且性能模式会检查 events_stages_history 和 events_stages_history_long 消费者。
如果event_stages_current为NO，则不会检查events_stages_history。否则，events_stages_history的值为NO或YES将禁用或启用在events_stages_history表中阶段事件的收集。
如果event_stages_current为NO，则不会检查events_stages_history_long。否则，events_stages_history_long的值为NO或YES将禁用或启用在events_stages_history_long表中阶段事件的收集。

语句事件消费者

这些消费者需要global_instrumentation和thread_instrumentation都设置为YES，否则将不会被检查。如果被选中，它们的作用如下：

如果events_statements_cpu为NO，则禁用CPU_TIME的测量。如果为YES，并且启用了仪器和计时，将测量CPU_TIME。
如果events_statements_current为NO，则禁用在events_statements_current表中收集单个语句事件。如果为YES，则启用语句事件收集，并且性能模式将检查events_statements_history和events_statements_history_long消费者。
如果events_statements_current为NO，则不会检查events_statements_history。否则，events_statements_history的值为NO或YES将禁用或启用在events_statements_history表中语句事件的收集。
如果events_statements_current为NO，则不会检查events_statements_history_long。否则，events_statements_history_long的值为NO或YES将禁用或启用在events_statements_history_long表中语句事件的收集。

事务事件消费者

这些消费者需要global_instrumentation和thread_instrumentation都设置为YES，否则将不会被检查。如果被选中，它们的作用如下：

如果events_transactions_current为NO，则禁用在events_transactions_current表中收集单个事务事件。如果为YES，则启用事务事件收集，并且性能模式将检查events_transactions_history和events_transactions_history_long消费者。
如果events_transactions_current为NO，则不会检查events_transactions_history。否则，events_transactions_history的值为NO或YES会禁用或启用events_transactions_history表中事务事件的收集。
如果events_transactions_current为NO，则不会检查events_transactions_history_long。否则，events_transactions_history_long的值为NO或YES会禁用或启用events_transactions_history_long表中事务事件的收集。

语句摘要消费者

statements_digest消费者要求global_instrumentation为YES，否则不会进行检查。对语句事件消费者没有依赖，因此您可以在不必在events_statements_current中收集统计信息的情况下，获得每个摘要的统计信息，这在开销方面是有利的。相反，您可以在events_statements_current中获取详细的语句，而不需要摘要（在这种情况下，DIGEST和DIGEST_TEXT列为NULL）。

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

29.4.8 示例消费者配置

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

setup_consumers表中的消费者设置形成从高级到低级的层次结构。以下讨论描述了消费者如何工作，展示了特定配置及其效果，随着从高到低逐渐启用消费者设置。所示的消费者值是代表性的。这里描述的一般原则适用于可能可用的其他消费者值。

配置描述按功能和开销递增的顺序出现。如果不需要启用较低级别设置提供的信息，则禁用它们，以便性能模式在您的代表执行更少的代码，并且需要筛选的信息更少。

setup_consumers表包含以下值的层次结构：

global_instrumentation
 thread_instrumentation
   events_waits_current
     events_waits_history
     events_waits_history_long
   events_stages_current
     events_stages_history
     events_stages_history_long
   events_statements_current
     events_statements_history
     events_statements_history_long
   events_transactions_current
     events_transactions_history
     events_transactions_history_long
 statements_digest

注意

在消费者层次结构中，等待、阶段、语句和事务的消费者都处于同一级别。这与事件嵌套层次结构不同，等待事件嵌套在阶段事件内，阶段事件嵌套在语句事件内，语句事件嵌套在事务事件内。

如果给定的消费者设置为NO，性能模式将禁用与该消费者相关联的仪器，并忽略所有较低级别的设置。如果给定的设置为YES，性能模式将启用与之相关联的仪器，并检查下一个较低级别的设置。有关每个消费者的规则描述，请参见第 29.4.7 节“按消费者进行预过滤”。

例如，如果启用了global_instrumentation，则会检查thread_instrumentation。如果启用了thread_instrumentation，则会检查events_*xxx*_current消费者。如果其中的events_waits_current已启用，则会检查events_waits_history和events_waits_history_long。

以下每个配置描述指示性能模式检查哪些设置元素，并维护哪些输出表（即，为哪些表收集信息）。

无仪器
仅全局仪器
仅全局和线程仪器
全局、线程和当前事件仪器
全局、线程、当前事件和事件历史仪器

无仪器

服务器配置状态：

mysql> SELECT * FROM performance_schema.setup_consumers;
+---------------------------+---------+
| NAME                      | ENABLED |
+---------------------------+---------+
| global_instrumentation    | NO      |
...
+---------------------------+---------+

在这种配置中，没有任何仪器。

检查的设置元素：

表 setup_consumers, 消费者 global_instrumentation

维护的输出表：

仅全局仪器

服务器配置状态：

mysql> SELECT * FROM performance_schema.setup_consumers;
+---------------------------+---------+
| NAME                      | ENABLED |
+---------------------------+---------+
| global_instrumentation    | YES     |
| thread_instrumentation    | NO      |
...
+---------------------------+---------+

在这种配置中，仪器仅用于全局状态。每个线程的仪器被禁用。

相对于前述配置，检查的额外设置元素：

表 setup_consumers, 消费者 thread_instrumentation
表 setup_instruments
表 setup_objects

相对于前述配置，维护的额外输出表：

mutex_instances
rwlock_instances
cond_instances
file_instances
users
hosts
accounts
socket_summary_by_event_name
file_summary_by_instance
file_summary_by_event_name
objects_summary_global_by_type
memory_summary_global_by_event_name
table_lock_waits_summary_by_table
table_io_waits_summary_by_index_usage
table_io_waits_summary_by_table
events_waits_summary_by_instance
events_waits_summary_global_by_event_name
events_stages_summary_global_by_event_name
events_statements_summary_global_by_event_name
events_transactions_summary_global_by_event_name

仅全局和线程仪器

服务器配置状态：

mysql> SELECT * FROM performance_schema.setup_consumers;
+----------------------------------+---------+
| NAME                             | ENABLED |
+----------------------------------+---------+
| global_instrumentation           | YES     |
| thread_instrumentation           | YES     |
| events_waits_current             | NO      |
...
| events_stages_current            | NO      |
...
| events_statements_current        | NO      |
...
| events_transactions_current      | NO      |
...
+----------------------------------+---------+

在这种配置下，仪器仪表是全局和每个线程都维护的。当前事件或事件历史表中不收集任何个别事件。

相对于前述配置，检查了额外的设置元素：

表setup_consumers，消费者events_*xxx*_current，其中xxx是waits、stages、statements、transactions
表setup_actors
列threads.instrumented

相对于前述配置，维护了额外的输出表：

events_*xxx*_summary_by_*yyy*_by_event_name，其中xxx是waits、stages、statements、transactions；yyy是thread、user、host、account

全局、线程和当前事件仪器

服务器配置状态：

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

在这种配置下，仪器仪表是全局和每个线程都维护的。个别事件在当前事件表中收集，但不在事件历史表中。

相对于前述配置，检查了额外的设置元素：

消费者events_*xxx*_history，其中xxx是waits、stages、statements、transactions
消费者events_*xxx*_history_long，其中xxx是waits、stages、statements、transactions

相对于前述配置，维护了额外的输出表：

events_*xxx*_current，其中xxx是waits、stages、statements、transactions

全局、线程、当前事件和事件历史仪器

前述配置未收集任何事件历史，因为events_*xxx*_history和events_*xxx*_history_long消费者已禁用。这些消费者可以单独或一起启用，以便按线程、全局或两者同时收集事件历史。

此配置按线程收集事件历史，但不全局：

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

为此配置维护的事件历史表：

events_*xxx*_history，其中xxx是waits、stages、statements、transactions

此配置全局收集事件历史，但不按线程：

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

为此配置维护的事件历史表：

events_*xxx*_history_long，其中xxx是waits、stages、statements、transactions

此配置按线程和全局收集事件历史：

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

为此配置维护的事件历史表：

events_*xxx*_history，其中xxx是waits、stages、statements、transactions
events_*xxx*_history_long，其中xxx是waits、stages、statements、transactions

29.4.9 为过滤操作命名仪表或消费者

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

为过滤操作提供的名称可以根据需要具体或一般。要指示单个仪表或消费者，请完整指定其名称：

UPDATE performance_schema.setup_instruments
SET ENABLED = 'NO'
WHERE NAME = 'wait/synch/mutex/myisammrg/MYRG_INFO::mutex';

UPDATE performance_schema.setup_consumers
SET ENABLED = 'NO'
WHERE NAME = 'events_waits_current';

要指定一组仪表或消费者，请使用匹配组成员的模式：

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

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

如果使用模式，应选择能够匹配所有感兴趣的项目但不匹配其他项目的模式。例如，要选择所有文件 I/O 仪表，最好使用包含整个仪表名称前缀的模式：

... WHERE NAME LIKE 'wait/io/file/%';

'%/file/%'的模式匹配其他仪表中名称中任何位置包含'/file/'的元素。更不合适的是'%file%'这种模式，因为它匹配名称中任何位置包含'file'的仪表，比如wait/synch/mutex/innodb/file_open_mutex。

要检查模式匹配的仪表或消费者名称，请执行简单测试：

SELECT NAME FROM performance_schema.setup_instruments
WHERE NAME LIKE '*pattern*';

SELECT NAME FROM performance_schema.setup_consumers
WHERE NAME LIKE '*pattern*';

有关支持的名称类型的信息，请参阅第 29.6 节，“性能模式仪表命名约定”。

29.4.10 确定仪器化的内容

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

通过检查setup_instruments表，始终可以确定性能模式包含哪些仪器。例如，要查看为InnoDB存储引擎仪器化的文件相关事件，请使用以下查询：

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

此文档未详细描述仪器化的内容，原因有几个：

仪器化的是服务器代码。对这些代码的更改经常发生，这也会影响仪器的集合。
不可能列出所有的仪器，因为它们有数百个。
如前所述，可以通过查询setup_instruments表来找到。这些信息始终是针对您的 MySQL 版本最新的，还包括您可能安装的不属于核心服务器的仪器化插件的仪器化，并可被自动化工具使用。

29.5 性能模式查询

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

预过滤限制了收集的事件信息，与任何特定用户无关。相比之下，后过滤是由个别用户通过使用带有适当WHERE子句的查询执行的，这些子句限制了在应用预过滤后可用的事件中选择哪些事件信息。

在第 29.4.3 节，“事件预过滤”中，一个示例展示了如何为文件工具进行预过滤。如果事件表中既包含文件信息又包含非文件信息，后过滤是另一种仅查看文件事件信息的方法。向查询添加WHERE子句以适当限制事件选择：

mysql> SELECT THREAD_ID, NUMBER_OF_BYTES
       FROM performance_schema.events_waits_history
       WHERE EVENT_NAME LIKE 'wait/io/file/%'
       AND NUMBER_OF_BYTES IS NOT NULL;
+-----------+-----------------+
| THREAD_ID | NUMBER_OF_BYTES |
+-----------+-----------------+
|        11 |              66 |
|        11 |              47 |
|        11 |             139 |
|         5 |              24 |
|         5 |             834 |
+-----------+-----------------+

大多数性能模式表都有索引，这使得优化器可以访问除全表扫描之外的执行计划。这些索引还提高了与使用这些表的sys模式视图等相关对象的性能。有关更多信息，请参见第 10.2.4 节，“优化性能模式查询”。

29.6 性能模式仪器命名约定

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

一个仪器名称由一系列由 '/' 字符分隔的元素组成。示例名称：

wait/io/file/myisam/log
wait/io/file/mysys/charset
wait/lock/table/sql/handler
wait/synch/cond/mysys/COND_alarm
wait/synch/cond/sql/BINLOG::update_cond
wait/synch/mutex/mysys/BITMAP_mutex
wait/synch/mutex/sql/LOCK_delete
wait/synch/rwlock/sql/Query_cache_query::lock
stage/sql/closing tables
stage/sql/Sorting result
statement/com/Execute
statement/com/Query
statement/sql/create_table
statement/sql/lock_tables
errors

仪器名称空间具有类似树状结构。仪器名称中的元素从左到右提供了从更一般到更具体的进展。名称中的元素数量取决于仪器的类型。

在名称中给定元素的解释取决于其左侧的元素。例如，myisam 出现在以下两个名称中，但第一个名称中的 myisam 与文件 I/O 有关，而第二个名称中的 myisam 与同步仪器有关：

wait/io/file/myisam/log
wait/synch/cond/myisam/MI_SORT_INFO::cond

仪器名称由性能模式实现定义的前缀结构和由实现仪器代码的开发人员定义的后缀组成。仪器前缀的顶层元素指示仪器的类型。此元素还确定performance_timers 表中的哪个事件计时器适用于该仪器。对于仪器名称的前缀部分，顶层元素指示仪器的类型。

仪器名称的后缀部分来自仪器本身的代码。后缀可能包括以下级别：

主要元素的名称（服务器模块，如 myisam，innodb，mysys 或 sql）或插件名称。
代码中变量的名称，形式为 XXX（全局变量）或 *CCC*::*MMM*（类 CCC 中的成员 MMM）。示例：COND_thread_cache，THR_LOCK_myisam，BINLOG::LOCK_index。
顶层仪器元素
空闲仪器元素
错误仪器元素
内存仪器元素
阶段仪器元素
语句仪器元素
线程仪器元素
等待仪器元素

顶层仪器元素

idle: 一个被检测的空闲事件。这个仪器没有进一步的元素。
error: 一个被检测的错误事件。这个仪器没有进一步的元素。
memory: 一个被检测的内存事件。
stage: 一个被检测的阶段事件。
statement: 一个被检测的语句事件。
transaction: 一个被检测的事务事件。这个仪器没有进一步的元素。
wait: 一个被检测的等待事件。

空闲仪器元素

idle仪器用于空闲事件，性能模式生成这些事件，如第 29.12.3.5 节中socket_instances.STATE列的描述所述。

错误仪器元素

error仪器指示是否收集有关服务器错误和警告的信息。这个仪器默认启用。setup_instruments表中error行的TIMED列不适用，因为不收集时间信息。

内存仪器元素

内存仪器默认情况下是启用的。内存仪器可以在启动时启用或禁用，或者通过更新setup_instruments表中相关仪器的ENABLED列来在运行时动态启用或禁用。内存仪器的名称形式为memory/*code_area*/*instrument_name*，其中code_area是一个值，例如sql或myisam，而instrument_name是仪器的详细信息。

以memory/performance_schema/前缀命名的仪器公开了性能模式中内部缓冲区分配了多少内存。memory/performance_schema/仪器是内置的，始终启用，并且无法在启动时或运行时禁用。内置内存仪器仅在memory_summary_global_by_event_name表中显示。有关更多信息，请参见第 29.17 节，“性能模式内存分配模型”。

阶段仪器元素

阶段工具的名称形式为stage/*code_area*/*stage_name*，其中code_area是诸如sql或myisam之类的值，stage_name表示语句处理阶段，例如Sorting result或Sending data。阶段对应于SHOW PROCESSLIST显示的线程状态或在信息模式PROCESSLIST表中可见的状态。

语句工具元素

statement/abstract/*：用于语句操作的抽象工具。在确切语句类型未知的语句分类早期阶段使用抽象工具，然后在了解类型后将其更改为更具体的语句工具。有关此过程的描述，请参阅 Section 29.12.6, “Performance Schema Statement Event Tables”。
statement/com：一个被检测的命令操作。这些名称对应于COM_*xxx*操作（请参阅mysql_com.h头文件和sql/sql_parse.cc。例如，statement/com/Connect和statement/com/Init DB工具对应于COM_CONNECT和COM_INIT_DB命令。
statement/scheduler/event：用于跟踪事件调度器执行的所有事件的单个工具。当计划事件开始执行时，此工具开始发挥作用。
statement/sp：由存储程序执行的一个被检测的内部指令。例如，statement/sp/cfetch和statement/sp/freturn工具用于游标获取和函数返回指令。
statement/sql：一个被检测的 SQL 语句操作。例如，statement/sql/create_db和statement/sql/select工具用于CREATE DATABASE和SELECT语句。

线程工具元素

被检测的线程显示在setup_threads表中，该表公开线程类名称和属性。

线程工具以thread开头（例如，thread/sql/parser_service或thread/performance_schema/setup）。

ndbcluster插件线程的线程工具名称以thread/ndbcluster/开头；有关更多信息，请参阅 ndbcluster Plugin Threads。

等待工具元素

wait/io

一个被检测的 I/O 操作。
- wait/io/file
  
  一个被检测的文件 I/O 操作。对于文件，等待是等待文件操作完成的时间（例如，调用fwrite()）。由于缓存，磁盘上的物理文件 I/O 可能不会在此调用中发生。
- wait/io/socket
  
  一个被检测的套接字操作。套接字工具的名称形式为wait/io/socket/sql/*socket_type*。服务器为它支持的每种网络协议都有一个监听套接字。与 TCP/IP 或 Unix 套接字文件连接的监听套接字相关的工具具有server_tcpip_socket或server_unix_socket的socket_type值。当一个监听套接字检测到一个连接时，服务器将连接传输给由单独线程管理的新套接字。新连接线程的工具具有client_connection的socket_type值。
- wait/io/table
  
  一个被检测的表 I/O 操作。这些包括对持久基表或临时表的行级访问。影响行的操作包括获取、插入、更新和删除。对于视图，等待与视图引用的基表相关联。
  
  与大多数等待不同，表 I/O 等待可能包括其他等待。例如，表 I/O 可能包括文件 I/O 或内存操作。因此，表 I/O 等待的events_waits_current通常有两行。有关更多信息，请参见第 29.8 节，“性能模式原子和分子事件”。
  
  一些行操作可能导致多个表 I/O 等待。例如，插入可能激活触发器导致更新。
wait/lock

一个被检测的锁操作。
- wait/lock/table
  
  一个被检测的表锁操作。
- wait/lock/metadata/sql/mdl
  
  一个被检测的元数据锁操作。
wait/synch

一个被检测的同步对象。对于同步对象，TIMER_WAIT时间包括在尝试获取对象锁时被阻塞的时间。
- wait/synch/cond
  
  一个条件被一个线程用来通知其他线程他们等待的事情已经发生。如果一个线程在等待一个条件，它可以唤醒并继续执行。如果有多个线程在等待，它们都可以被唤醒并竞争它们等待的资源。
- wait/synch/mutex
  
  一个用于允许访问资源（如可执行代码段）并防止其他线程访问资源的互斥对象。
- wait/synch/prlock
  
  一个优先级读/写锁锁对象。
- wait/synch/rwlock
  
  用于锁定特定变量以防止其他线程使用的普通读/写锁对象。多个线程可以同时获取共享读锁。独占写锁一次只能被一个线程获取。
- wait/synch/sxlock
  
  一个共享-独占（SX）锁是一种类型的 rwlock 锁对象，它允许其他线程进行不一致的读取，同时提供对共享资源的写访问。sxlocks优化并发性，提高读写工作负载的可伸缩性。

29.7 性能模式状态监控

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

与性能模式相关的几个状态变量有：

mysql> SHOW STATUS LIKE 'perf%';
+-----------------------------------------------+-------+
| Variable_name                                 | Value |
+-----------------------------------------------+-------+
| Performance_schema_accounts_lost              | 0     |
| Performance_schema_cond_classes_lost          | 0     |
| Performance_schema_cond_instances_lost        | 0     |
| Performance_schema_digest_lost                | 0     |
| Performance_schema_file_classes_lost          | 0     |
| Performance_schema_file_handles_lost          | 0     |
| Performance_schema_file_instances_lost        | 0     |
| Performance_schema_hosts_lost                 | 0     |
| Performance_schema_locker_lost                | 0     |
| Performance_schema_memory_classes_lost        | 0     |
| Performance_schema_metadata_lock_lost         | 0     |
| Performance_schema_mutex_classes_lost         | 0     |
| Performance_schema_mutex_instances_lost       | 0     |
| Performance_schema_nested_statement_lost      | 0     |
| Performance_schema_program_lost               | 0     |
| Performance_schema_rwlock_classes_lost        | 0     |
| Performance_schema_rwlock_instances_lost      | 0     |
| Performance_schema_session_connect_attrs_lost | 0     |
| Performance_schema_socket_classes_lost        | 0     |
| Performance_schema_socket_instances_lost      | 0     |
| Performance_schema_stage_classes_lost         | 0     |
| Performance_schema_statement_classes_lost     | 0     |
| Performance_schema_table_handles_lost         | 0     |
| Performance_schema_table_instances_lost       | 0     |
| Performance_schema_thread_classes_lost        | 0     |
| Performance_schema_thread_instances_lost      | 0     |
| Performance_schema_users_lost                 | 0     |
+-----------------------------------------------+-------+

性能模式状态变量提供了有关由于内存限制而无法加载或创建的仪器化信息。这些变量的名称有几种形式：

Performance_schema_*xxx*_classes_lost 表示无法加载类型为 xxx 的仪器数量。
Performance_schema_*xxx*_instances_lost 表示无法创建对象类型为 xxx 的实例数量。
Performance_schema_*xxx*_handles_lost 表示无法打开对象类型为 xxx 的实例数量。
Performance_schema_locker_lost 表示有多少事件“丢失”或未记录。

例如，如果在服务器源代码中为互斥仪器进行了仪器化，但服务器在运行时无法为仪器分配内存，则会增加 Performance_schema_mutex_classes_lost。互斥仍然作为同步对象运行（即，服务器继续正常运行），但不会收集其性能数据。如果可以分配仪器，则可以用于初始化仪器化的互斥实例。对于全局互斥体这样的单例互斥体，只有一个实例。其他互斥体每个连接或每个页面在各种缓存和数据缓冲区中有一个实例，因此实例数量随时间变化。增加最大连接数或某些缓冲区的最大大小会增加一次可能分配的实例的最大数量。如果服务器无法创建给定的仪器化互斥实例，则会增加 Performance_schema_mutex_instances_lost。

假设以下条件成立：

服务器使用 --performance_schema_max_mutex_classes=200 选项启动，因此有 200 个互斥仪器的空间。
已加载了 150 个互斥仪器。
名为 plugin_a 的插件包含 40 个互斥仪器。
名为 plugin_b 的插件包含 20 个互斥仪器。

服务器根据插件需要的数量和可用数量为插件分配互斥仪器，如下面的语句序列所示：

INSTALL PLUGIN plugin_a

服务器现在有 150+40 = 190 个互斥仪器。

UNINSTALL PLUGIN plugin_a;

服务器仍然有 190 个仪器。插件代码生成的所有历史数据仍然可用，但不会收集仪器的新事件。

INSTALL PLUGIN plugin_a;

服务器检测到已经定义了 40 个仪器，因此不会创建新的仪器，并且先前分配的内部内存缓冲区将被重用。服务器仍然有 190 个仪器。

INSTALL PLUGIN plugin_b;

服务器有 200-190 = 10 个仪器的空间（在本例中是互斥类），并且发现插件包含 20 个新仪器。加载了 10 个仪器，而 10 个被丢弃或“丢失”。Performance_schema_mutex_classes_lost 指示了丢失的仪器（互斥类）的数量：

mysql> SHOW STATUS LIKE "perf%mutex_classes_lost";
+---------------------------------------+-------+
| Variable_name                         | Value |
+---------------------------------------+-------+
| Performance_schema_mutex_classes_lost | 10    |
+---------------------------------------+-------+
1 row in set (0.10 sec)

仪器仍在工作并为 plugin_b 收集（部分）数据。

当服务器无法创建互斥仪器时，会出现以下结果：

仪器未插入 setup_instruments 表中。
Performance_schema_mutex_classes_lost 增加了 1。
Performance_schema_mutex_instances_lost 不会改变。（当互斥仪器未创建时，无法用于稍后创建仪器化的互斥实例。）

刚才描述的模式适用于所有类型的仪器，而不仅仅是互斥体。

Performance_schema_mutex_classes_lost 大于 0 的值可能出现在两种情况下：

为了节省一些内存空间，您可以使用 --performance_schema_max_mutex_classes=*N* 启动服务器，其中 N 小于默认值。默认值被选择为足以加载 MySQL 发行版中提供的所有插件，但如果某些插件从未加载，则可以减少此值。例如，您可能选择不加载发行版中的某些存储引擎。
您加载了一个为性能模式进行了仪器化的第三方插件，但在启动服务器时未考虑插件的仪器化内存需求。由于来自第三方，因此此引擎的仪器内存消耗不计入为 performance_schema_max_mutex_classes 选择的默认值。

如果服务器对插件的仪器资源不足，并且您未明确使用 --performance_schema_max_mutex_classes=*N* 分配更多资源，则加载插件会导致仪器资源匮乏。

如果为performance_schema_max_mutex_classes选择的值太小，错误日志中不会报告任何错误，并且在运行时不会出现故障。然而，performance_schema数据库中的表内容会缺少事件。Performance_schema_mutex_classes_lost状态变量是唯一可见的迹象，表明由于无法创建仪器而导致一些事件被丢弃。

如果一个仪器没有丢失，那么性能模式就会知道它，并在实例化时使用。例如，wait/synch/mutex/sql/LOCK_delete是setup_instruments表中一个互斥体仪器的名称。这个单一仪器在代码中创建互斥体时使用（在THD::LOCK_delete中），然而服务器运行时需要多个互斥体实例。在这种情况下，LOCK_delete是一个每个连接（THD）的互斥体，所以如果服务器有 1000 个连接，就有 1000 个线程，以及 1000 个被标记的LOCK_delete互斥体实例（THD::LOCK_delete）。

如果服务器没有足够的空间来容纳这 1000 个被标记的互斥体（实例），一些互斥体会被创建并标记，而另一些则会被创建但不被标记。如果服务器只能创建 800 个实例，那么就会丢失 200 个实例。服务器继续运行，但会将Performance_schema_mutex_instances_lost增加 200，以表示无法创建实例。

如果Performance_schema_mutex_instances_lost的值大于 0，可能是因为代码在运行时初始化的互斥体比为--performance_schema_max_mutex_instances=*N*分配的数量多。

关键是，如果SHOW STATUS LIKE 'perf%'显示没有丢失任何内容（所有值都为零），那么性能模式数据是准确的，可以信赖。如果有内容丢失，数据就是不完整的，性能模式无法记录所有内容，因为给定的内存量不足。在这种情况下，特定的Performance_schema_*xxx*_lost变量指示了问题区域。

在某些情况下，有意造成仪器匮乏可能是合适的。例如，如果您不关心文件 I/O 的性能数据，可以将服务器启动时与文件 I/O 相关的所有性能模式参数设置为 0。不会为与文件相关的类、实例或句柄分配任何内存，并且所有文件事件都会丢失。

使用SHOW ENGINE PERFORMANCE_SCHEMA STATUS来检查性能模式代码的内部操作：

mysql> SHOW ENGINE PERFORMANCE_SCHEMA STATUS\G
...
*************************** 3\. row ***************************
  Type: performance_schema
  Name: events_waits_history.size
Status: 76
*************************** 4\. row ***************************
  Type: performance_schema
  Name: events_waits_history.count
Status: 10000
*************************** 5\. row ***************************
  Type: performance_schema
  Name: events_waits_history.memory
Status: 760000
...
*************************** 57\. row ***************************
  Type: performance_schema
  Name: performance_schema.memory
Status: 26459600
...

这个语句旨在帮助数据库管理员理解不同性能模式选项对内存需求的影响。有关字段含义的描述，请参阅第 15.7.7.15 节，“SHOW ENGINE Statement”。

29.8 性能模式原子和分子事件

原文：dev.mysql.com/doc/refman/8.0/en/performance-schema-atom-molecule-events.html

对于表 I/O 事件，在events_waits_current中通常有两行，而不是一行。例如，行提取可能导致类似以下的行：

Row# EVENT_NAME                 TIMER_START TIMER_END
---- ----------                 ----------- ---------
   1 wait/io/file/myisam/dfile        10001 10002
   2 wait/io/table/sql/handler        10000 NULL

行提取导致文件读取。在这个例子中，表 I/O 提取事件在文件 I/O 事件之前开始，但尚未完成（其TIMER_END值为NULL）。文件 I/O 事件“嵌套”在表 I/O 事件中。

这是因为，与其他“原子”等待事件（如互斥或文件 I/O）不同，表 I/O 事件是“分子”事件，并包括（重叠）其他事件。在events_waits_current中，表 I/O 事件通常有两行：

最近的表 I/O 等待事件的一行
任何类型的最新等待事件的一行

通常情况下，“任何类型”的等待事件与表 I/O 事件不同。随着每个子事件的完成，它会从events_waits_current中消失。在此时，直到下一个子事件开始之前，表 I/O 等待也是任何类型的最新等待。

29.9 性能模式表用于当前和历史事件

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

对于等待、阶段、语句和事务事件，性能模式可以监视和存储当前事件。此外，当事件结束时，性能模式可以将它们存储在历史表中。对于每种事件类型，性能模式使用三个表来存储当前和历史事件。这些表的名称采用以下形式，其中xxx表示事件类型（waits、stages、statements、transactions）：

events_*xxx*_current： “当前事件”表为每个线程存储当前监视的事件（每个线程一行）。
events_*xxx*_history： “最近历史”表存储每个线程中已结束的最新事件（每个线程最多一定数量的行）。
events_*xxx*_history_long： “长历史”表存储全局结束的最新事件（跨所有线程，每个表最多一定数量的行）。

每种事件类型的_current表每个线程包含一行，因此没有用于配置其最大大小的系统变量。性能模式自动调整历史表的大小，或者可以在服务器启动时使用特定于表的系统变量显式配置大小，如在描述各个历史表的部分中所示。典型的自动调整值为_history表每个线程 10 行，_history_long表总共 10,000 行。

对于每种事件类型，_current、_history和_history_long表具有相同的列。_current和_history表具有相同的索引。_history_long表没有索引。

_current表显示服务器当前正在发生的情况。当当前事件结束时，它将从其_current表中移除。

_history和_history_long表显示最近发生的事件。当历史表变满时，旧事件将被丢弃，新事件将被添加。行从_history和_history_long表中以不同的方式过期，因为这些表有不同的用途：

_history用于独立于全局服务器负载调查单个线程。
_history_long用于全局调查服务器，而不是每个线程。

两种历史表之间的区别与数据保留政策有关。当事件首次出现时，两个表包含相同的数据。然而，随着时间的推移，每个表中的数据会以不同的方式过期，因此在每个表中可能会保留更长或更短的时间：

对于_history，当表对于给定线程包含最大数量的行时，当为该线程添加新行时，最旧的线程行将被丢弃。
对于_history_long，当表变满时，无论哪个线程生成了这两行，当添加新行时，最老的行都会被丢弃。

当一个线程结束时，它的所有行都会从_history表中丢弃，但不会从_history_long表中丢弃。

以下示例说明了如何向这两种类型的历史表中添加和丢弃事件的差异。这些原则同样适用于所有事件类型。该示例基于以下假设：

性能模式被配置为在_history表中保留每个线程的 10 行，在_history_long表中总共保留 10,000 行。
线程 A 每秒生成 1 个事件。

线程 B 每秒生成 100 个事件。
没有其他线程在运行。

执行 5 秒后：

A 和 B 分别生成了 5 和 500 个事件。
_history包含了 A 的 5 行和 B 的 10 行。因为每个线程的存储限制为 10 行，所以对于 A 没有丢弃行，而对于 B 已经丢弃了 490 行。
_history_long包含了 A 的 5 行和 B 的 500 行。因为表的最大行数为 10,000 行，所以对于任何一个线程都没有丢弃行。

执行 5 分钟（300 秒）后：

A 和 B 分别生成了 300 和 30,000 个事件。
_history包含了 A 的 10 行和 B 的 10 行。因为每个线程的存储限制为 10 行，对于 A 已经丢弃了 290 行，而对于 B 已经丢弃了 29,990 行。A 的行包含了 10 秒前的数据，而 B 的行只包含了 0.1 秒前的数据。
_history_long包含了 10,000 行。因为 A 和 B 一起每秒生成 101 个事件，所以表中的数据大约是 10,000/101 = 99 秒前的数据，其中 B 的行数大约是 A 的 100 倍。

29.10 性能模式语句摘要和采样

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

MySQL 服务器能够维护语句摘要信息。摘要过程将每个 SQL 语句转换为规范化形式（语句摘要），并从规范化结果计算一个 SHA-256 哈希值（摘要哈希值）。规范化允许类似的语句被分组和总结，以公开关于服务器正在执行的语句类型及其频率的信息。对于每个摘要，存储生成该摘要的代表性语句作为样本。本节描述了语句摘要和采样的发生方式以及它们的用途。

无论性能模式是否可用，解析器都会进行摘要处理，以便其他功能如 MySQL 企业防火墙和查询重写插件可以访问语句摘要。

语句摘要概念
性能模式中的语句摘要
语句摘要内存使用
语句采样

语句摘要概念

当解析器接收到一个 SQL 语句时，如果需要该摘要，则会计算一个语句摘要，如果以下任一条件为真，则为真：

启用了性能模式摘要工具
启用了 MySQL 企业防火墙
启用了查询重写插件

解析器还被 STATEMENT_DIGEST_TEXT() 和 STATEMENT_DIGEST() 函数使用，应用程序可以调用这些函数从 SQL 语句中计算规范化语句摘要和摘要哈希值。

max_digest_length 系统变量的值确定了每个会话用于计算规范化语句摘要的最大字节数。一旦在摘要计算过程中使用了这么多空间，就会发生截断：从解析语句中收集的标记不再被收集或计入其摘要值。只有在解析标记之后的那么多字节之后才有所不同的语句会产生相同的规范化语句摘要，并且如果进行比较或用于摘要统计，则被视为相同。

警告

将max_digest_length系统变量设置为零会禁用摘要生成，这也会禁用需要摘要的服务器功能。

计算规范化语句后，从中计算 SHA-256 哈希值。此外：

如果启用了 MySQL 企业防火墙，则会调用它，并且计算的摘要对其可用。
如果启用了任何查询重写插件，则会调用它，并且语句摘要和摘要值对其可用。
如果性能模式启用了摘要仪器，它会复制规范化的语句摘要，为其分配最多performance_schema_max_digest_length字节。因此，如果performance_schema_max_digest_length小于max_digest_length，则复制相对于原始文本被截断。规范化的语句摘要的副本存储在适当的性能模式表中，以及从原始规范化语句计算的 SHA-256 哈希值。（如果性能模式相对于原始文本截断其规范化语句摘要的副本，则不会重新计算 SHA-256 哈希值。）

语句规范化将语句文本转换为更标准化的摘要字符串表示形式，保留一般语句结构同时删除不影响结构的信息：

保留对象标识符，如数据库和表名。
文本值被转换为参数标记。规范化的语句不保留名称、密码、日期等信息。
注释被移除，空格被调整。

考虑这些语句：

SELECT * FROM orders WHERE customer_id=10 AND quantity>20
SELECT * FROM orders WHERE customer_id = 20 AND quantity > 100

为了规范化这些语句，解析器将数据值替换为?并调整空格。两个语句产生相同的规范化形式，因此被认为是“相同的”：

SELECT * FROM orders WHERE customer_id = ? AND quantity > ?

规范化的语句包含较少信息，但仍代表原始语句。其他类似的具有不同数据值的语句具有相同的规范化形式。

现在考虑这些语句：

SELECT * FROM customers WHERE customer_id = 1000
SELECT * FROM orders WHERE customer_id = 1000

在这种情况下，规范化的语句不同，因为对象标识符不同：

SELECT * FROM customers WHERE customer_id = ?
SELECT * FROM orders WHERE customer_id = ?

如果规范化产生的语句超过摘要缓冲区中可用的空间（由max_digest_length确定），则会发生截断，并且文本以“...”结尾。只有在“...”后面部分不同的长规范化语句被视为相同。考虑这些语句：

SELECT * FROM mytable WHERE cola = 10 AND colb = 20
SELECT * FROM mytable WHERE cola = 10 AND colc = 20

如果截断恰好发生在AND之后，则这两个语句具有相同的规范化形式：

SELECT * FROM mytable WHERE cola = ? AND ...

在这种情况下，第二列名称的差异被忽略，两个语句被视为相同。

性能模式中的语句摘要

在性能模式中，语句摘要涉及以下元素：

setup_consumers 表中的 statements_digest 消费者控制性能模式是否维护摘要信息。参见语句摘要消费者。
语句事件表（events_statements_current，events_statements_history 和 events_statements_history_long）具有用于存储规范语句摘要和相应摘要 SHA-256 哈希值的列：
- DIGEST_TEXT 是规范语句摘要的文本。这是原始规范语句的副本，计算到最大 max_digest_length 字节，根据需要进一步截断为 performance_schema_max_digest_length 字节。
- DIGEST 是从原始规范语句计算得出的摘要 SHA-256 哈希值。
参见第 29.12.6 节，“性能模式语句事件表”。
events_statements_summary_by_digest 摘要表提供了聚合的语句摘要信息。该表按 SCHEMA_NAME 和 DIGEST 组合对语句信息进行聚合。性能模式使用 SHA-256 哈希值进行聚合，因为它们计算速度快，并且具有有利的统计分布，可以最小化碰撞。参见第 29.12.20.3 节，“语句摘要表”。

一些性能表具有一个列，用于存储计算摘要的原始 SQL 语句：

events_statements_current，events_statements_history 和 events_statements_history_long 语句事件表的 SQL_TEXT 列。
events_statements_summary_by_digest 摘要表的 QUERY_SAMPLE_TEXT 列。

默认情况下，语句显示的最大空间为 1024 字节。要更改此值，请在服务器启动时设置 performance_schema_max_sql_text_length 系统变量。更改会影响所有上述列所需的存储空间。

performance_schema_max_digest_length 系统变量确定性能模式中用于摘要值存储的每个语句的最大字节数。然而，由于语句元素（如关键字和文字值）的内部编码，语句摘要的显示长度可能长于可用缓冲区大小。因此，从语句事件表的 DIGEST_TEXT 列中选择的值可能会超过 performance_schema_max_digest_length 的值。

events_statements_summary_by_digest 摘要表提供了服务器执行的语句的概要。它显示了应用程序执行的语句类型和频率。应用程序开发人员可以将此信息与表中的其他信息一起使用，评估应用程序的性能特征。例如，显示等待时间、锁定时间或索引使用的表列可能突出显示效率低下的查询类型。这使开发人员了解应用程序哪些部分需要关注。

events_statements_summary_by_digest 摘要表具有固定大小。默认情况下，性能模式在启动时估计要使用的大小。要明确指定表大小，请在服务器启动时设置 performance_schema_digests_size 系统变量。如果表变满，性能模式将具有 SCHEMA_NAME 和 DIGEST 值不匹配现有表中值的语句分组到一个特殊行中，该行的 SCHEMA_NAME 和 DIGEST 设置为 NULL。这允许计算所有语句。但是，如果特殊行占执行的语句的显著百分比，可能需要通过增加 performance_schema_digests_size 来增加摘要表大小。

语句摘要内存使用

对于生成仅在结尾处有所不同的非常长语句的应用程序，增加max_digest_length可以计算出区分否则会聚合到相同摘要的语句的摘要。相反，减少max_digest_length会导致服务器将更少的内存用于摘要存储，但增加较长语句聚合到相同摘要的可能性。管理员应牢记，较大的值会导致相应增加的内存需求，特别是对于涉及大量同时会话的工作负载（服务器为每个会话分配max_digest_length字节）。

如前所述，由解析器计算的规范化语句摘要受限于最多max_digest_length字节，而性能模式中存储的规范化语句摘要使用performance_schema_max_digest_length字节。关于max_digest_length和performance_schema_max_digest_length的相对值，以下内存使用考虑适用：

如果max_digest_length小于performance_schema_max_digest_length：
- 除了性能模式之外的服务器功能使用占用最多max_digest_length字节的规范化语句摘要。
- 性能模式不会进一步截断存储的规范化语句摘要，但为每个摘要分配比max_digest_length字节更多的内存，这是不必要的。
如果max_digest_length等于performance_schema_max_digest_length：
- 除了性能模式之外的服务器功能使用占用最多max_digest_length字节的规范化语句摘要。
- 性能模式不会进一步截断存储的规范化语句摘要，并为每个摘要分配与max_digest_length字节相同的内存。
如果max_digest_length大于performance_schema_max_digest_length：
- Performance Schema 之外的服务器功能使用占用max_digest_length字节的规范语句摘要。
- Performance Schema 进一步截断其存储的规范语句摘要，并为每个摘要分配少于max_digest_length字节的内存。

因为 Performance Schema 语句事件表可能存储许多摘要，所以将performance_schema_max_digest_length设置为小于max_digest_length使管理员能够平衡这些因素：

在 Performance Schema 之外的服务器功能需要长规范语句摘要
许多并发会话，每个会话分配摘要计算内存
在存储许多语句摘要时，需要限制 Performance Schema 语句事件表的内存消耗

performance_schema_max_digest_length设置不是每个会话，而是每个语句，一个会话可以在events_statements_history表中存储多个语句。在此表中的典型语句数量为每个会话 10 个，因此每个会话仅针对此表消耗了performance_schema_max_digest_length值所示的内存的 10 倍。

此外，全局收集了许多语句（和摘要），最显著的是在events_statements_history_long表中。在这里，存储的N语句消耗了N倍于performance_schema_max_digest_length值所示内存的内存。

要评估用于 SQL 语句存储和摘要计算的内存量，请使用SHOW ENGINE PERFORMANCE_SCHEMA STATUS语句，或监视这些指标：

mysql> SELECT NAME
       FROM performance_schema.setup_instruments
       WHERE NAME LIKE '%.sqltext';
+------------------------------------------------------------------+
| NAME                                                             |
+------------------------------------------------------------------+
| memory/performance_schema/events_statements_history.sqltext      |
| memory/performance_schema/events_statements_current.sqltext      |
| memory/performance_schema/events_statements_history_long.sqltext |
+------------------------------------------------------------------+

mysql> SELECT NAME
       FROM performance_schema.setup_instruments
       WHERE NAME LIKE 'memory/performance_schema/%.tokens';
+----------------------------------------------------------------------+
| NAME                                                                 |
+----------------------------------------------------------------------+
| memory/performance_schema/events_statements_history.tokens           |
| memory/performance_schema/events_statements_current.tokens           |
| memory/performance_schema/events_statements_summary_by_digest.tokens |
| memory/performance_schema/events_statements_history_long.tokens      |
+----------------------------------------------------------------------+

语句抽样

性能模式使用语句取样来收集在events_statements_summary_by_digest表中生成每个摘要值的代表性语句。这些列存储样本语句信息：QUERY_SAMPLE_TEXT（语句的文本），QUERY_SAMPLE_SEEN（语句被看到的时间）和QUERY_SAMPLE_TIMER_WAIT（语句等待或执行时间）。每次选择样本语句时，性能模式都会更新这三列。

当插入新表行时，生成行摘要值的语句将作为与摘要相关联的当前样本语句存储。此后，当服务器看到具有相同摘要值的其他语句时，它将确定是否使用新语句替换当前样本语句（即是否重新取样）。重新取样策略基于当前样本语句和新语句的比较等待时间，以及可选的当前样本语句的年龄：

基于等待时间的重新取样：如果新语句的等待时间大于当前样本语句的等待时间，则新语句将成为当前样本语句。
基于年龄的重新取样：如果performance_schema_max_digest_sample_age系统变量的值大于零，并且当前样本语句的年龄超过该秒数，则当前语句被视为“太旧”，新语句将替换它。即使新语句的等待时间小于当前样本语句的等待时间，也会发生这种情况。

默认情况下，performance_schema_max_digest_sample_age为 60 秒（1 分钟）。要更改样本语句由于年龄而“过期”的速度，增加或减少该值。要禁用基于年龄的重新取样策略的部分，请将performance_schema_max_digest_sample_age设置为 0。

29.11 性能模式通用表特性

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

performance_schema数据库的名称是小写的，其中的表名也是小写的。查询应该以小写指定名称。

performance_schema数据库中的许多表是只读的，不能被修改：

mysql> TRUNCATE TABLE performance_schema.setup_instruments;
ERROR 1683 (HY000): Invalid performance_schema usage.

一些设置表具有可以修改以影响性能模式操作的列；有些还允许插入或删除行。允许截断以清除收集的事件，因此可以在包含这些类型信息的表上使用TRUNCATE TABLE，例如以events_waits_为前缀命名的表。

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

权限与其他数据库和表相同：

要从performance_schema表中检索，您必须具有SELECT权限。
要更改可以修改的列，您必须具有UPDATE权限。
要截断可以截断的表，您必须具有DROP权限。

因为性能模式表只适用于有限的一组特权，尝试使用GRANT ALL作为在数据库或表级别授予权限的简写会导致错误：

mysql> GRANT ALL ON performance_schema.*
       TO 'u1'@'localhost';
ERROR 1044 (42000): Access denied for user 'root'@'localhost'
to database 'performance_schema'
mysql> GRANT ALL ON performance_schema.setup_instruments
       TO 'u2'@'localhost';
ERROR 1044 (42000): Access denied for user 'root'@'localhost'
to database 'performance_schema'

相反，授予确切所需的权限：

mysql> GRANT SELECT ON performance_schema.*
       TO 'u1'@'localhost';
Query OK, 0 rows affected (0.03 sec)

mysql> GRANT SELECT, UPDATE ON performance_schema.setup_instruments
       TO 'u2'@'localhost';
Query OK, 0 rows affected (0.02 sec)

29.12 性能模式表描述

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

29.12.1 性能模式表参考

29.12.2 性能模式设置表

29.12.3 性能模式实例表

29.12.4 性能模式等待事件表

29.12.5 性能模式阶段事件表

29.12.6 性能模式语句事件表

29.12.7 性能模式事务表

29.12.8 性能模式连接表

29.12.9 性能模式连接属性表

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

29.12.11 性能模式复制表

29.12.12 性能模式 NDB 集群表

29.12.13 性能模式锁表

29.12.14 性能模式系统变量表

29.12.15 性能模式状态变量表

29.12.16 性能模式线程池表

29.12.17 性能模式防火墙表

29.12.18 性能模式密钥环表

29.12.19 性能模式克隆表

29.12.20 性能模式摘要表

29.12.21 性能模式杂项表

performance_schema 数据库中的表可以分为以下几类：

设置表。这些表用于配置和显示监控特性。
当前事件表。events_waits_current 表包含每个线程的最新事件。其他类似的表包含不同层次事件的当前事件：events_stages_current 用于阶段事件，events_statements_current 用于语句事件，以及events_transactions_current 用于事务事件。
历史表。这些表与当前事件表具有相同的结构，但包含更多行。例如，对于等待事件，events_waits_history 表包含每个线程的最新 10 个事件。events_waits_history_long 包含最近的 10,000 个事件。其他类似的表存在于阶段、语句和事务历史中。

要更改历史表的大小，请在服务器启动时设置适当的系统变量。例如，要设置等待事件历史表的大小，请设置performance_schema_events_waits_history_size 和performance_schema_events_waits_history_long_size。
汇总表。这些表包含对事件组进行聚合的信息，包括已从历史表中丢弃的事件。
实例表。这些表记录了被检测对象的类型。当服务器使用被检测对象时，会产生一个事件。这些表提供事件名称、解释说明或状态信息。
杂项表。这些表不属于任何其他表组。

29.12.1 性能模式表参考

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

以下表格总结了所有可用的性能模式表。更详细的信息，请参阅各个表的描述。

表 29.1 性能模式表

表名	描述	引入版本
`accounts`	每个客户端账户的连接统计
`binary_log_transaction_compression_stats`	二进制日志事务压缩	8.0.20
`clone_progress`	克隆操作进度	8.0.17
`clone_status`	克隆操作状态	8.0.17
`component_scheduler_tasks`	计划任务的状态	8.0.34
`cond_instances`	同步对象实例
`data_lock_waits`	数据锁等待关系
`data_locks`	持有和请求的数据锁
`error_log`	服务器错误日志最近条目	8.0.22
`events_errors_summary_by_account_by_error`	每个账户和错误代码的错误
`events_errors_summary_by_host_by_error`	每个主机和错误代码的错误
`events_errors_summary_by_thread_by_error`	每个线程和错误代码的错误
`events_errors_summary_by_user_by_error`	每个用户和错误代码的错误
`events_errors_summary_global_by_error`	每个错误代码的错误
`events_stages_current`	当前阶段事件
`events_stages_history`	每个线程的最近阶段事件
`events_stages_history_long`	最近的整体阶段事件
`events_stages_summary_by_account_by_event_name`	每个帐户和事件名称的阶段事件
`events_stages_summary_by_host_by_event_name`	每个主机名称和事件名称的阶段事件
`events_stages_summary_by_thread_by_event_name`	每个线程和事件名称的阶段等待
`events_stages_summary_by_user_by_event_name`	每个用户名称和事件名称的阶段事件
`events_stages_summary_global_by_event_name`	每个事件名称的阶段等待
`events_statements_current`	当前语句事件
`events_statements_histogram_by_digest`	每个模式和摘要值的语句直方图
`events_statements_histogram_global`	全局汇总的语句直方图
`events_statements_history`	每个线程的最近语句事件
`events_statements_history_long`	最近的整体语句事件
`events_statements_summary_by_account_by_event_name`	每个帐户和事件名称的语句事件
`events_statements_summary_by_digest`	每个模式和摘要值的语句事件
`events_statements_summary_by_host_by_event_name`	每个主机名称和事件名称的语句事件
`events_statements_summary_by_program`	每个存储程序的语句事件
`events_statements_summary_by_thread_by_event_name`	每个线程和事件名称的语句事件
`events_statements_summary_by_user_by_event_name`	每个用户名称和事件名称的语句事件
`events_statements_summary_global_by_event_name`	每个事件名称的语句事件
`events_transactions_current`	当前事务事件
`events_transactions_history`	每个线程的最近事务事件
`events_transactions_history_long`	最近的所有事务事件
`events_transactions_summary_by_account_by_event_name`	每个帐户和事件名称的事务事件
`events_transactions_summary_by_host_by_event_name`	每个主机名称和事件名称的事务事件
`events_transactions_summary_by_thread_by_event_name`	每个线程和事件名称的事务事件
`events_transactions_summary_by_user_by_event_name`	每个用户名称和事件名称的事务事件
`events_transactions_summary_global_by_event_name`	每个事件名称的事务事件
`events_waits_current`	当前等待事件
`events_waits_history`	每个线程的最近等待事件
`events_waits_history_long`	最近的所有等待事件
`events_waits_summary_by_account_by_event_name`	每个帐户和事件名称的等待事件
`events_waits_summary_by_host_by_event_name`	每个主机名称和事件名称的等待事件
`events_waits_summary_by_instance`	每个实例的等待事件
`events_waits_summary_by_thread_by_event_name`	按线程和事件名称的等待事件
`events_waits_summary_by_user_by_event_name`	按用户名称和事件名称的等待事件
`events_waits_summary_global_by_event_name`	按事件名称的等待事件
`file_instances`	文件实例
`file_summary_by_event_name`	按事件名称的文件事件
`file_summary_by_instance`	按文件实例的文件事件
`firewall_group_allowlist`	组配置允许列表的防火墙内存数据	8.0.23
`firewall_groups`	组配置的防火墙内存数据	8.0.23
`firewall_membership`	组配置成员的防火墙内存数据	8.0.23
`global_status`	全局状态变量
`global_variables`	全局系统变量
`host_cache`	内部主机缓存的信息
`hosts`	每个客户端主机名称的连接统计
`keyring_component_status`	已安装密钥环组件的状态信息	8.0.24
`keyring_keys`	密钥环键的元数据	8.0.16
`log_status`	用于备份目的的服务器日志信息
`memory_summary_by_account_by_event_name`	按账户和事件名称的内存操作
`memory_summary_by_host_by_event_name`	按主机和事件名称的内存操作
`memory_summary_by_thread_by_event_name`	按线程和事件名称内存操作
`memory_summary_by_user_by_event_name`	按用户和事件名称内存操作
`memory_summary_global_by_event_name`	按事件名称全局内存操作
`metadata_locks`	元数据锁和锁请求
`mutex_instances`	互斥同步对象实例
`ndb_sync_excluded_objects`	无法同步的 NDB 对象	8.0.21
`ndb_sync_pending_objects`	等待同步的 NDB 对象	8.0.21
`objects_summary_global_by_type`	对象摘要
`performance_timers`	可用的事件计时器
`persisted_variables`	mysqld-auto.cnf 文件的内容
`prepared_statements_instances`	准备语句实例和统计信息
`processlist`	进程列表信息	8.0.22
`replication_applier_configuration`	复制应用程序在副本上的配置参数
`replication_applier_filters`	当前副本上的通道特定复制过滤器
`replication_applier_global_filters`	当前副本上的全局复制过滤器
`replication_applier_status`	复制应用程序在副本上的当前状态
`replication_applier_status_by_coordinator`	SQL 或协调器线程应用程序状态
`replication_applier_status_by_worker`	工作线程应用程序状态
`replication_asynchronous_connection_failover`	异步连接故障转移机制的源列表	8.0.22
`replication_asynchronous_connection_failover_managed`	异步连接故障转移机制的受控源列表	8.0.23
`replication_connection_configuration`	连接到源的配置参数
`replication_connection_status`	与源的当前连接状态
`replication_group_communication_information`	复制组配置选项	8.0.27
`replication_group_member_stats`	复制组成员统计信息
`replication_group_members`	复制组成员网络和状态
`rwlock_instances`	锁同步对象实例
`session_account_connect_attrs`	当前会话的连接属性
`session_connect_attrs`	所有会话的连接属性
`session_status`	当前会话的状态变量
`session_variables`	当前会话的系统变量
`setup_actors`	如何为新前台线程初始化监视
`setup_consumers`	可存储事件信息的消费者
`setup_instruments`	可收集事件的已标记对象类别
`setup_objects`	应监视的对象
`setup_threads`	已标记线程名称和属性
`socket_instances`	活动连接实例
`socket_summary_by_event_name`	按事件名称的套接字等待和 I/O
`socket_summary_by_instance`	按实例的套接字等待和 I/O
`status_by_account`	每个账户的会话状态变量
`status_by_host`	每个主机名的会话状态变量
`status_by_thread`	每个会话的会话状态变量
`status_by_user`	每个用户名的会话状态变量
`table_handles`	表锁和锁请求
`table_io_waits_summary_by_index_usage`	按索引使用情况的表 I/O 等待
`table_io_waits_summary_by_table`	按表的表 I/O 等待
`table_lock_waits_summary_by_table`	按表的表锁等待
`threads`	服务器线程信息
`tls_channel_status`	每个连接接口的 TLS 状态	8.0.21
`tp_thread_group_state`	线程池线程组状态	8.0.14
`tp_thread_group_stats`	线程池线程组统计信息	8.0.14
`tp_thread_state`	线程池线程信息	8.0.14
`user_defined_functions`	注册的可加载函数
`user_variables_by_thread`	每个线程的用户定义变量
`users`	每个客户端用户名的连接统计
`variables_by_thread`	每个会话的会话系统变量
`variables_info`	最近设置的系统变量
表名	描述	引入版本

29.12.2 性能模式设置表

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

29.12.2.1 设置演员表

29.12.2.2 设置消费者表

29.12.2.3 设置仪器表

29.12.2.4 设置对象表

29.12.2.5 设置线程表

设置表提供有关当前仪表化的信息，并允许更改监视配置。因此，如果您拥有UPDATE权限，则可以更改这些表中的某些列。

使用表而不是单个变量来存储设置信息，在修改性能模式配置方面提供了高度的灵活性。例如，您可以使用标准 SQL 语法的单个语句进行多个同时配置更改。

可用的设置表包括：

setup_actors：如何为新的前台线程初始化监视
setup_consumers：可以发送和存储事件信息的目的地
setup_instruments：可以收集事件的被检测对象的类别
setup_objects：应该监视哪些对象
setup_threads：被检测线程的名称和属性

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

29.12.2.1 设置 _actors 表

setup_actors表包含确定是否为新的前台服务器线程（与客户端连接关联的线程）启用监视和历史事件记录的信息。默认情况下，此表的最大大小为 100 行。要更改表大小，请在服务器启动时修改performance_schema_setup_actors_size系统变量。

对于每个新的前台线程，性能模式将线程的用户和主机与setup_actors表的行进行匹配。如果该表中的行匹配，则使用其ENABLED和HISTORY列值来设置线程的threads行的INSTRUMENTED和HISTORY列，分别。这使得可以根据主机、用户或帐户（用户和主机组合）有选择地应用仪器化和历史事件记录。如果没有匹配，则线程的INSTRUMENTED和HISTORY列设置为NO。

对于后台线程，没有关联的用户。INSTRUMENTED和HISTORY默认为YES，并且不会查询setup_actors。

setup_actors表的初始内容匹配任何用户和主机组合，因此默认情况下为所有前台线程启用监视和历史事件收集：

mysql> SELECT * FROM performance_schema.setup_actors;
+------+------+------+---------+---------+
| HOST | USER | ROLE | ENABLED | HISTORY |
+------+------+------+---------+---------+
| %    | %    | %    | YES     | YES     |
+------+------+------+---------+---------+

有关如何使用setup_actors表影响事件监视的信息，请参见第 29.4.6 节，“按线程进行预过滤”。

对setup_actors表的修改仅影响在修改后创建的前台线程，而不影响现有线程。要影响现有线程，请修改threads表行的INSTRUMENTED和HISTORY列。

setup_actors表具有以下列：

主机

主机名。这应该是一个字面名称，或者'%'表示“任何主机”。
用户

用户名。这应该是一个字面名称，或者'%'表示“任何用户”。
角色

未使用。
启用

是否为与行匹配的前台线程启用仪表化。该值为YES或NO。
HISTORY

是否记录与行匹配的前台线程的历史事件。该值为YES或NO。

setup_actors表具有以下索引：

主键为(HOST, USER, ROLE)

允许对setup_actors表执行TRUNCATE TABLE语句。它会删除行。

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

会员力量，点亮园子希望

刷新页面返回顶部

龙哥盟

掠夺·扩张·投机·博弈

MySQL8-中文参考-四十七-

MySQL8 中文参考（四十七）

28.4.4 INFORMATION_SCHEMA INNODB_BUFFER_POOL_STATS 表

示例。

注意事项。

28.4.5 INFORMATION_SCHEMA INNODB_CACHED_INDEXES 表

示例

注意

28.4.6 INFORMATION_SCHEMA INNODB_CMP 和 INNODB_CMP_RESET 表

示例

注意

28.4.7 INFORMATION_SCHEMA INNODB_CMPMEM 和 INNODB_CMPMEM_RESET 表

示例

注意

28.4.8 The INFORMATION_SCHEMA INNODB_CMP_PER_INDEX and INNODB_CMP_PER_INDEX_RESET Tables

示例

注意事项

28.4.9 INFORMATION_SCHEMA INNODB_COLUMNS 表

示例

注意事项

28.4.10 The INFORMATION_SCHEMA INNODB_DATAFILES Table

示例

注意

28.4.11 INFORMATION_SCHEMA INNODB_FIELDS 表

示例

注意事项

28.4.12 INFORMATION_SCHEMA INNODB_FOREIGN 表

示例

注意

28.4.13 INFORMATION_SCHEMA INNODB_FOREIGN_COLS 表

示例

注意

28.4.14 INNODB_FT_BEING_DELETED 表

注意

28.4.15 INFORMATION_SCHEMA INNODB_FT_CONFIG 表

示例

注意

28.4.16 INFORMATION_SCHEMA INNODB_FT_DEFAULT_STOPWORD 表

示例

注意

28.4.17 INFORMATION_SCHEMA INNODB_FT_DELETED 表

示例

注意

28.4.18 INFORMATION_SCHEMA INNODB_FT_INDEX_CACHE 表

注意

28.4.19 INFORMATION_SCHEMA INNODB_FT_INDEX_TABLE 表

注意事项

28.4.20 The INFORMATION_SCHEMA INNODB_INDEXES Table

示例

注意

28.4.21 INFORMATION_SCHEMA INNODB_METRICS 表

示例

笔记

28.4.22 The INFORMATION_SCHEMA INNODB_SESSION_TEMP_TABLESPACES Table

示例

注意

28.4.23 INFORMATION_SCHEMA INNODB_TABLES 表

示例

注意

28.4.24 INFORMATION_SCHEMA INNODB_TABLESPACES 表

示例

注意

28.4.25 The INFORMATION_SCHEMA INNODB_TABLESPACES_BRIEF Table

示例

笔记

28.4.26 INFORMATION_SCHEMA INNODB_TABLESTATS 视图

示例

注意

28.4.27 INFORMATION_SCHEMA INNODB_TEMP_TABLE_INFO 表

示例

注意

28.4.28 INFORMATION_SCHEMA INNODB_TRX 表

示例

注意事项

28.4.29 INFORMATION_SCHEMA INNODB_VIRTUAL 表

示例

注意

28.5 INFORMATION_SCHEMA 线程池表

28.4.13 `INFORMATION_SCHEMA` `INNODB_FOREIGN_COLS` 表

28.4.24 `INFORMATION_SCHEMA INNODB_TABLESPACES` 表

28.5.4 `INFORMATION_SCHEMA TP_THREAD_STATE` 表

28.8 `SHOW` 语句的扩展