目录
MySQL性能模式是一种用于监视低级别MySQL服务器执行的功能。 性能模式具有以下特征:
性能模式提供了一种在运行时检查服务器内部执行的方法。
它是使用
PERFORMANCE_SCHEMA
存储引擎和
performance_schema
数据库实现的。
性能模式主要关注性能数据。
这与
INFORMATION_SCHEMA
用于检查元数据的不同。
性能模式监视服务器事件。 一个 “ 事件 ” 是什么,该服务器确实需要时间和被装备,使定时信息可以收集。 通常,事件可以是函数调用,等待操作系统,SQL语句执行的阶段(例如解析或排序),或整个语句或语句组。 事件集合提供对服务器和多个存储引擎的同步调用(例如互斥锁)文件和表I / O,表锁等信息的访问。
性能模式事件与写入服务器的二进制日志(描述数据修改)和事件调度程序事件(这是一种存储程序)的事件不同。
性能模式事件特定于MySQL服务器的给定实例。 性能模式表被视为服务器的本地表,对它们的更改不会复制或写入二进制日志。
可以获得当前事件,以及事件历史和摘要。 这使您可以确定已执行的已检测活动的次数以及执行的时间。 事件信息可用于显示特定线程的活动,或与特定对象(如互斥锁或文件)关联的活动。
该
PERFORMANCE_SCHEMA
存储引擎使用收集事件数据
“
检测点
”
在服务器的源代码。
收集的事件存储在
performance_schema
数据库的
表中
。
可以使用
SELECT
其他表之类的语句
查询这些
表。
可以
performance_schema
通过SQL语句
更新
数据库中的
表来动态修改性能模式配置
。
配置更改会立即影响数据收集。
性能模式中的表是内存表,不使用持久性磁盘存储。 从服务器启动开始重新填充内容,并在服务器关闭时丢弃。
监控可在MySQL支持的所有平台上使用。
可能存在一些限制:计时器的类型可能因平台而异。 适用于存储引擎的仪器可能未针对所有存储引擎实施。 每个第三方引擎的仪表是引擎维护者的责任。 另见 第C.8节“性能模式的限制” 。
通过修改服务器源代码来添加检测来实现数据收集。 与其他功能(如复制或事件计划程序)不同,没有与Performance Schema关联的单独线程。
性能模式旨在提供对服务器执行的有用信息的访问,同时对服务器性能的影响最小。 实现遵循以下设计目标:
激活性能模式不会导致服务器行为发生任何变化。
例如,它不会导致线程调度发生更改,并且不会导致查询执行计划(如图所示
EXPLAIN
)发生更改。
服务器监控连续且不显眼地发生,只需很少的开销。 激活性能架构不会使服务器无法使用。
解析器没有变化。 没有新的关键字或陈述。
即使性能模式在内部失败,服务器代码的执行也会正常进行。
当在最初的事件收集期间或之后的事件检索期间执行处理之间存在选择时,优先考虑使收集更快。 这是因为收集正在进行,而检索是按需进行的,可能永远不会发生。
大多数性能模式表都有索引,这使得优化器可以访问除全表扫描之外的执行计划。 有关更多信息,请参见 第8.2.4节“优化性能架构查询” 。
添加新的仪器点很容易。
仪表是版本化的。 如果检测实现发生更改,则先前已检测的代码将继续工作。 这有利于第三方插件的开发人员,因为没有必要升级每个插件以与最新的性能模式更改保持同步。
MySQL
sys
模式是一组对象,可以方便地访问性能模式收集的数据。
该
sys
模式是默认安装的。
有关使用说明,请参见
第27章,
MySQL sys Schema
。
本节简要介绍了性能模式,并提供了说明如何使用它的示例。 有关其他示例,请参见 第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节“性能模式事件定时”
。
性能模式是强制性的,并且始终在其中编译。可以排除性能模式检测的某些部分。 例如,要排除阶段和语句检测,请执行以下操作:
外壳>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
。
这意味着性能模式可用,而不是它已启用。
要启用它,必须在服务器启动时执行此操作,如下一节中所述。
要使用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。
可以在运行时启用特定性能架构功能,以控制发生哪些类型的事件收集。
性能架构设置表包含有关监视配置的信息:
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
通过添加到服务器源代码的检测来收集事件。 仪器时间事件,这是性能模式提供事件所需时间的概念。 还可以配置仪器不收集定时信息。 本节讨论可用的计时器及其特征,以及如何在事件中表示计时值。
性能模式定时器的精度和开销量各不相同。
要查看可用的计时器及其特性,请查看
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
并且相关的消费者被启用。
事件以生产者/消费者方式处理:
检测代码是事件的来源,并产生要收集的事件。
该
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节“性能模式查询” 。
预过滤由性能模式完成,并具有适用于所有用户的全局效果。 预过滤可以应用于事件处理的生产者或消费者阶段:
要在生产者阶段配置预过滤,可以使用几个表:
setup_instruments
表示哪些仪器可用。
无论其他与生产相关的设置表的内容如何,此表中禁用的工具都不会生成任何事件。
允许在此表中启用的工具根据其他表的内容生成事件。
setup_objects
控制性能模式是否监视特定表和存储的程序对象。
threads
指示是否为每个服务器线程启用监视。
setup_actors
确定新前台线程的初始监视状态。
要在使用者阶段配置预过滤,请修改该
setup_consumers
表。
这确定了发送事件的目的地。
setup_consumers
也隐含地影响事件的产生。
如果给定事件不会发送到任何目标(即,不会被使用),则性能模式不会生成它。
对这些表的任何修改都会立即影响监视,但对
setup_actors
表的
修改
仅影响修改后创建的前台线程,而不影响现有线程。
更改监视配置时,性能架构不会刷新历史记录表。
已收集的事件将保留在当前事件和历史记录表中,直到被新事件取代。
如果您禁用乐器,您可能需要等待一段时间,然后才能通过感兴趣的新事件取代它们。
或者,用于
TRUNCATE
TABLE
清空历史表。
进行检测更改后,您可能希望截断摘要表。
通常,效果是将摘要列重置为0,或者
NULL
不删除行。
这使您可以清除收集的值并重新启动聚合。
例如,在您更改运行时配置之后,这可能很有用。
单个摘要表部分中记录了此截断行为的例外情况。
以下部分描述如何使用特定表来控制性能架构预过滤。
该
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 ='否';
该
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
行的
匹配
方式相同。
无法对一个表启用监视,而对另一个表启用监视。
但是,每个表都是单独检测的。
该
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
。
该
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节“性能模式语句摘要和采样” 。
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
_currentevents_waits_current
events_waits_history
events_waits_history_long
以下每个配置描述都指示性能模式检查哪些设置元素以及它维护哪些输出表(即,它收集信息的表)。
服务器配置状态:
MySQL的> SELECT * FROM performance_schema.setup_consumers;
+ --------------------------- + --------- +
| NAME | 启用|
+ --------------------------- + --------- +
| global_instrumentation | 没有|
...
+ --------------------------- + --------- +
在此配置中,不会检测任何内容。
检查设置元素:
表
setup_consumers
,消费者
global_instrumentation
保存输出表:
没有
服务器配置状态:
MySQL的> SELECT * FROM performance_schema.setup_consumers;
+ --------------------------- + --------- +
| NAME | 启用|
+ --------------------------- + --------- +
| global_instrumentation | 是的|
| thread_instrumentation | 没有|
...
+ --------------------------- + --------- +
在此配置中,仅为全局状态维护检测。 每线程检测已禁用。
相对于前面的配置,检查了其他设置元素:
表
setup_consumers
,消费者
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
_currentxxx
waits
stages
statements
transactions
柱
threads.instrumented
相对于前面的配置,维护了额外的输出表:
events_
,其中
xxx
_summary_by_yyy
_by_event_namexxx
是
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
_historyxxx
waits
stages
statements
transactions
消费者
,其中
为
,
,
,
events_
xxx
_history_longxxx
waits
stages
statements
transactions
相对于前面的配置,维护了额外的输出表:
events_
,其中
xxx
_currentxxx
是
waits
,
stages
,
statements
,
transactions
上述配置不会收集事件历史记录,因为
已禁用
和
使用者。
这些消费者可以单独或一起启用,以收集每个线程,全局或两者的事件历史记录。
events_
xxx
_historyevents_
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
_historyxxx
是
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_longxxx
是
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
_historyxxx
是
waits
,
stages
,
statements
,
transactions
events_
,其中
xxx
_history_longxxx
是
waits
,
stages
,
statements
,
transactions
为过滤操作指定的名称可以根据需要具体或一般。 要指明单个工具或消费者,请完整指定其名称:
更新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节“性能架构仪器命名约定” 。
通过查看
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版本的最新信息,还包括您可能已安装的不属于核心服务器的已检测插件的工具,并且可以由自动化工具使用。
预过滤限制收集哪些事件信息,并且独立于任何特定用户。
相比之下,后过滤是由各个用户通过使用具有适当
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节“优化性能架构查询”
。
仪器名称由一系列由
'/'
字符
分隔的组件组成
。
示例名称:
等待/ 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
优化并发性并提高读写工作负载的可伸缩性。
有几个与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_lostxxx
无法加载
多少种类型的乐器
。
Performance_schema_
表示
xxx
_instances_lostxxx
无法创建
多少个对象类型的实例
。
Performance_schema_
表示
xxx
_handles_lostxxx
无法打开
多少个对象类型的实例
。
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
。
当服务器无法创建互斥锁仪器时,会出现以下结果:
没有仪器的行插入
setup_instruments
表中。
Performance_schema_mutex_instances_lost
不会改变。
(如果未创建互斥锁仪器,则以后不能用于创建已检测的互斥锁实例。)
刚才描述的模式适用于所有类型的仪器,而不仅仅是互斥体。
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语法” 。
对于表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等待也是最近等待的任何类型。
对于等待,阶段,语句和事务事件,性能模式可以监视和存储当前事件。
此外,当事件结束时,性能模式可以将它们存储在历史表中。
对于每种事件类型,性能模式使用三个表来存储当前事件和历史事件。
该表具有以下形式的名称,其中,
xxx
指示事件类型(
waits
,
stages
,
statements
,
transactions
):
events_
:
“
当前事件
”
表存储每个线程的当前受监视事件(每个线程一行)。
xxx
_current
events_
:
“
最近历史记录
”
表存储每个线程已结束的最新事件(最多为每个线程的最大行数)。
xxx
_history
events_
:
“
long history
”
表存储全局结束的最新事件(跨所有线程,最多每个表的最大行数)。
xxx
_history_long
_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.
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 =?和......
在这种情况下,第二列名称的差异将丢失,并且两个语句都被视为相同。
在性能模式中,语句摘要涉及以下组件:
表中
的
statements_digest
使用者
setup_consumers
控制性能模式是否维护摘要信息。
请参阅
Statement Digest Consumer
。
语句事件表(
events_statements_current
,
events_statements_history
和
events_statements_history_long
)具有用于存储规范化语句摘要的列和相应的摘要SHA-256哈希值:
DIGEST_TEXT
是规范化语句摘要的文本。
这是原始规范化语句的副本,该语句被计算为最大
max_digest_length
字节数,并根据需要进一步截断为
performance_schema_max_digest_length
字节。
DIGEST
是从原始规范化语句计算的摘要SHA-256哈希值。
请参见 第26.12.6节“性能模式语句事件表” 。
该
events_statements_summary_by_digest
汇总表提供汇总声明摘要信息。
此表汇总了语句per
SCHEMA_NAME
和
DIGEST
combination的信息。
性能模式使用SHA-256哈希值进行聚合,因为它们计算速度快,并且具有有利的统计分布,可最大限度地减少冲突。
请参见
第26.12.16.3节“语句汇总表”
。
某些性能表具有一个列,用于存储从中计算摘要的原始SQL语句:
在
SQL_TEXT
该列
events_statements_current
,
events_statements_history
和
events_statements_history_long
语句事件表。
摘要表
的
QUERY_SAMPLE_TEXT
列
events_statements_summary_by_digest
。
默认情况下,语句显示的最大可用空间为1024字节。
要更改此值,请
performance_schema_max_sql_text_length
在服务器启动时
设置
系统变量。
更改会影响刚刚命名的所有列所需的存储。
的
performance_schema_max_digest_length
系统变量来确定用于摘要值存储在性能模式每语句可用的字节的最大数量。
但是,由于语句组件(如关键字和文字值)的内部编码,语句摘要的显示长度可能比可用的缓冲区大小长。
因此,从
DIGEST_TEXT
语句事件表列中
选择
的
performance_schema_max_digest_length
值
可能会超出该
值。
该
events_statements_summary_by_digest
汇总表提供了服务器执行的语句的概况。
它显示了应用程序正在执行的语句类型以及频率。
应用程序开发人员可以将此信息与表中的其他信息一起使用,以评估应用程序的性能特征。
例如,显示等待时间,锁定时间或索引使用的表列可能会突出显示效率低下的查询类型。
这使开发人员能够深入了解应用程序的哪些部分需要注意。
该
events_statements_summary_by_digest
汇总表具有固定的大小。
默认情况下,性能模式估计启动时使用的大小。
要显式指定表大小,请
performance_schema_digests_size
在服务器启动时
设置
系统变量。
如果表已满,则性能模式将具有
SCHEMA_NAME
和
DIGEST
值的
语句组合
在一个特殊行中
SCHEMA_NAME
并且
DIGEST
设置为
的表中的现有值不匹配
NULL
。
这允许计算所有陈述。
但是,如果特殊行占执行语句的很大一部分,则可能需要通过增加来增加汇总表大小
performance_schema_digests_size
。
对于生成仅在末尾不同的非常长的语句的应用程序,增加
max_digest_length
可以计算摘要,从而区分将以其他方式聚合到同一摘要的语句。
相反,减少
max_digest_length
会导致服务器将更少的内存用于消化存储,但会增加更长语句聚合到同一摘要的可能性。
管理员应该记住,较大的值会导致相应增加的内存需求,特别是对于涉及大量并发会话的工作负载(服务器
max_digest_length
为每个会话
分配
字节数)。
如前所述,由解析器计算的规范化语句摘要被约束为最大
max_digest_length
字节,而存储在性能模式中的规范化语句摘要使用
performance_schema_max_digest_length
字节。
以下内存使用注意事项适用于
max_digest_length
和
的相对值
performance_schema_max_digest_length
:
如果
max_digest_length
小于
performance_schema_max_digest_length
:
性能模式以外的服务器组件使用最多占用
max_digest_length
字节的
规范化语句摘要
。
性能模式不会进一步截断它存储的规范化语句摘要,但分配的内存多于
max_digest_length
每个摘要的字节数,这是不必要的。
如果
max_digest_length
等于
performance_schema_max_digest_length
:
性能模式以外的服务器组件使用最多占用
max_digest_length
字节的
规范化语句摘要
。
性能模式不会进一步截断它存储的规范化语句摘要,并为
max_digest_length
每个摘要
分配相同数量的内存作为
字节数。
如果
max_digest_length
大于
performance_schema_max_digest_length
:
性能模式以外的服务器组件使用最多占用
max_digest_length
字节的
规范化语句摘要
。
性能模式进一步截断了它存储的规范化语句摘要,并且
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。
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表,因此尝试
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秒)
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
。
汇总表。 这些表包含通过事件组聚合的信息,包括已从历史记录表中丢弃的事件。
实例表。 这些表记录了检测的对象类型。 当由服务器使用时,检测对象产生事件。 这些表提供事件名称和解释性说明或状态信息。
杂项表。 这些不属于任何其他表组。
下表列出了每个Performance Schema表,并提供了每个表的简短描述。
表26.1性能架构表
设置表提供有关当前检测的信息,并允许更改监视配置。
因此,如果您具有该
UPDATE
权限,
则可以更改这些表中的某些列
。
使用表而不是单个变量来设置信息可以在修改性能模式配置时提供高度的灵活性。 例如,您可以使用带有标准SQL语法的单个语句来进行多个同时进行的配置更改。
这些设置表可用:
setup_actors
:如何初始化新前台线程的监视
setup_consumers
:可以发送和存储事件信息的目标
setup_instruments
:可以为其收集事件的已检测对象的类
setup_objects
:应监控哪些对象
setup_threads
:检测线程名称和属性
该
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
表。
它删除了行。
该
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
表。
该
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
_instancesfile_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
表。
该
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
表。
它删除了行。
该
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
表。
实例表记录了检测的对象类型。 它们提供事件名称和解释性说明或状态信息:
cond_instances
:条件同步对象实例
file_instances
:文件实例
mutex_instances
:Mutex同步对象实例
rwlock_instances
:锁定同步对象实例
socket_instances
:活动连接实例
这些表列出了已检测的同步对象,文件和连接。
有三种类型的同步对象:
cond
,
mutex
,和
rwlock
。
每个实例表都有一个
EVENT_NAME
或一
NAME
列,用于指示与每行相关联的工具。
仪器名称可能有多个部分并形成层次结构,如
第26.6节“性能架构仪器命名约定”中所述
。
在
mutex_instances.LOCKED_BY_THREAD_ID
与
rwlock_instances.WRITE_LOCKED_BY_THREAD_ID
列调查性能瓶颈或死锁非常重要的。
有关如何将其用于此目的的示例,请参见
第26.19节“使用性能模式诊断问题”
该
cond_instances
表列出了服务器执行时性能模式所见的所有条件。
条件是代码中用于表示特定事件已发生的同步机制,以便等待此条件的线程可以恢复工作。
当线程正在等待某事发生时,条件名称表示线程正在等待什么,但是没有直接的方法来判断哪个其他线程或线程将导致该条件发生。
该
cond_instances
表包含以下列:
NAME
与条件关联的仪器名称。
OBJECT_INSTANCE_BEGIN
仪表化条件的内存地址。
该
cond_instances
表包含以下索引:
主键(
OBJECT_INSTANCE_BEGIN
)
索引(
NAME
)
TRUNCATE
TABLE
不允许使用该
cond_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
表。
该
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
列中)。
当一个线程成功锁定互斥锁时:
events_waits_current
显示互斥锁上的等待已完成(在
TIMER_END
和
TIMER_WAIT
列中)
已完成的等待事件将添加到
events_waits_history
和
events_waits_history_long
表中
mutex_instances
显示互斥锁现在由线程拥有(在
THREAD_ID
列中)。
当线程解锁互斥锁时,
mutex_instances
表明互斥锁现在没有所有者(
THREAD_ID
列是
NULL
)。
当销毁互斥对象时,将删除相应的行
mutex_instances
。
通过对以下两个表执行查询,监视应用程序或DBA可以检测涉及互斥锁的线程之间的瓶颈或死锁:
events_waits_current
,看看线程正在等待什么互斥量
mutex_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可以检测涉及锁的线程之间的一些瓶颈或死锁:
events_waits_current
,看看
rwlock
线程在等
什么
rwlock_instances
,查看当前拥有的其他线程
rwlock
有一个限制:
rwlock_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
服务器为其支持的每个网络协议都有一个侦听套接字。
与TCP / IP或Unix套接字文件连接的侦听套接字关联的工具的
socket_type
值
分别
为
server_tcpip_socket
或
server_unix_socket
。
当侦听套接字检测到连接时,服务器将连接传输到由单独线程管理的新套接字。
新连接线程的工具的
socket_type
值为
client_connection
。
当连接终止时,将
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
性能模式工具等待,这是需要时间的事件。 在事件层次结构中,等待事件嵌套在阶段事件中,阶段事件嵌套在事务事件中的语句事件中。
这些表存储等待事件:
events_waits_current
:每个线程的当前等待事件。
events_waits_history
:每个线程结束的最新等待事件。
events_waits_history_long
:最近全局结束的等待事件(跨所有线程)。
以下部分描述了等待事件表。 还有汇总表来汇总有关等待事件的信息; 请参见 第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节“性能架构运行时配置” 。
该
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
表。
它删除了行。
该
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节“性能架构等待事件表” 。
该
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节“性能架构等待事件表” 。
性能模式工具阶段,它们是语句执行过程中的步骤,例如解析语句,打开表或执行
filesort
操作。
阶段对应
SHOW
PROCESSLIST
于
INFORMATION_SCHEMA.PROCESSLIST
表中
显示的
或在
表
中可见
的线程状态
。
当状态值发生变化时,阶段开始和结束。
在事件层次结构中,等待事件嵌套在阶段事件中,阶段事件嵌套在事务事件中的语句事件中。
这些表存储舞台事件:
events_stages_current
:每个线程的当前阶段事件。
events_stages_history
:每个线程结束的最新阶段事件。
events_stages_history_long
:全局结束的最新阶段事件(跨所有线程)。
以下部分描述了舞台事件表。 还有汇总表,汇总有关舞台事件的信息; 请参见 第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
表中
选择
。
该
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
表。
它删除了行。
该
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节“性能架构阶段事件表” 。
该
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节“性能架构阶段事件表” 。
Performance Schema instruments语句执行。 语句事件发生在事件层次结构的高级别。 在事件层次结构中,等待事件嵌套在阶段事件中,阶段事件嵌套在事务事件中的语句事件中。
这些表存储语句事件:
events_statements_current
:每个线程的当前语句事件。
events_statements_history
:每个线程结束的最新语句事件。
events_statements_history_long
:全局结束的最新语句事件(跨所有线程)。
prepared_statements_instances
:准备好的语句实例和统计信息
以下部分描述了语句事件表。 还有汇总表来汇总有关语句事件的信息; 请参见 第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
codesmysql_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
使用并且语句事件包含指示错误性质的信息。
可以从以下任何来源获取请求:
作为来自客户端的命令或语句请求,它将请求作为数据包发送
作为从复制从站上的中继日志中读取的语句字符串
作为事件调度程序的事件
请求的详细信息最初未知,并且性能模式从抽象到特定工具名称的顺序依赖于请求的来源。
对于从客户收到的请求:
当服务器在套接字级别检测到新数据包时,将使用抽象工具名称启动新语句
statement/abstract/new_packet
。
当服务器读取数据包编号时,它会更多地了解收到的请求类型,并且性能模式会优化仪器名称。
例如,如果请求是
COM_PING
数据包,则仪器名称将成为
statement/com/Ping
最终名称。
如果请求是
COM_QUERY
数据包,则已知它对应于SQL语句但不对应于特定类型的语句。
在这种情况下,工具从一个抽象名称更改为更具体但仍然是抽象的名称
statement/abstract/Query
,并且该请求需要进一步分类。
如果请求是语句,则读取语句文本并将其提供给解析器。
解析后,确切的语句类型是已知的。
例如,如果请求是一个
INSERT
语句,则性能模式将仪器名称从
最终名称
statement/abstract/Query
改为
statement/sql/insert
。
对于从复制从站上的中继日志中读取的语句请求:
中继日志中的语句存储为文本,并按原样读取。
没有网络协议,因此
statement/abstract/new_packet
不使用
该
仪器。
相反,最初的工具是
statement/abstract/relay_log
。
解析语句时,确切的语句类型是已知的。
例如,如果请求是一个
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
因为没有任何陈述用抽象工具作为最终陈述名称进行分类。
该
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