25.12.4.1 events_waits_currenttable

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

在包含 await 事件行的 table 中，events_waits_current是最基本的。包含 await 事件行的其他 table 在逻辑上是从当前事件派生的。例如，events_waits_history和events_waits_history_longtable 是已结束的最近 await 事件的集合，每个事件最多可容纳最多的行数，并且在所有线程中最多可全局容纳。

有关三个 await 事件 table 之间的关系的更多信息，请参见第 25.9 节“当前和历史事件的性能架构 table”。

有关配置是否收集 await 事件的信息，请参见第 25.12.4 节“性能架构 await 事件 table”。

events_waits_currenttable 具有以下列：

• THREAD_ID , EVENT_ID

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

• END_EVENT_ID

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

• EVENT_NAME

产生事件的仪器的名称。这是setup_instrumentstable 中的NAME值。乐器名称可能包含多个部分，并形成一个层次结构，如第 25.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。

有关以皮秒为单位的事件时间和影响时间值的因素的讨论，请参阅第 25.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是内存中的地址。

对于 tableI/O 对象：

• OBJECT_SCHEMA是包含 table 的架构的名称。

  • OBJECT_NAME是 table 名。

  • OBJECT_TYPE是TABLE(对于持久基 table)或TEMPORARY TABLE(对于临时 table)。

  • OBJECT_INSTANCE_BEGIN是内存中的地址。

OBJECT_INSTANCE_BEGIN值本身没有意义，只是不同的值 table 示不同的对象。 OBJECT_INSTANCE_BEGIN可用于调试。例如，它可以与GROUP BY OBJECT_INSTANCE_BEGIN一起使用，以查看 1,000 个互斥锁(例如，保护 1,000 个页面或数据块)上的负载是平均分布的还是遇到了几个瓶颈。如果在日志文件或其他调试或性能工具中看到相同的对象地址，这可以帮助您与其他信息源关联。

• INDEX_NAME

使用的索引名称。 PRIMARYtable 示 table 的主索引。 NULLtable 示未使用索引。

• NESTING_EVENT_ID

嵌套该事件的事件的EVENT_ID值。

• NESTING_EVENT_TYPE

嵌套事件类型。值为TRANSACTION，STATEMENT，STAGE或WAIT。

• OPERATION

执行的操作类型，例如lock，read或write。

• NUMBER_OF_BYTES

操作读取或写入的字节数。对于 tableI/Oawait(wait/io/table/sql/handler仪器的事件)，NUMBER_OF_BYTEStable 示行数。如果该值大于 1，则该事件用于批处理 I/O 操作。下面的讨论描述了单行报告与反映批处理 I/O 的报告之间的区别。

MySQL 使用嵌套循环实现执行联接。 Performance Schema 工具的工作是提供 Connecting 每个 table 的行数和累积执行时间。假设使用 tablet1，t2，t3的 table 连接 Sequences 执行的以下形式的连接查询：

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

table“扇出”是联接处理期间由于添加 table 而增加或减少的行数。如果 tablet3的扇出大于 1，则大多数行提取操作都针对该 table。假设联接访问 tablet2的每行从t1到 10 行，从t1的每行从t2到 20 行，从t3的访问每行t3到 30 行。使用单行报告时，已执行的操作总数为：

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

通过在每次扫描(即，来自t1和t2的行的唯一组合)中汇总操作，可以大大减少检测操作的数量。使用批处理 I/O 报告，性能模式会针对最里面的 tablet3的每次扫描而不是每一行生成一个事件，并且检测到的行操作的数量减少为：

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

减少了 93％，说明了批处理报告策略如何通过减少报告调用次数显着减少了 tableI/O 的性能架构开销。权衡是事件计时的准确性较低。批处理 I/O 的时间而不是像单行报告中那样为单个行操作花费时间，而是包括诸如连接缓冲，聚合以及将行返回给 Client 端之类的操作所花费的时间。

为了进行批量 I/O 报告，必须满足以下条件：

• 查询执行访问查询块的最内 table(对于单 table 查询，该 table 计为最内 table)

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

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

• FLAGS

保留以备将来使用。

events_waits_currenttable 允许TRUNCATE TABLE。它删除行。