<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h3 class="title">
      <a name="concurrent-inserts">
      </a>
      10.11.3 Concurrent Inserts
     </h3>
    </div>
   </div>
  </div>
  <a class="indexterm" name="idm46045222745136">
  </a>
  <a class="indexterm" name="idm46045222744064">
  </a>
  <p>
   The
   <code class="literal">
    MyISAM
   </code>
   storage engine supports concurrent
        inserts to reduce contention between readers and writers for a
        given table: If a
   <code class="literal">
    MyISAM
   </code>
   table has no holes
        in the data file (deleted rows in the middle), an
   <a class="link" href="insert.html" title="15.2.7 INSERT Statement">
    <code class="literal">
     INSERT
    </code>
   </a>
   statement can be executed
        to add rows to the end of the table at the same time that
   <a class="link" href="select.html" title="15.2.13 SELECT Statement">
    <code class="literal">
     SELECT
    </code>
   </a>
   statements are reading
        rows from the table. If there are multiple
   <a class="link" href="insert.html" title="15.2.7 INSERT Statement">
    <code class="literal">
     INSERT
    </code>
   </a>
   statements, they are
        queued and performed in sequence, concurrently with the
   <a class="link" href="select.html" title="15.2.13 SELECT Statement">
    <code class="literal">
     SELECT
    </code>
   </a>
   statements. The results of
        a concurrent
   <a class="link" href="insert.html" title="15.2.7 INSERT Statement">
    <code class="literal">
     INSERT
    </code>
   </a>
   may not be
        visible immediately.
  </p>
  <p>
   The
   <a class="link" href="server-system-variables.html#sysvar_concurrent_insert">
    <code class="literal">
     concurrent_insert
    </code>
   </a>
   system
        variable can be set to modify the concurrent-insert processing.
        By default, the variable is set to
   <code class="literal">
    AUTO
   </code>
   (or
        1) and concurrent inserts are handled as just described. If
   <a class="link" href="server-system-variables.html#sysvar_concurrent_insert">
    <code class="literal">
     concurrent_insert
    </code>
   </a>
   is set to
   <code class="literal">
    NEVER
   </code>
   (or 0), concurrent inserts are
        disabled. If the variable is set to
   <code class="literal">
    ALWAYS
   </code>
   (or 2), concurrent inserts at the end of the table are permitted
        even for tables that have deleted rows. See also the description
        of the
   <a class="link" href="server-system-variables.html#sysvar_concurrent_insert">
    <code class="literal">
     concurrent_insert
    </code>
   </a>
   system
        variable.
  </p>
  <p>
   If you are using the binary log, concurrent inserts are
        converted to normal inserts for
   <code class="literal">
    CREATE ...
        SELECT
   </code>
   or
   <a class="link" href="insert-select.html" title="15.2.7.1 INSERT ... SELECT Statement">
    <code class="literal">
     INSERT ...
        SELECT
    </code>
   </a>
   statements. This is done to ensure that you can
        re-create an exact copy of your tables by applying the log
        during a backup operation. See
   <a class="xref" href="binary-log.html" title="7.4.4 The Binary Log">
    Section 7.4.4, “The Binary Log”
   </a>
   . In
        addition, for those statements a read lock is placed on the
        selected-from table such that inserts into that table are
        blocked. The effect is that concurrent inserts for that table
        must wait as well.
  </p>
  <p>
   With
   <a class="link" href="load-data.html" title="15.2.9 LOAD DATA Statement">
    <code class="literal">
     LOAD DATA
    </code>
   </a>
   , if you specify
   <code class="literal">
    CONCURRENT
   </code>
   with a
   <code class="literal">
    MyISAM
   </code>
   table that satisfies the condition for concurrent inserts (that
        is, it contains no free blocks in the middle), other sessions
        can retrieve data from the table while
   <a class="link" href="load-data.html" title="15.2.9 LOAD DATA Statement">
    <code class="literal">
     LOAD
        DATA
    </code>
   </a>
   is executing. Use of the
   <code class="literal">
    CONCURRENT
   </code>
   option affects the performance of
   <a class="link" href="load-data.html" title="15.2.9 LOAD DATA Statement">
    <code class="literal">
     LOAD DATA
    </code>
   </a>
   a bit, even if no other
        session is using the table at the same time.
  </p>
  <p>
   If you specify
   <code class="literal">
    HIGH_PRIORITY
   </code>
   , it overrides
        the effect of the
   <a class="link" href="server-system-variables.html#sysvar_low_priority_updates">
    <code class="option">
     --low-priority-updates
    </code>
   </a>
   option if
        the server was started with that option. It also causes
        concurrent inserts not to be used.
  </p>
  <p>
   For
   <a class="link" href="lock-tables.html" title="15.3.6 LOCK TABLES and UNLOCK TABLES Statements">
    <code class="literal">
     LOCK
        TABLE
    </code>
   </a>
   , the difference between
   <code class="literal">
    READ
        LOCAL
   </code>
   and
   <code class="literal">
    READ
   </code>
   is that
   <code class="literal">
    READ LOCAL
   </code>
   permits nonconflicting
   <a class="link" href="insert.html" title="15.2.7 INSERT Statement">
    <code class="literal">
     INSERT
    </code>
   </a>
   statements (concurrent
        inserts) to execute while the lock is held. However, this cannot
        be used if you are going to manipulate the database using
        processes external to the server while you hold the lock.
  </p>
 </div>
 <br/>
</div>
