The Performance Schema maintains file I/O summary tables that aggregate information about I/O operations.
Example file I/O event summary information:
mysql> SELECT * FROM file_summary_by_instance\G
...
*************************** 2. row ***************************
FILE_NAME: /var/mysql/share/english/errmsg.sys
EVENT_NAME: wait/io/file/sql/ERRMSG
COUNT_READ: 3
COUNT_WRITE: 0
SUM_NUMBER_OF_BYTES_READ: 42211
SUM_NUMBER_OF_BYTES_WRITE: 0
...
*************************** 6. row ***************************
FILE_NAME: /var/mysql/data/binlog.000001
EVENT_NAME: wait/io/file/sql/binlog
COUNT_READ: 0
COUNT_WRITE: 0
SUM_NUMBER_OF_BYTES_READ: 0
SUM_NUMBER_OF_BYTES_WRITE: 0
...
Each file I/O summary table has one or more grouping columns
to indicate how the table aggregates events. Event names refer
to names of event instruments in the
setup_instruments table.
file_summary_by_event_name
has an EVENT_NAME column. Each row
summarizes events for a given event name.
file_summary_by_instance has
FILE_NAME and
EVENT_NAME columns. Each row summarizes
events for a given file instrument instance.
Each file I/O summary table has these summary columns containing aggregated values:
COUNT_READ
The number of read operations in the summarized events.
COUNT_WRITE
The number of write operations in the summarized events.
SUM_NUMBER_OF_BYTES_READ
The number of bytes read in the summarized events.
SUM_NUMBER_OF_BYTES_WRITE
The number of bytes written in the summarized events.
TRUNCATE TABLE is permitted for
file I/O summary tables. It resets the summary columns to zero
rather than removing rows.
The MySQL server uses several techniques to avoid I/O operations by caching information read from files, so it is possible that statements you might expect to result in I/O events will not. You may be able to ensure that I/O does occur by flushing caches or restarting the server to reset its state.