MySQL 9.0 发行说明
该 events_waits_current 表包含当前等待事件。该表为每个线程存储一行，显示线程最近监控的等待事件的当前状态，因此没有用于配置表大小的系统变量。
在包含等待事件行的表中，events_waits_current 是最基本的一个。其他包含等待事件行的表从当前事件逻辑派生而来。例如，events_waits_history 和 events_waits_history_long 表是最近结束的等待事件的集合，分别最多包含每个线程的行数和所有线程的全局行数。
有关三个等待事件表之间关系的更多信息，请参见 第 29.9 节，“Performance Schema 用于当前和历史事件的表”。
有关配置是否收集等待事件的信息，请参见 第 29.12.4 节，“Performance Schema 等待事件表”。
该 events_waits_current 表具有以下列
THREAD_ID,EVENT_ID与事件关联的线程以及事件开始时线程的当前事件编号。
THREAD_ID和EVENT_ID值一起唯一标识该行。没有两行具有相同的价值对。END_EVENT_ID此列在事件开始时设置为
NULL，并在事件结束时更新为线程的当前事件编号。EVENT_NAME生成事件的仪器的名称。这是来自
setup_instruments表的NAME值。仪器名称可能包含多个部分并形成层次结构，如 第 29.6 节，“Performance Schema 仪器命名约定” 中所述。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 节，“Performance Schema 事件计时”。
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 ...表 “fanout” 是在连接处理过程中添加表后行数的增加或减少。如果表
t3的扇出大于 1，则大多数行获取操作都针对该表。假设连接从t1访问 10 行，从t2访问每行t1的 20 行，从t3访问每行t2的 30 行。使用单行报告，检测到的操作总数为10 + (10 * 20) + (10 * 20 * 30) = 6210通过按扫描（即，按
t1和t2的唯一行组合）聚合操作，可以显著减少检测到的操作数。使用批处理 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 表。它删除行。