InnoDB Disk I/O •Enabling or disabling features that provide extra durability at the expense of additional I/O. •Organizing tables into many small files, a few larger files, or a combination of both. •Balancing the size of redo log files against the I/O activity that occurs when the log files become full. •How to reorganize a table for optimal query performance. 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 : For information about configuring read-ahead heuristics, see Section 15.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 15.6.4, “Doublewrite Buffer” . The data files that you define in the configuration file using the  innodb_data_file_path  configuration option form the  InnoDB  system tablespace. The files are logically concatenated to form the system tablespace. There is no striping in use. You cannot define where within the system tablespace your tables are allocated. In a newly created system tablespace,  InnoDB  allocates space starting from the first data file. To avoid the issues that come with storing all tables and indexes inside the system tablespace, you can enable the  innodb_file_per_table  configuration option (the default), which stores each newly 15.11.2 File Space Management Doublewrite Buffer Read-Ahead 15.11.1 InnoDB Disk I/O •In sequential read-ahead, if  InnoDB  notices 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  InnoDB  notices 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. 3172