MySQL 8.4 Release Notes
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.
For information about configuring read-ahead heuristics, see Section 17.8.3.4, “Configuring InnoDB Buffer Pool Prefetching (Read-Ahead)”.
InnoDB uses a novel file flush technique
involving a structure called the
doublewrite
buffer, which is enabled by default in most cases
(innodb_doublewrite=ON). It
adds safety to recovery following an unexpected exit or power
outage, and improves performance on most varieties of Unix by
reducing the need for fsync() operations.
Before writing pages to a data file, InnoDB
first writes them to a storage area called the doublewrite
buffer. Only after the write and the flush to the doublewrite
buffer has completed does InnoDB write the
pages to their proper positions in the data file. If there is an
operating system, storage subsystem, or unexpected
mysqld process exit 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.
For more information about the doublewrite buffer, see Section 17.6.4, “Doublewrite Buffer”.