MySQL :: MySQL 8.4 Reference Manual :: 29.12.4.1 The events_waits

version 8.4

8.0 current
5.7

8.0 Japanese

MySQL 8.4 Reference Manual / ... / The events_waits_current Table

29.12.4.1 events_waits_current 表

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

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

关于三个等待事件表之间的关系，请参阅第29.9节，“Performance Schema Tables for Current and Historical Events”。

关于配置是否收集等待事件的信息，请参阅第29.12.4节，“Performance Schema Wait Event Tables”。

The events_waits_current 表具有以下列：

THREAD_ID, EVENT_ID

与事件关联的线程和线程当前事件号，当事件开始时。THREAD_ID 和 EVENT_ID 值组成唯一的行标识符。没有两个行具有相同的对值。
END_EVENT_ID

该列在事件开始时设置为 NULL，当事件结束时更新到线程当前事件号。
EVENT_NAME

事件名称。该名称来自setup_instruments 表中的 NAME 值。仪器名称可能具有多个部分，形成层次结构，如第29.6节，“Performance Schema Instrument Naming Conventions”中讨论的那样。
SOURCE

事件产生的源文件名称和行号，该文件包含了事件产生的代码。这样可以检查源代码，以确定具体的代码是哪个。例如，如果锁或互斥锁被阻塞，可以检查上下文，以确定阻塞的原因。
TIMER_START, TIMER_END, TIMER_WAIT

事件的计时信息。这些值的单位是-pic秒（十亿分之一秒）。TIMER_START 和 TIMER_END 值表示事件计时的开始和结束。TIMER_WAIT 是事件的延迟时间（持续时间）。

如果事件尚未完成，TIMER_END 是当前计时值，TIMER_WAIT 是到目前为止的时间（TIMER_END - TIMER_START）。

如果事件来自于一个不记录时间的工具，那么计时信息将不被收集，TIMER_START、TIMER_END 和 TIMER_WAIT 都将是 NULL。

关于-pic秒作为事件时间的单位和影响时间值的因素，请参见第29.4.1节，“性能架构事件计时”。
SPINS

对于互斥锁，spin rounds的数量。如果值为 NULL，那么代码不使用spin rounds或spin rounds没有被instrumented。
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 是内存中的地址。
对于socket对象：
- OBJECT_NAME 是socket的 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

事件的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 使用嵌套循环实现连接。性能Schema工具的任务是为每个表在连接中的行数和累积执行时间提供统计信息。假设以下形式的连接查询被执行，使用表连接顺序t1、t2、t3：
```
SELECT ... FROM t1 JOIN t2 ON ... JOIN t3 ON ...
```
““fanout””是连接处理时添加表时行数的增加或减少。如果t3的fanout值大于1，majority的行fetch操作都是对该表的。假设连接访问t1的10行、t2的20行和t3的30行。单行报告中，总的instrumented操作数为：
```
10 + (10 * 20) + (10 * 20 * 30) = 6210
```
通过将instrumented操作聚合到扫描（即唯一的表t1和t2的组合）可以实现 instrumented操作的显著减少。批处理I/O报告中，性能Schema生成事件每个扫描的innermost表t3，而不是每行，instrumented行操作数减少到：
```
10 + (10 * 20) + (10 * 20) = 410
```
这是一种93%的减少，表明批处理报告策略对表I/O性能Schema的开销的减少。然而，这种策略的tradeoff是事件时间的不准确性。相比单行报告，批处理I/O报告包括时间用于操作如join缓冲、聚合和返回行给客户端的时间。

为了使批量I/O报告出现，必须满足以下条件：
- 查询执行访问查询块的最内层表（对于单表查询，该表视为最内层）
- 查询执行不请求从表中获取单行数据（例如，eq_ref访问将阻止批量报告的使用）
- 查询执行不评估包含表访问的子查询
FLAGS

保留用于将来使用。

The events_waits_current 表具有以下索引：

主键（THREAD_ID，EVENT_ID）

TRUNCATE TABLE 允许对 events_waits_current 表进行。它将删除行。

PREV HOME UP NEXT