<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h3 class="title">
      <a name="innodb-disk-io">
      </a>
      17.11.1 InnoDB Disk I/O
     </h3>
    </div>
   </div>
  </div>
  <a class="indexterm" name="idm46045160724544">
  </a>
  <p>
   <code class="literal">
    InnoDB
   </code>
   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,
   <code class="literal">
    InnoDB
   </code>
   uses the available OS and
      library functions to perform
   <span class="quote">
    “
    <span class="quote">
     native
    </span>
    ”
   </span>
   asynchronous
      I/O. On other platforms,
   <code class="literal">
    InnoDB
   </code>
   still uses I/O
      threads, but the threads may actually wait for I/O requests to
      complete; this technique is known as
   <span class="quote">
    “
    <span class="quote">
     simulated
    </span>
    ”
   </span>
   asynchronous I/O.
  </p>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h4 class="title">
       <a name="innodb-disk-io-read-ahead">
       </a>
       Read-Ahead
      </h4>
     </div>
    </div>
   </div>
   <p>
    If
    <code class="literal">
     InnoDB
    </code>
    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
    <code class="literal">
     InnoDB
    </code>
    :
   </p>
   <div class="itemizedlist">
    <ul class="itemizedlist" style="list-style-type: disc; ">
     <li class="listitem">
      <p>
       In sequential read-ahead, if
       <code class="literal">
        InnoDB
       </code>
       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.
      </p>
     </li>
     <li class="listitem">
      <p>
       In random read-ahead, if
       <code class="literal">
        InnoDB
       </code>
       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.
      </p>
     </li>
    </ul>
   </div>
   <p>
    For information about configuring read-ahead heuristics, see
    <a class="xref" href="innodb-performance-read_ahead.html" title="17.8.3.4 Configuring InnoDB Buffer Pool Prefetching (Read-Ahead)">
     Section 17.8.3.4, “Configuring InnoDB Buffer Pool Prefetching (Read-Ahead)”
    </a>
    .
   </p>
  </div>
  <div class="simplesect">
   <div class="titlepage">
    <div>
     <div class="simple">
      <h4 class="title">
       <a name="innodb-disk-io-doublewrite">
       </a>
       Doublewrite Buffer
      </h4>
     </div>
    </div>
   </div>
   <a class="indexterm" name="idm46045160709360">
   </a>
   <a class="indexterm" name="idm46045160708288">
   </a>
   <p>
    <code class="literal">
     InnoDB
    </code>
    uses a novel file flush technique
        involving a structure called the
    <a class="link" href="glossary.html#glos_doublewrite_buffer" title="doublewrite buffer">
     doublewrite
        buffer
    </a>
    , which is enabled by default in most cases
        (
    <a class="link" href="innodb-parameters.html#sysvar_innodb_doublewrite">
     <code class="literal">
      innodb_doublewrite=ON
     </code>
    </a>
    ). 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
    <code class="literal">
     fsync()
    </code>
    operations.
   </p>
   <p>
    Before writing pages to a data file,
    <code class="literal">
     InnoDB
    </code>
    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
    <code class="literal">
     InnoDB
    </code>
    write the
        pages to their proper positions in the data file. If there is an
        operating system, storage subsystem, or unexpected
    <a class="link" href="mysqld.html" title="6.3.1 mysqld — The MySQL Server">
     <span class="command">
      <strong>
       mysqld
      </strong>
     </span>
    </a>
    process exit in the middle of a page
        write (causing a
    <a class="link" href="glossary.html#glos_torn_page" title="torn page">
     torn page
    </a>
    condition),
    <code class="literal">
     InnoDB
    </code>
    can later find a good copy
        of the page from the doublewrite buffer during recovery.
   </p>
   <p>
    For more information about the doublewrite buffer, see
    <a class="xref" href="innodb-doublewrite-buffer.html" title="17.6.4 Doublewrite Buffer">
     Section 17.6.4, “Doublewrite Buffer”
    </a>
    .
   </p>
  </div>
 </div>
 <br/>
</div>
