对于表 I/O 事件，events_waits_current 中通常有两行，而不是一行。例如，一次行获取可能会产生如下类似的行：For a table I/O event, there are usually two rows in events_waits_current, not one. For example, a row fetch might result in rows like this:

Row# EVENT_NAME                 TIMER_START TIMER_END
---- ----------                 ----------- ---------
   1 wait/io/file/myisam/dfile        10001 10002
   2 wait/io/table/sql/handler        10000 NULL

行抓取会导致文件读取。在示例中，表 I/O 抓取事件在文件 I/O 事件之前开始，但尚未完成（其 TIMER_END 值为 NULL）。文件 I/O 事件在表 I/O 事件中是 “嵌套” 的。The row fetch causes a file read. In the example, the table I/O fetch event started before the file I/O event but has not finished (its TIMER_END value is NULL). The file I/O event is “nested” within the table I/O event.

之所以会这样，是因为与互斥锁或文件 I/O 等其他 “原子” 等待事件不同，表 I/O 事件是 “分子” 的，并且包括（与）其他事件重叠。在 events_waits_current 中，表 I/O 事件通常有两行：This occurs because, unlike other “atomic” wait events such as for mutexes or file I/O, table I/O events are “molecular” and include (overlap with) other events. In events_waits_current, the table I/O event usually has two rows:

通常，但并非总是，“任何类型”等待事件与表 I/O 事件不同。随着每个子事件完成，它会从 events_waits_current 中消失。此时，在下一个子事件开始之前，表 I/O 等待也是最近的任何类型等待。Usually, but not always, the “of any kind” wait event differs from the table I/O event. As each subsidiary event completes, it disappears from events_waits_current. At this point, and until the next subsidiary event begins, the table I/O wait is also the most recent wait of any kind.