For a table I/O event, there are usually two rows in *note 'events_waits_current': performance-schema-events-waits-current-table, 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 NULLThe 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.
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 *note 'events_waits_current': performance-schema-events-waits-current-table, the table I/O event usually has two rows:
One row for the most recent table I/O wait event
One row for the most recent wait event of any kind
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 *note 'events_waits_current': performance-schema-events-waits-current-table. At this point, and until the next subsidiary event begins, the table I/O wait is also the most recent wait of any kind.
File: manual.info.tmp, Node: performance-schema-event-tables, Next: performance-schema-statement-digests, Prev: performance-schema-atom-molecule-events, Up: performance-schema