<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h3 class="title">
      <a name="innodb-benefits">
      </a>
      17.1.1 Benefits of Using InnoDB Tables
     </h3>
    </div>
   </div>
  </div>
  <p>
   <code class="literal">
    InnoDB
   </code>
   tables have the following benefits:
  </p>
  <div class="itemizedlist">
   <ul class="itemizedlist" style="list-style-type: disc; ">
    <li class="listitem">
     <p>
      If the server unexpectedly exits because of a hardware or
          software issue, regardless of what was happening in the
          database at the time, you don't need to do anything special
          after restarting the database.
      <code class="literal">
       InnoDB
      </code>
      crash
          recovery automatically finalizes changes that were committed
          before the time of the crash, and undoes changes that were in
          process but not committed, permitting you to restart and
          continue from where you left off. See
      <a class="xref" href="innodb-recovery.html" title="17.18.2 InnoDB Recovery">
       Section 17.18.2, “InnoDB Recovery”
      </a>
      .
     </p>
    </li>
    <li class="listitem">
     <p>
      The
      <code class="literal">
       InnoDB
      </code>
      storage engine maintains its own
          buffer pool that caches table and index data in main memory as
          data is accessed. Frequently used data is processed directly
          from memory. This cache applies to many types of information
          and speeds up processing. On dedicated database servers, up to
          80% of physical memory is often assigned to the buffer pool.
          See
      <a class="xref" href="innodb-buffer-pool.html" title="17.5.1 Buffer Pool">
       Section 17.5.1, “Buffer Pool”
      </a>
      .
     </p>
    </li>
    <li class="listitem">
     <p>
      If you split up related data into different tables, you can
          set up foreign keys that enforce referential integrity. See
      <a class="xref" href="create-table-foreign-keys.html" title="15.1.20.5 FOREIGN KEY Constraints">
       Section 15.1.20.5, “FOREIGN KEY Constraints”
      </a>
      .
     </p>
    </li>
    <li class="listitem">
     <p>
      If data becomes corrupted on disk or in memory, a checksum
          mechanism alerts you to the bogus data before you use it. The
      <a class="link" href="innodb-parameters.html#sysvar_innodb_checksum_algorithm">
       <code class="literal">
        innodb_checksum_algorithm
       </code>
      </a>
      variable defines the checksum algorithm used by
      <code class="literal">
       InnoDB
      </code>
      .
     </p>
    </li>
    <li class="listitem">
     <p>
      When you design a database with appropriate primary key
          columns for each table, operations involving those columns are
          automatically optimized. It is very fast to reference the
          primary key columns in
      <a class="link" href="select.html" title="15.2.13 SELECT Statement">
       <code class="literal">
        WHERE
       </code>
      </a>
      clauses,
      <a class="link" href="select.html" title="15.2.13 SELECT Statement">
       <code class="literal">
        ORDER
          BY
       </code>
      </a>
      clauses,
      <a class="link" href="select.html" title="15.2.13 SELECT Statement">
       <code class="literal">
        GROUP BY
       </code>
      </a>
      clauses, and join operations. See
      <a class="xref" href="innodb-index-types.html" title="17.6.2.1 Clustered and Secondary Indexes">
       Section 17.6.2.1, “Clustered and Secondary Indexes”
      </a>
      .
     </p>
    </li>
    <li class="listitem">
     <p>
      Inserts, updates, and deletes are optimized by an automatic
          mechanism called change buffering.
      <code class="literal">
       InnoDB
      </code>
      not only allows concurrent read and write access to the same
          table, it caches changed data to streamline disk I/O. See
      <a class="xref" href="innodb-change-buffer.html" title="17.5.2 Change Buffer">
       Section 17.5.2, “Change Buffer”
      </a>
      .
     </p>
    </li>
    <li class="listitem">
     <p>
      Performance benefits are not limited to large tables with
          long-running queries. When the same rows are accessed over and
          over from a table, the Adaptive Hash Index takes over to make
          these lookups even faster, as if they came out of a hash
          table. See
      <a class="xref" href="innodb-adaptive-hash.html" title="17.5.3 Adaptive Hash Index">
       Section 17.5.3, “Adaptive Hash Index”
      </a>
      .
     </p>
    </li>
    <li class="listitem">
     <p>
      You can compress tables and associated indexes. See
      <a class="xref" href="innodb-compression.html" title="17.9 InnoDB Table and Page Compression">
       Section 17.9, “InnoDB Table and Page Compression”
      </a>
      .
     </p>
    </li>
    <li class="listitem">
     <p>
      You can encrypt your data. See
      <a class="xref" href="innodb-data-encryption.html" title="17.13 InnoDB Data-at-Rest Encryption">
       Section 17.13, “InnoDB Data-at-Rest Encryption”
      </a>
      .
     </p>
    </li>
    <li class="listitem">
     <p>
      You can create and drop indexes and perform other DDL
          operations with much less impact on performance and
          availability. See
      <a class="xref" href="innodb-online-ddl-operations.html" title="17.12.1 Online DDL Operations">
       Section 17.12.1, “Online DDL Operations”
      </a>
      .
     </p>
    </li>
    <li class="listitem">
     <p>
      Truncating a file-per-table tablespace is very fast and can
          free up disk space for the operating system to reuse rather
          than only
      <code class="literal">
       InnoDB
      </code>
      . See
      <a class="xref" href="innodb-file-per-table-tablespaces.html" title="17.6.3.2 File-Per-Table Tablespaces">
       Section 17.6.3.2, “File-Per-Table Tablespaces”
      </a>
      .
     </p>
    </li>
    <li class="listitem">
     <p>
      The storage layout for table data is more efficient for
      <a class="link" href="blob.html" title="13.3.4 The BLOB and TEXT Types">
       <code class="literal">
        BLOB
       </code>
      </a>
      and long text fields, with
          the
      <code class="literal">
       DYNAMIC
      </code>
      row format. See
      <a class="xref" href="innodb-row-format.html" title="17.10 InnoDB Row Formats">
       Section 17.10, “InnoDB Row Formats”
      </a>
      .
     </p>
    </li>
    <li class="listitem">
     <p>
      You can monitor the internal workings of the storage engine by
          querying
      <code class="literal">
       INFORMATION_SCHEMA
      </code>
      tables. See
      <a class="xref" href="innodb-information-schema.html" title="17.15 InnoDB INFORMATION_SCHEMA Tables">
       Section 17.15, “InnoDB INFORMATION_SCHEMA Tables”
      </a>
      .
     </p>
    </li>
    <li class="listitem">
     <p>
      You can monitor the performance details of the storage engine
          by querying Performance Schema tables. See
      <a class="xref" href="innodb-performance-schema.html" title="17.16 InnoDB Integration with MySQL Performance Schema">
       Section 17.16, “InnoDB Integration with MySQL Performance Schema”
      </a>
      .
     </p>
    </li>
    <li class="listitem">
     <p>
      You can mix
      <code class="literal">
       InnoDB
      </code>
      tables with tables from
          other MySQL storage engines, even within the same statement.
          For example, you can use a join operation to combine data from
      <code class="literal">
       InnoDB
      </code>
      and
      <a class="link" href="memory-storage-engine.html" title="18.3 The MEMORY Storage Engine">
       <code class="literal">
        MEMORY
       </code>
      </a>
      tables in a single query.
     </p>
    </li>
    <li class="listitem">
     <p>
      <code class="literal">
       InnoDB
      </code>
      has been designed for CPU efficiency
          and maximum performance when processing large data volumes.
     </p>
    </li>
    <li class="listitem">
     <p>
      <code class="literal">
       InnoDB
      </code>
      tables can handle large quantities
          of data, even on operating systems where file size is limited
          to 2GB.
     </p>
    </li>
   </ul>
  </div>
  <p>
   For
   <code class="literal">
    InnoDB
   </code>
   -specific tuning techniques you can
      apply to your MySQL server and application code, see
   <a class="xref" href="optimizing-innodb.html" title="10.5 Optimizing for InnoDB Tables">
    Section 10.5, “Optimizing for InnoDB Tables”
   </a>
   .
  </p>
 </div>
 <br/>
</div>
