Documentation Home

27.12.4.1 events_waits_current 表

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

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

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

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

events_waits_current表有以下列:

  • THREAD_ID,EVENT_ID

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

  • END_EVENT_ID

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

  • EVENT_NAME

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

  • SOURCE

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

  • TIMER_START, TIMER_END, TIMER_WAIT

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

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

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

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

  • SPINS

    对于互斥量,自旋轮数。如果值为 NULL,则代码不使用自旋轮或不检测自旋。

  • OBJECT_SCHEMA, OBJECT_NAME, OBJECT_TYPE, OBJECT_INSTANCE_BEGIN

    这些列标识了“被操作的对象这意味着什么取决于对象类型。

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

    • OBJECT_SCHEMA, OBJECT_NAME, 并且 OBJECT_TYPENULL

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

    对于文件 I/O 对象:

    • OBJECT_SCHEMANULL

    • OBJECT_NAME是文件名。

    • OBJECT_TYPEFILE

    • OBJECT_INSTANCE_BEGIN是内存中的一个地址。

    对于套接字对象:

    • OBJECT_NAMEIP: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

    嵌套事件类型。值为 TRANSACTIONSTATEMENTSTAGEWAIT

  • OPERATION

    执行的操作类型,例如 lockreadwrite

  • NUMBER_OF_BYTES

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

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

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

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

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

    通过每次扫描聚合它们(即,来自 t1和的行的每个唯一组合t2),可以显着减少检测操作的数量。通过批处理 I/O 报告,Performance Schema 为最内层表的每次扫描 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。它删除行。