文档首页
MySQL 8.4 参考手册
相关文档 下载本手册
PDF (US Ltr) - 39.9Mb
PDF (A4) - 40.0Mb
手册页 (TGZ) - 258.5Kb
手册页 (Zip) - 365.5Kb
Info (Gzip) - 4.0Mb
Info (Zip) - 4.0Mb


29.12.4.1 events_waits_current 表

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

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

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

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

The events_waits_current 表具有以下列

  • THREAD_ID, EVENT_ID

    与事件关联的线程,以及事件开始时线程的当前事件号。 THREAD_IDEVENT_ID 的值组合在一起可以唯一标识该行。没有两行具有相同的数值对。

  • END_EVENT_ID

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

  • EVENT_NAME

    产生该事件的仪器名称。这是一个来自 setup_instruments 表的 NAME 值。仪器名称可能有多个部分,并形成一个层次结构,如 第 29.6 节,“性能模式仪器命名约定” 中所述。

  • SOURCE

    包含产生事件的已完成 instrumentation 代码的源文件名称,以及 instrumentation 发生的源文件中的行号。这使您能够检查源代码以确定确切涉及的代码。例如,如果互斥锁或锁被阻塞,则可以检查发生此情况的上下文。

  • TIMER_START, TIMER_END, TIMER_WAIT

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

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

    如果事件是从具有 TIMED = NO 的仪器产生的,则不会收集计时信息,并且 TIMER_STARTTIMER_ENDTIMER_WAIT 均为 NULL

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

  • SPINS

    对于互斥锁,自旋轮数。如果值为 NULL,则代码不使用自旋轮,或者自旋未完成 instrumentation。

  • OBJECT_SCHEMA, OBJECT_NAME, OBJECT_TYPE, OBJECT_INSTANCE_BEGIN

    这些列标识了“被操作的对象”。对象的含义取决于对象类型。

    对于同步对象(cond, mutex, rwlock

    • OBJECT_SCHEMA, OBJECT_NAMEOBJECT_TYPENULL

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

    对于文件 I/O 对象

    • OBJECT_SCHEMANULL

    • OBJECT_NAME 是文件名。

    • OBJECT_TYPEFILE

    • 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 表示表的 primary 索引。 NULL 表示没有使用索引。

  • NESTING_EVENT_ID

    此事件嵌套在其中的事件的 EVENT_ID 值。

  • NESTING_EVENT_TYPE

    嵌套事件类型。该值为 TRANSACTION, STATEMENT, STAGEWAIT

  • OPERATION

    执行的操作类型,例如 lock, readwrite

  • 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 ...

    表“fanout”是在连接处理过程中添加表时行数的增加或减少。如果表 t3 的 fanout 大于 1,则大多数行提取操作都是针对该表。假设连接从 t1 访问 10 行,从 t2 访问每行 t1 的 20 行,从 t3 访问每行 t2 的 30 行。使用单行报告,仪表化操作的总数为

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

    通过将它们按扫描(即,按 t1t2 的行唯一组合)进行聚合,可以显著减少仪表化操作的数量。使用批处理 I/O 报告,Performance Schema 为每个最内层表 t3 的扫描生成一个事件,而不是为每行生成一个事件,并且仪表化行操作的数量减少到

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

    即减少了 93%,说明批处理报告策略如何通过减少报告调用次数来显著降低表 I/O 的 Performance Schema 开销。权衡是事件时间的准确性较低。与按行报告中的单个行操作时间不同,批处理 I/O 的时间包括用于连接缓冲、聚合和将行返回给客户端等操作的时间。

    为了执行批处理 I/O 报告,必须满足以下条件

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

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

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

  • FLAGS

    为将来使用保留。

events_waits_current 表具有以下索引

  • 主键 (THREAD_ID, EVENT_ID)

TRUNCATE TABLE 允许用于 events_waits_current 表。它会删除行。