MySQL 8.3 Release Notes
该 events_waits_current 表包含当前等待事件。该表存储每个线程的当前状态，显示线程最近的监控等待事件，因此没有系统变量来配置表大小。
在包含等待事件行的表中，events_waits_current 是最基本的。其他包含等待事件行的表是从当前事件逻辑派生的。例如，events_waits_history 和 events_waits_history_long 表是每个线程和所有线程的最近等待事件的集合，分别。
有关三个等待事件表之间关系的更多信息，请参阅 第 29.9 节，“性能模式当前和历史事件表”。
有关配置是否收集等待事件的信息，请参阅 第 29.12.4 节，“性能模式等待事件表”。
该 events_waits_current 表具有以下列：
-
THREAD_ID,EVENT_ID与事件关联的线程和事件开始时的线程当前事件号。
THREAD_ID和EVENT_ID值组合唯一标识该行。没有两个行具有相同的对值。 -
END_EVENT_ID该列在事件开始时设置为
NULL，并在事件结束时更新为线程当前事件号。 -
EVENT_NAME产生事件的仪器名称。这是一个
NAME值来自setup_instruments表。仪器名称可能具有多个部分，并形成一个层次结构，如 第 29.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。有关皮秒作为事件时间单位的讨论和影响时间值的因素，请参阅 第 29.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 使用嵌套循环实现连接。性能模式仪器的任务是提供每个表的行计数和累积执行时间。在执行连接查询时，假设查询的形式如下所示，并使用表连接顺序
t1,t2,t3：SELECT ... FROM t1 JOIN t2 ON ... JOIN t3 ON ...表 “fanout” 是在连接处理中添加表时行数的增加或减少。如果表
t3的 fanout 大于 1，那么大多数行提取操作都是针对该表的。假设连接访问t1的 10 行，t2的 20 行（每行来自t1），t3的 30 行（每行来自t2）。使用单行报告，总的仪器操作数为：10 + (10 * 20) + (10 * 20 * 30) = 6210通过聚合每个扫描（即，每个唯一的
t1和t2行组合），可以实现仪器操作数的显著减少。使用批量 I/O 报告，性能模式将为每个扫描 innermost 表t3生成事件，而不是每行，仪器行操作数减少到：10 + (10 * 20) + (10 * 20) = 410这是 93% 的减少，表明批量报告策略可以显著减少性能模式的开销，以减少报告调用次数。 tradeoff 是事件计时的准确性较低。相比于每行操作的时间，批量 I/O 的时间包括连接缓冲、聚合和将行返回给客户端的时间。
要使批量 I/O 报告发生，以下条件必须为真：
-
查询执行访问查询块中的最内层表（对于单表查询，该表计为最内层）
-
查询执行不请求表中的单行（因此，例如，
eq_ref访问防止批量报告的使用） -
查询执行不评估包含表访问的子查询
-
-
FLAGS保留供将来使用。
该 events_waits_current 表具有以下索引：
-
主键在 (
THREAD_ID,EVENT_ID) 上
TRUNCATE TABLE 允许用于 events_waits_current 表。它删除行。