第26章MySQL性能架构

目录

26.1性能架构快速入门
26.2性能架构构建配置
26.3性能模式启动配置
26.4性能模式运行时配置
26.4.1性能模式事件时序
26.4.2性能模式事件过滤
26.4.3事件预过滤
26.4.4按仪器预过滤
26.4.5按对象预过滤
26.4.6按线程预过滤
26.4.7消费者预过滤
26.4.8消费者配置示例
26.4.9命名仪器或消费者进行过滤操作
26.4.10确定仪器的内容
26.5性能模式查询
26.6性能架构仪器命名约定
26.7性能模式状态监控
26.8性能模式原子和分子事件
26.9当前和历史事件的性能模式表
26.10性能模式语句摘要和抽样
26.11性能模式通用表特性
26.12性能架构表描述
26.12.1性能模式表索引
26.12.2性能模式设置表
26.12.3性能模式实例表
26.12.4性能模式等待事件表
26.12.5性能模式阶段事件表
26.12.6性能模式语句事件表
26.12.7性能模式事务表
26.12.8性能模式连接表
26.12.9性能模式连接属性表
26.12.10性能模式用户定义的变量表
26.12.11性能模式复制表
26.12.12性能模式锁表
26.12.13性能模式系统变量表
26.12.14性能模式状态变量表
26.12.15性能架构线程池表
26.12.16性能模式摘要表
26.12.17性能模式其他表
26.13性能模式选项和变量参考
26.14性能模式命令选项
26.15性能模式系统变量
26.16性能模式状态变量
26.17性能模式内存分配模型
26.18性能架构和插件
26.19使用性能模式诊断问题
26.19.1使用性能模式进行查询分析
26.19.2获取父事件信息

MySQL性能模式是一种用于监视低级别MySQL服务器执行的功能。 性能模式具有以下特征:

性能模式旨在提供对服务器执行的有用信息的访问,同时对服务器性能的影响最小。 实现遵循以下设计目标:

注意

MySQL sys 模式是一组对象,可以方便地访问性能模式收集的数据。 sys 模式是默认安装的。 有关使用说明,请参见 第27章, MySQL sys Schema

26.1性能架构快速入门

本节简要介绍了性能模式,并提供了说明如何使用它的示例。 有关其他示例,请参见 第26.19节“使用性能模式诊断问题”

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

的[mysqld]
performance_schema = ON

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

MySQL的> SHOW VARIABLES LIKE 'performance_schema';
+ -------------------- + ------- +
| Variable_name | 价值|
+ -------------------- + ------- +
| performance_schema | ON |
+ -------------------- + ------- +

ON 表示性能模式已成功初始化并可供使用。 OFF 表示发生了一些错误。 检查服务器错误日志以获取有关错误的信息。

性能模式是作为存储引擎实现的,因此您将在 INFORMATION_SCHEMA.ENGINES 表或 SHOW ENGINES 语句 的输出中看到它

MySQL的> SELECT * FROM INFORMATION_SCHEMA.ENGINES
       WHERE ENGINE='PERFORMANCE_SCHEMA'\G
*************************** 1。排******************** *******
      ENGINE:PERFORMANCE_SCHEMA
     支持:是的
     评论:性能模式
交易:没有
          XA:没有
  SAVEPOINTS:没有

MySQL的> SHOW ENGINES\G
...
      引擎:PERFORMANCE_SCHEMA
     支持:是的
     评论:性能架构
交易:NO
          XA:没有
  保存点:没有
...

PERFORMANCE_SCHEMA 存储引擎上的表进行操作 performance_schema 数据库。 您可以创建 performance_schema 默认数据库,以便不需要使用数据库名称限定对其表的引用:

MySQL的> USE performance_schema;

性能模式表存储在 performance_schema 数据库中。 通过从 INFORMATION_SCHEMA 数据库中 选择 或使用 SHOW 语句 ,可以获得有关此数据库及其表的结构的信息,就像任何其他数据库一样 例如,使用以下任一语句来查看存在哪些Performance Schema表:

MySQL的> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
       WHERE TABLE_SCHEMA = 'performance_schema';
+ ------------------------------------------------- ----- +
| TABLE_NAME |
+ ------------------------------------------------- ----- +
| 帐户|
| 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 |
| 主持人|
| 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 |
| 线程|
| 用户|
+ ------------------------------------------------- ----- +

MySQL的> SHOW TABLES FROM performance_schema;
+ ------------------------------------------------- ----- +
| Tables_in_performance_schema |
+ ------------------------------------------------- ----- +
| 帐户|
| 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。排******************** *******
       表:setup_consumers
创建表:CREATE TABLE`setup_consumers`(
  `NAME` varchar(64)NOT NULL,
  `ENABLED`枚举('YES','NO')NOT NULL,
  主键(`NAME`)
)ENGINE = PERFORMANCE_SCHEMA DEFAULT CHARSET = utf8mb4 COLLATE = utf8mb4_0900_ai_ci

表结构也可以从表中选择,例如 INFORMATION_SCHEMA.COLUMNS 使用或使用语句 SHOW COLUMNS

performance_schema 数据库中的 可以根据其中的信息类型进行分组:当前事件,事件历史和摘要,对象实例和设置(配置)信息。 以下示例说明了这些表的一些用法。 有关每个组中表的详细信息,请参见 第26.12节“性能架构表描述”

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

MySQL的> UPDATE performance_schema.setup_instruments
       SET ENABLED = 'YES', TIMED = 'YES';
查询OK,560行受影响(0.04秒)
MySQL的> UPDATE performance_schema.setup_consumers
       SET ENABLED = 'YES';
查询OK,10行受影响(0.00秒)

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

MySQL的> SELECT *
       FROM performance_schema.events_waits_current\G
*************************** 1。排******************** *******
            THREAD_ID:0
             EVENT_ID:5523
         END_EVENT_ID:5523
           EVENT_NAME:wait / synch / mutex / mysys / THR_LOCK :: mutex
               消息来源: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
            操作:锁定
      NUMBER_OF_BYTES:空
                标志:0
...

此事件表示线程0正在等待86,526皮秒来获取锁定 THR_LOCK::mutex ,即 mysys 子系统中 的互斥锁 前几列提供以下信息:

  • ID列指示事件来自哪个线程以及事件编号。

  • EVENT_NAME 指示已检测的内容并 SOURCE 指示哪个源文件包含已检测的代码。

  • 计时器列显示事件开始和停止的时间以及花费的时间。 如果一个事件仍在进行中,在 TIMER_END TIMER_WAIT NULL 定时器值是近似值,以皮秒表示。 有关定时器和事件时间收集的信息,请参见 第26.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 |
+ ---------- + -------------------------------------- --- + ------------ +

当新事件添加到历史记录表时,如果表已满,则会丢弃旧事件。

摘要表提供了一段时间内所有事件的汇总信息。 该组中的表以不同方式汇总事件数据。 要查看哪些工具执行次数最多或者等待时间最长,请 events_waits_summary_global_by_event_name COUNT_STAR or或 SUM_TIMER_WAIT 上的表进行 排序,这些 分别对应于 所有事件计算的 a 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。排******************** *******
 FILE_NAME:/opt/mysql-log/60500/binlog.000007
EVENT_NAME:wait / io / file / sql / binlog
OPEN_COUNT:0
*************************** 2.排******************** *******
 FILE_NAME:/opt/mysql/60500/data/mysql/tables_priv.MYI
EVENT_NAME:wait / io / file / myisam / kfile
OPEN_COUNT:1
*************************** 3。排******************** *******
 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 | 启用| 定时|
+ ------------------------------------------------- -  + --------- + ------- +
...
| stage / sql / end | 没有| 没有|
| stage / sql / execution | 没有| 没有|
| stage / sql / init | 没有| 没有|
| stage / sql / insert | 没有| 没有|
...
| statement / sql / load | 是的| 是的|
| statement / sql / grant | 是的| 是的|
| statement / sql / check | 是的| 是的|
| statement / sql / flush | 是的| 是的|
...
| wait / synch / mutex / sql / LOCK_global_read_lock | 是的| 是的|
| wait / synch / mutex / sql / LOCK_global_system_variables | 是的| 是的|
| wait / synch / mutex / sql / LOCK_lock_db | 是的| 是的|
| wait / synch / mutex / sql / LOCK_manager | 是的| 是的|
...
| wait / synch / rwlock / sql / LOCK_grant | 是的| 是的|
| wait / synch / rwlock / sql / LOGGER :: LOCK_logger | 是的| 是的|
| wait / synch / rwlock / sql / LOCK_sys_init_connect | 是的| 是的|
| wait / synch / rwlock / sql / LOCK_sys_init_slave | 是的| 是的|
...
| wait / io / file / sql / binlog | 是的| 是的|
| wait / io / file / sql / binlog_index | 是的| 是的|
| wait / io / file / sql / casetest | 是的| 是的|
| wait / io / file / sql / dbopt | 是的| 是的|
...

要了解如何解释仪器名称,请参见 第26.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 | 启用|
+ ---------------------------------- + --------- +
| 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 | 没有|
| events_waits_current | 没有|
| events_waits_history | 没有|
| events_waits_history_long | 没有|
| global_instrumentation | 是的|
| thread_instrumentation | 是的|
| statements_digest | 是的|
+ ---------------------------------- + --------- +

要控制性能模式是否将使用者维护为事件信息的目标,请设置其 ENABLED 值。

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

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

26.2性能架构构建配置

性能模式是强制性的,并且始终在其中编译。可以排除性能模式检测的某些部分。 例如,要排除阶段和语句检测,请执行以下操作:

外壳> cmake . \
        -DDISABLE_PSI_STAGE=1 \
        -DDISABLE_PSI_STATEMENT=1

有关更多信息,请参见 第2.9.4节“MySQL源配置选项” 中的 CMake 选项 说明 DISABLE_PSI_XXX

如果您在先前安装的情况下安装MySQL,而该安装是在没有性能架构的情况下配置的(或者是具有缺失或过时表的旧版本的性能架构)。 此问题的一个指示是错误日志中存在以下消息:

[错误]原生表'performance_schema'。'events_waits_history'
有错误的结构
[错误]原生表'performance_schema'。'events_waits_history_long'
有错误的结构
...

要解决该问题,请执行MySQL升级过程。 请参见 第2.11节“升级MySQL”

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

26.3性能模式启动配置

要使用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-架构仪器= '等待/同步/ COND /%=计数'

要禁用所有仪器,请使用此选项:

--performance-架构仪器= '(%)= OFF'

例外: memory/performance_schema/% 仪器内置,启动时无法禁用。

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

无法识别的仪器名称将被忽略。 稍后安装的插件可能会创建仪器,此时可以识别和配置名称。

要在服务器启动时控制使用者,请使用以下形式的选项:

--performance-schema-consumer- consumer_name=value

这里 consumer_name 是消费者名称,例如 events_waits_history ,并且 value 是以下值之一:

  • OFF ,, FALSE 0 :不要为消费者收集活动

  • ON ,, TRUE 1 :为消费者收集事件

例如,要启用 events_waits_history 使用者,请使用以下选项:

--performance-架构消费者的事件,等待历史= ON

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

性能模式包括几个提供配置信息的系统变量:

MySQL的> SHOW VARIABLES LIKE 'perf%';
+ ------------------------------------------------- ------- + --------- +
| Variable_name | 价值|
+ ------------------------------------------------- ------- + --------- +
| 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 指示是启用还是禁用性能架构。 其他变量表示表大小(行数)或内存分配值。

注意

启用性能模式后,性能模式实例的数量可能会在很大程度上影响服务器内存占用。 性能模式自动调整许多参数以仅在需要时使用内存; 请参见 第26.17节“性能模式内存分配模型”

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

的[mysqld]
performance_schema
performance_schema_events_waits_history_size = 20
performance_schema_events_waits_history_long_size = 15000

如果未明确设置性能模式,则性能模式会在服务器启动时自动调整其几个参数的值。 例如,它通过这种方式调整控制事件大小的参数。 性能模式以递增方式分配内存,将其内存使用量扩展到实际服务器负载,而不是在服务器启动期间分配所需的所有内存。 因此,根本不需要设置许多尺寸参数。 要查看哪些参数是自动调整大小或自动调整的,请使用 mysqld --verbose --help 并检查选项描述,或参见 第26.15节“性能架构系统变量”

对于未在服务器启动时设置的每个自动调整参数,性能模式将根据以下系统值的值确定如何设置其值,这些值被视为 有关如何配置MySQL服务器的 提示

MAX_CONNECTIONS
open_files_limit
table_definition_cache
table_open_cache

要覆盖给定参数的自动调整大小或自动调节,请在启动时将其设置为-1以外的值。 在这种情况下,性能模式为其分配指定的值。

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

如果禁用了性能模式,则其自动调整和自动调整的参数将保持设置为-1并 SHOW VARIABLES 显示-1。

26.4性能模式运行时配置

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

性能架构设置表包含有关监视配置的信息:

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 权限,则可以通过修改设置表来更改性能模式操作,以影响监视的发生方式。 有关这些表的其他详细信息,请参见 第26.12.2节“性能架构设置表”

setup_instruments setup_consumers 表列出可以收集该事件的手段和类型哪个事件信息实际上被收集,分别消费者。 其他设置表可以进一步修改监视配置。 第26.4.2节“性能模式事件过滤” 讨论了如何修改这些表以影响事件收集。

如果必须在运行时使用SQL语句进行性能模式配置更改,并且您希望每次服务器启动时这些更改生效,请将语句放在文件中并使用该 选项 启动服务器 如果您有多个监视配置,每个监视配置都可以生成不同类型的监视,例如临时服务器运行状况监视,事件调查,应用程序行为故障排除等,则此策略也很有用。 将每个监视配置的语句放入它们自己的文件中,并 在启动服务器时 将相应的文件指定为 参数。 --init-file=file_name --init-file

26.4.1性能模式事件时序

通过添加到服务器源代码的检测来收集事件。 仪器时间事件,这是性能模式提供事件所需时间的概念。 还可以配置仪器不收集定时信息。 本节讨论可用的计时器及其特征,以及如何在事件中表示计时值。

性能模式定时器

性能模式定时器的精度和开销量各不相同。 要查看可用的计时器及其特性,请查看 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 |
+ ------------- + ----------------- + ----------------- -  + ---------------- +

如果与给定计时器名称关联的值为 NULL ,则您的平台不支持该计时器。

这些列具有以下含义:

  • TIMER_NAME 列显示可用计时器的名称。 CYCLE 指的是基于CPU(处理器)周期计数器的计时器。

  • TIMER_FREQUENCY 表示每秒的计时器单位数。 对于循环定时器,频率通常与CPU速度有关。 显示的值是在具有2.4GHz处理器的系统上获得的。 其他计时器基于固定的秒数。

  • TIMER_RESOLUTION 表示定时器值一次增加的定时器单位数。 如果计时器的分辨率为10,则其值每次增加10。

  • TIMER_OVERHEAD 是给定定时器获得一个定时的最小开销周期数。 每个事件的开销是显示值的两倍,因为在事件的开始和结束时调用了计时器。

Performance Schema按如下方式分配定时器:

  • 等待计时器使用 CYCLE

  • 空闲,阶段,语句和事务计时器 NANOSECOND NANOSECOND 计时器可用的 平台上 使用, MICROSECOND 否则使用。

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

对于等待事件的时间,最重要的标准是减少开销,可能以定时器精度为代价,因此使用 CYCLE 定时器是最好的。

语句(或阶段)执行所花费的时间通常比执行单个等待所花费的时间大几个数量级。 对于时间陈述,最重要的标准是准确度量,不受处理器频率变化的影响,因此使用不基于周期的定时器是最好的。 语句的默认计时器是 NANOSECOND 额外的 开销 与之相比 CYCLE 计时器并不重要,因为调用计时器两次(一旦语句启动时,一次结束时)所产生的开销与用于执行语句本身的CPU时间相比要小几个数量级。 使用 CYCLE 计时器在这里没有任何好处,只有缺点。

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

循环计数器也有缺点:

  • 最终用户希望看到挂钟单位的时间,例如几分之一秒。 从周期转换为几分之一秒可能很昂贵。 因此,转换是一种快速且相当粗略的乘法运算。

  • 处理器循环速率可能会发生变化,例如当笔记本电脑进入省电模式或CPU减速以减少热量产生时。 如果处理器的循环速率波动,则从循环到实时单位的转换会出错。

  • 根据处理器或操作系统的不同,循环计数器可能不可靠或不可用。 例如,在Pentiums上,指令是 RDTSC (汇编语言而不是C指令),理论上操作系统可以阻止用户模式程序使用它。

  • 与乱序执行或多处理器同步相关的某些处理器详细信息可能会使计数器看起来快或慢达1000个周期。

MySQL适用于x386(Windows,macOS,Linux,Solaris和其他Unix版本),PowerPC和IA-64上的循环计数器。

事件中的性能模式定时器表示

在性能模式中的表行存储时事和历史事件有三列表示定时信息 TIMER_START TIMER_END 指示当事件开始和结束,并 TIMER_WAIT 表示事件持续时间。

setup_instruments 表有一 ENABLED 列表示要收集事件的工具。 该表还有一 TIMED 列表明哪些工具是定时的。 如果未启用仪器,则不会生成任何事件。 如果启用了仪器不能定时,通过仪器产生的事件都 NULL TIMER_START TIMER_END TIMER_WAIT 定时器的值。 这反过来会导致在汇总表(总和,最小值,最大值和平均值)中计算汇总时间值时忽略这些值。

在内部,事件内的时间以事件计时开始时有效的计时器给出的单位存储。 对于从性能模式表中检索事件时的显示,无论选择哪个计时器,时间都以皮秒(万亿分之一秒)显示,以将它们标准化为标准单位。

计时器基线( 时间零 )发生在服务器启动期间的性能架构初始化中。 TIMER_START TIMER_END 在活动值表示自基线皮秒。 TIMER_WAIT 值是以皮秒为单位的持续时间。

事件中的皮秒值是近似值。 它们的准确性取决于从一个单元转换到另一个单元的常见错误形式。 如果使用 CYCLE 定时器并且处理器速率变化,则可能存在漂移。 由于这些原因, TIMER_START 将事件 值视为自服务器启动以来经过的时间的准确度量 是不合理的 另一方面, 条款中 使用 TIMER_START TIMER_WAIT 来合理 ORDER BY 按开始时间或持续时间排序事件 是合理的

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

在执行wait,stage,statement或transaction事件时,相应的当前事件表显示当前事件时序信息:

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是NULL和TIMER_WAIT> N

刚刚描述的事件识别假设相应的仪器具有 ENABLED TIMED 设置为 YES 并且相关的消费者被启用。

26.4.2性能模式事件过滤

事件以生产者/消费者方式处理:

  • 检测代码是事件的来源,并产生要收集的事件。 setup_instruments 表列出了可以收集事件的工具,是否已启用,以及(对于已启用的工具)是否收集时间信息:

    MySQL的> SELECT NAME, ENABLED, TIMED
           FROM performance_schema.setup_instruments;
    + ------------------------------------------------- -  + --------- + ------- +
    | NAME | 启用| 定时|
    + ------------------------------------------------- -  + --------- + ------- +
    ...
    | wait / synch / mutex / sql / LOCK_global_read_lock | 是的| 是的|
    | wait / synch / mutex / sql / LOCK_global_system_variables | 是的| 是的|
    | wait / synch / mutex / sql / LOCK_lock_db | 是的| 是的|
    | wait / synch / mutex / sql / LOCK_manager | 是的| 是的|
    ...
    

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

  • 性能架构表是事件和消耗事件的目标。 setup_consumers 表列出了可以向其发送事件信息的消费者类型以及是否已启用它们:

    MySQL的> SELECT * FROM performance_schema.setup_consumers;
    + ---------------------------------- + --------- +
    | NAME | 启用|
    + ---------------------------------- + --------- +
    | 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 | 没有|
    | events_waits_current | 没有|
    | events_waits_history | 没有|
    | events_waits_history_long | 没有|
    | global_instrumentation | 是的|
    | thread_instrumentation | 是的|
    | statements_digest | 是的|
    + ---------------------------------- + --------- +
    

过滤可以在性能监控的不同阶段完成:

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

    使用预过滤的原因:

    • 减少开销。 即使启用了所有仪器,性能模式开销也应该很小,但也许您希望进一步降低它。 或者您不关心时序事件,并希望禁用时序代码以消除时序开销。

    • 避免使用您不感兴趣的事件填充当前事件或历史记录表。 对于已启用的仪器类型, 预过滤会 在这些表中 留出更多 空间 用于行的实例。 如果仅启用具有预过滤功能的文件工具,则不会为非文件工具收集任何行。 通过后过滤,可以收集非文件事件,从而为文件事件留下更少的行。

    • 避免维护某些事件表。 如果禁用使用者,则服务器不会花时间维护该使用者的目标。 例如,如果您不关心事件历史记录,则可以禁用历史记录表使用者以提高性能。

  • 后过滤。  这涉及在 WHERE 从Performance Schema表中选择信息的查询中 使用 子句,以指定要查看的可用事件。 后过滤是基于每个用户执行的,因为各个用户选择感兴趣的哪些可用事件。

    使用后过滤的原因:

    • 避免为个别用户决定感兴趣的事件信息。

    • 在预先不知道使用预过滤的限制时,使用性能模式来调查性能问题。

以下部分提供了有关预过滤的更多详细信息,并为过滤操作中的命名工具或使用者提供了指导。 有关编写查询以检索信息(过滤后)的信息,请参见 第26.5节“性能模式查询”

26.4.3事件预过滤

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

  • 要在生产者阶段配置预过滤,可以使用几个表:

    • setup_instruments 表示哪些仪器可用。 无论其他与生产相关的设置表的内容如何,​​此表中禁用的工具都不会生成任何事件。 允许在此表中启用的工具根据其他表的内容生成事件。

    • setup_objects 控制性能模式是否监视特定表和存储的程序对象。

    • threads 指示是否为每个服务器线程启用监视。

    • setup_actors 确定新前台线程的初始监视状态。

  • 要在使用者阶段配置预过滤,请修改该 setup_consumers 表。 这确定了发送事件的目的地。 setup_consumers 也隐含地影响事件的产生。 如果给定事件不会发送到任何目标(即,不会被使用),则性能模式不会生成它。

对这些表的任何修改都会立即影响监视,但对 setup_actors 表的 修改 仅影响修改后创建的前台线程,而不影响现有线程。

更改监视配置时,性能架构不会刷新历史记录表。 已收集的事件将保留在当前事件和历史记录表中,直到被新事件取代。 如果您禁用乐器,您可能需要等待一段时间,然后才能通过感兴趣的新事件取代它们。 或者,用于 TRUNCATE TABLE 清空历史表。

进行检测更改后,您可能希望截断摘要表。 通常,效果是将摘要列重置为0,或者 NULL 不删除行。 这使您可以清除收集的值并重新启动聚合。 例如,在您更改运行时配置之后,这可能很有用。 单个摘要表部分中记录了此截断行为的例外情况。

以下部分描述如何使用特定表来控制性能架构预过滤。

26.4.4按仪器预过滤

setup_instruments 表列出了可用的工具:

MySQL的> SELECT NAME, ENABLED, TIMED
       FROM performance_schema.setup_instruments;
+ ------------------------------------------------- -  + --------- + ------- +
| NAME | 启用| 定时|
+ ------------------------------------------------- -  + --------- + ------- +
...
| stage / sql / end | 没有| 没有|
| stage / sql / execution | 没有| 没有|
| stage / sql / init | 没有| 没有|
| stage / sql / insert | 没有| 没有|
...
| statement / sql / load | 是的| 是的|
| statement / sql / grant | 是的| 是的|
| statement / sql / check | 是的| 是的|
| statement / sql / flush | 是的| 是的|
...
| wait / synch / mutex / sql / LOCK_global_read_lock | 是的| 是的|
| wait / synch / mutex / sql / LOCK_global_system_variables | 是的| 是的|
| wait / synch / mutex / sql / LOCK_lock_db | 是的| 是的|
| wait / synch / mutex / sql / LOCK_manager | 是的| 是的|
...
| wait / synch / rwlock / sql / LOCK_grant | 是的| 是的|
| wait / synch / rwlock / sql / LOGGER :: LOCK_logger | 是的| 是的|
| wait / synch / rwlock / sql / LOCK_sys_init_connect | 是的| 是的|
| wait / synch / rwlock / sql / LOCK_sys_init_slave | 是的| 是的|
...
| wait / io / file / sql / binlog | 是的| 是的|
| wait / io / file / sql / binlog_index | 是的| 是的|
| wait / io / file / sql / casetest | 是的| 是的|
| wait / io / file / sql / dbopt | 是的| 是的|
...

要控制是否启用仪器,请将其 ENABLED 设置 YES NO 要配置是否收集已启用仪器的计时信息,请将其 TIMED 设置 YES NO 设置 TIMED 列会影响性能架构表内容,如 第26.4.1节“性能架构事件时序”中所述

对大多数 setup_instruments 行的 修改 会立即影响监视。 对于某些仪器,修改仅在服务器启动时有效; 在运行时更改它们没有任何效果。 这主要影响服务器中的互斥锁,条件和rwlock,尽管可能有其他工具也是如此。

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

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

  • 禁用所有乐器:

    更新performance_schema.setup_instruments
    SET ENABLED ='NO';
    

    现在不会收集任何事件。

  • 禁用所有文件工具,将它们添加到当前禁用的工具集:

    更新performance_schema.setup_instruments
    SET ENABLED ='NO'
    在哪里名称'wait / io / file /%';
    
  • 仅禁用文件工具,启用所有其他工具:

    更新performance_schema.setup_instruments
    SET ENABLED = IF(NAME LIKE'wait / io / file /%','NO','YES');
    
  • 启用 mysys 中的所有工具

    更新performance_schema.setup_instruments
    SET ENABLED =例如,名称如'%/ mysys /%'那么'是'''否''结束;
    
  • 禁用特定仪器:

    更新performance_schema.setup_instruments
    SET ENABLED ='NO'
    WHERE NAME ='wait / synch / mutex / mysys / TMPDIR_mutex';
    
  • 要切换乐器的状态,请 翻转 ENABLED 值:

    更新performance_schema.setup_instruments
    SET ENABLED = IF(ENABLED ='YES','NO','YES')
    WHERE NAME ='wait / synch / mutex / mysys / TMPDIR_mutex';
    
  • 禁用所有事件的时间:

    更新performance_schema.setup_instruments
    SET TIMED ='否';
    

26.4.5按对象预过滤

setup_objects 表控制性能模式是否监视特定表和存储的程序对象。 初始 setup_objects 内容如下所示:

MySQL的> SELECT * FROM performance_schema.setup_objects;
+ ------------- + -------------------- + ------------- + --------- ------- + +
| OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | 启用| 定时|
+ ------------- + -------------------- + ------------- + --------- ------- + +
| 活动| mysql | %| 没有| 没有|
| 活动| performance_schema | %| 没有| 没有|
| 活动| information_schema | %| 没有| 没有|
| 活动| %| %| 是的| 是的|
| 功能| mysql | %| 没有| 没有|
| 功能| performance_schema | %| 没有| 没有|
| 功能| information_schema | %| 没有| 没有|
| 功能| %| %| 是的| 是的|
| 程序| mysql | %| 没有| 没有|
| 程序| performance_schema | %| 没有| 没有|
| 程序| information_schema | %| 没有| 没有|
| 程序| %| %| 是的| 是的|
| 表| mysql | %| 没有| 没有|
| 表| performance_schema | %| 没有| 没有|
| 表| information_schema | %| 没有| 没有|
| 表| %| %| 是的| 是的|
| TRIGGER | mysql | %| 没有| 没有|
| TRIGGER | performance_schema | %| 没有| 没有|
| TRIGGER | information_schema | %| 没有| 没有|
| TRIGGER | %| %| 是的| 是的|
+ ------------- + -------------------- + ------------- + --------- ------- + +

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

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

OBJECT_SCHEMA OBJECT_NAME 列应包含文本模式或对象的名称,或 '%' 以匹配任何名称。

ENABLED 列指示是否监视匹配对象,并 TIMED 指示是否收集定时信息。 设置 TIMED 列会影响性能架构表内容,如 第26.4.1节“性能架构事件时序”中所述

缺省对象配置的效果是仪器除了那些在所有对象 mysql INFORMATION_SCHEMA performance_schema 数据库。 INFORMATION_SCHEMA 无论内容如何,​​数据库中的 都不会被检测 setup_objects ;该行 information_schema.% 只是使其默认为显式。)

当性能模式检查匹配时 setup_objects ,它会尝试首先查找更具体的匹配项。 对于与给定匹配的行, OBJECT_TYPE Performance Schema按以下顺序检查行:

  • 和的 OBJECT_SCHEMA='literal' OBJECT_NAME='literal'

  • 和的 OBJECT_SCHEMA='literal' OBJECT_NAME='%'

  • OBJECT_SCHEMA='%' 和的 OBJECT_NAME='%'

例如,有一张桌子 db1.t1 ,性能架构看起来 TABLE 行的匹配 'db1' 't1' ,然后 'db1' '%' ,然后 '%' '%' 匹配发生的顺序很重要,因为不同的匹配 setup_objects 行可以具有不同的 ENABLED TIMED 值。

对于与表相关的事件,性能模式将 setup_objects with 的内容组合在一起 setup_instruments 以确定是否启用仪器以及是否启用时间启用的仪器:

  • 对于匹配一排桌子 setup_objects ,桌子仪器产生的事件仅 ENABLED YES 在这两个 setup_instruments setup_objects

  • TIMED 两个表中 值组合在一起,因此仅在两个值都收集时才收集定时信息 YES

对于存储的程序对象,性能模式 直接从 行中 获取 ENABLED TIMED setup_objects 没有价值观的组合 setup_instruments

假设 setup_objects 包含以下 TABLE 适用于行 db1 db2 以及 db3

+ ------------- + --------------- + ------------- + ----- ---- + ------- +
| OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | 启用| 定时|
+ ------------- + --------------- + ------------- + ----- ---- + ------- +
| 表| db1 | t1 | 是的| 是的|
| 表| db1 | t2 | 没有| 没有|
| 表| db2 | %| 是的| 是的|
| 表| db3 | %| 没有| 没有|
| 表| %| %| 是的| 是的|
+ ------------- + --------------- + ------------- + ----- ---- + ------- +

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

  • db1.t1 事件受到监控

  • db1.t2 事件不受监控

  • db2.t3 事件受到监控

  • db3.t4 事件不受监控

  • db4.t5 事件受到监控

类似的逻辑适用于组合 TIMED 来自 setup_instruments setup_objects 以确定是否收集事件定时信息。

如果持久表和临时表具有相同的名称,则对两 setup_objects 行的 匹配 方式相同。 无法对一个表启用监视,而对另一个表启用监视。 但是,每个表都是单独检测的。

26.4.6按线程预过滤

threads 表包含每个服务器线程的行。 每行包含有关线程的信息,并指示是否为其启用了监视。 要使Performance Schema监视线程,必须满足以下条件:

  • 表中 thread_instrumentation 消费者 setup_consumers 必须是 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 中启用的仪器生成的那些线程事件进行记录

对于前台线程(由客户端连接产生), 表行中 INSTRUMENTED HISTORY 的初始值 threads 由与线程关联的用户帐户是否与 setup_actors 中的任何行匹配来确定 值来自 匹配 表行 ENABLED HISTORY setup_actors

对于后台线程,没有关联的用户。 INSTRUMENTED 并且 HISTORY YES 在默认情况下并 setup_actors 没有意见。

初始 setup_actors 内容如下所示:

MySQL的> SELECT * FROM performance_schema.setup_actors;
+ ------ + ------ + ------ + --------- + --------- +
| 主持人| 用户| 角色| 启用| 历史|
+ ------ + ------ + ------ + --------- + --------- +
| %| %| %| 是的| 是的|
+ ------ + ------ + ------ + --------- + --------- +

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

行中 ENABLED HISTORY setup_actors 可以设置为 彼此 YES NO 彼此独立。 这意味着您可以与是否收集历史事件分开启用检测。

默认情况下,为所有新的前台线程启用监视和历史事件收集,因为该 setup_actors 表最初包含一个包含 '%' for HOST 的行 USER 要执行更有限的匹配(例如,仅为某些前台线程启用监视),必须更改此行,因为它匹配任何连接,并添加更多特定 HOST / USER 组合的

假设您修改 setup_actors 如下:

更新performance_schema.setup_actors
SET ENABLED ='NO',HISTORY ='NO'
WHERE HOST ='%'和USER ='%';
INSERT INTO performance_schema.setup_actors
(主机,用户,角色,启用,历史)
VALUES( '本地主机', '乔', '%', 'YES', 'YES');
INSERT INTO performance_schema.setup_actors
(主机,用户,角色,启用,历史)
VALUES( 'hosta.example.com', '乔', '%', 'YES', '否');
INSERT INTO performance_schema.setup_actors
(主机,用户,角色,启用,历史)
VALUES( '%', 'SAM', '%', '否', '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 表的 修改 仅影响修改后创建的前台线程,而不影响现有线程。 要影响现有线程,请修改 表行的 INSTRUMENTED HISTORY threads

26.4.7消费者预过滤

setup_consumers 表列出了可用的使用者类型以及已启用的类型:

MySQL的> SELECT * FROM performance_schema.setup_consumers;
+ ---------------------------------- + --------- +
| NAME | 启用|
+ ---------------------------------- + --------- +
| 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 | 没有|
| events_waits_current | 没有|
| events_waits_history | 没有|
| events_waits_history_long | 没有|
| global_instrumentation | 是的|
| thread_instrumentation | 是的|
| statements_digest | 是的|
+ ---------------------------------- + --------- +

修改 setup_consumers 表以影响使用者阶段的预过滤并确定发送事件的目标。 要启用或禁用使用者,请将其 ENABLED 设置 YES NO

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

如果禁用使用者,则服务器不会花时间维护该使用者的目标。 例如,如果您不关心历史事件信息,请禁用历史记录使用者:

更新performance_schema.setup_consumers
SET ENABLED ='NO'
名称在哪里'%history%';

setup_consumers 表中 的使用者设置 形成从较高级别到较低级别的层次结构。 以下原则适用:

  • 除非性能模式检查使用者并且启用了使用者,否则与使用者关联的目标不会接收任何事件。

  • 仅在启用了依赖于(如果有)的所有使用者时才检查使用者。

  • 如果未检查消费者,或者已对其进行检查但已禁用,则不会检查依赖于此消费者的其他消费者。

  • 依赖消费者可能有自己的依赖消费者。

  • 如果事件不会发送到任何目标,则性能架构不会生成它。

以下列表描述了可用的使用者值。 有关几种有代表性的消费者配置及其对仪器的影响的讨论,请参见 第26.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 ,if NO ,禁用 events_waits_current 中单个等待事件的收集 如果 YES ,它启用等待事件收集,并且性能模式检查 events_waits_history events_waits_history_long 消费者。

  • events_waits_history 如果未选中 event_waits_current NO 否则,表的 events_waits_history 值为 NO YES 禁用或启用等待事件的集合 events_waits_history

  • events_waits_history_long 如果未选中 event_waits_current NO 否则,表的 events_waits_history_long 值为 NO YES 禁用或启用等待事件的集合 events_waits_history_long

舞台活动消费者

这些消费者既需要 global_instrumentation thread_instrumentation YES ,否则将无法检查。 如果选中,它们的行为如下:

  • events_stages_current ,if NO ,禁用 events_stages_current 中各个阶段事件的收集 如果 YES ,它启用阶段事件收集,性能模式检查 events_stages_history events_stages_history_long 消费者。

  • events_stages_history 如果未选中 event_stages_current NO 否则,表的 events_stages_history 值为 NO YES 禁用或启用阶段事件的集合 events_stages_history

  • events_stages_history_long 如果未选中 event_stages_current NO 否则,表的 events_stages_history_long 值为 NO YES 禁用或启用阶段事件的集合 events_stages_history_long

声明事件消费者

这些消费者既需要 global_instrumentation thread_instrumentation YES ,否则将无法检查。 如果选中,它们的行为如下:

  • events_statements_current ,if NO ,禁用 events_statements_current 中单个语句事件的收集 如果 YES ,它启用语句事件收集和性能模式检查 events_statements_history events_statements_history_long 消费者。

  • events_statements_history 如果未选中 events_statements_current NO 否则,表的 events_statements_history 值为 NO YES 禁用或启用语句事件的集合 events_statements_history

  • events_statements_history_long 如果未选中 events_statements_current NO 否则,表的 events_statements_history_long 值为 NO YES 禁用或启用语句事件的集合 events_statements_history_long

交易事件消费者

这些消费者既需要 global_instrumentation thread_instrumentation YES ,否则将无法检查。 如果选中,它们的行为如下:

  • events_transactions_current ,if NO ,禁用 events_transactions_current 中单个事务事件的收集 如果 YES ,它启用事务事件收集和性能架构检查 events_transactions_history events_transactions_history_long 消费者。

  • events_transactions_history 如果未选中 events_transactions_current NO 否则,表的 events_transactions_history 值为 NO YES 禁用或启用事务事件的集合 events_transactions_history

  • events_transactions_history_long 如果未选中 events_transactions_current NO 否则,表的 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 )。

有关 语句摘要的 更多信息,请参见 第26.10节“性能模式语句摘要和采样”

26.4.8消费者配置示例

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 ,则性能模式将启用与其关联的检测,并检查下一个最低级别的设置。 有关每个使用者的规则的说明,请参见 第26.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 | 启用|
+ --------------------------- + --------- +
| global_instrumentation | 没有|
...
+ --------------------------- + --------- +

在此配置中,不会检测任何内容。

检查设置元素:

保存输出表:

  • 没有

仅限全球仪器

服务器配置状态:

MySQL的> SELECT * FROM performance_schema.setup_consumers;
+ --------------------------- + --------- +
| NAME | 启用|
+ --------------------------- + --------- +
| global_instrumentation | 是的|
| thread_instrumentation | 没有|
...
+ --------------------------- + --------- +

在此配置中,仅为全局状态维护检测。 每线程检测已禁用。

相对于前面的配置,检查了其他设置元素:

相对于前面的配置,维护了额外的输出表:

仅限全局和线程检测

服务器配置状态:

MySQL的> SELECT * FROM performance_schema.setup_consumers;
+ ---------------------------------- + --------- +
| NAME | 启用|
+ ---------------------------------- + --------- +
| global_instrumentation | 是的|
| thread_instrumentation | 是的|
| events_waits_current | 没有|
...
| events_stages_current | 没有|
...
| events_statements_current | 没有|
...
| events_transactions_current | 没有|
...
+ ---------------------------------- + --------- +

在此配置中,全局和每个线程都维护检测。 当前事件或事件历史表中不会收集任何单个事件。

相对于前面的配置,检查了其他设置元素:

  • setup_consumers ,消费者 ,其中 events_xxx_currentxxxwaitsstagesstatementstransactions

  • 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 | 启用|
+ ---------------------------------- + --------- +
| 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 | 没有|
...
+ ---------------------------------- + --------- +

在此配置中,全局和每个线程都维护检测。 单个事件在current-events表中收集,但不在事件历史表中收集。

相对于前面的配置,检查了其他设置元素:

  • 消费者 ,其中 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 | 启用|
+ ---------------------------------- + --------- +
| 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 | 没有|
...
+ ---------------------------------- + --------- +

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

  • events_xxx_history ,其中 xxx waits stages statements transactions

此配置全局收集事件历史记录,但不是每个线程:

MySQL的> SELECT * FROM performance_schema.setup_consumers;
+ ---------------------------------- + --------- +
| NAME | 启用|
+ ---------------------------------- + --------- +
| 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 | 是的|
...
+ ---------------------------------- + --------- +

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

  • events_xxx_history_long ,其中 xxx waits stages statements transactions

此配置收集每个线程和全局的事件历史记录:

MySQL的> SELECT * FROM performance_schema.setup_consumers;
+ ---------------------------------- + --------- +
| NAME | 启用|
+ ---------------------------------- + --------- +
| 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 | 是的|
...
+ ---------------------------------- + --------- +

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

  • events_xxx_history ,其中 xxx waits stages statements transactions

  • events_xxx_history_long ,其中 xxx waits stages statements transactions

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

为过滤操作指定的名称可以根据需要具体或一般。 要指明单个工具或消费者,请完整指定其名称:

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

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

要指定一组工具或消费者,请使用与组成员匹配的模式:

更新performance_schema.setup_instruments
SET ENABLED ='NO'
在哪里名称'wait / synch / mutex /%';

更新performance_schema.setup_consumers
SET ENABLED ='NO'
名称在哪里'%history%';

如果您使用模式,则应选择它以使其匹配所有感兴趣的项目而不匹配其他项目。 例如,要选择所有文件I / O仪器,最好使用包含整个仪器名称前缀的模式:

...在哪里名称'wait / io / file /%';

一种模式 '%/file/%' 将匹配其他具有 '/file/' 名称 任何位置 组件的工具 更不合适的是模式, '%file%' 因为它会匹配 'file' 名称中任何位置的 乐器 ,例如 wait/synch/mutex/innodb/file_open_mutex

要检查模式匹配的仪器或消费者名称,请执行简单测试:

从performance_schema.setup_instruments中选择名称
名称在哪里' pattern';

从performance_schema.setup_consumers中选择名称
名称在哪里' pattern';

有关支持的名称类型的信息,请参见 第26.6节“性能架构仪器命名约定”

26.4.10确定仪器的内容

通过查看 setup_instruments 表格, 始终可以确定性能模式包含哪些工具 例如,要查看为 InnoDB 存储引擎 检测的文件相关事件 ,请使用以下查询:

MySQL的> SELECT NAME, ENABLED, TIMED
       FROM performance_schema.setup_instruments
       WHERE NAME LIKE 'wait/io/file/innodb/%';
+ ------------------------------------------------- + --------- + ------- +
| NAME | 启用| 定时|
+ ------------------------------------------------- + --------- + ------- +
| wait / io / file / innodb / innodb_tablespace_open_file | 是的| 是的|
| wait / io / file / innodb / innodb_data_file | 是的| 是的|
| wait / io / file / innodb / innodb_log_file | 是的| 是的|
| wait / io / file / innodb / innodb_temp_file | 是的| 是的|
| wait / io / file / innodb / innodb_arch_file | 是的| 是的|
| wait / io / file / innodb / innodb_clone_file | 是的| 是的|
+ ------------------------------------------------- + --------- + ------- +

由于以下几个原因,本文档中未详细说明精确检测的内容:

  • 检测的是服务器代码。 对此代码的更改经常发生,这也会影响仪器集。

  • 列出所有仪器是不切实际的,因为它们有数百种。

  • 如前所述,可以通过查询 setup_instruments 找出答案 此信息始终是您的MySQL版本的最新信息,还包括您可能已安装的不属于核心服务器的已检测插件的工具,并且可以由自动化工具使用。

26.5性能模式查询

预过滤限制收集哪些事件信息,并且独立于任何特定用户。 相比之下,后过滤是由各个用户通过使用具有适当 WHERE 子句 的查询来执行的,这些 子句限制在应用预过滤之后从可用事件中选择哪些事件信息。

第26.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 使用这些表的架构视图。 有关更多信息,请参见 第8.2.4节“优化性能架构查询”

26.6性能架构仪器命名约定

仪器名称由一系列由 '/' 字符 分隔的组件组成 示例名称:

等待/ IO /文件/ MyISAM数据/日志
等待/ IO /文件/ MYSYS /字符集
等待/锁/表/ SQL /处理器
等待/同步/湿/ MYSYS / COND_alarm
等待/同步/湿/ SQL / BINLOG :: update_cond
等待/同步/互斥/ MYSYS / BITMAP_mutex
等待/同步/互斥/ SQL / LOCK_delete
等待/同步/ rwlock中/ SQL / Query_cache_query ::锁
stage / sql / closing tables
stage / sql /排序结果
声明/ COM /执行
声明/ COM /查询
声明/ SQL / CREATE_TABLE
声明/ SQL / lock_tables
错误

仪器名称空间具有树状结构。 仪器名称的组成部分从左到右提供从更一般到更具体的进展。 名称所具有的组件数量取决于仪器的类型。

名称中给定组件的解释取决于其左侧的组件。 例如, myisam 出现在以下两个名称中,但 myisam 第一个名称与文件I / O相关,而在第二个名称中,它与同步工具有关:

等待/ IO /文件/ MyISAM数据/日志
等待/同步/湿/ MyISAM数据/ MI_SORT_INFO :: COND

仪器名称包含一个前缀,该前缀具有由Performance Schema实现定义的结构,以及由实现仪器代码的开发人员定义的后缀。 仪器前缀的顶级组件表示仪器的类型。 该组件还确定 performance_timers 中的哪个事件计时器 适用于仪器。 对于仪器名称的前缀部分,顶级表示仪器的类型。

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

  • 一种主要成分名(一服务器模块,例如 myisam innodb mysys ,或 sql )或插件名称。

  • 代码中变量的名称,形式 XXX (全局变量)或 类中 的成员 )。 例如: CCC::MMM MMM CCC COND_thread_cache THR_LOCK_myisam BINLOG::LOCK_index

顶级仪器组件

  • idle :一个仪表化的空闲事件。 该仪器没有其他组件。

  • error :检测错误事件。 该仪器没有其他组件。

  • memory :一个检测内存事件。

  • stage :仪表化舞台活动。

  • statement :一个检测语句事件。

  • transaction :已检测的事务事件。 该仪器没有其他组件。

  • wait :一个仪表化的等待事件。

闲置仪表组件

idle 工具用于空闲事件,性能模式生成,如 第26.12.3.5节“socket_instances表” 中的 socket_instances.STATE 说明中所述

错误仪器组件

error 仪器指示是否收集服务器错误和警告信息。 默认情况下启用此仪器。 中行 TIMED 不适用,因为未收集计时信息。 error setup_instruments

记忆仪器组件

默认情况下启用内存检测。 内存检测可以在启动时启用或禁用,也可以在运行时通过更新 表中 ENABLED 相关仪器 动态启用 setup_instruments 记忆仪器具有表格的名称, 其中 的值是 ,并且 是仪器细节。 memory/code_area/instrument_name code_area sql myisam instrument_name

使用前缀命名的仪器会 memory/performance_schema/ 在性能模式中公开为内部缓冲区分配的内存量。 memory/performance_schema/ 仪器是建立在,始终处于启用状态,并且不能在启动或运行时被禁用。 内置记忆仪器仅显示在 memory_summary_global_by_event_name 表格中。 有关更多信息,请参见 第26.17节“性能模式内存分配模型”

舞台乐器组件

舞台乐器具有形式的名称 ,其中 是诸如 的值 ,并且 表示声明处理的阶段,例如 阶段对应 表中 显示的 或在 中可见 的线程状态 stage/code_area/stage_name code_area sql myisam stage_name Sorting result Sending data SHOW PROCESSLIST INFORMATION_SCHEMA.PROCESSLIST

声明仪器组件

  • statement/abstract/* :语句操作的抽象工具。 在已知确切语句类型之前,在语句分类的早期阶段使用抽象工具,然后在已知类型时将其更改为更具体的语句工具。 有关此过程的说明,请参见 第26.12.6节“性能模式语句事件表”

  • 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 开头

等待仪器组件

  • wait/io

    仪表化I / O操作。

    • wait/io/file

      检测文件I / O操作。 对于文件,等待是等待文件操作完成的时间(例如,调用 fwrite() )。 由于缓存,磁盘上的物理文件I / O可能不会在此调用中发生。

    • wait/io/socket

      一个检测的套接字操作。 套接字工具具有表单的名称 服务器为其支持的每个网络协议都有一个侦听套接字。 与TCP / IP或Unix套接字文件连接的侦听套接字关联的工具的 分别 当侦听套接字检测到连接时,服务器将连接传输到由单独线程管理的新套接字。 新连接线程的工具的 值为 wait/io/socket/sql/socket_type socket_type server_tcpip_socket server_unix_socket socket_type client_connection

    • wait/io/table

      一个检测表I / O操作。 这些包括对持久性基表或临时表的行级访问。 影响行的操作是获取,插入,更新和删除。 对于视图,等待与视图引用的基表相关联。

      与大多数等待不同,表I / O等待可以包括其他等待。 例如,表I / O可能包括文件I / O或内存操作。 因此, events_waits_current 对于表I / O等待通常有两行。 有关更多信息,请参见 第26.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

      优先级 rwlock 锁定对象。

    • wait/synch/rwlock

      一个普通的 读/写锁 对象,用于锁定特定变量以进行访问,同时防止其他线程使用它。 共享读锁可以由多个线程同时获取。 一次只能通过一个线程获取独占写锁。

    • wait/synch/sxlock

      共享独占(SX)锁是一种 rwlock 锁对象,它提供对公共资源的写访问,同时允许其他线程的读取不一致。 sxlocks 优化并发性并提高读写工作负载的可伸缩性。

26.7性能模式状态监控

有几个与Performance Schema关联的状态变量:

MySQL的> SHOW STATUS LIKE 'perf%';
+ ----------------------------------------------- +  - ------ +
| Variable_name | 价值|
+ ----------------------------------------------- +  - ------ +
| 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状态变量提供有关由于内存限制而无法加载或创建的检测的信息。 这些变量的名称有以下几种形式:

  • 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个互斥乐器。

服务器根据插件的数量和可用数量分配插件的互斥工具,如以下语句序列所示:

安装PLUGIN plugin_a

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

UNINSTALL PLUGIN plugin_a;

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

安装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 | 价值|
+ --------------------------------------- + ------- +
| Performance_schema_mutex_classes_lost | 10 |
+ --------------------------------------- + ------- +
1排(0.10秒)

仪器仍然可以工作并收集(部分)数据 plugin_b

当服务器无法创建互斥锁仪器时,会出现以下结果:

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

Performance_schema_mutex_classes_lost 在两种情况下可能会发生大于0的

  • 为了节省内存的几个字节,你先从服务器 ,其中 小于默认值。 选择默认值足以加载MySQL发行版中提供的所有插件,但如果从未加载某些插件,则可以减少此值。 例如,您可以选择不在分发中加载某些存储引擎。 --performance_schema_max_mutex_classes=N N

  • 您加载了为性能模式检测的第三方插件,但在启动服务器时不允许插件的检测内存要求。 因为它来自第三方,所以此引擎的仪器内存消耗不计入所选的默认值 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 在代码(in 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。排******************** *******
  输入:performance_schema
  名称:events_waits_history.size
状态:76
****************************排******************** *******
  输入:performance_schema
  名称:events_waits_history.count
状态:10000
****************************排******************** *******
  输入:performance_schema
  名称:events_waits_history.memory
状态:760000
...
*************************** 57.排******************** *******
  输入:performance_schema
  名称:performance_schema.memory
状态:26459600
...

此语句旨在帮助DBA了解不同性能模式选项对内存要求的影响。 有关字段含义的说明,请参见 第13.7.6.15节“SHOW ENGINE语法”

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

对于表I / O事件,通常有两行 events_waits_current ,而不是一行。 例如,行提取可能会产生如下行:

行#EVENT_NAME TIMER_START TIMER_END
---- ---------- ----------- ---------
   1等待/ 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等待也是最近等待的任何类型。

26.9当前和历史事件的性能模式表

对于等待,阶段,语句和事务事件,性能模式可以监视和存储当前事件。 此外,当事件结束时,性能模式可以将它们存储在历史表中。 对于每种事件类型,性能模式使用三个表来存储当前事件和历史事件。 该表具有以下形式的名称,其中, xxx 指示事件类型( waits stages statements transactions ):

  • events_xxx_current 当前事件 表存储每个线程的当前受监视事件(每个线程一行)。

  • events_xxx_history 最近历史记录 表存储每个线程已结束的最新事件(最多为每个线程的最大行数)。

  • events_xxx_history_long long history 表存储全局结束的最新事件(跨所有线程,最多每个表的最大行数)。

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

对于每个事件类型, _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行,在 表中 保留 10,000行 _history_long

  • 线程A每秒生成1个事件。

    线程B每秒生成100个事件。

  • 没有其他线程在运行。

执行5秒后:

  • A和B分别产生了5和500个事件。

  • _history A包含5行,B包含10行。因为每个线程的存储限制为10行,所以A没有丢弃任何行,而B丢弃了490行。

  • _history_long 包含5行A和500行B.因为表的最大大小为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的行混合大约100比1而不是A.

26.10性能模式语句摘要和抽样

MySQL服务器能够维护语句摘要信息。 摘要过程将每个SQL语句转换为规范化形式(语句摘要),并根据规范化结果计算SHA-256哈希值(摘要哈希值)。 规范化允许类似于语句的分组和汇总,以公开有关服务器正在执行的语句类型以及它们发生频率的信息。 对于每个摘要,生成摘要的代表性语句将存储为样本。 本节介绍语句摘要和采样的发生方式以及它们如何有用。

无论性能模式是否可用,解析器都会发生摘要,因此查询重写插件等其他服务器组件可以访问语句摘要。

声明摘要一般概念

当解析器收到SQL语句时,如果需要该摘要,它将计算语句摘要,如果满足以下任一条件,则为true:

  • 已启用Performance Schema摘要检测

  • 启用了“查询重写插件”

解析器也由 STATEMENT_DIGEST_TEXT() STATEMENT_DIGEST() 函数使用,应用程序可以调用 这些解析器 分别从SQL语句计算规范化语句摘要和摘要散列值。

所述 max_digest_length 系统变量值确定归一化的语句摘要的计算每个会话中可用的字节的最大数量。 在摘要计算期间使用该空间量后,将发生截断:不会收集来自已解析语句的其他标记或将其计入其摘要值。 仅在解析的令牌的许多字节之后不同的语句产生相同的规范化语句摘要,并且如果比较或者如果聚合用于摘要统计则被认为是相同的。

在计算规范化语句之后,从中计算SHA-256哈希值。 此外:

  • 如果启用了任何Query Rewrite Plugin,则会调用它,并且语句摘要和摘要值可用。

  • 如果性能模式启用了摘要检测,它会生成规范化语句摘要的副本,为其分配最大 performance_schema_max_digest_length 字节数。 因此,如果 performance_schema_max_digest_length 小于 max_digest_length ,则相对于原始副本被截断。 规范化语句摘要的副本存储在相应的性能模式表中,以及从原始规范化语句计算的SHA-256哈希值。 (如果Performance Schema截断了相对于原始语法的规范化语句摘要的副本,则它不会重新计算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 =?和数量>?

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

现在考虑以下陈述:

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 =?和......

在这种情况下,第二列名称的差异将丢失,并且两个语句都被视为相同。

性能模式中的语句摘要

在性能模式中,语句摘要涉及以下组件:

某些性能表具有一个列,用于存储从中计算摘要的原始SQL语句:

默认情况下,语句显示的最大可用空间为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

由于Performance Schema语句事件表可能存储了许多摘要,因此设置 performance_schema_max_digest_length 小于 max_digest_length 使管理员能够平衡这些因素:

  • 需要为Performance Schema之外的服务器组件提供长规范化语句摘要

  • 许多并发会话,每个会话分配摘要计算内存

  • 存储许多语句摘要时,需要通过Performance Schema语句事件表限制内存消耗

performance_schema_max_digest_length 设置不是每个会话,它是per语句,并且会话可以在 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。

26.11性能模式通用表特性

performance_schema 数据库 的名称 是小写的,其中的表名称也是如此。 查询应以小写形式指定名称。

performance_schema 数据库中的 许多表 都是只读的,无法修改:

MySQL的> TRUNCATE TABLE performance_schema.setup_instruments;
ERROR 1683(HY000):performance_schema使用无效。

某些安装表具有可以修改以影响性能模式操作的列; 有些还允许插入或删除行。 允许截断清除收集的事件,因此 TRUNCATE TABLE 可以在包含这些信息的表上使用,例如以前缀为 events_waits_

可以截断摘要表 TRUNCATE TABLE 通常,效果是将摘要列重置为0,或者 NULL 不删除行。 这使您可以清除收集的值并重新启动聚合。 例如,在您更改运行时配置之后,这可能很有用。 单个摘要表部分中记录了此截断行为的例外情况。

权限与其他数据库和表一样:

  • 要从 performance_schema 表中 检索 ,您必须具有该 SELECT 权限。

  • 要更改可以修改的列,您必须具有该 UPDATE 权限。

  • 要截断可以截断的表,您必须具有该 DROP 权限。

由于只有一组有限的权限适用于Performance Schema表,因此尝试 GRANT ALL 用作在数据库或表leval上授予权限的简写失败,并显示错误:

MySQL的> GRANT ALL ON performance_schema.*
       TO 'u1'@'localhost';
ERROR 1044(42000):用户'root'@'localhost'拒绝访问
到数据库'performance_schema'
MySQL的> GRANT ALL ON performance_schema.setup_instruments
       TO 'u2'@'localhost';
ERROR 1044(42000):用户'root'@'localhost'拒绝访问
到数据库'performance_schema'

相反,准确授予所需的权限:

MySQL的> GRANT SELECT ON performance_schema.*
       TO 'u1'@'localhost';
查询正常,0行受影响(0.03秒)

MySQL的> GRANT SELECT, UPDATE ON performance_schema.setup_instruments
       TO 'u2'@'localhost';
查询OK,0行受影响(0.02秒)

26.12性能架构表描述

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

  • 汇总表。 这些表包含通过事件组聚合的信息,包括已从历史记录表中丢弃的事件。

  • 实例表。 这些表记录了检测的对象类型。 当由服务器使用时,检测对象产生事件。 这些表提供事件名称和解释性说明或状态信息。

  • 杂项表。 这些不属于任何其他表组。

26.12.1性能模式表索引

下表列出了每个Performance Schema表,并提供了每个表的简短描述。

表26.1性能架构表

表名 描述
accounts 每个客户帐户的连接统计
cond_instances 同步对象实例
data_lock_waits 数据锁等待关系
data_locks 持有和请求数据锁
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 Stage等待每个线程和事件名称
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 每个文件实例的文件事件
global_status 全局状态变量
global_variables 全局系统变量
host_cache 来自内部主机缓存的信息
hosts 每个客户端主机名的连接统计
keyring_keys 密钥环密钥的元数据
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 互斥同步对象实例
objects_summary_global_by_type 对象摘要
performance_timers 哪些活动计时器可用
persisted_variables mysqld-auto.cnf 文件 内容
prepared_statements_instances 准备好的语句实例和统计信息
replication_applier_configuration 从站上的事务应用程序的配置参数
replication_applier_status 从站上的事务应用程序的当前状态
replication_applier_status_by_coordinator SQL或协调程序线程应用程序状态
replication_applier_status_by_worker 工作线程应用程序状态(除非slave是多线程的,否则为空)
replication_connection_configuration 用于连接主站的配置参数
replication_connection_status 与主站的连接的当前状态
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 有关服务器线程的信息
tp_thread_group_state 有关线程池线程组状态的信息
tp_thread_group_stats 线程组统计信息
tp_thread_state 有关线程池线程状态的信息
user_defined_functions 注册的用户定义函数
user_variables_by_thread 每个线程的用户定义变量
users 每个客户端用户名的连接统计
variables_by_thread 每个会话的会话系统变量
variables_info 最近如何设置系统变量

26.12.2性能模式设置表

设置表提供有关当前检测的信息,并允许更改监视配置。 因此,如果您具有该 UPDATE 权限, 则可以更改这些表中的某些列

使用表而不是单个变量来设置信息可以在修改性能模式配置时提供高度的灵活性。 例如,您可以使用带有标准SQL语法的单个语句来进行多个同时进行的配置更改。

这些设置表可用:

26.12.2.1 setup_actors表

setup_actors 表包含的信息确定是否为新的前台服务器线程(与客户端连接关联的线程)启用监视和历史事件日志记录。 默认情况下,此表的最大大小为100行。 要更改表大小,请 performance_schema_setup_actors_size 在服务器启动时 修改 系统变量。

对于每个新的前台线程,性能模式将线程的用户和主机与 setup_actors 的行匹配 如果该表中的行匹配,则其 ENABLED HISTORY 列值分别用于设置 线程 表行 INSTRUMENTED HISTORY threads 这使得可以根据主机,用户或帐户(用户和主机组合)有选择地应用检测和历史事件记录。 如果没有匹配项, 则将线程 INSTRUMENTED HISTORY 列设置为 NO

对于后台线程,没有关联的用户。 INSTRUMENTED 并且 HISTORY YES 在默认情况下并 setup_actors 没有意见。

setup_actors 的初始内容 与任何用户和主机组合匹配,因此默认情况下为所有前台线程启用监视和历史事件收集:

MySQL的> SELECT * FROM performance_schema.setup_actors;
+ ------ + ------ + ------ + --------- + --------- +
| 主持人| 用户| 角色| 启用| 历史|
+ ------ + ------ + ------ + --------- + --------- +
| %| %| %| 是的| 是的|
+ ------ + ------ + ------ + --------- + --------- +

有关如何使用该 setup_actors 表来影响事件监视的信息,请参见 第26.4.6节“按线程预过滤”

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

setup_actors 表包含以下列:

  • HOST

    主机名。 这应该是文字名称,或者 '%' 表示 任何主机。

  • USER

    用户名。 这应该是文字名称,或者 '%' 表示 任何用户。

  • ROLE

    没用过。

  • ENABLED

    是否为行匹配的前台线程启用检测。 值是 YES NO

  • HISTORY

    是否记录行匹配的前台线程的历史事件。 值是 YES NO

setup_actors 表包含以下索引:

  • 在主键( HOST USER ROLE

TRUNCATE TABLE 是允许的 setup_actors 表。 它删除了行。

26.12.2.2 setup_consumers表

setup_consumers 表列出了可以存储事件信息和启用哪些消费者的消费者类型:

MySQL的> SELECT * FROM performance_schema.setup_consumers;
+ ---------------------------------- + --------- +
| NAME | 启用|
+ ---------------------------------- + --------- +
| 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 | 没有|
| events_waits_current | 没有|
| events_waits_history | 没有|
| events_waits_history_long | 没有|
| global_instrumentation | 是的|
| thread_instrumentation | 是的|
| statements_digest | 是的|
+ ---------------------------------- + --------- +

setup_consumers 表中 的使用者设置 形成从较高级别到较低级别的层次结构。 有关启用不同消费者的效果的详细信息,请参见 第26.4.7节“按消费者预过滤”

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

setup_consumers 表包含以下列:

  • NAME

    消费者名称。

  • ENABLED

    消费者是否已启用。 值是 YES NO 此列可以修改。 如果禁用使用者,则服务器不会花时间向其添加事件信息。

setup_consumers 表包含以下索引:

  • 主键( NAME

TRUNCATE TABLE 不允许使用该 setup_consumers 表。

26.12.2.3 setup_instruments表

setup_instruments 表列出了可以为其收集事件的检测对象的类:

MySQL的> SELECT * FROM performance_schema.setup_instruments\G
*************************** 1。排******************** *******
         名称:wait / synch / mutex / pfs / LOCK_pfs_share_list
      启用:没有
        时间:没有
   特性:单身
   挥发性:1
文档:组件可以提供自己的performance_schema表。
               此锁保护此类表定义的列表。
...
*************************** 369.排******************** *******
         名称:stage / sql / execution
      启用:没有
        时间:没有
   属性: 
   波动性:0
文档:NULL
...
*************************** 687.排******************** *******
         名称:statement / abstract / Query
      启用:是的
        时间:是的
   特性:可变
   波动性:0
文档:刚刚从网络收到的SQL查询。在此刻,
               真实的语句类型是未知的,类型将是
               SQL解析后改进。
...
*************************** 696.排******************** *******
         名称:memory / performance_schema / metadata_locks
      启用:是的
        TIMED:NULL
   属性:global_statistics
   挥发性:1
文档:用于表performance_schema.metadata_locks的内存
...

添加到源代码中的每个工具都为 setup_instruments 提供了一行 ,即使未执行检测代码也是如此。 启用并执行仪器后,将创建已检测的实例,这些实例在 xxx_instances 中可见 ,例如 file_instances rwlock_instances

对大多数 setup_instruments 行的 修改 会立即影响监视。 对于某些仪器,修改仅在服务器启动时有效; 在运行时更改它们没有任何效果。 这主要影响服务器中的互斥锁,条件和rwlock,尽管可能有其他工具也是如此。

有关 setup_instruments 表在事件过滤中 的作用的更多信息 ,请参见 第26.4.3节“事件预过滤”

setup_instruments 表包含以下列:

  • NAME

    仪器名称。 仪器名称可能有多个部分并形成层次结构,如 第26.6节“性能架构仪器命名约定”中所述 执行仪器产生的事件具有 EVENT_NAME 取自仪器 NAME 值的值。 (事件实际上没有 名称 ”, 但这提供了一种将事件与工具相关联的方法。)

  • ENABLED

    仪器是否已启用。 值是 YES NO 禁用的乐器不会产生任何事件。 虽然设置 ENABLED 对已创建的仪器没有影响 ,但可以修改此列

  • TIMED

    仪器是否定时。 值是 YES NO ,或 NULL 虽然设置 TIMED 对已创建的仪器没有影响 ,但可以修改此列

    TIMED 的值 NULL 表示该仪器不支持定时。 例如,内存操作没有定时,所以它们的 TIMED 列是 NULL

    设置 TIMED NULL 对于支持定时没有影响的仪器,如不设置 TIMED 于非 NULL 对不支持定时的仪器。

    如果启用的仪器未定时,则启用仪器代码,但不启用定时器。 由仪器产生的事件具有 NULL 用于 TIMER_START TIMER_END TIMER_WAIT 计时器值。 这反过来导致在计算汇总表中的总和,最小值,最大值和平均时间值时忽略这些值。

  • PROPERTIES

    仪器属性。 此列使用 SET 数据类型,因此可以为每个工具设置以下列表中的多个标志:

    • global_statistics :该工具仅生成全局摘要。 更精细级别的摘要不可用,例如每个线程,帐户,用户或主机。 例如,大多数记忆仪器仅产生全局摘要。

    • mutable :该仪器可以 变异 为更具体的一种。 此属性仅适用于声明工具。

    • progress :仪器能够报告进度数据。 此属性仅适用于舞台乐器。

    • singleton :仪器有一个实例。 例如,服务器中的大多数全局互斥锁都是单例,因此相应的工具也是如此。

    • user :仪器与用户工作负载直接相关(与系统工作负载相反)。 一个这样的工具是 wait/io/socket/sql/client_connection

  • VOLATILITY

    仪器波动。 波动率值从低到高。 这些值对应 头文件中 定义 常量 PSI_VOLATILITY_xxx mysql/psi/psi_base.h

    #define PSI_VOLATILITY_UNKNOWN 0
    #define PSI_VOLATILITY_PERMANENT 1
    #define PSI_VOLATILITY_PROVISIONING 2
    #define PSI_VOLATILITY_DDL 3
    #define PSI_VOLATILITY_CACHE 4
    #define PSI_VOLATILITY_SESSION 5
    #define PSI_VOLATILITY_TRANSACTION 6
    #define PSI_VOLATILITY_QUERY 7
    #define PSI_VOLATILITY_INTRA_QUERY 8
    

    VOLATILITY 列纯粹是信息性的,为用户(和性能模式代码)提供有关仪器运行时行为的一些提示。

    具有低波动率指数(PERMANENT = 1)的仪器在服务器启动时创建一次,并且在正常服务器操作期间永不销毁或重新创建。 它们仅在服务器关闭期间销毁。

    例如, wait/synch/mutex/pfs/LOCK_pfs_share_list 互斥量定义为波动率为1,这意味着它被创建一次。 仪器本身的可能开销(即互斥初始化)对此仪器没有影响。 仅在锁定或解锁互斥锁时才会发生运行时开销。

    对于每个用户会话,创建并销毁具有较高波动率指数的工具(例如,SESSION = 5)。 例如, wait/synch/mutex/sql/THD::LOCK_query_plan 每次会话连接时都会创建互斥锁,并在会话断开连接时销毁互斥锁​​。

    此互斥锁对性能模式开销更敏感,因为开销不仅来自锁定和解锁检测,还来自互斥创建和销毁检测,这些检测更频繁地执行。

    波动性的另一个方面涉及是否以及何时对 ENABLED 的更新 实际产生某些影响:

    • 更新 ENABLED 影响随后创建的已检测对象,但对已创建的仪器没有影响。

    • 易变 ”的 仪器会更快地 使用 setup_instruments 表中的 新设置

    例如,此语句不会影响 LOCK_query_plan 现有会话 互斥锁,但会对更新后创建的新会话产生影响:

    更新performance_schema.setup_instruments
    SET ENABLED =value
    WHERE NAME ='wait / synch / mutex / sql / THD :: LOCK_query_plan';
    

    该声明实际上根本没有效果:

    更新performance_schema.setup_instruments
    SET ENABLED =value
    WHERE NAME ='wait / synch / mutex / pfs / LOCK_pfs_share_list';
    

    此互斥锁是永久性的,并且在执行更新之前已创建。 永远不会再次创建互斥锁,因此 永远不会使用 ENABLED setup_instruments 要启用或禁用此互斥锁,请改用 mutex_instances 表格。

  • DOCUMENTATION

    描述仪器用途的字符串。 NULL 如果没有可用的描述,则为 该值

setup_instruments 表包含以下索引:

  • 主键( NAME

TRUNCATE TABLE 不允许使用该 setup_instruments 表。

26.12.2.4 setup_objects表

setup_objects 表控制性能模式是否监视特定对象。 默认情况下,此表的最大大小为100行。 要更改表大小,请修改 performance_schema_setup_objects_size 在服务器启动时 系统变量。

最初的 setup_objects 内容如下所示:

MySQL的> SELECT * FROM performance_schema.setup_objects;
+ ------------- + -------------------- + ------------- + --------- ------- + +
| OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | 启用| 定时|
+ ------------- + -------------------- + ------------- + --------- ------- + +
| 活动| mysql | %| 没有| 没有|
| 活动| performance_schema | %| 没有| 没有|
| 活动| information_schema | %| 没有| 没有|
| 活动| %| %| 是的| 是的|
| 功能| mysql | %| 没有| 没有|
| 功能| performance_schema | %| 没有| 没有|
| 功能| information_schema | %| 没有| 没有|
| 功能| %| %| 是的| 是的|
| 程序| mysql | %| 没有| 没有|
| 程序| performance_schema | %| 没有| 没有|
| 程序| information_schema | %| 没有| 没有|
| 程序| %| %| 是的| 是的|
| 表| mysql | %| 没有| 没有|
| 表| performance_schema | %| 没有| 没有|
| 表| information_schema | %| 没有| 没有|
| 表| %| %| 是的| 是的|
| TRIGGER | mysql | %| 没有| 没有|
| TRIGGER | performance_schema | %| 没有| 没有|
| TRIGGER | information_schema | %| 没有| 没有|
| TRIGGER | %| %| 是的| 是的|
+ ------------- + -------------------- + ------------- + --------- ------- + +

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

对于列出的对象类型 setup_objects ,性能模式使用该表来监视它们。 对象匹配基于 OBJECT_SCHEMA OBJECT_NAME 列。 不监视没有匹配的对象。

缺省对象配置的效果是仪器除了那些在所有的表 mysql INFORMATION_SCHEMA performance_schema 数据库。 INFORMATION_SCHEMA 无论内容如何,​​数据库中的 都没有检测 setup_objects ;行为 information_schema.% 只是使其默认为显式。)

当性能模式检查匹配时 setup_objects ,它会尝试首先查找更具体的匹配项。 例如,有一张桌子 db1.t1 ,它会寻找一个匹配 'db1' 't1' ,然后 'db1' '%' ,然后 '%' '%' 匹配发生的顺序很重要,因为不同的匹配 setup_objects 行可以具有不同的 ENABLED TIMED 值。

可以使用 表上的权限 权限将 setup_objects 用户 插入或删除行 对于现有行, 具有 该表特权 的用户只能修改 INSERT DELETE ENABLED TIMED UPDATE

有关 setup_objects 表在事件过滤中 的作用的更多信息 ,请参见 第26.4.3节“事件预过滤”

setup_objects 表包含以下列:

  • OBJECT_TYPE

    仪器的类型。 该值是 'EVENT' (事件调度程序事件), 'FUNCTION' (存储函数), 'PROCEDURE' (存储过程), 'TABLE' (基表)或 'TRIGGER' (触发器)之一。

    TABLE 过滤会影响表I / O事件( wait/io/table/sql/handler 仪器)和表锁定事件( wait/lock/table/sql/handler 仪器)。

  • OBJECT_SCHEMA

    包含该对象的架构。 这应该是文字名称,或者 '%' 表示 任何架构。

  • OBJECT_NAME

    已检测对象的名称。 这应该是一个文字名称,或者 '%' 意思是 任何对象。

  • ENABLED

    是否检测对象的事件。 值是 YES NO 此列可以修改。

  • TIMED

    对象的事件是否定时。 此列可以修改。

setup_objects 表包含以下索引:

  • 指数( OBJECT_TYPE OBJECT_SCHEMA OBJECT_NAME

TRUNCATE TABLE 是允许的 setup_objects 表。 它删除了行。

26.12.2.5 setup_threads表

setup_threads 表列出了已检测的线程类。 它公开了线程类名称和属性:

MySQL的> SELECT * FROM performance_schema.setup_threads\G
*************************** 1。排******************** *******
         名称:thread / performance_schema / setup
      启用:是的
      历史:是的
   特性:单身
   波动性:0
文档:NULL
...
****************************排******************** *******
         名称:thread / sql / main
      启用:是的
      历史:是的
   特性:单身
   波动性:0
文档:NULL
****************************排******************** *******
         名称:thread / sql / one_connection
      启用:是的
      历史:是的
   属性:用户
   波动性:0
文档:NULL
...
*************************** 10.排******************** *******
         名称:thread / sql / event_scheduler
      启用:是的
      历史:是的
   特性:单身
   波动性:0
文档:NULL

setup_threads 表包含以下列:

  • NAME

    仪器名称。 线程乐器以 thread (例如, thread/sql/parser_service thread/performance_schema/setup 开头

  • ENABLED

    仪器是否已启用。 值是 YES NO 虽然设置 ENABLED 对已经运行的线程没有影响 ,但可以修改此列

    对于后台线程,设置 ENABLED 值控制 INSTRUMENTED 是设置为 YES 还是 NO 为随后为此工具创建并在 threads 表中 列出的线程 对于前台线程,此列无效; setup_actors 表优先。

  • HISTORY

    是否记录仪器的历史事件。 值是 YES NO 虽然设置 HISTORY 对已经运行的线程没有影响 ,但可以修改此列

    对于后台线程,设置 HISTORY 值控制 HISTORY 是设置为 YES 还是 NO 为随后为此工具创建并在 threads 表中 列出的线程 对于前台线程,此列无效; setup_actors 表优先。

  • PROPERTIES

    仪器属性。 此列使用 SET 数据类型,因此可以为每个工具设置以下列表中的多个标志:

    • singleton :仪器有一个实例。 例如, thread/sql/main 仪器 只有一个螺纹

    • user :仪器与用户工作负载直接相关(与系统工作负载相反)。 例如,诸如 thread/sql/one_connection 执行用户会话之类的 线程 具有将 user 它们与系统线程区分开 属性。

  • VOLATILITY

    仪器波动。 此列与 setup_instruments 表中的 含义相同 请参见 第26.12.2.3节“setup_instruments表”

  • DOCUMENTATION

    描述仪器用途的字符串。 NULL 如果没有可用的描述,则为 该值

setup_threads 表包含以下索引:

  • 主键( NAME

TRUNCATE TABLE 不允许使用该 setup_threads 表。

26.12.2.6 setup_timers表

此表已在MySQL 8.0.4中删除。

26.12.3性能模式实例表

实例表记录了检测的对象类型。 它们提供事件名称和解释性说明或状态信息:

这些表列出了已检测的同步对象,文件和连接。 有三种类型的同步对象: cond mutex ,和 rwlock 每个实例表都有一个 EVENT_NAME 或一 NAME 列,用于指示与每行相关联的工具。 仪器名称可能有多个部分并形成层次结构,如 第26.6节“性能架构仪器命名约定”中所述

mutex_instances.LOCKED_BY_THREAD_ID rwlock_instances.WRITE_LOCKED_BY_THREAD_ID 列调查性能瓶颈或死锁非常重要的。 有关如何将其用于此目的的示例,请参见 第26.19节“使用性能模式诊断问题”

26.12.3.1 cond_instances表

cond_instances 表列出了服务器执行时性能模式所见的所有条件。 条件是代码中用于表示特定事件已发生的同步机制,以便等待此条件的线程可以恢复工作。

当线程正在等待某事发生时,条件名称表示线程正在等待什么,但是没有直接的方法来判断哪个其他线程或线程将导致该条件发生。

cond_instances 表包含以下列:

  • NAME

    与条件关联的仪器名称。

  • OBJECT_INSTANCE_BEGIN

    仪表化条件的内存地址。

cond_instances 表包含以下索引:

  • 主键( OBJECT_INSTANCE_BEGIN

  • 索引( NAME

TRUNCATE TABLE 不允许使用该 cond_instances 表。

26.12.3.2 file_instances表

file_instances 表列出了执行文件I / O检测时性能模式所看到的所有文件。 如果磁盘上的文件从未打开过,则不会打开 file_instances 从磁盘中删除文件时,也会从 file_instances 表中 删除该文件

file_instances 表包含以下列:

  • FILE_NAME

    文件名。

  • EVENT_NAME

    与文件关联的仪器名称。

  • OPEN_COUNT

    文件上打开句柄的计数。 如果文件已打开然后关闭,则会打开一次,但 OPEN_COUNT 打开 0.要列出服务器当前打开的所有文件,请使用 WHERE OPEN_COUNT > 0

file_instances 表包含以下索引:

  • 主键( FILE_NAME

  • 索引( EVENT_NAME

TRUNCATE TABLE 不允许使用该 file_instances 表。

26.12.3.3 mutex_instances表

mutex_instances 表列出了服务器执行时Performance Schema看到的所有互斥锁。 互斥体是代码中使用的同步机制,用于强制在给定时间只有一个线程可以访问某些公共资源。 该资源据说被 互斥锁 保护

当在服务器中执行的两个线程(例如,同时执行查询的两个用户会话)确实需要访问相同的资源(文件,缓冲区或某些数据)时,这两个线程将相互竞争,因此在互斥锁上获取锁定的第一个查询将导致另一个查询等到第一个查询完成并解锁互斥锁。

持有互斥锁时执行的工作被称为处于 关键部分 ”, 并且多个查询以串行方式(一次一个)执行此关键部分,这是一个潜在的瓶颈。

mutex_instances 表包含以下列:

  • NAME

    与互斥锁关联的仪器名称。

  • OBJECT_INSTANCE_BEGIN

    已检测互斥锁的内存地址。

  • LOCKED_BY_THREAD_ID

    当一个线程当前有一个互斥锁被锁定时, LOCKED_BY_THREAD_ID THREAD_ID 锁定线程,否则就是 NULL

mutex_instances 表包含以下索引:

  • 主键( OBJECT_INSTANCE_BEGIN

  • 索引( NAME

  • 索引( LOCKED_BY_THREAD_ID

TRUNCATE TABLE 不允许使用该 mutex_instances 表。

对于代码中检测到的每个互斥锁,性能模式提供以下信息。

  • setup_instruments 表列出了带有前缀的检测点的名称 wait/synch/mutex/

  • 当某些代码创建互斥锁时,会向 mutex_instances 表中 添加一行 OBJECT_INSTANCE_BEGIN 列是唯一标识互斥锁的属性。

  • 当线程尝试锁定互斥锁时,该 events_waits_current 表显示该线程的一行,表示它正在等待互斥锁(在 EVENT_NAME 列中),并指示等待哪个互斥锁(在 OBJECT_INSTANCE_BEGIN 列中)。

  • 当一个线程成功锁定互斥锁时:

  • 当线程解锁互斥锁时, mutex_instances 表明互斥锁现在没有所有者( THREAD_ID 列是 NULL )。

  • 当销毁互斥对象时,将删除相应的行 mutex_instances

通过对以下两个表执行查询,监视应用程序或DBA可以检测涉及互斥锁的线程之间的瓶颈或死锁:

26.12.3.4 rwlock_instances表

rwlock_instances 表列出 了服务器执行时Performance Schema看到的 所有 rwlock (读写锁)实例。 An rwlock 是一种在代码中使用的同步机制,用于强制在给定时间的线程可以访问遵循某些规则的某些公共资源。 该资源被称为 受保护 rwlock 访问是共享的(许多线程可以同时具有读锁定),独占(在给定时间只有一个线程可以具有写锁定),或者共享独占(线程可以在允许不一致的情况下具有写锁定通过其他线程读取)。 共享独占访问也称为 sxlock 并优化并发性并提高读写工作负载的可伸缩性。

根据请求锁的线程数以及所请求锁的性质,可以在共享模式,独占模式,共享独占模式下授予访问权限,或者根本不授予访问权限,等待其他线程首先完成。

rwlock_instances 表包含以下列:

  • NAME

    与锁相关联的仪器名称。

  • OBJECT_INSTANCE_BEGIN

    仪表锁内存中的地址。

  • WRITE_LOCKED_BY_THREAD_ID

    当一个线程当前 rwlock 在独占(写入)模式下 WRITE_LOCKED_BY_THREAD_ID THREAD_ID 锁定时 锁定线程的锁定线程,否则它是 NULL

  • READ_LOCKED_BY_COUNT

    当一个线程当前具有 rwlock 锁定的共享(读取)模式时, READ_LOCKED_BY_COUNT 增加1.这只是一个计数器,所以它不能直接用于查找哪个线程持有读锁定,但它可以用于查看是否存在a上的读取争用 rwlock ,并查看当前有多少读者活跃。

rwlock_instances 表包含以下索引:

  • 主键( OBJECT_INSTANCE_BEGIN

  • 索引( NAME

  • 索引( WRITE_LOCKED_BY_THREAD_ID

TRUNCATE TABLE 不允许使用该 rwlock_instances 表。

通过对以下两个表执行查询,监视应用程序或DBA可以检测涉及锁的线程之间的一些瓶颈或死锁:

有一个限制: rwlock_instances 只能用于识别持有写锁定的线程,而不能用于识别持有读锁定的线程。

26.12.3.5 socket_instances表

socket_instances 表提供了与MySQL服务器的活动连接的实时快照。 该表包含每个TCP / IP或Unix套接字文件连接一行。 此表中提供的信息提供了与服务器的活动连接的实时快照。 (附加信息在套接字汇总表中可用,包括网络活动,如套接字操作和发送和接收的字节数;请参见 第26.12.16.9节“套接字汇总表” )。

MySQL的> SELECT * FROM performance_schema.socket_instances\G
*************************** 1。排******************** *******
           EVENT_NAME:wait / io / socket / sql / server_unix_socket
OBJECT_INSTANCE_BEGIN:4316619408
            THREAD_ID:1
            SOCKET_ID:16
                   IP:
                 港口:0
                状态:有效
*************************** 2.排******************** *******
           EVENT_NAME:wait / io / socket / sql / client_connection
OBJECT_INSTANCE_BEGIN:4316644608
            THREAD_ID:21
            SOCKET_ID:39
                   IP:127.0.0.1
                 港口:55233
                状态:有效
*************************** 3。排******************** *******
           EVENT_NAME:wait / io / socket / sql / server_tcpip_socket
OBJECT_INSTANCE_BEGIN:4316699040
            THREAD_ID:1
            SOCKET_ID:14
                   IP:0.0.0.0
                 港口:50603
                状态:有效

套接字工具具有表单的名称, 并使用如下: wait/io/socket/sql/socket_type

  1. 服务器为其支持的每个网络协议都有一个侦听套接字。 与TCP / IP或Unix套接字文件连接的侦听套接字关联的工具的 socket_type 分别 server_tcpip_socket server_unix_socket

  2. 当侦听套接字检测到连接时,服务器将连接传输到由单独线程管理的新套接字。 新连接线程的工具的 socket_type 值为 client_connection

  3. 当连接终止时,将 socket_instances 删除与其对应 的行

socket_instances 表包含以下列:

  • EVENT_NAME

    wait/io/socket/* 产生事件 工具 的名称 这是 表中 NAME setup_instruments 仪器名称可能有多个部分并形成层次结构,如 第26.6节“性能架构仪器命名约定”中所述

  • OBJECT_INSTANCE_BEGIN

    此列唯一标识套接字。 该值是内存中对象的地址。

  • THREAD_ID

    服务器分配的内部线程标识符。 每个套接字由单个线程管理,因此每个套接字都可以映射到一个可以映射到服务器进程的线程。

  • SOCKET_ID

    分配给套接字的内部文件句柄。

  • IP

    客户端IP地址。 值可以是IPv4或IPv6地址,也可以是空白以表示Unix套接字文件连接。

  • PORT

    TCP / IP端口号,取值范围为0~65535。

  • STATE

    套接字状态, IDLE 或者 ACTIVE 使用相应的插座仪器跟踪活动插座的等待时间。 使用 idle 仪器 跟踪空闲插座的等待时间

    如果套接字正在等待来自客户端的请求,则它是空闲的。 当套接字变为空闲时,其中的事件行将 socket_instances 跟踪套接字切换的状态 ACTIVE IDLE EVENT_NAME 值仍然存在 wait/io/socket/* ,但该工具的时间暂停。 而是在 events_waits_current 表中 生成 一个 EVENT_NAME 值为的事件 idle

    当接收到下一个请求时, idle 事件终止,套接字实例从切换 IDLE ACTIVE ,并且套接字仪器的定时恢复。

socket_instances 表包含以下索引:

  • 主键( OBJECT_INSTANCE_BEGIN

  • 索引( THREAD_ID

  • 索引( SOCKET_ID

  • 索引( IP PORT

TRUNCATE TABLE 不允许使用该 socket_instances 表。

IP:PORT 列组合值标识的连接。 此组合值用于 OBJECT_NAME ,以标识套接字事件的连接: events_waits_xxx

  • 对于Unix域侦听器套接字( server_unix_socket ),端口为0,IP为 ''

  • 对于通过Unix域监听器( client_connection )的 客户端连接 ,端口为0,IP为 ''

  • 对于TCP / IP服务器侦听器套接字( server_tcpip_socket ),端口始终是主端口(例如,3306),并且IP始终是 0.0.0.0

  • 对于通过TCP / IP侦听器( client_connection )的 客户端连接 ,端口是服务器分配的任何内容,但从不为0. IP是发起主机( 127.0.0.1 ::1 本地主机) 的IP

26.12.4性能模式等待事件表

性能模式工具等待,这是需要时间的事件。 在事件层次结构中,等待事件嵌套在阶段事件中,阶段事件嵌套在事务事件中的语句事件中。

这些表存储等待事件:

以下部分描述了等待事件表。 还有汇总表来汇总有关等待事件的信息; 请参见 第26.12.16.1节“等待事件汇总表”

有关三个等待事件表之间关系的更多信息,请参见 第26.9节“当前事件和历史事件的性能模式表”

配置等待事件收集

要控制是否收集等待事件,请设置相关工具和消费者的状态:

  • setup_instruments 表包含以名称开头的工具 wait 使用这些工具启用或禁用单个等待事件类的收集。

  • setup_consumers 表包含消费者值,其名称对应于当前和历史等待事件表名称。 使用这些使用者来过滤等待事件的集合。

默认情况下启用一些等待仪器; 其他人被禁用。 例如:

MySQL的> SELECT NAME, ENABLED, TIMED
       FROM performance_schema.setup_instruments
       WHERE NAME LIKE 'wait/io/file/innodb%';
+ ------------------------------------------------- + --------- + ------- +
| NAME | 启用| 定时|
+ ------------------------------------------------- + --------- + ------- +
| wait / io / file / innodb / innodb_tablespace_open_file | 是的| 是的|
| wait / io / file / innodb / innodb_data_file | 是的| 是的|
| wait / io / file / innodb / innodb_log_file | 是的| 是的|
| wait / io / file / innodb / innodb_temp_file | 是的| 是的|
| wait / io / file / innodb / innodb_arch_file | 是的| 是的|
| wait / io / file / innodb / innodb_clone_file | 是的| 是的|
+ ------------------------------------------------- + --------- + ------- +
MySQL的> SELECT NAME, ENABLED, TIMED
       FROM performance_schema.setup_instruments
       WHERE NAME LIKE 'wait/io/socket/%';
+ ---------------------------------------- + -------- -  + ------- +
| NAME | 启用| 定时|
+ ---------------------------------------- + -------- -  + ------- +
| wait / io / socket / sql / server_tcpip_socket | 没有| 没有|
| wait / io / socket / sql / server_unix_socket | 没有| 没有|
| wait / io / socket / sql / client_connection | 没有| 没有|
+ ---------------------------------------- + -------- -  + ------- +

默认情况下禁用等待使用者:

MySQL的> SELECT *
       FROM performance_schema.setup_consumers
       WHERE NAME LIKE 'events_waits%';
+ --------------------------- + --------- +
| NAME | 启用|
+ --------------------------- + --------- +
| events_waits_current | 没有|
| events_waits_history | 没有|
| events_waits_history_long | 没有|
+ --------------------------- + --------- +

要在服务器启动时控制等待事件收集,请在 my.cnf 文件中 使用以下行

  • 启用:

    的[mysqld]
    性能架构仪器=“等待/%= ON”
    性能架构的消费活动,等待电流= ON
    性能架构的消费活动,等待历史= ON
    性能架构的消费活动,等待历史长= ON
    
  • 禁用:

    的[mysqld]
    性能架构仪器=“等待/%= OFF”
    性能架构的消费活动,等待电流= OFF
    性能架构的消费活动,等待历史= OFF
    性能架构的消费活动,等待历史长= OFF
    

要在运行时控制等待事件集合,请更新 setup_instruments setup_consumers 表:

  • 启用:

    更新performance_schema.setup_instruments
    SET ENABLED ='YES',TIMED ='YES'
    WHERE NAME ='wait /%';
    
    更新performance_schema.setup_consumers
    SET ENABLED ='YES'
    在哪里名称'events_waits%';
    
  • 禁用:

    更新performance_schema.setup_instruments
    SET ENABLED ='NO',TIMED ='NO'
    WHERE NAME ='wait /%';
    
    更新performance_schema.setup_consumers
    SET ENABLED ='NO'
    在哪里名称'events_waits%';
    

要仅收集特定的等待事件,请仅启用相应的等待仪器。 要仅为特定的等待事件表收集等待事件,请启用等待工具,但仅启用与所需表对应的等待使用者。

有关配置事件收集的其他信息,请参见 第26.3节“性能架构启动配置” 第26.4节“性能架构运行时配置”

26.12.4.1 events_waits_current表

events_waits_current 表包含当前的等待事件。 该表每个线程存储一行,显示线程最近监视的等待事件的当前状态,因此没有用于配置表大小的系统变量。

在包含等待事件行的表中, events_waits_current 是最基本的。 包含等待事件行的其他表在逻辑上从当前事件派生。 例如, events_waits_history events_waits_history_long 表是最近已结束的等待事件的集合,分别是每个线程的最大行数和所有线程的全局行数。

有关三个等待事件表之间关系的更多信息,请参见 第26.9节“当前事件和历史事件的性能模式表”

有关配置是否收集等待事件的信息,请参见 第26.12.4节“性能架构等待事件表”

events_waits_current 表包含以下列:

  • THREAD_ID EVENT_ID

    事件开始时与事件关联的线程和线程当前事件编号。 THREAD_ID EVENT_ID 一起唯一标识行值。 没有两行具有相同的值对。

  • END_EVENT_ID

    此列设置为 NULL 事件开始时,并在事件结束时更新为线程当前事件编号。

  • EVENT_NAME

    产生事件的工具的名称。 这是 表中 NAME setup_instruments 仪器名称可能有多个部分并形成层次结构,如 第26.6节“性能架构仪器命名约定”中所述

  • SOURCE

    源文件的名称,包含生成事件的检测代码和发生检测的文件中的行号。 这使您可以检查源以确切地确定涉及的代码。 例如,如果阻止互斥锁或锁,则可以检查发生这种情况的上下文。

  • TIMER_START TIMER_END TIMER_WAIT

    活动的时间信息。 这些值的单位是皮秒(万亿分之一秒)。 TIMER_START TIMER_END 值指示何时事件时间开始和结束。 TIMER_WAIT 是事件经过的时间(持续时间)。

    如果事件尚未完成, TIMER_END 则是当前计时器值,并且 TIMER_WAIT 是到目前为止经过的时间( TIMER_END - TIMER_START )。

    如果事件是从具有产生仪器 TIMED = NO ,定时信息不是收集,并且 TIMER_START TIMER_END 以及 TIMER_WAIT 是所有 NULL

    有关皮秒作为事件时间单位和影响时间值的因素的讨论,请参见 第26.4.1节“性能模式事件时序”

  • SPINS

    对于互斥锁,旋转轮次数。 如果值为 NULL ,则代码不使用旋转轮或旋转未检测。

  • OBJECT_SCHEMA OBJECT_NAME OBJECT_TYPE OBJECT_INSTANCE_BEGIN

    这些列标识 正在执行 的对象 这意味着什么取决于对象类型。

    用于同步对象( cond mutex rwlock ):

    • OBJECT_SCHEMA OBJECT_NAME OBJECT_TYPE NULL

    • OBJECT_INSTANCE_BEGIN 是内存中同步对象的地址。

    对于文件I / O对象:

    • OBJECT_SCHEMA NULL

    • OBJECT_NAME 是文件名。

    • OBJECT_TYPE FILE

    • OBJECT_INSTANCE_BEGIN 是内存中的地址。

    对于套接字对象:

    • OBJECT_NAME IP:PORT 套接字 值。

    • OBJECT_INSTANCE_BEGIN 是内存中的地址。

    对于表I / O对象:

    • OBJECT_SCHEMA 是包含表的架构的名称。

    • OBJECT_NAME 是表名。

    • OBJECT_TYPE TABLE 用于持久性基表或 TEMPORARY TABLE 用于临时表。

    • OBJECT_INSTANCE_BEGIN 是内存中的地址。

    一个 OBJECT_INSTANCE_BEGIN 值本身是没有意义的,只是不同的值表示不同的对象。 OBJECT_INSTANCE_BEGIN 可用于调试。 例如,它可用于 GROUP BY OBJECT_INSTANCE_BEGIN 查看1,000个互斥锁(保护,例如,1,000页或数据块)上的负载是均匀分布还是只是遇到几个瓶颈。 如果您在日志文件或其他调试或性能工具中看到相同的对象地址,这可以帮助您与其他信息源相关联。

  • INDEX_NAME

    使用的索引的名称。 PRIMARY 表主要索引。 NULL 表示没有使用索引。

  • NESTING_EVENT_ID

    EVENT_ID 嵌套此事件的事件 值。

  • NESTING_EVENT_TYPE

    嵌套事件类型。 值是 TRANSACTION STATEMENT STAGE ,或 WAIT

  • OPERATION

    该类型的操作进行的,例如 lock read ,或 write

  • NUMBER_OF_BYTES

    操作读取或写入的字节数。 对于表I / O等待( wait/io/table/sql/handler 仪器的 事件 ), NUMBER_OF_BYTES 指示行数。 如果该值大于1,则该事件用于批处理I / O操作。 以下讨论描述了仅反映批量I / O的单行报告和报告之间的区别。

    MySQL使用嵌套循环实现执行连接。 Performance Schema检测的工作是在连接中提供每个表的行计数和累计执行时间。 假设一个连接正在使用一个表连接的顺序执行以下形式的查询 t1 t2 t3

    SELECT ... FROM t1 JOIN t2 ON ... JOIN t3 ON ...
    

    扇出 是在连接处理期间添加表的行数的增加或减少。 如果表的扇出 t3 大于1,则大多数行获取操作都是针对该表的。 假设访问加入10行从 t1 ,20行从 t2 每行从 t1 ,并从30行 t3 每表中的行 t2 对于单行报告,检测操作的总数为:

    10 +(10 * 20)+(10 * 20 * 30)= 6210
    

    通过每次扫描聚合它们(即,来自 t1 和的 每行的唯一组合),可以实现仪表化操作数量的显着减少 t2 通过批处理I / O报告,性能模式为最内层表的每次扫描 t3 而不是每行 扫描生成一个事件 ,并且检测的行操作数减少为:

    10 +(10 * 20)+(10 * 20)= 410
    

    这减少了93%,说明了批量报告策略如何通过减少报告调用的数量来显着降低表I / O的性能模式开销。 权衡时间的准确度较低。 而不是像在每行报告中那样为单个行操作计时,批量I / O的时间包括诸如连接缓冲,聚合和向客户端返回行等操作所花费的时间。

    要进行批量I / O报告,必须满足以下条件:

    • 查询执行访问查询块的最内层表(对于单表查询,该表计为最内层)

    • 查询执行不会从表中请求单行(例如, eq_ref 访问会阻止使用批处理报告)

    • 查询执行不会评估包含表的表访问权的子查询

  • FLAGS

    保留供将来使用。

events_waits_current 表包含以下索引:

  • 主键( THREAD_ID EVENT_ID

TRUNCATE TABLE 是允许的 events_waits_current 表。 它删除了行。

26.12.4.2 events_waits_history表

events_waits_history 表包含 N 每个线程结束的最新等待事件。 等待事件在结束之前不会添加到表中。 当表包含给定线程的最大行数时,当添加该线程的新行时,将丢弃最旧的线程行。 当一个线程结束时,它的所有行都将被丢弃。

性能模式自动调整 N 服务器启动期间 的值 要显式设置每个线程的行数,请 performance_schema_events_waits_history_size 在服务器启动时 设置 系统变量。

events_waits_history 表具有相同的列和索引 events_waits_current 请参见 第26.12.4.1节“events_waits_current表”

TRUNCATE TABLE 是允许的 events_waits_history 表。 它删除了行。

有关三个等待事件表之间关系的更多信息,请参见 第26.9节“当前事件和历史事件的性能模式表”

有关配置是否收集等待事件的信息,请参见 第26.12.4节“性能架构等待事件表”

26.12.4.3 events_waits_history_long表

events_waits_history_long 表包含 N 所有线程中全局结束的最新等待事件。 等待事件在结束之前不会添加到表中。 当表变满时,添加新行时将丢弃最旧的行,而不管哪个行生成了哪一行。

性能模式自动调整 N 服务器启动期间 的值 要显式设置表大小,请 performance_schema_events_waits_history_long_size 在服务器启动时 设置 系统变量。

events_waits_history_long 表与列具有相同的列 events_waits_current 请参见 第26.12.4.1节“events_waits_current表” 不像 events_waits_current events_waits_history_long 没有索引。

TRUNCATE TABLE 是允许的 events_waits_history_long 表。 它删除了行。

有关三个等待事件表之间关系的更多信息,请参见 第26.9节“当前事件和历史事件的性能模式表”

有关配置是否收集等待事件的信息,请参见 第26.12.4节“性能架构等待事件表”

26.12.5性能模式阶段事件表

性能模式工具阶段,它们是语句执行过程中的步骤,例如解析语句,打开表或执行 filesort 操作。 阶段对应 SHOW PROCESSLIST INFORMATION_SCHEMA.PROCESSLIST 表中 显示的 或在 中可见 的线程状态 当状态值发生变化时,阶段开始和结束。

在事件层次结构中,等待事件嵌套在阶段事件中,阶段事件嵌套在事务事件中的语句事件中。

这些表存储舞台事件:

以下部分描述了舞台事件表。 还有汇总表,汇总有关舞台事件的信息; 请参见 第26.12.16.2节“阶段汇总表”

有关三个阶段事件表之间关系的更多信息,请参见 第26.9节“当前事件和历史事件的性能架构表”

配置舞台事件收集

要控制是否收集阶段事件,请设置相关工具和消费者的状态:

  • setup_instruments 表包含以名称开头的工具 stage 使用这些工具启用或禁用各个阶段事件类的收集。

  • setup_consumers 表包含消费者值,其名称对应于当前和历史阶段事件表名称。 使用这些使用者过滤阶段事件的集合。

除提供报表进度信息的那些工具外,默认情况下禁用舞台工具。 例如:

MySQL的> SELECT NAME, ENABLED, TIMED
       FROM performance_schema.setup_instruments
       WHERE NAME RLIKE 'stage/sql/[a-c]';
+ ------------------------------------------------- --- + --------- + ------- +
| NAME | 启用| 定时|
+ ------------------------------------------------- --- + --------- + ------- +
| stage / sql /创建后| 没有| 没有|
| stage / sql / assign本地表| 没有| 没有|
| stage / sql / altering table | 没有| 没有|
| stage / sql /将alter table提交到存储引擎| 没有| 没有|
| stage / sql /更改master | 没有| 没有|
| stage / sql /检查主版本| 没有| 没有|
| stage / sql / checking permissions | 没有| 没有|
| stage / sql /清理| 没有| 没有|
| stage / sql / closing tables | 没有| 没有|
| stage / sql /连接到master | 没有| 没有|
| stage / sql /将HEAP转换为MyISAM | 没有| 没有|
| stage / sql /复制到组表| 没有| 没有|
| stage / sql /复制到tmp表| 没有| 没有|
| stage / sql / copy to tmp table | 没有| 没有|
| stage / sql /创建排序索引| 没有| 没有|
| stage / sql / creating table | 没有| 没有|
| stage / sql /创建tmp表| 没有| 没有|
+ ------------------------------------------------- --- + --------- + ------- +

提供语句进度信息的舞台事件工具默认启用并定时:

MySQL的> SELECT NAME, ENABLED, TIMED
       FROM performance_schema.setup_instruments
       WHERE ENABLED='YES' AND NAME LIKE "stage/%";
+ ------------------------------------------------- ----- + --------- + ------- +
| NAME | 启用| 定时|
+ ------------------------------------------------- ----- + --------- + ------- +
| stage / sql / copy to tmp table | 是的| 是的|
| stage / sql /应用批量的行更改(写入)| 是的| 是的|
| stage / sql /应用批量的行更改(更新)| 是的| 是的|
| stage / sql /应用批量行更改(删除)| 是的| 是的|
| stage / innodb / alter table(结束)| 是的| 是的|
| stage / innodb / alter table(flush)| 是的| 是的|
| stage / innodb / alter table(insert)| 是的| 是的|
| stage / innodb / alter table(log apply index)| 是的| 是的|
| stage / innodb / alter table(log apply table)| 是的| 是的|
| stage / innodb / alter table(合并排序)| 是的| 是的|
| stage / innodb / alter table(读取PK和内部排序)| 是的| 是的|
| stage / innodb / buffer pool load | 是的| 是的|
| stage / innodb / clone(文件副本)| 是的| 是的|
| stage / innodb / clone(redo copy)| 是的| 是的|
| stage / innodb / clone(页面副本)| 是的| 是的|
+ ------------------------------------------------- ----- + --------- + ------- +

默认情况下禁用阶段使用者:

MySQL的> SELECT *
       FROM performance_schema.setup_consumers
       WHERE NAME LIKE 'events_stages%';
+ ---------------------------- + --------- +
| NAME | 启用|
+ ---------------------------- + --------- +
| events_stages_current | 没有|
| events_stages_history | 没有|
| events_stages_history_long | 没有|
+ ---------------------------- + --------- +

要在服务器启动时控制阶段事件收集,请在 my.cnf 文件中 使用以下行

  • 启用:

    的[mysqld]
    性能架构仪器=“阶段/%= ON”
    性能架构消费者的事件,阶段电流= ON
    性能架构消费者的事件,阶段历史= ON
    性能架构消费者的事件,阶段历史长= ON
    
  • 禁用:

    的[mysqld]
    性能架构仪器=“阶段/%= OFF”
    性能架构消费者的事件,阶段电流= OFF
    性能架构消费者的事件,阶段历史= OFF
    性能架构消费者的事件,阶段历史长= OFF
    

要在运行时控制阶段事件集合,请更新 setup_instruments setup_consumers 表:

  • 启用:

    更新performance_schema.setup_instruments
    SET ENABLED ='YES',TIMED ='YES'
    在哪里NAME ='stage /%';
    
    更新performance_schema.setup_consumers
    SET ENABLED ='YES'
    名称在哪里'events_stages%';
    
  • 禁用:

    更新performance_schema.setup_instruments
    SET ENABLED ='NO',TIMED ='NO'
    在哪里NAME ='stage /%';
    
    更新performance_schema.setup_consumers
    SET ENABLED ='NO'
    名称在哪里'events_stages%';
    

要仅收集特定的舞台活动,请仅启用相应的舞台乐器。 要仅为特定阶段事件表收集阶段事件,请启用阶段工具,但仅启用与所需表对应的阶段使用者。

有关配置事件收集的其他信息,请参见 第26.3节“性能架构启动配置” 第26.4节“性能架构运行时配置”

舞台活动进展信息

Performance Schema阶段事件表包含两列,它们一起为每行提供阶段进度指示器:

  • WORK_COMPLETED :为舞台完成的工作单元数量

  • WORK_ESTIMATED :舞台预期的工作单位数量

NULL 如果没有为仪器提供进度信息,则 每列都是 如果信息可用,对信息的解释完全取决于仪器的实施。 Performance Schema表提供了一个存储进度数据的容器,但不对指标本身的语义做出任何假设:

  • 单位 是一个整数度量执行期间随时间增加,如字节,行,文件或表处理的数量。 特定仪器 工作单元 的定义 留给提供数据的仪器代码。

  • WORK_COMPLETED 值可以一次增加一个或多个单位,具体取决于已检测的代码。

  • WORK_ESTIMATED 值可以根据仪表代码在阶段变化,。

舞台事件进度指示器的工具可以实现以下任何行为:

  • 没有进展仪器

    这是最典型的情况,没有提供进度数据。 WORK_COMPLETED WORK_ESTIMATED 列都是 NULL

  • 无限制的进度仪器

    只有 WORK_COMPLETED 列才有意义。 没有为 WORK_ESTIMATED 提供数据,该 列显示0。

    通过查询 events_stages_current 监视会话 表,监视应用程序可以报告到目前为止已执行了多少工作,但无法报告阶段是否接近完成。 目前,没有任何阶段像这样进行检测。

  • 有限的进度仪器

    WORK_COMPLETED WORK_ESTIMATED 列都是有意义的。

    这种类型的进度指示器适用于具有定义的完成标准的操作,例如稍后描述的表复制工具。 通过查询 events_stages_current 监视会话 表,监视应用程序可以报告到目前为止已执行了多少工作,并且可以通过计算 WORK_COMPLETED / WORK_ESTIMATED 比率 来报告阶段的总体完成百分比

stage/sql/copy to tmp table 文书说明了进展指标的运作方式。 在执行 ALTER TABLE 语句 期间 ,将 stage/sql/copy to tmp table 使用该阶段,并且此阶段可能会长时间执行,具体取决于要复制的数据的大小。

表复制任务具有已定义的终止(复制所有行),并且对该 stage/sql/copy to tmp table 阶段进行检测以提供有界进度信息:使用的工作单位是复制的行数, WORK_COMPLETED 并且 WORK_ESTIMATED 都是有意义的,并且它们的比率表示任务百分比已完成。

要启用仪器和相关的使用者,请执行以下语句:

更新performance_schema.setup_instruments
SET ENABLED ='YES'
WHERE NAME ='stage / sql / copy to tmp table';

更新performance_schema.setup_consumers
SET ENABLED ='YES'
名称在哪里'events_stages_%';

要查看正在进行的 ALTER TABLE 声明 的进度,请 events_stages_current 表中 选择

26.12.5.1 events_stages_current表

events_stages_current 表包含当前阶段事件。 该表为每个线程存储一行,显示线程最近监视的阶段事件的当前状态,因此没有用于配置表大小的系统变量。

包含阶段事件行的表中, events_stages_current 是最基本的。 包含阶段事件行的其他表在逻辑上从当前事件派生。 例如, events_stages_history events_stages_history_long 表是已结束的最新阶段事件的集合,分别是每个线程的最大行数和所有线程的全局行数。

有关三个阶段事件表之间关系的更多信息,请参见 第26.9节“当前事件和历史事件的性能架构表”

有关配置是否收集阶段事件的信息,请参见 第26.12.5节“性能架构阶段事件表”

events_stages_current 表包含以下列:

  • THREAD_ID EVENT_ID

    事件开始时与事件关联的线程和线程当前事件编号。 THREAD_ID EVENT_ID 一起唯一标识行值。 没有两行具有相同的值对。

  • END_EVENT_ID

    此列设置为 NULL 事件开始时,并在事件结束时更新为线程当前事件编号。

  • EVENT_NAME

    产生事件的工具的名称。 这是 表中 NAME setup_instruments 仪器名称可能有多个部分并形成层次结构,如 第26.6节“性能架构仪器命名约定”中所述

  • SOURCE

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

  • TIMER_START TIMER_END TIMER_WAIT

    活动的时间信息。 这些值的单位是皮秒(万亿分之一秒)。 TIMER_START TIMER_END 值指示何时事件时间开始和结束。 TIMER_WAIT 是事件经过的时间(持续时间)。

    如果事件尚未完成, TIMER_END 则是当前计时器值,并且 TIMER_WAIT 是到目前为止经过的时间( TIMER_END - TIMER_START )。

    如果事件是从具有产生仪器 TIMED = NO ,定时信息不是收集,并且 TIMER_START TIMER_END 以及 TIMER_WAIT 是所有 NULL

    有关皮秒作为事件时间单位和影响时间值的因素的讨论,请参见 第26.4.1节“性能模式事件时序”

  • WORK_COMPLETED WORK_ESTIMATED

    这些列提供了阶段进度信息,用于生成此类信息的工具。 WORK_COMPLETED 表示该阶段已完成的工作单元数量,并 WORK_ESTIMATED 指示该阶段预计有多少个工作单元。 有关更多信息,请参阅 阶段事件进度信息

  • NESTING_EVENT_ID

    EVENT_ID 嵌套此事件的事件 值。 舞台事件的嵌套事件通常是语句事件。

  • NESTING_EVENT_TYPE

    嵌套事件类型。 值是 TRANSACTION STATEMENT STAGE ,或 WAIT

events_stages_current 表包含以下索引:

  • 主键( THREAD_ID EVENT_ID

TRUNCATE TABLE 是允许的 events_stages_current 表。 它删除了行。

26.12.5.2 events_stages_history表

events_stages_history 表包含 N 每个线程结束的最新阶段事件。 阶段事件在结束之前不会添加到表中。 当表包含给定线程的最大行数时,当添加该线程的新行时,将丢弃最旧的线程行。 当一个线程结束时,它的所有行都将被丢弃。

性能模式自动调整 N 服务器启动期间 的值 要显式设置每个线程的行数,请 performance_schema_events_stages_history_size 在服务器启动时 设置 系统变量。

events_stages_history 表具有相同的列和索引 events_stages_current 请参见 第26.12.5.1节“events_stages_current表”

TRUNCATE TABLE 是允许的 events_stages_history 表。 它删除了行。

有关三个阶段事件表之间关系的更多信息,请参见 第26.9节“当前事件和历史事件的性能架构表”

有关配置是否收集阶段事件的信息,请参见 第26.12.5节“性能架构阶段事件表”

26.12.5.3 events_stages_history_long表

events_stages_history_long 表包含 N 所有线程中全局结束的最新阶段事件。 阶段事件在结束之前不会添加到表中。 当表变满时,添加新行时将丢弃最旧的行,而不管哪个行生成了哪一行。

性能模式自动调整 N 服务器启动期间 的值 要显式设置表大小,请 performance_schema_events_stages_history_long_size 在服务器启动时 设置 系统变量。

events_stages_history_long 表与列具有相同的列 events_stages_current 请参见 第26.12.5.1节“events_stages_current表” 不像 events_stages_current events_stages_history_long 没有索引。

TRUNCATE TABLE 是允许的 events_stages_history_long 表。 它删除了行。

有关三个阶段事件表之间关系的更多信息,请参见 第26.9节“当前事件和历史事件的性能架构表”

有关配置是否收集阶段事件的信息,请参见 第26.12.5节“性能架构阶段事件表”

26.12.6性能模式语句事件表

Performance Schema instruments语句执行。 语句事件发生在事件层次结构的高级别。 在事件层次结构中,等待事件嵌套在阶段事件中,阶段事件嵌套在事务事件中的语句事件中。

这些表存储语句事件:

以下部分描述了语句事件表。 还有汇总表来汇总有关语句事件的信息; 请参见 第26.12.16.3节“语句汇总表”

有关三个 事件表 之间关系的更多信息 ,请参见 第26.9节“当前事件和历史事件的性能架构表” events_statements_xxx

配置语句事件排序规则

要控制是否收集报表事件,请设置相关工具和消费者的状态:

  • setup_instruments 表包含以名称开头的工具 statement 使用这些工具启用或禁用单个语句事件类的收集。

  • setup_consumers 表包含名称与当前和历史语句事件表名称对应的消费者值,以及语句摘要使用者。 使用这些使用者来过滤语句事件和语句摘要的集合。

声明工具在默认情况下启用,并且 events_statements_current events_statements_history statements_digest 语句消费者是默认启用的:

MySQL的> SELECT NAME, ENABLED, TIMED
       FROM performance_schema.setup_instruments
       WHERE NAME LIKE 'statement/%';
+ --------------------------------------------- + --- ------ + ------- +
| NAME | 启用| 定时|
+ --------------------------------------------- + --- ------ + ------- +
| statement / sql / select | 是的| 是的|
| statement / sql / create_table | 是的| 是的|
| statement / sql / create_index | 是的| 是的|
...
| statement / sp / stmt | 是的| 是的|
| statement / sp / set | 是的| 是的|
| statement / sp / set_trigger_field | 是的| 是的|
| 声明/调度程序/事件| 是的| 是的|
| 声明/ com /睡眠| 是的| 是的|
| 声明/ com /退出| 是的| 是的|
| statement / com / Init DB | 是的| 是的|
...
| 声明/摘要/查询| 是的| 是的|
| statement / abstract / new_packet | 是的| 是的|
| statement / abstract / relay_log | 是的| 是的|
+ --------------------------------------------- + --- ------ + ------- +
MySQL的> SELECT *
       FROM performance_schema.setup_consumers
       WHERE NAME LIKE '%statements%';
+ -------------------------------- + --------- +
| NAME | 启用|
+ -------------------------------- + --------- +
| events_statements_current | 是的|
| events_statements_history | 是的|
| events_statements_history_long | 没有|
| statements_digest | 是的|
+ -------------------------------- + --------- +

要在服务器启动时控制语句事件收集,请在 my.cnf 文件中 使用以下行

  • 启用:

    的[mysqld]
    性能架构的仪器=“语句/%= ON”
    性能架构消费者的事件陈述电流= ON
    性能架构消费者的事件陈述历史= ON
    性能架构消费者的事件陈述历史长= ON
    性能架构的消费报表消化= ON
    
  • 禁用:

    的[mysqld]
    性能架构的仪器=“语句/%= OFF”
    性能架构消费者的事件陈述电流= OFF
    性能架构消费者的事件陈述历史= OFF
    性能架构消费者的事件陈述历史长= OFF
    性能架构的消费报表消化= OFF
    

要在运行时控制语句事件集合,请更新 setup_instruments setup_consumers 表:

  • 启用:

    更新performance_schema.setup_instruments
    SET ENABLED ='YES',TIMED ='YES'
    名称在哪里'声明/%';
    
    更新performance_schema.setup_consumers
    SET ENABLED ='YES'
    在哪里名称像'%statement%';
    
  • 禁用:

    更新performance_schema.setup_instruments
    SET ENABLED ='NO',TIMED ='NO'
    名称在哪里'声明/%';
    
    更新performance_schema.setup_consumers
    SET ENABLED ='NO'
    在哪里名称像'%statement%';
    

要仅收集特定的语句事件,请仅启用相应的语句工具。 要仅为特定语句事件表收集语句事件,请启用语句工具,但仅启用与所需表对应的语句使用者。

有关配置事件收集的其他信息,请参见 第26.3节“性能架构启动配置” 第26.4节“性能架构运行时配置”

报表监控

语句监视从服务器在线程上请求活动的那一刻开始,直到所有活动停止的那一刻开始。 通常,这意味着从服务器从客户端获取第一个数据包到服务器完成发送响应的时间。 存储程序中的语句与其他语句一样受到监视。

当性能模式检测请求(服务器命令或SQL语句)时,它使用从更一般(或 抽象 )到更具体的 阶段进行的仪器名称, 直到它到达最终的仪器名称。

最终的仪器名称对应于服务器命令和SQL语句:

  • 服务器命令对应 头文件中 定义并在其中 处理 例子是 命令仪器的名称以 ,例如 开头 COM_xxx codes mysql_com.h sql/sql_parse.cc COM_PING COM_QUIT statement/com statement/com/Ping statement/com/Quit

  • SQL语句表示为文本,例如 DELETE FROM t1 SELECT * FROM t2 SQL语句的工具的名称 statement/sql statement/sql/delete 开头 statement/sql/select

一些最终的仪器名称特定于错误处理:

  • statement/com/Error 对服务器收到的带外消息进行说明。 它可用于检测服务器不理解的客户端发送的命令。 这可能有助于识别错误配置的客户端或使用比服务器更新的MySQL版本的客户端,或尝试攻击服务器的客户端。

  • statement/sql/error 对无法解析的SQL语句的帐户。 它可用于检测客户端发送的格式错误的查询。 无法解析的查询与解析但由于执行期间的错误而失败的查询不同。 例如, SELECT * FROM 格式不正确,使用 statement/sql/error 仪器。 相比之下, SELECT * 解析但失败并出现 No tables used 错误。 在这种情况下, statement/sql/select 使用并且语句事件包含指示错误性质的信息。

可以从以下任何来源获取请求:

  • 作为来自客户端的命令或语句请求,它将请求作为数据包发送

  • 作为从复制从站上的中继日志中读取的语句字符串

  • 作为事件调度程序的事件

请求的详细信息最初未知,并且性能模式从抽象到特定工具名称的顺序依赖于请求的来源。

对于从客户收到的请求:

  1. 当服务器在套接字级别检测到新数据包时,将使用抽象工具名称启动新语句 statement/abstract/new_packet

  2. 当服务器读取数据包编号时,它会更多地了解收到的请求类型,并且性能模式会优化仪器名称。 例如,如果请求是 COM_PING 数据包,则仪器名称将成为 statement/com/Ping 最终名称。 如果请求是 COM_QUERY 数据包,则已知它对应于SQL语句但不对应于特定类型的语句。 在这种情况下,工具从一个抽象名称更改为更具体但仍然是抽象的名称 statement/abstract/Query ,并且该请求需要进一步分类。

  3. 如果请求是语句,则读取语句文本并将其提供给解析器。 解析后,确切的语句类型是已知的。 例如,如果请求是一个 INSERT 语句,则性能模式将仪器名称从 最终名称 statement/abstract/Query 改为 statement/sql/insert

对于从复制从站上的中继日志中读取的语句请求:

  1. 中继日志中的语句存储为文本,并按原样读取。 没有网络协议,因此 statement/abstract/new_packet 不使用 仪器。 相反,最初的工具是 statement/abstract/relay_log

  2. 解析语句时,确切的语句类型是已知的。 例如,如果请求是一个 INSERT 语句,则性能模式将仪器名称从 最终名称 statement/abstract/Query 改为 statement/sql/insert

前面的描述仅适用于基于语句的复制。 对于基于行的复制,可以检测在从属进行行更改时在从属上完成的表I / O,但是中继日志中的行事件不会显示为离散语句。

对于从事件调度程序收到的请求:

使用名称检测事件执行 statement/scheduler/event 这是最终名称。

在事件正文中执行的语句使用 statement/sql/* 名称进行检测,而不使用任何前面的抽象工具。 事件是存储的程序,并且存储的程序在执行之前被预编译在存储器中。 因此,在运行时没有解析,并且每个语句的类型在执行时都是已知的。

在事件正文中执行的语句是子语句。 例如,如果一个事件执行一个 INSERT 语句,那么事件本身的执行就是父项,使用仪器化 statement/scheduler/event ,并且 INSERT 是使用仪器化的子项 statement/sql/insert 父/子关系 不同的检测操作 之间保持 这不同于细化发生该序列 的单个仪器化操作中,从抽象到最终乐器名称。

对于要为语句收集的统计信息,仅启用 statement/sql/* 用于单个语句类型 的最终 工具 是不够的 statement/abstract/* 必须同时启用 abtract 工具。 这通常不是问题,因为默认情况下启用所有语句工具。 但是,有选择地启用或禁用语句工具的应用程序必须考虑到禁用抽象工具还会禁用各个语句工具的统计信息收集。 例如,要收集 INSERT 语句的 统计信息 statement/sql/insert 必须启用,还要 statement/abstract/new_packet statement/abstract/Query 同样,对于要检测的复制语句, statement/abstract/relay_log 必须启用。

没有为抽象工具汇总统计数据,例如 statement/abstract/Query 因为没有任何陈述用抽象工具作为最终陈述名称进行分类。

26.12.6.1 events_statements_current表

events_statements_current 表包含当前语句事件。 该表为每个线程存储一行,显示线程最近监视的语句事件的当前状态,因此没有用于配置表大小的系统变量。

包含语句事件行的表中, events_statements_current 是最基本的。 包含语句事件行的其他表在逻辑上从当前事件派生。 例如, events_statements_history events_statements_history_long 表是最近结束的语句事件的集合,分别是每个线程的最大行数和所有线程的全局行数。

有关三个 事件表 之间关系的更多信息 ,请参见 第26.9节“当前事件和历史事件的性能架构表” events_statements_xxx

有关配置是否收集语句事件的信息,请参见 第26.12.6节“性能架构语句事件表”

events_statements_current 表包含以下列:

  • THREAD_ID EVENT_ID

    事件开始时与事件关联的线程和线程当前事件编号。 THREAD_ID EVENT_ID 一起唯一标识行值。 没有两行具有相同的值对。

  • END_EVENT_ID

    此列设置为 NULL 事件开始时,并在事件结束时更新为线程当前事件编号。

  • EVENT_NAME

    收集事件的工具的名称。 这是 表中 NAME setup_instruments 仪器名称可能有多个部分并形成层次结构,如 第26.6节“性能架构仪器命名约定”中所述

    对于SQL语句,该 EVENT_NAME 值最初是 statement/com/Query 在解析语句之前,然后更改为更合适的值,如 第26.12.6节“性能架构语句事件表”中所述

  • SOURCE

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

  • TIMER_START TIMER_END TIMER_WAIT

    活动的时间信息。 这些值的单位是皮秒(万亿分之一秒)。 TIMER_START TIMER_END 值指示何时事件时间开始和结束。 TIMER_WAIT 是事件经过的时间(持续时间)。

    如果事件尚未完成, TIMER_END 则是当前计时器值,并且 TIMER_WAIT 是到目前为止经过的时间( TIMER_END - TIMER_START )。

    如果事件是从具有产生仪器 TIMED = NO ,定时信息不是收集,并且 TIMER_START TIMER_END 以及 TIMER_WAIT 是所有 NULL

    有关皮秒作为事件时间单位和影响时间值的因素的讨论,请参见 第26.4.1节“性能模式事件时序”

  • LOCK_TIME

    等待表锁的时间。 此值以微秒计算,但标准化为皮秒,以便于与其他性能模式计时器进行比较。

  • SQL_TEXT

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

    默认情况下,语句显示的最大可用空间为1024字节。 要更改此值,请 performance_schema_max_sql_text_length 在服务器启动时 设置 系统变量。 (更改此值也会影响其他Performance Schema表中的列。请参见 第26.10节“性能架构语句摘要和采样” 。)

  • DIGEST

    该语句将SHA-256值摘要为64个十六进制字符的字符串,或者 NULL 如果 statements_digest 消费者是 no 有关 语句摘要的 更多信息,请参见 第26.10节“性能模式语句摘要和采样”

  • DIGEST_TEXT

    标准化语句摘要文本,或者 NULL 如果是 statements_digest 消费者 no 有关 语句摘要的 更多信息,请参见 第26.10节“性能模式语句摘要和采样”

    performance_schema_max_digest_length 系统变量来确定用于摘要值存储每会话中可用的最大字节数。 但是,由于语句组件(如关键字和摘要缓冲区中的文字值)的编码,语句摘要的显示长度可能比可用的缓冲区大小长。 因此,从 DIGEST_TEXT 语句事件表列中 选择 performance_schema_max_digest_length 可能会超出该 值。

  • CURRENT_SCHEMA

    语句的默认数据库( NULL 如果没有)。

  • OBJECT_SCHEMA OBJECT_NAME OBJECT_TYPE

    对于嵌套语句(存储程序),这些列包含有关父语句的信息。 否则他们是 NULL

  • OBJECT_INSTANCE_BEGIN

    此列标识该语句。 该值是内存中对象的地址。

  • MYSQL_ERRNO

    语句诊断区域中的语句错误号。

  • RETURNED_SQLSTATE

    语句SQLSTATE值,来自语句诊断区域。

  • MESSAGE_TEXT

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

  • ERRORS

    是否为语句发生错误。 如果SQLSTATE值以 00 (完成)或 01