Performance Schema Tables for Current and Historical Events 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. For wait, stage, statement, and transaction events, the Performance Schema can monitor and store current events. In addition, when events end, the Performance Schema can store them in history tables. For each event type, the Performance Schema uses three tables for storing current and historical events. The tables have names of the following forms, where  xxx  indicates the event type ( waits ,  stages ,  statements , transactions ): 27.9 Performance Schema Tables for Current and Historical Events The difference between the two types of history tables relates to the data retention policy. Both tables contains the same data when an event is first seen. However, data within each table expires differently over time, so that data might be preserved for a longer or shorter time in each table: 4932 • _history_long  is meant to investigate the server globally, not each thread. • _history  is meant to investigate individual threads, independently of the global server load. • events_ xxx _history_long : The “long history”  table stores the most recent events that have ended globally (across all threads, up to a maximum number of rows per table). • events_ xxx _history : The “recent history”  table stores the most recent events that have ended per thread (up to a maximum number of rows per thread). • events_ xxx _current : The “current events”  table stores the current monitored event for each thread (one row per thread). The  _current  table for each event type contains one row per thread, so there is no system variable for configuring its maximum size. The Performance Schema autosizes the history tables, or the sizes can be configured explicitly at server startup using table-specific system variables, as indicated in the sections that describe the individual history tables. Typical autosized values are 10 rows per thread for  _history tables, and 10,000 rows total for  _history_long  tables. For each event type, the  _current ,  _history , and  _history_long  tables have the same columns. The  _current  and  _history  tables have the same indexing. The  _history_long  table has no indexing. The  _current  tables show what is currently happening within the server. When a current event ends, it is removed from its  _current  table. The  _history  and  _history_long  tables show what has happened in the recent past. When the history tables become full, old events are discarded as new events are added. Rows expire from the  _history and  _history_long  tables in different ways because the tables serve different purposes: