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
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
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
It adds safety to recovery following an operating system crash or
a 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 the
operating system crashes in the middle of a page write (causing a
torn page condition),
InnoDB can later find a good copy of the page
from the doublewrite buffer during recovery.