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
      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.
    
      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:
- 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
      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.