InnoDB uses asynchronous disk I/O where
possible, by creating a number of threads to handle I/O
operations, while permitting other database operations to proceed
while the I/O is still in progress. On Linux and Windows
platforms, InnoDB uses the available OS and library functions to
perform “native” asynchronous I/O. On other
platforms, InnoDB still uses I/O threads, but the threads may
actually wait for I/O requests to complete; this technique is
known as “simulated” asynchronous I/O.
If InnoDB can determine there is a high probability that data might be needed soon, it performs read-ahead operations to bring that data into the buffer pool so that it is available in memory. Making a few large read requests for contiguous data can be more efficient than making several small, spread-out requests. There are two read-ahead heuristics in InnoDB:
In sequential read-ahead, if
InnoDBnotices that the access pattern to a segment in the tablespace is sequential, it posts in advance a batch of reads of database pages to the I/O system.
In random read-ahead, if
InnoDBnotices that some area in a tablespace seems to be in the process of being fully read into the buffer pool, it posts the remaining reads to the I/O system.
InnoDB uses a novel file flush technique
involving a structure called the
which is enabled by default
innodb_doublewrite=ON). It adds
safety to recovery following a crash or power outage, and improves
performance on most varieties of Unix by reducing the need for
Before writing pages to a data file,
first writes them to a contiguous tablespace area called the
doublewrite buffer. Only after the write and the flush to the
doublewrite buffer has completed does
write the pages to their proper positions in the data file. If
there is an operating system, storage subsystem, or
mysqld process crash in the middle of a page
write (causing a torn page
InnoDB can later find a good copy
of the page from the doublewrite buffer during recovery.