File: mysqlqb_statements.html

package info (click to toggle)
mysql-gui-tools 5.0r14%2BopenSUSE-2.1
links: PTS, VCS
area: main
in suites: squeeze
size: 116,956 kB
ctags: 48,715
sloc: sql: 341,918; pascal: 276,698; ansic: 91,020; cpp: 90,451; objc: 33,236; sh: 29,481; yacc: 10,756; xml: 10,589; java: 10,079; php: 2,806; python: 2,092; makefile: 1,783; perl: 4
file content (12147 lines) | stat: -rw-r--r-- 822,888 bytes
parent folder | download | duplicates (2)
<?xml version="1.0" encoding="utf-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8" /><title>SQL Statement Syntax</title><link rel="stylesheet" href="main.css" type="text/css" /><meta name="generator" content="DocBook XSL Stylesheets V1.69.1" /><link rel="start" href="index.html" title="Query Browser Help" /><link rel="up" href="index.html" title="Query Browser Help" /><link rel="prev" href="mysqlqb_functions.html" title="Functions and Operators" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">SQL Statement Syntax</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="mysqlqb_functions.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> </td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="sql-syntax"></a>SQL Statement Syntax</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="mysqlqb_statements.html#data-definition">Data Definition Statements</a></span></dt><dd><dl><dt><span class="section"><a href="mysqlqb_statements.html#alter-database"><code class="literal">ALTER DATABASE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#alter-table"><code class="literal">ALTER TABLE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#create-database"><code class="literal">CREATE DATABASE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#create-index"><code class="literal">CREATE INDEX</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#create-table"><code class="literal">CREATE TABLE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#drop-database"><code class="literal">DROP DATABASE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#drop-index"><code class="literal">DROP INDEX</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#drop-table"><code class="literal">DROP TABLE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#rename-table"><code class="literal">RENAME TABLE</code> Syntax</a></span></dt></dl></dd><dt><span class="section"><a href="mysqlqb_statements.html#data-manipulation">Data Manipulation Statements</a></span></dt><dd><dl><dt><span class="section"><a href="mysqlqb_statements.html#delete"><code class="literal">DELETE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#do"><code class="literal">DO</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#handler"><code class="literal">HANDLER</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#insert"><code class="literal">INSERT</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#load-data"><code class="literal">LOAD DATA INFILE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#replace"><code class="literal">REPLACE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#select"><code class="literal">SELECT</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#subqueries">Subquery Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#truncate"><code class="literal">TRUNCATE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#update"><code class="literal">UPDATE</code> Syntax</a></span></dt></dl></dd><dt><span class="section"><a href="mysqlqb_statements.html#basic-user-commands">MySQL Utility Statements</a></span></dt><dd><dl><dt><span class="section"><a href="mysqlqb_statements.html#describe"><code class="literal">DESCRIBE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#help"><code class="literal">HELP</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#use"><code class="literal">USE</code> Syntax</a></span></dt></dl></dd><dt><span class="section"><a href="mysqlqb_statements.html#transactional-commands">MySQL Transactional and Locking Statements</a></span></dt><dd><dl><dt><span class="section"><a href="mysqlqb_statements.html#commit"><code class="literal">START TRANSACTION</code>, <code class="literal">COMMIT</code>, and
        <code class="literal">ROLLBACK</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#cannot-roll-back">Statements That Cannot Be Rolled Back</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#implicit-commit">Statements That Cause an Implicit Commit</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#savepoints"><code class="literal">SAVEPOINT</code> and <code class="literal">ROLLBACK TO
        SAVEPOINT</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#lock-tables"><code class="literal">LOCK TABLES</code> and <code class="literal">UNLOCK TABLES</code>
        Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#set-transaction"><code class="literal">SET TRANSACTION</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#xa">XA Transactions</a></span></dt></dl></dd><dt><span class="section"><a href="mysqlqb_statements.html#database-administration-statements">Database Administration Statements</a></span></dt><dd><dl><dt><span class="section"><a href="mysqlqb_statements.html#account-management-sql">Account Management Statements</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#table-maintenance-sql">Table Maintenance Statements</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#set-option"><code class="literal">SET</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#show"><code class="literal">SHOW</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#other-administrative-sql">Other Administrative Statements</a></span></dt></dl></dd><dt><span class="section"><a href="mysqlqb_statements.html#replication-sql">Replication Statements</a></span></dt><dd><dl><dt><span class="section"><a href="mysqlqb_statements.html#replication-master-sql">SQL Statements for Controlling Master Servers</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#replication-slave-sql">SQL Statements for Controlling Slave Servers</a></span></dt></dl></dd><dt><span class="section"><a href="mysqlqb_statements.html#sqlps">SQL Syntax for Prepared Statements</a></span></dt></dl></div><p>
    This chapter describes the syntax for most of the SQL statements
    supported by MySQL. Additional statement descriptions can be found
    in the following chapters:
  </p><div class="itemizedlist"><ul type="disc"><li><p>
        The <code class="literal">EXPLAIN</code> statement is discussed in
        <a href="http://dev.mysql.com/doc/refman/5.0/en/optimization.html" target="_top">Optimization</a>.
      </p></li><li><p>
        Statements for writing stored routines are covered in
        <a href="http://dev.mysql.com/doc/refman/5.0/en/stored-procedures.html" target="_top">Stored Procedures and Functions</a>.
      </p></li><li><p>
        Statements for writing triggers are covered in
        <a href="http://dev.mysql.com/doc/refman/5.0/en/triggers.html" target="_top">Triggers</a>.
      </p></li><li><p>
        View-related statements are covered in <a href="http://dev.mysql.com/doc/refman/5.0/en/views.html" target="_top">Views</a>.
      </p></li></ul></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="data-definition"></a>Data Definition Statements</h2></div></div></div><div class="toc"><dl><dt><span class="section"><a href="mysqlqb_statements.html#alter-database"><code class="literal">ALTER DATABASE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#alter-table"><code class="literal">ALTER TABLE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#create-database"><code class="literal">CREATE DATABASE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#create-index"><code class="literal">CREATE INDEX</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#create-table"><code class="literal">CREATE TABLE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#drop-database"><code class="literal">DROP DATABASE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#drop-index"><code class="literal">DROP INDEX</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#drop-table"><code class="literal">DROP TABLE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#rename-table"><code class="literal">RENAME TABLE</code> Syntax</a></span></dt></dl></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="alter-database"></a><code class="literal">ALTER DATABASE</code> Syntax</h3></div></div></div><a id="id2857643" class="indexterm"></a><a id="id2857650" class="indexterm"></a><a id="id2857657" class="indexterm"></a><a id="id2857667" class="indexterm"></a><a id="id2857677" class="indexterm"></a><a id="id2857687" class="indexterm"></a><pre class="programlisting">ALTER {DATABASE | SCHEMA} [<em class="replaceable"><code>db_name</code></em>]
    <em class="replaceable"><code>alter_specification</code></em> [<em class="replaceable"><code>alter_specification</code></em>] ...

<em class="replaceable"><code>alter_specification</code></em>:
    [DEFAULT] CHARACTER SET <em class="replaceable"><code>charset_name</code></em>
  | [DEFAULT] COLLATE <em class="replaceable"><code>collation_name</code></em>
</pre><p>
        <code class="literal">ALTER DATABASE</code> enables you to change the
        overall characteristics of a database. These characteristics are
        stored in the <code class="filename">db.opt</code> file in the database
        directory. To use <code class="literal">ALTER DATABASE</code>, you need
        the <code class="literal">ALTER</code> privilege on the database.
        <code class="literal">ALTER SCHEMA</code> is a synonym for <code class="literal">ALTER
        DATABASE</code> as of MySQL 5.0.2.
      </p><p>
        The <code class="literal">CHARACTER SET</code> clause changes the default
        database character set. The <code class="literal">COLLATE</code> clause
        changes the default database collation.
        <a href="http://dev.mysql.com/doc/refman/5.0/en/charset.html" target="_top">Character Set Support</a>, discusses character set and collation
        names.
      </p><p>
        The database name can be omitted, in which case the statement
        applies to the default database.
      </p><p class="mnmas"><b>MySQL Enterprise. </b>
          In a production environment, alteration of a database is not a
          common occurrence and may indicate a security breach. Advisors
          provided as part of the MySQL Network Monitoring and Advisory
          Service automatically alert you when data definition
          statements are issued. For more information see,
          <a href="http://www.mysql.com/products/enterprise/advisors.html" target="_top">http://www.mysql.com/products/enterprise/advisors.html</a>.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="alter-table"></a><code class="literal">ALTER TABLE</code> Syntax</h3></div></div></div><a id="id2857843" class="indexterm"></a><a id="id2857850" class="indexterm"></a><a id="id2857860" class="indexterm"></a><pre class="programlisting">ALTER [IGNORE] TABLE <em class="replaceable"><code>tbl_name</code></em>
    <em class="replaceable"><code>alter_specification</code></em> [, <em class="replaceable"><code>alter_specification</code></em>] ...

<em class="replaceable"><code>alter_specification</code></em>:
    <em class="replaceable"><code>table_option</code></em> ...
  | ADD [COLUMN] <em class="replaceable"><code>column_definition</code></em> [FIRST | AFTER <em class="replaceable"><code>col_name</code></em> ]
  | ADD [COLUMN] (<em class="replaceable"><code>column_definition</code></em>,...)
  | ADD {INDEX|KEY} [<em class="replaceable"><code>index_name</code></em>] [<em class="replaceable"><code>index_type</code></em>] (<em class="replaceable"><code>index_col_name</code></em>,...)
  | ADD [CONSTRAINT [<em class="replaceable"><code>symbol</code></em>]]
        PRIMARY KEY [<em class="replaceable"><code>index_type</code></em>] (<em class="replaceable"><code>index_col_name</code></em>,...)
  | ADD [CONSTRAINT [<em class="replaceable"><code>symbol</code></em>]]
        UNIQUE [INDEX|KEY] [<em class="replaceable"><code>index_name</code></em>] [<em class="replaceable"><code>index_type</code></em>] (<em class="replaceable"><code>index_col_name</code></em>,...)
  | ADD [FULLTEXT|SPATIAL] [INDEX|KEY] [<em class="replaceable"><code>index_name</code></em>] (<em class="replaceable"><code>index_col_name</code></em>,...)
  | ADD [CONSTRAINT [<em class="replaceable"><code>symbol</code></em>]]
        FOREIGN KEY [<em class="replaceable"><code>index_name</code></em>] (<em class="replaceable"><code>index_col_name</code></em>,...)
        [<em class="replaceable"><code>reference_definition</code></em>]
  | ALTER [COLUMN] <em class="replaceable"><code>col_name</code></em> {SET DEFAULT <em class="replaceable"><code>literal</code></em> | DROP DEFAULT}
  | CHANGE [COLUMN] <em class="replaceable"><code>old_col_name</code></em> <em class="replaceable"><code>column_definition</code></em>
        [FIRST|AFTER <em class="replaceable"><code>col_name</code></em>]
  | MODIFY [COLUMN] <em class="replaceable"><code>column_definition</code></em> [FIRST | AFTER <em class="replaceable"><code>col_name</code></em>]
  | DROP [COLUMN] <em class="replaceable"><code>col_name</code></em>
  | DROP PRIMARY KEY
  | DROP {INDEX|KEY} <em class="replaceable"><code>index_name</code></em>
  | DROP FOREIGN KEY <em class="replaceable"><code>fk_symbol</code></em>
  | DISABLE KEYS
  | ENABLE KEYS
  | RENAME [TO] <em class="replaceable"><code>new_tbl_name</code></em>
  | ORDER BY <em class="replaceable"><code>col_name</code></em> [, <em class="replaceable"><code>col_name</code></em>] ...
  | CONVERT TO CHARACTER SET <em class="replaceable"><code>charset_name</code></em> [COLLATE <em class="replaceable"><code>collation_name</code></em>]
  | [DEFAULT] CHARACTER SET <em class="replaceable"><code>charset_name</code></em> [COLLATE <em class="replaceable"><code>collation_name</code></em>]
  | DISCARD TABLESPACE
  | IMPORT TABLESPACE

<em class="replaceable"><code>index_col_name</code></em>:
    <em class="replaceable"><code>col_name</code></em> [(<em class="replaceable"><code>length</code></em>)] [ASC | DESC]

<em class="replaceable"><code>index_type</code></em>:
    USING {BTREE | HASH}
</pre><p>
        <code class="literal">ALTER TABLE</code> enables you to change the
        structure of an existing table. For example, you can add or
        delete columns, create or destroy indexes, change the type of
        existing columns, or rename columns or the table itself. You can
        also change the comment for the table and type of the table.
      </p><p>
        The syntax for many of the allowable alterations is similar to
        clauses of the <code class="literal">CREATE TABLE</code> statement. See
        <a href="mysqlqb_statements.html#create-table" title="CREATE TABLE Syntax"><code class="literal">CREATE TABLE</code> Syntax</a>, for more information.
      </p><p>
        Some operations may result in warnings if attempted on a table
        for which the storage engine does not support the operation.
        These warnings can be displayed with <code class="literal">SHOW
        WARNINGS</code>. See <a href="mysqlqb_statements.html#show-warnings" title="SHOW WARNINGS Syntax"><code class="literal">SHOW WARNINGS</code> Syntax</a>.
      </p><p>
        If you use <code class="literal">ALTER TABLE</code> to change a column
        specification but <code class="literal">DESCRIBE
        <em class="replaceable"><code>tbl_name</code></em></code> indicates that
        your column was not changed, it is possible that MySQL ignored
        your modification for one of the reasons described in
        <a href="mysqlqb_statements.html#silent-column-changes" title="Silent Column Specification Changes">Silent Column Specification Changes</a>.
      </p><p>
        In most cases, <code class="literal">ALTER TABLE</code> works by making a
        temporary copy of the original table. The alteration is
        performed on the copy, and then the original table is deleted
        and the new one is renamed. While <code class="literal">ALTER TABLE</code>
        is executing, the original table is readable by other clients.
        Updates and writes to the table are stalled until the new table
        is ready, and then are automatically redirected to the new table
        without any failed updates.
      </p><p>
        If you use <code class="literal">ALTER TABLE
        <em class="replaceable"><code>tbl_name</code></em> RENAME TO
        <em class="replaceable"><code>new_tbl_name</code></em></code> without any
        other options, MySQL simply renames any files that correspond to
        the table <em class="replaceable"><code>tbl_name</code></em>. (You can also use
        the <code class="literal">RENAME TABLE</code> statement to rename tables.
        See <a href="mysqlqb_statements.html#rename-table" title="RENAME TABLE Syntax"><code class="literal">RENAME TABLE</code> Syntax</a>.) Any privileges granted
        specifically for the renamed table are not migrated to the new
        name. They must be changed manually.
      </p><p>
        If you use any option to <code class="literal">ALTER TABLE</code> other
        than <code class="literal">RENAME</code>, MySQL always creates a temporary
        table, even if the data wouldn't strictly need to be copied
        (such as when you change the name of a column). For
        <code class="literal">MyISAM</code> tables, you can speed up the index
        re-creation operation (which is the slowest part of the
        alteration process) by setting the
        <code class="literal">myisam_sort_buffer_size</code> system variable to a
        high value.
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            To use <code class="literal">ALTER TABLE</code>, you need
            <code class="literal">ALTER</code>, <code class="literal">INSERT</code>, and
            <code class="literal">CREATE</code> privileges for the table.
          </p></li><li><p>
            <code class="literal">IGNORE</code> is a MySQL extension to standard
            SQL. It controls how <code class="literal">ALTER TABLE</code> works if
            there are duplicates on unique keys in the new table or if
            warnings occur when strict mode is enabled. If
            <code class="literal">IGNORE</code> is not specified, the copy is
            aborted and rolled back if duplicate-key errors occur. If
            <code class="literal">IGNORE</code> is specified, only the first row
            is used of rows with duplicates on a unique key, The other
            conflicting rows are deleted. Incorrect values are truncated
            to the closest matching acceptable value.
          </p></li><li><p>
            <em class="replaceable"><code>table_option</code></em> signifies a table
            option of the kind that can be used in the <code class="literal">CREATE
            TABLE</code> statement. (<a href="mysqlqb_statements.html#create-table" title="CREATE TABLE Syntax"><code class="literal">CREATE TABLE</code> Syntax</a>,
            lists all table options.) This includes options such as
            <code class="literal">ENGINE</code>,
            <code class="literal">AUTO_INCREMENT</code>, and
            <code class="literal">AVG_ROW_LENGTH</code>. However, <code class="literal">ALTER
            TABLE</code> ignores the <code class="literal">DATA
            DIRECTORY</code> and <code class="literal">INDEX DIRECTORY</code>
            table options.
          </p><p>
            For example, to convert a table to be an
            <code class="literal">InnoDB</code> table, use this statement:
          </p><pre class="programlisting">ALTER TABLE t1 ENGINE = InnoDB;
</pre><p>
            As of MySQL 5.0.23, to prevent inadvertent loss of data,
            <code class="literal">ALTER TABLE</code> cannot be used to change the
            storage engine of a table to <code class="literal">MERGE</code> or
            <code class="literal">BLACKHOLE</code>.
          </p><p>
            To change the value of the <code class="literal">AUTO_INCREMENT</code>
            counter to be used for new rows, do this:
          </p><pre class="programlisting">ALTER TABLE t2 AUTO_INCREMENT = <em class="replaceable"><code>value</code></em>;
</pre><p>
            You cannot reset the counter to a value less than or equal
            to any that have already been used. For
            <code class="literal">MyISAM</code>, if the value is less than or
            equal to the maximum value currently in the
            <code class="literal">AUTO_INCREMENT</code> column, the value is reset
            to the current maximum plus one. For
            <code class="literal">InnoDB</code>, you can use <code class="literal">ALTER TABLE
            ... AUTO_INCREMENT =
            <em class="replaceable"><code>value</code></em></code> as of MySQL
            5.0.3, but <span class="emphasis"><em>if the value is less than the current
            maximum value in the column, no error message is given and
            the current sequence value is not changed.</em></span>
          </p></li><li><p>
            You can issue multiple <code class="literal">ADD</code>,
            <code class="literal">ALTER</code>, <code class="literal">DROP</code>, and
            <code class="literal">CHANGE</code> clauses in a single <code class="literal">ALTER
            TABLE</code> statement, separated by commas. This is a
            MySQL extension to standard SQL, which allows only one of
            each clause per <code class="literal">ALTER TABLE</code> statement.
            For example, to drop multiple columns in a single statement,
            do this:
          </p><pre class="programlisting">ALTER TABLE t2 DROP COLUMN c, DROP COLUMN d;
</pre></li><li><p>
            <code class="literal">CHANGE
            <em class="replaceable"><code>col_name</code></em></code>, <code class="literal">DROP
            <em class="replaceable"><code>col_name</code></em></code>, and
            <code class="literal">DROP INDEX</code> are MySQL extensions to
            standard SQL.
          </p></li><li><p>
            <code class="literal">MODIFY</code> is an Oracle extension to
            <code class="literal">ALTER TABLE</code>.
          </p></li><li><p>
            The word <code class="literal">COLUMN</code> is optional and can be
            omitted.
          </p></li><li><p>
            <em class="replaceable"><code>column_definition</code></em> clauses use the
            same syntax for <code class="literal">ADD</code> and
            <code class="literal">CHANGE</code> as for <code class="literal">CREATE
            TABLE</code>. Note that this syntax includes the column
            name, not just its data type. See
            <a href="mysqlqb_statements.html#create-table" title="CREATE TABLE Syntax"><code class="literal">CREATE TABLE</code> Syntax</a>.
          </p></li><li><p>
            You can rename a column using a <code class="literal">CHANGE
            <em class="replaceable"><code>old_col_name</code></em>
            <em class="replaceable"><code>column_definition</code></em></code>
            clause. To do so, specify the old and new column names and
            the type that the column currently has. For example, to
            rename an <code class="literal">INTEGER</code> column from
            <code class="literal">a</code> to <code class="literal">b</code>, you can do
            this:
          </p><pre class="programlisting">ALTER TABLE t1 CHANGE a b INTEGER;
</pre><p>
            If you want to change a column's type but not the name,
            <code class="literal">CHANGE</code> syntax still requires an old and
            new column name, even if they are the same. For example:
          </p><pre class="programlisting">ALTER TABLE t1 CHANGE b b BIGINT NOT NULL;
</pre><p>
            You can also use <code class="literal">MODIFY</code> to change a
            column's type without renaming it:
          </p><pre class="programlisting">ALTER TABLE t1 MODIFY b BIGINT NOT NULL;
</pre></li><li><p>
            If you use <code class="literal">CHANGE</code> or
            <code class="literal">MODIFY</code> to shorten a column for which an
            index exists on the column, and the resulting column length
            is less than the index length, MySQL shortens the index
            automatically.
          </p></li><li><p>
            When you change a data type using <code class="literal">CHANGE</code>
            or <code class="literal">MODIFY</code>, MySQL tries to convert
            existing column values to the new type as well as possible.
          </p></li><li><p>
            To add a column at a specific position within a table row,
            use <code class="literal">FIRST</code> or <code class="literal">AFTER
            <em class="replaceable"><code>col_name</code></em></code>. The default
            is to add the column last. You can also use
            <code class="literal">FIRST</code> and <code class="literal">AFTER</code> in
            <code class="literal">CHANGE</code> or <code class="literal">MODIFY</code>
            operations.
          </p></li><li><p>
            <a id="id2858651" class="indexterm"></a>

            <a id="id2858658" class="indexterm"></a>

            <a id="id2858668" class="indexterm"></a>

            <a id="id2858678" class="indexterm"></a>

            <a id="id2858688" class="indexterm"></a>

            <code class="literal">ALTER ... SET DEFAULT</code> or <code class="literal">ALTER
            ... DROP DEFAULT</code> specify a new default value for a
            column or remove the old default value, respectively. If the
            old default is removed and the column can be
            <code class="literal">NULL</code>, the new default is
            <code class="literal">NULL</code>. If the column cannot be
            <code class="literal">NULL</code>, MySQL assigns a default value, as
            described in <a href="http://dev.mysql.com/doc/refman/5.0/en/data-type-defaults.html" target="_top">Data Type Default Values</a>.
          </p></li><li><p>
            <a id="id2858736" class="indexterm"></a>

            <a id="id2858742" class="indexterm"></a>

            <a id="id2858753" class="indexterm"></a>

            <code class="literal">DROP INDEX</code> removes an index. This is a
            MySQL extension to standard SQL. See
            <a href="mysqlqb_statements.html#drop-index" title="DROP INDEX Syntax"><code class="literal">DROP INDEX</code> Syntax</a>.
          </p></li><li><p>
            If columns are dropped from a table, the columns are also
            removed from any index of which they are a part. If all
            columns that make up an index are dropped, the index is
            dropped as well.
          </p></li><li><p>
            If a table contains only one column, the column cannot be
            dropped. If what you intend is to remove the table, use
            <code class="literal">DROP TABLE</code> instead.
          </p></li><li><p>
            <a id="id2858803" class="indexterm"></a>

            <a id="id2858810" class="indexterm"></a>

            <a id="id2858820" class="indexterm"></a>

            <code class="literal">DROP PRIMARY KEY</code> drops the primary index.
            <span class="emphasis"><em>Note</em></span>: In older versions of MySQL, if no
            primary index existed, <code class="literal">DROP PRIMARY KEY</code>
            would drop the first <code class="literal">UNIQUE</code> index in the
            table. This is not the case in MySQL 5.0, where
            trying to use <code class="literal">DROP PRIMARY KEY</code> on a table
            with no primary key results in an error.
          </p><a id="id2858855" class="indexterm"></a><a id="id2858861" class="indexterm"></a><p>
            If you add a <code class="literal">UNIQUE INDEX</code> or
            <code class="literal">PRIMARY KEY</code> to a table, it is stored
            before any non-unique index so that MySQL can detect
            duplicate keys as early as possible.
          </p></li><li><p>
            Some storage engines allow you to specify an index type when
            creating an index. The syntax for the
            <em class="replaceable"><code>index_type</code></em> specifier is
            <code class="literal">USING
            <em class="replaceable"><code>type_name</code></em></code>. For details
            about <code class="literal">USING</code>, see
            <a href="mysqlqb_statements.html#create-index" title="CREATE INDEX Syntax"><code class="literal">CREATE INDEX</code> Syntax</a>.
          </p></li><li><p>
            <a id="id2858915" class="indexterm"></a>

            <code class="literal">ORDER BY</code> enables you to create the new
            table with the rows in a specific order. Note that the table
            does not remain in this order after inserts and deletes.
            This option is useful primarily when you know that you are
            mostly to query the rows in a certain order most of the
            time. By using this option after major changes to the table,
            you might be able to get higher performance. In some cases,
            it might make sorting easier for MySQL if the table is in
            order by the column that you want to order it by later.
          </p><p>
            <code class="literal">ORDER BY</code> syntax allows for one or more
            column names to be specified for sorting, each of which
            optionally can be followed by <code class="literal">ASC</code> or
            <code class="literal">DESC</code> to indicate ascending or descending
            sort order, respectively. The default is ascending order.
            Only column names are allowed as sort criteria; arbitrary
            expressions are not allowed.
          </p></li><li><p>
            <a id="id2858962" class="indexterm"></a>

            <a id="id2858969" class="indexterm"></a>

            <a id="id2858979" class="indexterm"></a>

            If you use <code class="literal">ALTER TABLE</code> on a
            <code class="literal">MyISAM</code> table, all non-unique indexes are
            created in a separate batch (as for <code class="literal">REPAIR
            TABLE</code>). This should make <code class="literal">ALTER
            TABLE</code> much faster when you have many indexes.
          </p><p>
            This feature can be activated explicitly. <code class="literal">ALTER
            TABLE ... DISABLE KEYS</code> tells MySQL to stop
            updating non-unique indexes for a <code class="literal">MyISAM</code>
            table. <code class="literal">ALTER TABLE ... ENABLE KEYS</code> then
            should be used to re-create missing indexes. MySQL does this
            with a special algorithm that is much faster than inserting
            keys one by one, so disabling keys before performing bulk
            insert operations should give a considerable speedup. Using
            <code class="literal">ALTER TABLE ... DISABLE KEYS</code> requires the
            <code class="literal">INDEX</code> privilege in addition to the
            privileges mentioned earlier.
          </p></li><li><p>
            <a id="id2859046" class="indexterm"></a>

            <a id="id2859053" class="indexterm"></a>

            The <code class="literal">FOREIGN KEY</code> and
            <code class="literal">REFERENCES</code> clauses are supported by the
            <code class="literal">InnoDB</code> storage engine, which implements
            <code class="literal">ADD [CONSTRAINT
            [<em class="replaceable"><code>symbol</code></em>]] FOREIGN KEY (...)
            REFERENCES ... (...)</code>. See
            <a href="http://dev.mysql.com/doc/refman/5.0/en/innodb-foreign-key-constraints.html" target="_top"><code class="literal">FOREIGN KEY</code> Constraints</a>. For other
            storage engines, the clauses are parsed but ignored. The
            <code class="literal">CHECK</code> clause is parsed but ignored by all
            storage engines. See <a href="mysqlqb_statements.html#create-table" title="CREATE TABLE Syntax"><code class="literal">CREATE TABLE</code> Syntax</a>. The
            reason for accepting but ignoring syntax clauses is for
            compatibility, to make it easier to port code from other SQL
            servers, and to run applications that create tables with
            references. See <a href="http://dev.mysql.com/doc/refman/5.0/en/differences-from-ansi.html" target="_top">MySQL Differences from Standard SQL</a>.
          </p><p>
            You cannot add a foreign key and drop a foreign key in
            separate clauses of a single <code class="literal">ALTER TABLE</code>
            statement. You must use separate statements.
          </p></li><li><p>
            <a id="id2859130" class="indexterm"></a>

            <a id="id2859136" class="indexterm"></a>

            <a id="id2859146" class="indexterm"></a>

            <code class="literal">InnoDB</code> supports the use of <code class="literal">ALTER
            TABLE</code> to drop foreign keys:
          </p><pre class="programlisting">ALTER TABLE <em class="replaceable"><code>tbl_name</code></em> DROP FOREIGN KEY <em class="replaceable"><code>fk_symbol</code></em>;
</pre><p>
            You cannot add a foreign key and drop a foreign key in
            separate clauses of a single <code class="literal">ALTER TABLE</code>
            statement. You must use separate statements.
          </p><p>
            For more information, see
            <a href="http://dev.mysql.com/doc/refman/5.0/en/innodb-foreign-key-constraints.html" target="_top"><code class="literal">FOREIGN KEY</code> Constraints</a>.
          </p></li><li><p>
            Pending <code class="literal">INSERT DELAYED</code> statements are
            lost if a table is write locked and <code class="literal">ALTER
            TABLE</code> is used to modify the table structure.
          </p></li><li><p>
            <a id="id2859223" class="indexterm"></a>

            If you want to change the table default character set and
            all character columns (<code class="literal">CHAR</code>,
            <code class="literal">VARCHAR</code>, <code class="literal">TEXT</code>) to a
            new character set, use a statement like this:
          </p><pre class="programlisting">ALTER TABLE <em class="replaceable"><code>tbl_name</code></em> CONVERT TO CHARACTER SET <em class="replaceable"><code>charset_name</code></em>;
</pre><p>
            <span class="bold"><strong>Warning:</strong></span> The preceding
            operation converts column values between the character sets.
            This is <span class="emphasis"><em>not</em></span> what you want if you have a
            column in one character set (like <code class="literal">latin1</code>)
            but the stored values actually use some other, incompatible
            character set (like <code class="literal">utf8</code>). In this case,
            you have to do the following for each such column:
          </p><pre class="programlisting">ALTER TABLE t1 CHANGE c1 c1 BLOB;
ALTER TABLE t1 CHANGE c1 c1 TEXT CHARACTER SET utf8;
</pre><p>
            The reason this works is that there is no conversion when
            you convert to or from <code class="literal">BLOB</code> columns.
          </p><p>
            If you specify <code class="literal">CONVERT TO CHARACTER SET
            binary</code>, the <code class="literal">CHAR</code>,
            <code class="literal">VARCHAR</code>, and <code class="literal">TEXT</code>
            columns are converted to their corresponding binary string
            types (<code class="literal">BINARY</code>,
            <code class="literal">VARBINARY</code>, <code class="literal">BLOB</code>). This
            means that the columns no longer will have a character set
            and a subsequent <code class="literal">CONVERT TO</code> operation
            will not apply to them.
          </p><p>
            To change only the <span class="emphasis"><em>default</em></span> character
            set for a table, use this statement:
          </p><pre class="programlisting">ALTER TABLE <em class="replaceable"><code>tbl_name</code></em> DEFAULT CHARACTER SET <em class="replaceable"><code>charset_name</code></em>;
</pre><p>
            The word <code class="literal">DEFAULT</code> is optional. The default
            character set is the character set that is used if you do
            not specify the character set for a new column which you add
            to a table (for example, with <code class="literal">ALTER TABLE ... ADD
            column</code>).
          </p></li><li><p>
            <a id="id2859374" class="indexterm"></a>

            <a id="id2859381" class="indexterm"></a>

            For an <code class="literal">InnoDB</code> table that is created with
            its own tablespace in an <code class="filename">.ibd</code> file,
            that file can be discarded and imported. To discard the
            <code class="filename">.ibd</code> file, use this statement:
          </p><pre class="programlisting">ALTER TABLE <em class="replaceable"><code>tbl_name</code></em> DISCARD TABLESPACE;
</pre><p>
            This deletes the current <code class="filename">.ibd</code> file, so
            be sure that you have a backup first. Attempting to access
            the table while the tablespace file is discarded results in
            an error.
          </p><p>
            To import the backup <code class="filename">.ibd</code> file back
            into the table, copy it into the database directory, and
            then issue this statement:
          </p><pre class="programlisting">ALTER TABLE <em class="replaceable"><code>tbl_name</code></em> IMPORT TABLESPACE;
</pre><p>
            See <a href="http://dev.mysql.com/doc/refman/5.0/en/multiple-tablespaces.html" target="_top">Using Per-Table Tablespaces</a>.
          </p></li></ul></div><a id="id2859452" class="indexterm"></a><p>
        With the <code class="literal">mysql_info()</code> C API function, you can
        find out how many rows were copied, and (when
        <code class="literal">IGNORE</code> is used) how many rows were deleted
        due to duplication of unique key values. See
        <a href="http://dev.mysql.com/doc/refman/5.0/en/mysql-info.html" target="_top"><code class="literal">mysql_info()</code></a>.
      </p><p>
        Here are some examples that show uses of <code class="literal">ALTER
        TABLE</code>. Begin with a table <code class="literal">t1</code> that
        is created as shown here:
      </p><pre class="programlisting">CREATE TABLE t1 (a INTEGER,b CHAR(10));
</pre><p>
        To rename the table from <code class="literal">t1</code> to
        <code class="literal">t2</code>:
      </p><pre class="programlisting">ALTER TABLE t1 RENAME t2;
</pre><p>
        To change column <code class="literal">a</code> from
        <code class="literal">INTEGER</code> to <code class="literal">TINYINT NOT
        NULL</code> (leaving the name the same), and to change column
        <code class="literal">b</code> from <code class="literal">CHAR(10)</code> to
        <code class="literal">CHAR(20)</code> as well as renaming it from
        <code class="literal">b</code> to <code class="literal">c</code>:
      </p><pre class="programlisting">ALTER TABLE t2 MODIFY a TINYINT NOT NULL, CHANGE b c CHAR(20);
</pre><p>
        To add a new <code class="literal">TIMESTAMP</code> column named
        <code class="literal">d</code>:
      </p><pre class="programlisting">ALTER TABLE t2 ADD d TIMESTAMP;
</pre><p>
        To add indexes on column <code class="literal">d</code> and on column
        <code class="literal">a</code>:
      </p><pre class="programlisting">ALTER TABLE t2 ADD INDEX (d), ADD INDEX (a);
</pre><p>
        To remove column <code class="literal">c</code>:
      </p><pre class="programlisting">ALTER TABLE t2 DROP COLUMN c;
</pre><p>
        To add a new <code class="literal">AUTO_INCREMENT</code> integer column
        named <code class="literal">c</code>:
      </p><pre class="programlisting">ALTER TABLE t2 ADD c INT UNSIGNED NOT NULL AUTO_INCREMENT,
  ADD PRIMARY KEY (c);
</pre><p>
        Note that we indexed <code class="literal">c</code> (as a <code class="literal">PRIMARY
        KEY</code>), because <code class="literal">AUTO_INCREMENT</code>
        columns must be indexed, and also that we declare
        <code class="literal">c</code> as <code class="literal">NOT NULL</code>, because
        primary key columns cannot be <code class="literal">NULL</code>.
      </p><p>
        When you add an <code class="literal">AUTO_INCREMENT</code> column, column
        values are filled in with sequence numbers for you
        automatically. For <code class="literal">MyISAM</code> tables, you can set
        the first sequence number by executing <code class="literal">SET
        INSERT_ID=<em class="replaceable"><code>value</code></em></code> before
        <code class="literal">ALTER TABLE</code> or by using the
        <code class="literal">AUTO_INCREMENT=<em class="replaceable"><code>value</code></em></code>
        table option. See <a href="mysqlqb_statements.html#set-option" title="SET Syntax"><code class="literal">SET</code> Syntax</a>.
      </p><p>
        With <code class="literal">MyISAM</code> tables, if you do not change the
        <code class="literal">AUTO_INCREMENT</code> column, the sequence number is
        not affected. If you drop an <code class="literal">AUTO_INCREMENT</code>
        column and then add another <code class="literal">AUTO_INCREMENT</code>
        column, the numbers are resequenced beginning with 1.
      </p><p>
        When replication is used, adding an
        <code class="literal">AUTO_INCREMENT</code> column to a table might not
        produce the same ordering of the rows on the slave and the
        master. This occurs because the order in which the rows are
        numbered depends on the specific storage engine used for the
        table and the order in which the rows were inserted. If it is
        important to have the same order on the master and slave, the
        rows must be ordered before assigning an
        <code class="literal">AUTO_INCREMENT</code> number. Assuming that you want
        to add an <code class="literal">AUTO_INCREMENT</code> column to the table
        <code class="literal">t1</code>, the following statements produce a new
        table <code class="literal">t2</code> identical to <code class="literal">t1</code>
        but with an <code class="literal">AUTO_INCREMENT</code> column:
      </p><pre class="programlisting">CREATE TABLE t2 (id INT AUTO_INCREMENT PRIMARY KEY) 
SELECT * FROM t1 ORDER BY col1, col2;
</pre><p>
        This assumes that the table <code class="literal">t1</code> has columns
        <code class="literal">col1</code> and <code class="literal">col2</code>.
      </p><p>
        This set of statements will also produce a new table
        <code class="literal">t2</code> identical to <code class="literal">t1</code>, with
        the addition of an <code class="literal">AUTO_INCREMENT</code> column:
      </p><pre class="programlisting">CREATE TABLE t2 LIKE t1;
ALTER TABLE T2 ADD id INT AUTO_INCREMENT PRIMARY KEY;
INSERT INTO t2 SELECT * FROM t1 ORDER BY col1, col2;
</pre><p>
        <span class="bold"><strong>Important</strong></span>: To guarantee the
        same ordering on both master and slave, <span class="emphasis"><em>all</em></span>
        columns of <code class="literal">t1</code> must be referenced in the
        <code class="literal">ORDER BY</code> clause.
      </p><p>
        Regardless of the method used to create and populate the copy
        having the <code class="literal">AUTO_INCREMENT</code> column, the final
        step is to drop the original table and then rename the copy:
      </p><pre class="programlisting">DROP t1;
ALTER TABLE t2 RENAME t1;
</pre><p>
        See also <a href="http://dev.mysql.com/doc/refman/5.0/en/alter-table-problems.html" target="_top">Problems with <code class="literal">ALTER TABLE</code></a>.
      </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="create-database"></a><code class="literal">CREATE DATABASE</code> Syntax</h3></div></div></div><a id="id2859835" class="indexterm"></a><a id="id2859841" class="indexterm"></a><a id="id2859848" class="indexterm"></a><a id="id2859858" class="indexterm"></a><a id="id2859868" class="indexterm"></a><a id="id2859879" class="indexterm"></a><pre class="programlisting">CREATE {DATABASE | SCHEMA} [IF NOT EXISTS] <em class="replaceable"><code>db_name</code></em>
    [<em class="replaceable"><code>create_specification</code></em> [<em class="replaceable"><code>create_specification</code></em>] ...]

<em class="replaceable"><code>create_specification</code></em>:
    [DEFAULT] CHARACTER SET <em class="replaceable"><code>charset_name</code></em>
  | [DEFAULT] COLLATE <em class="replaceable"><code>collation_name</code></em>
</pre><p>
        <code class="literal">CREATE DATABASE</code> creates a database with the
        given name. To use this statement, you need the
        <code class="literal">CREATE</code> privilege for the database.
        <code class="literal">CREATE SCHEMA</code> is a synonym for
        <code class="literal">CREATE DATABASE</code> as of MySQL 5.0.2.
      </p><p>
        An error occurs if the database exists and you did not specify
        <code class="literal">IF NOT EXISTS</code>.
      </p><p>
        <em class="replaceable"><code>create_specification</code></em> options specify
        database characteristics. Database characteristics are stored in
        the <code class="filename">db.opt</code> file in the database directory.
        The <code class="literal">CHARACTER SET</code> clause specifies the
        default database character set. The <code class="literal">COLLATE</code>
        clause specifies the default database collation.
        <a href="http://dev.mysql.com/doc/refman/5.0/en/charset.html" target="_top">Character Set Support</a>, discusses character set and collation
        names.
      </p><p>
        A database in MySQL is implemented as a directory containing
        files that correspond to tables in the database. Because there
        are no tables in a database when it is initially created, the
        <code class="literal">CREATE DATABASE</code> statement creates only a
        directory under the MySQL data directory and the
        <code class="filename">db.opt</code> file. Rules for allowable database
        names are given in <a href="http://dev.mysql.com/doc/refman/5.0/en/identifiers.html" target="_top">Database, Table, Index, Column, and Alias Names</a>.
      </p><p>
        If you manually create a directory under the data directory (for
        example, with <span><strong class="command">mkdir</strong></span>), the server considers it
        a database directory and it shows up in the output of
        <code class="literal">SHOW DATABASES</code>.
      </p><a id="id2860042" class="indexterm"></a><p>
        You can also use the <span><strong class="command">mysqladmin</strong></span> program to
        create databases. See <a href="http://dev.mysql.com/doc/refman/5.0/en/mysqladmin.html" target="_top">mysqladmin</a>.
      </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="create-index"></a><code class="literal">CREATE INDEX</code> Syntax</h3></div></div></div><a id="id2860076" class="indexterm"></a><a id="id2860083" class="indexterm"></a><a id="id2860090" class="indexterm"></a><a id="id2860100" class="indexterm"></a><pre class="programlisting">CREATE [UNIQUE|FULLTEXT|SPATIAL] INDEX <em class="replaceable"><code>index_name</code></em>
    [<em class="replaceable"><code>index_type</code></em>]
    ON <em class="replaceable"><code>tbl_name</code></em> (<em class="replaceable"><code>index_col_name</code></em>,...)

<em class="replaceable"><code>index_col_name</code></em>:
    <em class="replaceable"><code>col_name</code></em> [(<em class="replaceable"><code>length</code></em>)] [ASC | DESC]

<em class="replaceable"><code>index_type</code></em>:
    USING {BTREE | HASH}
</pre><p>
        <code class="literal">CREATE INDEX</code> is mapped to an <code class="literal">ALTER
        TABLE</code> statement to create indexes. See
        <a href="mysqlqb_statements.html#alter-table" title="ALTER TABLE Syntax"><code class="literal">ALTER TABLE</code> Syntax</a>. <code class="literal">CREATE INDEX</code>
        cannot be used to create a <code class="literal">PRIMARY KEY</code>; use
        <code class="literal">ALTER TABLE</code> instead. For more information
        about indexes, see <a href="http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html" target="_top">How MySQL Uses Indexes</a>.
      </p><p>
        Normally, you create all indexes on a table at the time the
        table itself is created with <code class="literal">CREATE TABLE</code>.
        See <a href="mysqlqb_statements.html#create-table" title="CREATE TABLE Syntax"><code class="literal">CREATE TABLE</code> Syntax</a>. <code class="literal">CREATE
        INDEX</code> enables you to add indexes to existing tables.
      </p><p>
        A column list of the form <code class="literal">(col1,col2,...)</code>
        creates a multiple-column index. Index values are formed by
        concatenating the values of the given columns.
      </p><p>
        Indexes can be created that use only the leading part of column
        values, using
        <code class="literal"><em class="replaceable"><code>col_name</code></em>(<em class="replaceable"><code>length</code></em>)</code>
        syntax to specify an index prefix length:
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            Prefixes can be specified for <code class="literal">CHAR</code>,
            <code class="literal">VARCHAR</code>, <code class="literal">BINARY</code>, and
            <code class="literal">VARBINARY</code> columns.
          </p></li><li><p>
            <code class="literal">BLOB</code> and <code class="literal">TEXT</code> columns
            also can be indexed, but a prefix length
            <span class="emphasis"><em>must</em></span> be given.
          </p></li><li><p>
            Prefix lengths are given in characters for non-binary string
            types and in bytes for binary string types. That is, index
            entries consist of the first
            <em class="replaceable"><code>length</code></em> characters of each column
            value for <code class="literal">CHAR</code>,
            <code class="literal">VARCHAR</code>, and <code class="literal">TEXT</code>
            columns, and the first <em class="replaceable"><code>length</code></em>
            bytes of each column value for <code class="literal">BINARY</code>,
            <code class="literal">VARBINARY</code>, and <code class="literal">BLOB</code>
            columns.
          </p></li><li><p>
            For spatial columns, prefix values can be given as described
            later in this section.
          </p></li></ul></div><p>
        The statement shown here creates an index using the first 10
        characters of the <code class="literal">name</code> column:
      </p><pre class="programlisting">CREATE INDEX part_of_name ON customer (name(10));
</pre><p>
        If names in the column usually differ in the first 10
        characters, this index should not be much slower than an index
        created from the entire <code class="literal">name</code> column. Also,
        using column prefixes for indexes can make the index file much
        smaller, which could save a lot of disk space and might also
        speed up <code class="literal">INSERT</code> operations.
      </p><p>
        Prefix lengths are storage engine-dependent (for example, a
        prefix can be up to 1000 bytes long for
        <code class="literal">MyISAM</code> tables, 767 bytes for
        <code class="literal">InnoDB</code> tables). Note that prefix limits are
        measured in bytes, whereas the prefix length in <code class="literal">CREATE
        INDEX</code> statements is interpreted as number of
        characters for non-binary data types (<code class="literal">CHAR</code>,
        <code class="literal">VARCHAR</code>, <code class="literal">TEXT</code>). Take this
        into account when specifying a prefix length for a column that
        uses a multi-byte character set. For example,
        <code class="literal">utf8</code> columns require up to three index bytes
        per character.
      </p><p>
        A <code class="literal">UNIQUE</code> index creates a constraint such that
        all values in the index must be distinct. An error occurs if you
        try to add a new row with a key value that matches an existing
        row. This constraint does not apply to <code class="literal">NULL</code>
        values except for the <code class="literal">BDB</code> storage engine. For
        other engines, a <code class="literal">UNIQUE</code> index allows multiple
        <code class="literal">NULL</code> values for columns that can contain
        <code class="literal">NULL</code>. If you specify a prefix value for a
        column in a <code class="literal">UNIQUE</code> index, the column values
        must be unique within the prefix.
      </p><p>
        <code class="literal">FULLTEXT</code> indexes are supported only for
        <code class="literal">MyISAM</code> tables and can include only
        <code class="literal">CHAR</code>, <code class="literal">VARCHAR</code>, and
        <code class="literal">TEXT</code> columns. Indexing always happens over
        the entire column; column prefix indexing is not supported and
        any prefix length is ignored if specified. See
        <a href="mysqlqb_functions.html#fulltext-search" title="Full-Text Search Functions">Full-Text Search Functions</a>, for details of operation.
      </p><p>
        The <code class="literal">MyISAM</code>, <code class="literal">InnoDB</code>,
        <code class="literal">NDB</code>, <code class="literal">BDB</code>, and
        <code class="literal">ARCHIVE</code> storage engines support spatial
        columns such as (<code class="literal">POINT</code> and
        <code class="literal">GEOMETRY</code>.
        (<a href="http://dev.mysql.com/doc/refman/5.0/en/spatial-extensions.html" target="_top">Spatial Extensions</a>, describes the spatial
        data types.) However, support for spatial column indexing varies
        among engines. Spatial and non-spatial indexes are available
        according to the following rules.
      </p><p>
        Spatial indexes (created using <code class="literal">SPATIAL
        INDEX</code>):
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            Available only for <code class="literal">MyISAM</code> tables.
            Specifying a <code class="literal">SPATIAL INDEX</code> for other
            storage engines results in an error.
          </p></li><li><p>
            Indexed columns must be <code class="literal">NOT NULL</code>.
          </p></li><li><p>
            In MySQL 5.0, the full width of each column is
            indexed by default, but column prefix lengths are allowed.
            However, as of MySQL 5.0.40, the length is not displayed in
            <code class="literal">SHOW CREATE TABLE</code> output.
            <span><strong class="command">mysqldump</strong></span> uses that statement. As of that
            version, if a table with <code class="literal">SPATIAL</code> indexes
            containing prefixed columns is dumped and reloaded, the
            index is created with no prefixes. (The full column width of
            each column is indexed.)
          </p></li></ul></div><p>
        Non-spatial indexes (created with <code class="literal">INDEX</code>,
        <code class="literal">UNIQUE</code>, or <code class="literal">PRIMARY KEY</code>):
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            Allowed for any storage engine that supports spatial columns
            except <code class="literal">ARCHIVE</code>.
          </p></li><li><p>
            Columns can be <code class="literal">NULL</code> unless the index is a
            primary key.
          </p></li><li><p>
            For each spatial column in a non-<code class="literal">SPATIAL</code>
            index except <code class="literal">POINT</code> columns, a column
            prefix length must be specified. (This is the same
            requirement as for indexed <code class="literal">BLOB</code> columns.)
            The prefix length is given in bytes.
          </p></li><li><p>
            The index type for a non-<code class="literal">SPATIAL</code> index
            depends on the storage engine. Currently, B-tree is used.
          </p></li></ul></div><p>
        In MySQL 5.0:
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            You can add an index on a column that can have
            <code class="literal">NULL</code> values only if you are using the
            <code class="literal">MyISAM</code>, <code class="literal">InnoDB</code>,
            <code class="literal">BDB</code>, or <code class="literal">MEMORY</code> storage
            engine.
          </p></li><li><p>
            You can add an index on a <code class="literal">BLOB</code> or
            <code class="literal">TEXT</code> column only if you are using the
            <code class="literal">MyISAM</code>, <code class="literal">BDB</code>, or
            <code class="literal">InnoDB</code> storage engine.
          </p></li></ul></div><p>
        An <em class="replaceable"><code>index_col_name</code></em> specification can
        end with <code class="literal">ASC</code> or <code class="literal">DESC</code>.
        These keywords are allowed for future extensions for specifying
        ascending or descending index value storage. Currently, they are
        parsed but ignored; index values are always stored in ascending
        order.
      </p><p>
        Some storage engines allow you to specify an index type when
        creating an index. The allowable index type values supported by
        different storage engines are shown in the following table.
        Where multiple index types are listed, the first one is the
        default when no index type specifier is given.
      </p><div class="informaltable"><table border="1"><colgroup><col /><col /></colgroup><tbody><tr><td><span class="bold"><strong>Storage Engine</strong></span></td><td><span class="bold"><strong>Allowable Index Types</strong></span></td></tr><tr><td><code class="literal">MyISAM</code></td><td><code class="literal">BTREE</code></td></tr><tr><td><code class="literal">InnoDB</code></td><td><code class="literal">BTREE</code></td></tr><tr><td><code class="literal">MEMORY</code>/<code class="literal">HEAP</code></td><td><code class="literal">HASH</code>, <code class="literal">BTREE</code></td></tr></tbody></table></div><p>
        If you specify an index type that is not legal for a given
        storage engine, but there is another index type available that
        the engine can use without affecting query results, the engine
        uses the available type.
      </p><p>
        Examples:
      </p><pre class="programlisting">CREATE TABLE lookup (id INT) ENGINE = MEMORY;
CREATE INDEX id_index USING BTREE ON lookup (id);
</pre><p>
        <code class="literal">TYPE <em class="replaceable"><code>type_name</code></em></code> is
        recognized as a synonym for <code class="literal">USING
        <em class="replaceable"><code>type_name</code></em></code>. However,
        <code class="literal">USING</code> is the preferred form.
      </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="create-table"></a><code class="literal">CREATE TABLE</code> Syntax</h3></div></div></div><div class="toc"><dl><dt><span class="section"><a href="mysqlqb_statements.html#silent-column-changes">Silent Column Specification Changes</a></span></dt></dl></div><a id="id2860876" class="indexterm"></a><pre class="programlisting">CREATE [TEMPORARY] TABLE [IF NOT EXISTS] <em class="replaceable"><code>tbl_name</code></em>
    (<em class="replaceable"><code>create_definition</code></em>,...)
    [<em class="replaceable"><code>table_option</code></em> ...]
</pre><p>
        Or:
      </p><pre class="programlisting">CREATE [TEMPORARY] TABLE [IF NOT EXISTS] <em class="replaceable"><code>tbl_name</code></em>
    [(<em class="replaceable"><code>create_definition</code></em>,...)]
    [<em class="replaceable"><code>table_option</code></em> ...]
    <em class="replaceable"><code>select_statement</code></em>
</pre><p>
        Or:
      </p><pre class="programlisting">CREATE [TEMPORARY] TABLE [IF NOT EXISTS] <em class="replaceable"><code>tbl_name</code></em>
    { LIKE <em class="replaceable"><code>old_tbl_name</code></em> | (LIKE <em class="replaceable"><code>old_tbl_name</code></em>) }

<em class="replaceable"><code>create_definition</code></em>:
    <em class="replaceable"><code>column_definition</code></em>
  | [CONSTRAINT [<em class="replaceable"><code>symbol</code></em>]] PRIMARY KEY [<em class="replaceable"><code>index_type</code></em>] (<em class="replaceable"><code>index_col_name</code></em>,...)
  | {INDEX|KEY} [<em class="replaceable"><code>index_name</code></em>] [<em class="replaceable"><code>index_type</code></em>] (<em class="replaceable"><code>index_col_name</code></em>,...)
  | [CONSTRAINT [<em class="replaceable"><code>symbol</code></em>]] UNIQUE [INDEX|KEY]
      [<em class="replaceable"><code>index_name</code></em>] [<em class="replaceable"><code>index_type</code></em>] (<em class="replaceable"><code>index_col_name</code></em>,...)
  | {FULLTEXT|SPATIAL} [INDEX|KEY] [<em class="replaceable"><code>index_name</code></em>] (<em class="replaceable"><code>index_col_name</code></em>,...)
  | [CONSTRAINT [<em class="replaceable"><code>symbol</code></em>]] FOREIGN KEY
      [<em class="replaceable"><code>index_name</code></em>] (<em class="replaceable"><code>index_col_name</code></em>,...) [<em class="replaceable"><code>reference_definition</code></em>]
  | CHECK (<em class="replaceable"><code>expr</code></em>)

<em class="replaceable"><code>column_definition</code></em>:
    <em class="replaceable"><code>col_name</code></em> <em class="replaceable"><code>data_type</code></em> [NOT NULL | NULL] [DEFAULT <em class="replaceable"><code>default_value</code></em>]
      [AUTO_INCREMENT] [UNIQUE [KEY] | [PRIMARY] KEY]
      [COMMENT '<em class="replaceable"><code>string</code></em>'] [<em class="replaceable"><code>reference_definition</code></em>]

<em class="replaceable"><code>data_type</code></em>:
    BIT[(<em class="replaceable"><code>length</code></em>)]
  | TINYINT[(<em class="replaceable"><code>length</code></em>)] [UNSIGNED] [ZEROFILL]
  | SMALLINT[(<em class="replaceable"><code>length</code></em>)] [UNSIGNED] [ZEROFILL]
  | MEDIUMINT[(<em class="replaceable"><code>length</code></em>)] [UNSIGNED] [ZEROFILL]
  | INT[(<em class="replaceable"><code>length</code></em>)] [UNSIGNED] [ZEROFILL]
  | INTEGER[(<em class="replaceable"><code>length</code></em>)] [UNSIGNED] [ZEROFILL]
  | BIGINT[(<em class="replaceable"><code>length</code></em>)] [UNSIGNED] [ZEROFILL]
  | REAL[(<em class="replaceable"><code>length</code></em>,<em class="replaceable"><code>decimals</code></em>)] [UNSIGNED] [ZEROFILL]
  | DOUBLE[(<em class="replaceable"><code>length</code></em>,<em class="replaceable"><code>decimals</code></em>)] [UNSIGNED] [ZEROFILL]
  | FLOAT[(<em class="replaceable"><code>length</code></em>,<em class="replaceable"><code>decimals</code></em>)] [UNSIGNED] [ZEROFILL]
  | DECIMAL(<em class="replaceable"><code>length</code></em>,<em class="replaceable"><code>decimals</code></em>) [UNSIGNED] [ZEROFILL]
  | NUMERIC(<em class="replaceable"><code>length</code></em>,<em class="replaceable"><code>decimals</code></em>) [UNSIGNED] [ZEROFILL]
  | DATE
  | TIME
  | TIMESTAMP
  | DATETIME
  | YEAR
  | CHAR(<em class="replaceable"><code>length</code></em>)
      [CHARACTER SET <em class="replaceable"><code>charset_name</code></em>] [COLLATE <em class="replaceable"><code>collation_name</code></em>]
  | VARCHAR(<em class="replaceable"><code>length</code></em>)
      [CHARACTER SET <em class="replaceable"><code>charset_name</code></em>] [COLLATE <em class="replaceable"><code>collation_name</code></em>]
  | BINARY(<em class="replaceable"><code>length</code></em>)
  | VARBINARY(<em class="replaceable"><code>length</code></em>)
  | TINYBLOB
  | BLOB
  | MEDIUMBLOB
  | LONGBLOB
  | TINYTEXT [BINARY]
      [CHARACTER SET <em class="replaceable"><code>charset_name</code></em>] [COLLATE <em class="replaceable"><code>collation_name</code></em>]
  | TEXT [BINARY]
      [CHARACTER SET <em class="replaceable"><code>charset_name</code></em>] [COLLATE <em class="replaceable"><code>collation_name</code></em>]
  | MEDIUMTEXT [BINARY]
      [CHARACTER SET <em class="replaceable"><code>charset_name</code></em>] [COLLATE <em class="replaceable"><code>collation_name</code></em>]
  | LONGTEXT [BINARY]
      [CHARACTER SET <em class="replaceable"><code>charset_name</code></em>] [COLLATE <em class="replaceable"><code>collation_name</code></em>]
  | ENUM(<em class="replaceable"><code>value1</code></em>,<em class="replaceable"><code>value2</code></em>,<em class="replaceable"><code>value3</code></em>,...)
      [CHARACTER SET <em class="replaceable"><code>charset_name</code></em>] [COLLATE <em class="replaceable"><code>collation_name</code></em>]
  | SET(<em class="replaceable"><code>value1</code></em>,<em class="replaceable"><code>value2</code></em>,<em class="replaceable"><code>value3</code></em>,...)
      [CHARACTER SET <em class="replaceable"><code>charset_name</code></em>] [COLLATE <em class="replaceable"><code>collation_name</code></em>]
  | <em class="replaceable"><code>spatial_type</code></em>

<em class="replaceable"><code>index_col_name</code></em>:
    <em class="replaceable"><code>col_name</code></em> [(<em class="replaceable"><code>length</code></em>)] [ASC | DESC]

<em class="replaceable"><code>index_type</code></em>:
    USING {BTREE | HASH}

<em class="replaceable"><code>reference_definition</code></em>:
    REFERENCES <em class="replaceable"><code>tbl_name</code></em> [(<em class="replaceable"><code>index_col_name</code></em>,...)]
      [MATCH FULL | MATCH PARTIAL | MATCH SIMPLE]
      [ON DELETE <em class="replaceable"><code>reference_option</code></em>]
      [ON UPDATE <em class="replaceable"><code>reference_option</code></em>]

<em class="replaceable"><code>reference_option</code></em>:
    RESTRICT | CASCADE | SET NULL | NO ACTION

<em class="replaceable"><code>table_option</code></em>:
    {ENGINE|TYPE} [=] <em class="replaceable"><code>engine_name</code></em>
  | AUTO_INCREMENT [=] <em class="replaceable"><code>value</code></em>
  | AVG_ROW_LENGTH [=] <em class="replaceable"><code>value</code></em>
  | [DEFAULT] CHARACTER SET <em class="replaceable"><code>charset_name</code></em>
  | CHECKSUM [=] {0 | 1}
  | COLLATE <em class="replaceable"><code>collation_name</code></em>
  | COMMENT [=] '<em class="replaceable"><code>string</code></em>'
  | CONNECTION [=] '<em class="replaceable"><code>connect_string</code></em>'
  | DATA DIRECTORY [=] '<em class="replaceable"><code>absolute path to directory</code></em>'
  | DELAY_KEY_WRITE [=] {0 | 1}
  | INDEX DIRECTORY [=] '<em class="replaceable"><code>absolute path to directory</code></em>'
  | INSERT_METHOD [=] { NO | FIRST | LAST }
  | MAX_ROWS [=] <em class="replaceable"><code>value</code></em>
  | MIN_ROWS [=] <em class="replaceable"><code>value</code></em>
  | PACK_KEYS [=] {0 | 1 | DEFAULT}
  | PASSWORD [=] '<em class="replaceable"><code>string</code></em>'
  | ROW_FORMAT [=] {DEFAULT|DYNAMIC|FIXED|COMPRESSED|REDUNDANT|COMPACT}
  | UNION [=] (<em class="replaceable"><code>tbl_name</code></em>[,<em class="replaceable"><code>tbl_name</code></em>]...)

<em class="replaceable"><code>select_statement:</code></em>
    [IGNORE | REPLACE] [AS] SELECT ...   (<em class="replaceable"><code>Some legal select statement</code></em>)
</pre><p>
        <code class="literal">CREATE TABLE</code> creates a table with the given
        name. You must have the <code class="literal">CREATE</code> privilege for
        the table.
      </p><p>
        Rules for allowable table names are given in
        <a href="http://dev.mysql.com/doc/refman/5.0/en/identifiers.html" target="_top">Database, Table, Index, Column, and Alias Names</a>. By default, the table is created
        in the default database. An error occurs if the table exists, if
        there is no default database, or if the database does not exist.
      </p><p>
        The table name can be specified as
        <em class="replaceable"><code>db_name.tbl_name</code></em> to create the table
        in a specific database. This works regardless of whether there
        is a default database, assuming that the database exists. If you
        use quoted identifiers, quote the database and table names
        separately. For example, write
        <code class="literal">`mydb`.`mytbl`</code>, not
        <code class="literal">`mydb.mytbl`</code>.
      </p><p>
        You can use the <code class="literal">TEMPORARY</code> keyword when
        creating a table. A <code class="literal">TEMPORARY</code> table is
        visible only to the current connection, and is dropped
        automatically when the connection is closed. This means that two
        different connections can use the same temporary table name
        without conflicting with each other or with an existing
        non-<code class="literal">TEMPORARY</code> table of the same name. (The
        existing table is hidden until the temporary table is dropped.)
        To create temporary tables, you must have the <code class="literal">CREATE
        TEMPORARY TABLES</code> privilege.
      </p><p>
        <span class="bold"><strong>Note</strong></span>: <code class="literal">CREATE
        TABLE</code> does not automatically commit the current active
        transaction if you use the <code class="literal">TEMPORARY</code> keyword.
      </p><p>
        The keywords <code class="literal">IF NOT EXISTS</code> prevent an error
        from occurring if the table exists. However, there is no
        verification that the existing table has a structure identical
        to that indicated by the <code class="literal">CREATE TABLE</code>
        statement. <span class="emphasis"><em>Note</em></span>: If you use <code class="literal">IF NOT
        EXISTS</code> in a <code class="literal">CREATE TABLE ... SELECT</code>
        statement, any rows selected by the <code class="literal">SELECT</code>
        part are inserted regardless of whether the table already
        exists.
      </p><p>
        MySQL represents each table by an <code class="filename">.frm</code>
        table format (definition) file in the database directory. The
        storage engine for the table might create other files as well.
        In the case of <code class="literal">MyISAM</code> tables, the storage
        engine creates data and index files. Thus, for each
        <code class="literal">MyISAM</code> table
        <em class="replaceable"><code>tbl_name</code></em>, there are three disk files:
      </p><div class="informaltable"><table border="1"><colgroup><col /><col /></colgroup><tbody><tr><td><span class="bold"><strong>File</strong></span></td><td><span class="bold"><strong>Purpose</strong></span></td></tr><tr><td><code class="filename"><em class="replaceable"><code>tbl_name</code></em>.frm</code></td><td>Table format (definition) file</td></tr><tr><td><code class="filename"><em class="replaceable"><code>tbl_name</code></em>.MYD</code></td><td>Data file</td></tr><tr><td><code class="filename"><em class="replaceable"><code>tbl_name</code></em>.MYI</code></td><td>Index file</td></tr></tbody></table></div><p>
        <a href="http://dev.mysql.com/doc/refman/5.0/en/storage-engines.html" target="_top">Storage Engines and Table Types</a>, describes what files each
        storage engine creates to represent tables.
      </p><p>
        <em class="replaceable"><code>data_type</code></em> represents the data type is
        a column definition. <em class="replaceable"><code>spatial_type</code></em>
        represents a spatial data type. The data type syntax shown is
        representative only. For a full description of the syntax
        available for specfiying column data types, as well as
        information about the properties of each type, see
        <a href="http://dev.mysql.com/doc/refman/5.0/en/data-types.html" target="_top">Data Types</a>, and
        <a href="http://dev.mysql.com/doc/refman/5.0/en/spatial-extensions.html" target="_top">Spatial Extensions</a>.
      </p><p>
        Some attributes do not apply to all data types.
        <code class="literal">AUTO_INCREMENT</code> applies only to integer types.
        <code class="literal">DEFAULT</code> does not apply to the
        <code class="literal">BLOB</code> or <code class="literal">TEXT</code> types.
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            If neither <code class="literal">NULL</code> nor <code class="literal">NOT
            NULL</code> is specified, the column is treated as though
            <code class="literal">NULL</code> had been specified.
          </p></li><li><p>
            An integer column can have the additional attribute
            <code class="literal">AUTO_INCREMENT</code>. When you insert a value
            of <code class="literal">NULL</code> (recommended) or
            <code class="literal">0</code> into an indexed
            <code class="literal">AUTO_INCREMENT</code> column, the column is set
            to the next sequence value. Typically this is
            <code class="literal"><em class="replaceable"><code>value</code></em>+1</code>, where
            <em class="replaceable"><code>value</code></em> is the largest value for
            the column currently in the table.
            <code class="literal">AUTO_INCREMENT</code> sequences begin with
            <code class="literal">1</code>.
          </p><p>
            To retrieve an <code class="literal">AUTO_INCREMENT</code> value after
            inserting a row, use the <code class="literal">LAST_INSERT_ID()</code>
            SQL function or the <code class="literal">mysql_insert_id()</code> C
            API function. See <a href="mysqlqb_functions.html#information-functions" title="Information Functions">Information Functions</a>,
            and <a href="http://dev.mysql.com/doc/refman/5.0/en/mysql-insert-id.html" target="_top"><code class="literal">mysql_insert_id()</code></a>.
          </p><p>
            If the <code class="literal">NO_AUTO_VALUE_ON_ZERO</code> SQL mode is
            enabled, you can store <code class="literal">0</code> in
            <code class="literal">AUTO_INCREMENT</code> columns as
            <code class="literal">0</code> without generating a new sequence
            value. See <a href="http://dev.mysql.com/doc/refman/5.0/en/server-sql-mode.html" target="_top">SQL Modes</a>.
          </p><p>
            <span class="bold"><strong>Note</strong></span>: There can be only one
            <code class="literal">AUTO_INCREMENT</code> column per table, it must
            be indexed, and it cannot have a <code class="literal">DEFAULT</code>
            value. An <code class="literal">AUTO_INCREMENT</code> column works
            properly only if it contains only positive values. Inserting
            a negative number is regarded as inserting a very large
            positive number. This is done to avoid precision problems
            when numbers “<span class="quote">wrap</span>” over from positive to
            negative and also to ensure that you do not accidentally get
            an <code class="literal">AUTO_INCREMENT</code> column that contains
            <code class="literal">0</code>.
          </p><p>
            For <code class="literal">MyISAM</code> and <code class="literal">BDB</code>
            tables, you can specify an <code class="literal">AUTO_INCREMENT</code>
            secondary column in a multiple-column key. See
            <a href="http://dev.mysql.com/doc/refman/5.0/en/example-auto-increment.html" target="_top">Using <code class="literal">AUTO_INCREMENT</code></a>.
          </p><a id="id2861845" class="indexterm"></a><a id="id2861851" class="indexterm"></a><p>
            To make MySQL compatible with some ODBC applications, you
            can find the <code class="literal">AUTO_INCREMENT</code> value for the
            last inserted row with the following query:
          </p><pre class="programlisting">SELECT * FROM <em class="replaceable"><code>tbl_name</code></em> WHERE <em class="replaceable"><code>auto_col</code></em> IS NULL
</pre><p>
            For information about <code class="literal">InnoDB</code> and
            <code class="literal">AUTO_INCREMENT</code>, see
            <a href="http://dev.mysql.com/doc/refman/5.0/en/innodb-auto-increment-column.html" target="_top">How <code class="literal">AUTO_INCREMENT</code> Columns Work in  <code class="literal">InnoDB</code></a>.
          </p></li><li><p>
            Character data types (<code class="literal">CHAR</code>,
            <code class="literal">VARCHAR</code>, <code class="literal">TEXT</code>) can
            include <code class="literal">CHARACTER SET</code> and
            <code class="literal">COLLATE</code> attributes to specify the
            character set and collation for the column. For details, see
            <a href="http://dev.mysql.com/doc/refman/5.0/en/charset.html" target="_top">Character Set Support</a>. <code class="literal">CHARSET</code> is a
            synonym for <code class="literal">CHARACTER SET</code>. Example:
          </p><pre class="programlisting">CREATE TABLE t (c CHAR(20) CHARACTER SET utf8 COLLATE utf8_bin);
</pre><p>
            MySQL 5.0 interprets length specifications in
            character column definitions in characters. (Versions before
            MySQL 4.1 interpreted them in bytes.) Lengths for
            <code class="literal">BINARY</code> and <code class="literal">VARBINARY</code>
            are in bytes.
          </p></li><li><p>
            <a id="id2861975" class="indexterm"></a>

            <a id="id2861982" class="indexterm"></a>

            The <code class="literal">DEFAULT</code> clause specifies a default
            value for a column. With one exception, the default value
            must be a constant; it cannot be a function or an
            expression. This means, for example, that you cannot set the
            default for a date column to be the value of a function such
            as <code class="literal">NOW()</code> or
            <code class="literal">CURRENT_DATE</code>. The exception is that you
            can specify <code class="literal">CURRENT_TIMESTAMP</code> as the
            default for a <code class="literal">TIMESTAMP</code> column. See
            <a href="http://dev.mysql.com/doc/refman/5.0/en/timestamp-4-1.html" target="_top"><code class="literal">TIMESTAMP</code> Properties as of MySQL 4.1</a>.
          </p><p>
            If a column definition includes no explicit
            <code class="literal">DEFAULT</code> value, MySQL determines the
            default value as described in
            <a href="http://dev.mysql.com/doc/refman/5.0/en/data-type-defaults.html" target="_top">Data Type Default Values</a>.
          </p><p>
            <code class="literal">BLOB</code> and <code class="literal">TEXT</code> columns
            cannot be assigned a default value.
          </p></li><li><p>
            <a id="id2862060" class="indexterm"></a>

            A comment for a column can be specified with the
            <code class="literal">COMMENT</code> option, up to 255 characters
            long. The comment is displayed by the <code class="literal">SHOW CREATE
            TABLE</code> and <code class="literal">SHOW FULL COLUMNS</code>
            statements.
          </p></li><li><p>
            <code class="literal">KEY</code> is normally a synonym for
            <code class="literal">INDEX</code>. The key attribute <code class="literal">PRIMARY
            KEY</code> can also be specified as just
            <code class="literal">KEY</code> when given in a column definition.
            This was implemented for compatibility with other database
            systems.
          </p></li><li><p>
            A <code class="literal">UNIQUE</code> index creates a constraint such
            that all values in the index must be distinct. An error
            occurs if you try to add a new row with a key value that
            matches an existing row. This constraint does not apply to
            <code class="literal">NULL</code> values except for the
            <code class="literal">BDB</code> storage engine. For other engines, a
            <code class="literal">UNIQUE</code> index allows multiple
            <code class="literal">NULL</code> values for columns that can contain
            <code class="literal">NULL</code>.
          </p></li><li><p>
            <a id="id2862147" class="indexterm"></a>

            A <code class="literal">PRIMARY KEY</code> is a unique index where all
            key columns must be defined as <code class="literal">NOT NULL</code>.
            If they are not explicitly declared as <code class="literal">NOT
            NULL</code>, MySQL declares them so implicitly (and
            silently). A table can have only one <code class="literal">PRIMARY
            KEY</code>. If you do not have a <code class="literal">PRIMARY
            KEY</code> and an application asks for the
            <code class="literal">PRIMARY KEY</code> in your tables, MySQL returns
            the first <code class="literal">UNIQUE</code> index that has no
            <code class="literal">NULL</code> columns as the <code class="literal">PRIMARY
            KEY</code>.
          </p><p>
            In <code class="literal">InnoDB</code> tables, having a long
            <code class="literal">PRIMARY KEY</code> wastes a lot of space. (See
            <a href="http://dev.mysql.com/doc/refman/5.0/en/innodb-table-and-index.html" target="_top"><code class="literal">InnoDB</code> Table and Index Structures</a>.)
          </p></li><li><p>
            In the created table, a <code class="literal">PRIMARY KEY</code> is
            placed first, followed by all <code class="literal">UNIQUE</code>
            indexes, and then the non-unique indexes. This helps the
            MySQL optimizer to prioritize which index to use and also
            more quickly to detect duplicated <code class="literal">UNIQUE</code>
            keys.
          </p></li><li><p>
            A <code class="literal">PRIMARY KEY</code> can be a multiple-column
            index. However, you cannot create a multiple-column index
            using the <code class="literal">PRIMARY KEY</code> key attribute in a
            column specification. Doing so only marks that single column
            as primary. You must use a separate <code class="literal">PRIMARY
            KEY(<em class="replaceable"><code>index_col_name</code></em>,
            ...)</code> clause.
          </p></li><li><p>
            <a id="id2862272" class="indexterm"></a>

            If a <code class="literal">PRIMARY KEY</code> or
            <code class="literal">UNIQUE</code> index consists of only one column
            that has an integer type, you can also refer to the column
            as <code class="literal">_rowid</code> in <code class="literal">SELECT</code>
            statements.
          </p></li><li><p>
            In MySQL, the name of a <code class="literal">PRIMARY KEY</code> is
            <code class="literal">PRIMARY</code>. For other indexes, if you do not
            assign a name, the index is assigned the same name as the
            first indexed column, with an optional suffix
            (<code class="literal">_2</code>, <code class="literal">_3</code>,
            <code class="literal">...</code>) to make it unique. You can see index
            names for a table using <code class="literal">SHOW INDEX FROM
            <em class="replaceable"><code>tbl_name</code></em></code>. See
            <a href="mysqlqb_statements.html#show-index" title="SHOW INDEX Syntax"><code class="literal">SHOW INDEX</code> Syntax</a>.
          </p></li><li><p>
            Some storage engines allow you to specify an index type when
            creating an index. The syntax for the
            <em class="replaceable"><code>index_type</code></em> specifier is
            <code class="literal">USING
            <em class="replaceable"><code>type_name</code></em></code>.
          </p><p>
            Example:
          </p><pre class="programlisting">CREATE TABLE lookup
  (id INT, INDEX USING BTREE (id))
  ENGINE = MEMORY;
</pre><p>
            For details about <code class="literal">USING</code>, see
            <a href="mysqlqb_statements.html#create-index" title="CREATE INDEX Syntax"><code class="literal">CREATE INDEX</code> Syntax</a>.
          </p><p>
            For more information about indexes, see
            <a href="http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html" target="_top">How MySQL Uses Indexes</a>.
          </p></li><li><p>
            <a id="id2862396" class="indexterm"></a>

            <a id="id2862408" class="indexterm"></a>

            In MySQL 5.0, only the
            <code class="literal">MyISAM</code>, <code class="literal">InnoDB</code>,
            <code class="literal">BDB</code>, and <code class="literal">MEMORY</code>
            storage engines support indexes on columns that can have
            <code class="literal">NULL</code> values. In other cases, you must
            declare indexed columns as <code class="literal">NOT NULL</code> or an
            error results.
          </p></li><li><p>
            For <code class="literal">CHAR</code>, <code class="literal">VARCHAR</code>,
            <code class="literal">BINARY</code>, and <code class="literal">VARBINARY</code>
            columns, indexes can be created that use only the leading
            part of column values, using
            <code class="literal"><em class="replaceable"><code>col_name</code></em>(<em class="replaceable"><code>length</code></em>)</code>
            syntax to specify an index prefix length.
            <code class="literal">BLOB</code> and <code class="literal">TEXT</code> columns
            also can be indexed, but a prefix length
            <span class="emphasis"><em>must</em></span> be given. Prefix lengths are given
            in characters for non-binary string types and in bytes for
            binary string types. That is, index entries consist of the
            first <em class="replaceable"><code>length</code></em> characters of each
            column value for <code class="literal">CHAR</code>,
            <code class="literal">VARCHAR</code>, and <code class="literal">TEXT</code>
            columns, and the first <em class="replaceable"><code>length</code></em>
            bytes of each column value for <code class="literal">BINARY</code>,
            <code class="literal">VARBINARY</code>, and <code class="literal">BLOB</code>
            columns. Indexing only a prefix of column values like this
            can make the index file much smaller. See
            <a href="http://dev.mysql.com/doc/refman/5.0/en/indexes.html" target="_top">Column Indexes</a>.
          </p><a id="id2862540" class="indexterm"></a><a id="id2862552" class="indexterm"></a><a id="id2862566" class="indexterm"></a><a id="id2862579" class="indexterm"></a><p>
            Only the <code class="literal">MyISAM</code>, <code class="literal">BDB</code>,
            and <code class="literal">InnoDB</code> storage engines support
            indexing on <code class="literal">BLOB</code> and
            <code class="literal">TEXT</code> columns. For example:
          </p><pre class="programlisting">CREATE TABLE test (blob_col BLOB, INDEX(blob_col(10)));
</pre><p>
            Prefixes can be up to 1000 bytes long (767 bytes for
            <code class="literal">InnoDB</code> tables). Note that prefix limits
            are measured in bytes, whereas the prefix length in
            <code class="literal">CREATE TABLE</code> statements is interpreted as
            number of characters for non-binary data types
            (<code class="literal">CHAR</code>, <code class="literal">VARCHAR</code>,
            <code class="literal">TEXT</code>). Take this into account when
            specifying a prefix length for a column that uses a
            multi-byte character set.
          </p></li><li><p>
            An <em class="replaceable"><code>index_col_name</code></em> specification
            can end with <code class="literal">ASC</code> or
            <code class="literal">DESC</code>. These keywords are allowed for
            future extensions for specifying ascending or descending
            index value storage. Currently, they are parsed but ignored;
            index values are always stored in ascending order.
          </p></li><li><p>
            When you use <code class="literal">ORDER BY</code> or <code class="literal">GROUP
            BY</code> on a <code class="literal">TEXT</code> or
            <code class="literal">BLOB</code> column in a
            <code class="literal">SELECT</code>, the server sorts values using
            only the initial number of bytes indicated by the
            <code class="literal">max_sort_length</code> system variable. See
            <a href="http://dev.mysql.com/doc/refman/5.0/en/blob.html" target="_top">The <code class="literal">BLOB</code> and <code class="literal">TEXT</code> Types</a>.
          </p></li><li><p>
            You can create special <code class="literal">FULLTEXT</code> indexes,
            which are used for full-text searches. Only the
            <code class="literal">MyISAM</code> storage engine supports
            <code class="literal">FULLTEXT</code> indexes. They can be created
            only from <code class="literal">CHAR</code>,
            <code class="literal">VARCHAR</code>, and <code class="literal">TEXT</code>
            columns. Indexing always happens over the entire column;
            column prefix indexing is not supported and any prefix
            length is ignored if specified. See
            <a href="mysqlqb_functions.html#fulltext-search" title="Full-Text Search Functions">Full-Text Search Functions</a>, for details of operation.
          </p></li><li><p>
            You can create <code class="literal">SPATIAL</code> indexes on spatial
            data types. Spatial types are supported only for
            <code class="literal">MyISAM</code> tables and indexed columns must be
            declared as <code class="literal">NOT NULL</code>. See
            <a href="http://dev.mysql.com/doc/refman/5.0/en/spatial-extensions.html" target="_top">Spatial Extensions</a>.
          </p></li><li><p>
            <code class="literal">InnoDB</code> tables support checking of foreign
            key constraints. See <a href="http://dev.mysql.com/doc/refman/5.0/en/innodb.html" target="_top">The <code class="literal">InnoDB</code> Storage Engine</a>. Note that the
            <code class="literal">FOREIGN KEY</code> syntax in
            <code class="literal">InnoDB</code> is more restrictive than the
            syntax presented for the <code class="literal">CREATE TABLE</code>
            statement at the beginning of this section: The columns of
            the referenced table must always be explicitly named.
            <code class="literal">InnoDB</code> supports both <code class="literal">ON
            DELETE</code> and <code class="literal">ON UPDATE</code> actions on
            foreign keys. For the precise syntax, see
            <a href="http://dev.mysql.com/doc/refman/5.0/en/innodb-foreign-key-constraints.html" target="_top"><code class="literal">FOREIGN KEY</code> Constraints</a>.
          </p><p>
            For other storage engines, MySQL Server parses and ignores
            the <code class="literal">FOREIGN KEY</code> and
            <code class="literal">REFERENCES</code> syntax in <code class="literal">CREATE
            TABLE</code> statements. The <code class="literal">CHECK</code>
            clause is parsed but ignored by all storage engines. See
            <a href="http://dev.mysql.com/doc/refman/5.0/en/ansi-diff-foreign-keys.html" target="_top">Foreign Keys</a>.
          </p></li><li><p>
            For <code class="literal">MyISAM</code> tables, each
            <code class="literal">NULL</code> column takes one bit extra, rounded
            up to the nearest byte. The maximum row length in bytes can
            be calculated as follows:
          </p><pre class="programlisting">row length = 1
             + (<em class="replaceable"><code>sum of column lengths</code></em>)
             + (<em class="replaceable"><code>number of NULL columns</code></em> + <em class="replaceable"><code>delete_flag</code></em> + 7)/8
             + (<em class="replaceable"><code>number of variable-length columns</code></em>)
</pre><p>
            <em class="replaceable"><code>delete_flag</code></em> is 1 for tables with
            static row format. Static tables use a bit in the row record
            for a flag that indicates whether the row has been deleted.
            <em class="replaceable"><code>delete_flag</code></em> is 0 for dynamic
            tables because the flag is stored in the dynamic row header.
          </p><p>
            These calculations do not apply for
            <code class="literal">InnoDB</code> tables, for which storage size is
            no different for <code class="literal">NULL</code> columns than for
            <code class="literal">NOT NULL</code> columns.
          </p></li></ul></div><p>
        The <code class="literal">ENGINE</code> table option specifies the storage
        engine for the table. <code class="literal">TYPE</code> is a synonym, but
        <code class="literal">ENGINE</code> is the preferred option name.
      </p><p>
        The <code class="literal">ENGINE</code> table option takes the storage
        engine names shown in the following table.
      </p><div class="informaltable"><table border="1"><colgroup><col /><col /></colgroup><tbody><tr><td><span class="bold"><strong>Storage Engine</strong></span></td><td><span class="bold"><strong>Description</strong></span></td></tr><tr><td><code class="literal">ARCHIVE</code></td><td>The archiving storage engine. See
                <a href="http://dev.mysql.com/doc/refman/5.0/en/archive-storage-engine.html" target="_top">The <code class="literal">ARCHIVE</code> Storage Engine</a>.</td></tr><tr><td><code class="literal">BDB</code></td><td>Transaction-safe tables with page locking. Also known as
                <code class="literal">BerkeleyDB</code>. See
                <a href="http://dev.mysql.com/doc/refman/5.0/en/bdb-storage-engine.html" target="_top">The <code class="literal">BDB</code> (<code class="literal">BerkeleyDB</code>) Storage  Engine</a>.</td></tr><tr><td><code class="literal">CSV</code></td><td>Tables that store rows in comma-separated values format. See
                <a href="http://dev.mysql.com/doc/refman/5.0/en/csv-storage-engine.html" target="_top">The <code class="literal">CSV</code> Storage Engine</a>.</td></tr><tr><td><code class="literal">EXAMPLE</code></td><td>An example engine. See <a href="http://dev.mysql.com/doc/refman/5.0/en/example-storage-engine.html" target="_top">The <code class="literal">EXAMPLE</code> Storage Engine</a>.</td></tr><tr><td><code class="literal">FEDERATED</code></td><td>Storage engine that accesses remote tables. See
                <a href="http://dev.mysql.com/doc/refman/5.0/en/federated-storage-engine.html" target="_top">The <code class="literal">FEDERATED</code> Storage Engine</a>.</td></tr><tr><td><code class="literal">HEAP</code></td><td>This is a synonym for <code class="literal">MEMORY</code>.</td></tr><tr><td><code class="literal">ISAM</code> (<span class="emphasis"><em>OBSOLETE</em></span>)</td><td>Not available in MySQL 5.0. If you are upgrading to MySQL
                5.0 from a previous version, you should
                convert any existing <code class="literal">ISAM</code> tables to
                <code class="literal">MyISAM</code> <span class="emphasis"><em>before</em></span>
                performing the upgrade.</td></tr><tr><td><code class="literal">InnoDB</code></td><td>Transaction-safe tables with row locking and foreign keys. See
                <a href="http://dev.mysql.com/doc/refman/5.0/en/innodb.html" target="_top">The <code class="literal">InnoDB</code> Storage Engine</a>.</td></tr><tr><td><code class="literal">MEMORY</code></td><td>The data for this storage engine is stored only in memory. See
                <a href="http://dev.mysql.com/doc/refman/5.0/en/memory-storage-engine.html" target="_top">The <code class="literal">MEMORY</code> (<code class="literal">HEAP</code>) Storage Engine</a>.</td></tr><tr><td><code class="literal">MERGE</code></td><td>A collection of <code class="literal">MyISAM</code> tables used as one table. Also
                known as <code class="literal">MRG_MyISAM</code>. See
                <a href="http://dev.mysql.com/doc/refman/5.0/en/merge-storage-engine.html" target="_top">The <code class="literal">MERGE</code> Storage Engine</a>.</td></tr><tr><td><code class="literal">MyISAM</code></td><td>The binary portable storage engine that is the default storage engine
                used by MySQL. See
                <a href="http://dev.mysql.com/doc/refman/5.0/en/myisam-storage-engine.html" target="_top">The <code class="literal">MyISAM</code> Storage Engine</a>.</td></tr><tr><td><code class="literal">NDBCLUSTER</code></td><td>Clustered, fault-tolerant, memory-based tables. Also known as
                <code class="literal">NDB</code>. See
                <a href="http://dev.mysql.com/doc/refman/5.0/en/mysql-cluster.html" target="_top">MySQL Cluster</a>.</td></tr></tbody></table></div><p>
        If a storage engine is specified that is not available, MySQL
        uses the default engine instead. Normally, this is
        <code class="literal">MyISAM</code>. For example, if a table definition
        includes the <code class="literal">ENGINE=BDB</code> option but the MySQL
        server does not support <code class="literal">BDB</code> tables, the table
        is created as a <code class="literal">MyISAM</code> table. This makes it
        possible to have a replication setup where you have
        transactional tables on the master but tables created on the
        slave are non-transactional (to get more speed). In MySQL
        5.0, a warning occurs if the storage engine
        specification is not honored.
      </p><p>
        The other table options are used to optimize the behavior of the
        table. In most cases, you do not have to specify any of them.
        These options apply to all storage engines unless otherwise
        indicated. Options that do not apply to a given storage engine
        may be accepted and remembered as part of the table definition.
        Such options then apply if you later use <code class="literal">ALTER
        TABLE</code> to convert the table to use a different storage
        engine.
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            <code class="literal">AUTO_INCREMENT</code>
          </p><p>
            The initial <code class="literal">AUTO_INCREMENT</code> value for the
            table. In MySQL 5.0, this works for
            <code class="literal">MyISAM</code> and <code class="literal">MEMORY</code>
            tables. It is also supported for <code class="literal">InnoDB</code>
            as of MySQL 5.0.3. To set the first auto-increment value for
            engines that do not support the
            <code class="literal">AUTO_INCREMENT</code> table option, insert a
            “<span class="quote">dummy</span>” row with a value one less than the
            desired value after creating the table, and then delete the
            dummy row.
          </p><p>
            For engines that support the
            <code class="literal">AUTO_INCREMENT</code> table option in
            <code class="literal">CREATE TABLE</code> statements, you can also use
            <code class="literal">ALTER TABLE <em class="replaceable"><code>tbl_name</code></em>
            AUTO_INCREMENT = <em class="replaceable"><code>N</code></em></code> to
            reset the <code class="literal">AUTO_INCREMENT</code> value. The value
            cannot be set lower than the maximum value currently in the
            column.
          </p></li><li><p>
            <code class="literal">AVG_ROW_LENGTH</code>
          </p><p>
            An approximation of the average row length for your table.
            You need to set this only for large tables with
            variable-size rows.
          </p><p>
            When you create a <code class="literal">MyISAM</code> table, MySQL
            uses the product of the <code class="literal">MAX_ROWS</code> and
            <code class="literal">AVG_ROW_LENGTH</code> options to decide how big
            the resulting table is. If you don't specify either option,
            the maximum size for a table is 256TB of data by default
            (4GB before MySQL 5.0.6). (If your operating system does not
            support files that large, table sizes are constrained by the
            file size limit.) If you want to keep down the pointer sizes
            to make the index smaller and faster and you don't really
            need big files, you can decrease the default pointer size by
            setting the <code class="literal">myisam_data_pointer_size</code>
            system variable, which was added in MySQL 4.1.2. (See
            <a href="http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html" target="_top">System Variables</a>.) If you want all
            your tables to be able to grow above the default limit and
            are willing to have your tables slightly slower and larger
            than necessary, you can increase the default pointer size by
            setting this variable.
          </p></li><li><p>
            <code class="literal">[DEFAULT] CHARACTER SET</code>
          </p><p>
            Specify a default character set for the table.
            <code class="literal">CHARSET</code> is a synonym for
            <code class="literal">CHARACTER SET</code>.
          </p></li><li><p>
            <code class="literal">CHECKSUM</code>
          </p><p>
            Set this to 1 if you want MySQL to maintain a live checksum
            for all rows (that is, a checksum that MySQL updates
            automatically as the table changes). This makes the table a
            little slower to update, but also makes it easier to find
            corrupted tables. The <code class="literal">CHECKSUM TABLE</code>
            statement reports the checksum. (<code class="literal">MyISAM</code>
            only.)
          </p></li><li><p>
            <code class="literal">COLLATE</code>
          </p><p>
            Specify a default collation for the table.
          </p></li><li><p>
            <code class="literal">COMMENT</code>
          </p><p>
            A comment for the table, up to 60 characters long.
          </p></li><li><p>
            <code class="literal">CONNECTION</code>
          </p><p>
            The connection string for a <code class="literal">FEDERATED</code>
            table. This option is available as of MySQL 5.0.13; before
            that, use a <code class="literal">COMMENT</code> option for the
            connection string.
          </p></li><li><p>
            <code class="literal">DATA DIRECTORY</code>, <code class="literal">INDEX
            DIRECTORY</code>
          </p><p>
            By using <code class="literal">DATA
            DIRECTORY='<em class="replaceable"><code>directory</code></em>'</code>
            or <code class="literal">INDEX
            DIRECTORY='<em class="replaceable"><code>directory</code></em>'</code>
            you can specify where the <code class="literal">MyISAM</code> storage
            engine should put a table's data file and index file. The
            directory must be the full pathname to the directory, not a
            relative path.
          </p><p>
            These options work only when you are not using the
            <code class="option">--skip-symbolic-links</code> option. Your
            operating system must also have a working, thread-safe
            <code class="literal">realpath()</code> call. See
            <a href="http://dev.mysql.com/doc/refman/5.0/en/symbolic-links-to-tables.html" target="_top">Using Symbolic Links for Tables on Unix</a>, for more
            complete information.
          </p></li><li><p>
            <code class="literal">DELAY_KEY_WRITE</code>
          </p><p>
            Set this to 1 if you want to delay key updates for the table
            until the table is closed. See the description of the
            <code class="literal">delay_key_write</code> system variable in
            <a href="http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html" target="_top">System Variables</a>.
            (<code class="literal">MyISAM</code> only.)
          </p></li><li><p>
            <code class="literal">INSERT_METHOD</code>
          </p><p>
            If you want to insert data into a <code class="literal">MERGE</code>
            table, you must specify with
            <code class="literal">INSERT_METHOD</code> the table into which the
            row should be inserted. <code class="literal">INSERT_METHOD</code> is
            an option useful for <code class="literal">MERGE</code> tables only.
            Use a value of <code class="literal">FIRST</code> or
            <code class="literal">LAST</code> to have inserts go to the first or
            last table, or a value of <code class="literal">NO</code> to prevent
            inserts. See <a href="http://dev.mysql.com/doc/refman/5.0/en/merge-storage-engine.html" target="_top">The <code class="literal">MERGE</code> Storage Engine</a>.
          </p></li><li><p>
            <code class="literal">MAX_ROWS</code>
          </p><p>
            The maximum number of rows you plan to store in the table.
            This is not a hard limit, but rather a hint to the storage
            engine that the table must be able to store at least this
            many rows.
          </p></li><li><p>
            <code class="literal">MIN_ROWS</code>
          </p><p>
            The minimum number of rows you plan to store in the table.
          </p></li><li><p>
            <code class="literal">PACK_KEYS</code>
          </p><p>
            <code class="literal">PACK_KEYS</code> takes effect only with
            <code class="literal">MyISAM</code> tables. Set this option to 1 if
            you want to have smaller indexes. This usually makes updates
            slower and reads faster. Setting the option to 0 disables
            all packing of keys. Setting it to
            <code class="literal">DEFAULT</code> tells the storage engine to pack
            only long <code class="literal">CHAR</code> or
            <code class="literal">VARCHAR</code> columns.
          </p><p>
            If you do not use <code class="literal">PACK_KEYS</code>, the default
            is to pack strings, but not numbers. If you use
            <code class="literal">PACK_KEYS=1</code>, numbers are packed as well.
          </p><p>
            When packing binary number keys, MySQL uses prefix
            compression:
          </p><div class="itemizedlist"><ul type="circle"><li><p>
                Every key needs one extra byte to indicate how many
                bytes of the previous key are the same for the next key.
              </p></li><li><p>
                The pointer to the row is stored in high-byte-first
                order directly after the key, to improve compression.
              </p></li></ul></div><p>
            This means that if you have many equal keys on two
            consecutive rows, all following “<span class="quote">same</span>” keys
            usually only take two bytes (including the pointer to the
            row). Compare this to the ordinary case where the following
            keys takes <code class="literal">storage_size_for_key +
            pointer_size</code> (where the pointer size is usually
            4). Conversely, you get a significant benefit from prefix
            compression only if you have many numbers that are the same.
            If all keys are totally different, you use one byte more per
            key, if the key is not a key that can have
            <code class="literal">NULL</code> values. (In this case, the packed
            key length is stored in the same byte that is used to mark
            if a key is <code class="literal">NULL</code>.)
          </p></li><li><p>
            <code class="literal">PASSWORD</code>
          </p><p>
            This option is unused. If you have a need to scramble your
            <code class="filename">.frm</code> files and make them unusable to
            any other MySQL server, please contact our sales department.
          </p></li><li><p>
            <code class="literal">ROW_FORMAT</code>
          </p><p>
            Defines how the rows should be stored. For
            <code class="literal">MyISAM</code> tables, the option value can be
            <code class="literal">FIXED</code> or <code class="literal">DYNAMIC</code> for
            static or variable-length row format.
            <span><strong class="command">myisampack</strong></span> sets the type to
            <code class="literal">COMPRESSED</code>. See
            <a href="http://dev.mysql.com/doc/refman/5.0/en/myisam-table-formats.html" target="_top"><code class="literal">MyISAM</code> Table Storage Formats</a>.
          </p><p>
            Starting with MySQL 5.0.3, for <code class="literal">InnoDB</code>
            tables, rows are stored in compact format
            (<code class="literal">ROW_FORMAT=COMPACT</code>) by default. The
            non-compact format used in older versions of MySQL can still
            be requested by specifying
            <code class="literal">ROW_FORMAT=REDUNDANT</code>.
          </p></li><li><p>
            <code class="literal">RAID_TYPE</code>
          </p><p>
            <code class="literal">RAID</code> support has been removed as of MySQL
            5.0. For information on <code class="literal">RAID</code>, see
            <a href="http://dev.mysql.com/doc/refman/4.1/en/create-table.html" target="_top">http://dev.mysql.com/doc/refman/4.1/en/create-table.html</a>.
          </p></li><li><p>
            <code class="literal">UNION</code>
          </p><p>
            <code class="literal">UNION</code> is used when you want to access a
            collection of identical <code class="literal">MyISAM</code> tables as
            one. This works only with <code class="literal">MERGE</code> tables.
            See <a href="http://dev.mysql.com/doc/refman/5.0/en/merge-storage-engine.html" target="_top">The <code class="literal">MERGE</code> Storage Engine</a>.
          </p><p>
            You must have <code class="literal">SELECT</code>,
            <code class="literal">UPDATE</code>, and <code class="literal">DELETE</code>
            privileges for the tables you map to a
            <code class="literal">MERGE</code> table. (<span class="emphasis"><em>Note</em></span>:
            Formerly, all tables used had to be in the same database as
            the <code class="literal">MERGE</code> table itself. This restriction
            no longer applies.)
          </p></li></ul></div><a id="id2864053" class="indexterm"></a><a id="id2864060" class="indexterm"></a><p>
        You can create one table from another by adding a
        <code class="literal">SELECT</code> statement at the end of the
        <code class="literal">CREATE TABLE</code> statement:
      </p><pre class="programlisting">CREATE TABLE <em class="replaceable"><code>new_tbl</code></em> SELECT * FROM <em class="replaceable"><code>orig_tbl</code></em>;
</pre><p>
        MySQL creates new columns for all elements in the
        <code class="literal">SELECT</code>. For example:
      </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>CREATE TABLE test (a INT NOT NULL AUTO_INCREMENT,</code></strong>
    -&gt;        <strong class="userinput"><code>PRIMARY KEY (a), KEY(b))</code></strong>
    -&gt;        <strong class="userinput"><code>ENGINE=MyISAM SELECT b,c FROM test2;</code></strong>
</pre><p>
        This creates a <code class="literal">MyISAM</code> table with three
        columns, <code class="literal">a</code>, <code class="literal">b</code>, and
        <code class="literal">c</code>. Notice that the columns from the
        <code class="literal">SELECT</code> statement are appended to the right
        side of the table, not overlapped onto it. Take the following
        example:
      </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SELECT * FROM foo;</code></strong>
+---+
| n |
+---+
| 1 |
+---+

mysql&gt; <strong class="userinput"><code>CREATE TABLE bar (m INT) SELECT n FROM foo;</code></strong>
Query OK, 1 row affected (0.02 sec)
Records: 1  Duplicates: 0  Warnings: 0

mysql&gt; <strong class="userinput"><code>SELECT * FROM bar;</code></strong>
+------+---+
| m    | n |
+------+---+
| NULL | 1 |
+------+---+
1 row in set (0.00 sec)
</pre><p>
        For each row in table <code class="literal">foo</code>, a row is inserted
        in <code class="literal">bar</code> with the values from
        <code class="literal">foo</code> and default values for the new columns.
      </p><p>
        In a table resulting from <code class="literal">CREATE TABLE ...
        SELECT</code>, columns named only in the <code class="literal">CREATE
        TABLE</code> part come first. Columns named in both parts or
        only in the <code class="literal">SELECT</code> part come after that. The
        data type of <code class="literal">SELECT</code> columns can be overridden
        by also specifying the column in the <code class="literal">CREATE
        TABLE</code> part.
      </p><p>
        If any errors occur while copying the data to the table, it is
        automatically dropped and not created.
      </p><p>
        <code class="literal">CREATE TABLE ... SELECT</code> does not
        automatically create any indexes for you. This is done
        intentionally to make the statement as flexible as possible. If
        you want to have indexes in the created table, you should
        specify these before the <code class="literal">SELECT</code> statement:
      </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>CREATE TABLE bar (UNIQUE (n)) SELECT n FROM foo;</code></strong>
</pre><p>
        Some conversion of data types might occur. For example, the
        <code class="literal">AUTO_INCREMENT</code> attribute is not preserved,
        and <code class="literal">VARCHAR</code> columns can become
        <code class="literal">CHAR</code> columns.
      </p><p>
        When creating a table with <code class="literal">CREATE ... SELECT</code>,
        make sure to alias any function calls or expressions in the
        query. If you do not, the <code class="literal">CREATE</code> statement
        might fail or result in undesirable column names.
      </p><pre class="programlisting">CREATE TABLE artists_and_works
  SELECT artist.name, COUNT(work.artist_id) AS number_of_works
  FROM artist LEFT JOIN work ON artist.id = work.artist_id
  GROUP BY artist.id;
</pre><p>
        You can also explicitly specify the data type for a generated
        column:
      </p><pre class="programlisting">CREATE TABLE foo (a TINYINT NOT NULL) SELECT b+1 AS a FROM bar;
</pre><p>
        Use <code class="literal">LIKE</code> to create an empty table based on
        the definition of another table, including any column attributes
        and indexes defined in the original table:
      </p><pre class="programlisting">CREATE TABLE <em class="replaceable"><code>new_tbl</code></em> LIKE <em class="replaceable"><code>orig_tbl</code></em>;
</pre><p>
        The copy is created using the same version of the table storage
        format as the original table.
      </p><p>
        <code class="literal">CREATE TABLE ... LIKE</code> does not preserve any
        <code class="literal">DATA DIRECTORY</code> or <code class="literal">INDEX
        DIRECTORY</code> table options that were specified for the
        original table, or any foreign key definitions.
      </p><p>
        You can precede the <code class="literal">SELECT</code> by
        <code class="literal">IGNORE</code> or <code class="literal">REPLACE</code> to
        indicate how to handle rows that duplicate unique key values.
        With <code class="literal">IGNORE</code>, new rows that duplicate an
        existing row on a unique key value are discarded. With
        <code class="literal">REPLACE</code>, new rows replace rows that have the
        same unique key value. If neither <code class="literal">IGNORE</code> nor
        <code class="literal">REPLACE</code> is specified, duplicate unique key
        values result in an error.
      </p><p>
        To ensure that the binary log can be used to re-create the
        original tables, MySQL does not allow concurrent inserts during
        <code class="literal">CREATE TABLE ... SELECT</code>.
      </p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="silent-column-changes"></a>Silent Column Specification Changes</h4></div></div></div><a id="id2864379" class="indexterm"></a><p>
          In some cases, MySQL silently changes column specifications
          from those given in a <code class="literal">CREATE TABLE</code> or
          <code class="literal">ALTER TABLE</code> statement. These might be
          changes to a data type, to attributes associated with a data
          type, or to an index specification.
        </p><p>
          Some silent column specification changes include modifications
          to attribute or index specifications:
        </p><div class="itemizedlist"><ul type="disc"><li><p>
              <code class="literal">TIMESTAMP</code> display sizes are discarded.
            </p><p>
              Also note that <code class="literal">TIMESTAMP</code> columns are
              <code class="literal">NOT NULL</code> by default.
            </p></li><li><p>
              Columns that are part of a <code class="literal">PRIMARY KEY</code>
              are made <code class="literal">NOT NULL</code> even if not declared
              that way.
            </p></li><li><p>
              Trailing spaces are automatically deleted from
              <code class="literal">ENUM</code> and <code class="literal">SET</code> member
              values when the table is created.
            </p></li><li><p>
              MySQL maps certain data types used by other SQL database
              vendors to MySQL types. See
              <a href="http://dev.mysql.com/doc/refman/5.0/en/other-vendor-data-types.html" target="_top">Using Data Types from Other Database Engines</a>.
            </p></li><li><p>
              If you include a <code class="literal">USING</code> clause to
              specify an index type that is not legal for a given
              storage engine, but there is another index type available
              that the engine can use without affecting query results,
              the engine uses the available type.
            </p></li></ul></div><p>
          Possible data type changes are given in the following list.
          These occur only up to the versions listed. After that, an
          error occurs if a column cannot be created using the specified
          data type.
        </p><div class="itemizedlist"><ul type="disc"><li><p>
              Before MySQL 5.0.3, <code class="literal">VARCHAR</code> columns
              with a length less than four are changed to
              <code class="literal">CHAR</code>.
            </p></li><li><p>
              Before MySQL 5.0.3, if any column in a table has a
              variable length, the entire row becomes variable-length as
              a result. Therefore, if a table contains any
              variable-length columns (<code class="literal">VARCHAR</code>,
              <code class="literal">TEXT</code>, or <code class="literal">BLOB</code>), all
              <code class="literal">CHAR</code> columns longer than three
              characters are changed to <code class="literal">VARCHAR</code>
              columns. This does not affect how you use the columns in
              any way; in MySQL, <code class="literal">VARCHAR</code> is just a
              different way to store characters. MySQL performs this
              conversion because it saves space and makes table
              operations faster. See <a href="http://dev.mysql.com/doc/refman/5.0/en/storage-engines.html" target="_top">Storage Engines and Table Types</a>.
            </p></li><li><p>
              Before MySQL 5.0.3, a <code class="literal">CHAR</code> or
              <code class="literal">VARCHAR</code> column with a length
              specification greater than 255 is converted to the
              smallest <code class="literal">TEXT</code> type that can hold values
              of the given length. For example,
              <code class="literal">VARCHAR(500)</code> is converted to
              <code class="literal">TEXT</code>, and
              <code class="literal">VARCHAR(200000)</code> is converted to
              <code class="literal">MEDIUMTEXT</code>. Similar conversions occur
              for <code class="literal">BINARY</code> and
              <code class="literal">VARBINARY</code>, except that they are
              converted to a <code class="literal">BLOB</code> type.
            </p><p>
              Note that these conversions result in a change in behavior
              with regard to treatment of trailing spaces.
            </p><p>
              As of MySQL 5.0.3, a <code class="literal">CHAR</code> or
              <code class="literal">BINARY</code> column with a length
              specification greater than 255 is not silently converted.
              Instead, an error occurs. From MySQL 5.0.6 on, silent
              conversion of <code class="literal">VARCHAR</code> and
              <code class="literal">VARBINARY</code> columns with a length
              specification greater than 65,535 does not occur if strict
              SQL mode is enabled. Instead, an error occurs.
            </p></li><li><p>
              Before MySQL 5.0.10, for a specification of
              <code class="literal">DECIMAL(<em class="replaceable"><code>M</code></em>,<em class="replaceable"><code>D</code></em>)</code>,
              if <em class="replaceable"><code>M</code></em> is not larger than
              <em class="replaceable"><code>D</code></em>, it is adjusted upward. For
              example, <code class="literal">DECIMAL(10,10)</code> becomes
              <code class="literal">DECIMAL(11,10)</code>. As of MySQL 5.0.10,
              <code class="literal">DECIMAL(10,10)</code> is created as specified.
            </p></li></ul></div><p>
          To see whether MySQL used a data type other than the one you
          specified, issue a <code class="literal">DESCRIBE</code> or
          <code class="literal">SHOW CREATE TABLE</code> statement after creating
          or altering the table.
        </p><a id="id2864702" class="indexterm"></a><p>
          Certain other data type changes can occur if you compress a
          table using <span><strong class="command">myisampack</strong></span>. See
          <a href="http://dev.mysql.com/doc/refman/5.0/en/compressed-format.html" target="_top">Compressed Table Characteristics</a>.
        </p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="drop-database"></a><code class="literal">DROP DATABASE</code> Syntax</h3></div></div></div><a id="id2864739" class="indexterm"></a><a id="id2864746" class="indexterm"></a><a id="id2864752" class="indexterm"></a><a id="id2864762" class="indexterm"></a><a id="id2864773" class="indexterm"></a><a id="id2864783" class="indexterm"></a><pre class="programlisting">DROP {DATABASE | SCHEMA} [IF EXISTS] <em class="replaceable"><code>db_name</code></em>
</pre><p>
        <code class="literal">DROP DATABASE</code> drops all tables in the
        database and deletes the database. Be <span class="emphasis"><em>very</em></span>
        careful with this statement! To use <code class="literal">DROP
        DATABASE</code>, you need the <code class="literal">DROP</code>
        privilege on the database. <code class="literal">DROP SCHEMA</code> is a
        synonym for <code class="literal">DROP DATABASE</code> as of MySQL 5.0.2.
      </p><p>
        <span class="bold"><strong>Important</strong></span>: When a database is
        dropped, user privileges on the database are
        <span class="emphasis"><em>not</em></span> automatically dropped. See
        <a href="mysqlqb_statements.html#grant" title="GRANT Syntax"><code class="literal">GRANT</code> Syntax</a>.
      </p><p>
        <code class="literal">IF EXISTS</code> is used to prevent an error from
        occurring if the database does not exist.
      </p><p>
        If you use <code class="literal">DROP DATABASE</code> on a symbolically
        linked database, both the link and the original database are
        deleted.
      </p><p>
        <code class="literal">DROP DATABASE</code> returns the number of tables
        that were removed. This corresponds to the number of
        <code class="filename">.frm</code> files removed.
      </p><p>
        The <code class="literal">DROP DATABASE</code> statement removes from the
        given database directory those files and directories that MySQL
        itself may create during normal operation:
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            All files with these extensions:
          </p><div class="informaltable"><table border="1"><colgroup><col /><col /><col /><col /></colgroup><tbody><tr><td><code class="literal">.BAK</code></td><td><code class="literal">.DAT</code></td><td><code class="literal">.HSH</code></td><td><code class="literal">.MRG</code></td></tr><tr><td><code class="literal">.MYD</code></td><td><code class="literal">.MYI</code></td><td><code class="literal">.TRG</code></td><td><code class="literal">.TRN</code></td></tr><tr><td><code class="literal">.db</code></td><td><code class="literal">.frm</code></td><td><code class="literal">.ibd</code></td><td><code class="literal">.ndb</code></td></tr></tbody></table></div></li><li><p>
            All subdirectories with names that consist of two hex digits
            <code class="literal">00</code>-<code class="literal">ff</code>. These are
            subdirectories used for <code class="literal">RAID</code> tables.
            (These directories are not removed as of MySQL 5.0, when
            support for <code class="literal">RAID</code> tables was removed. You
            should convert any existing <code class="literal">RAID</code> tables
            and remove these directories manually before upgrading to
            MySQL 5.0. See <a href="http://dev.mysql.com/doc/refman/5.0/en/upgrading-from-4-1.html" target="_top">Upgrading from MySQL 4.1 to 5.0</a>.)
          </p></li><li><p>
            The <code class="filename">db.opt</code> file, if it exists.
          </p></li></ul></div><p>
        If other files or directories remain in the database directory
        after MySQL removes those just listed, the database directory
        cannot be removed. In this case, you must remove any remaining
        files or directories manually and issue the <code class="literal">DROP
        DATABASE</code> statement again.
      </p><a id="id2865079" class="indexterm"></a><p>
        You can also drop databases with <span><strong class="command">mysqladmin</strong></span>.
        See <a href="http://dev.mysql.com/doc/refman/5.0/en/mysqladmin.html" target="_top">mysqladmin</a>.
      </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="drop-index"></a><code class="literal">DROP INDEX</code> Syntax</h3></div></div></div><a id="id2865113" class="indexterm"></a><a id="id2865120" class="indexterm"></a><a id="id2865130" class="indexterm"></a><pre class="programlisting">DROP INDEX <em class="replaceable"><code>index_name</code></em> ON <em class="replaceable"><code>tbl_name</code></em>
</pre><p>
        <code class="literal">DROP INDEX</code> drops the index named
        <em class="replaceable"><code>index_name</code></em> from the table
        <em class="replaceable"><code>tbl_name</code></em>. This statement is mapped to
        an <code class="literal">ALTER TABLE</code> statement to drop the index.
        See <a href="mysqlqb_statements.html#alter-table" title="ALTER TABLE Syntax"><code class="literal">ALTER TABLE</code> Syntax</a>.
      </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="drop-table"></a><code class="literal">DROP TABLE</code> Syntax</h3></div></div></div><a id="id2865213" class="indexterm"></a><a id="id2865220" class="indexterm"></a><a id="id2865230" class="indexterm"></a><pre class="programlisting">DROP [TEMPORARY] TABLE [IF EXISTS]
    <em class="replaceable"><code>tbl_name</code></em> [, <em class="replaceable"><code>tbl_name</code></em>] ...
    [RESTRICT | CASCADE]
</pre><p>
        <code class="literal">DROP TABLE</code> removes one or more tables. You
        must have the <code class="literal">DROP</code> privilege for each table.
        All table data and the table definition are
        <span class="emphasis"><em>removed</em></span>, so <span class="emphasis"><em>be careful</em></span>
        with this statement! If any of the tables named in the argument
        list do not exist, MySQL returns an error indicating by name
        which non-existing tables it was unable to drop, but it also
        drops all of the tables in the list that do exist.
      </p><p>
        <span class="bold"><strong>Important</strong></span>: When a table is
        dropped, user privileges on the table are
        <span class="emphasis"><em>not</em></span> automatically dropped. See
        <a href="mysqlqb_statements.html#grant" title="GRANT Syntax"><code class="literal">GRANT</code> Syntax</a>.
      </p><p>
        Use <code class="literal">IF EXISTS</code> to prevent an error from
        occurring for tables that do not exist. A
        <code class="literal">NOTE</code> is generated for each non-existent table
        when using <code class="literal">IF EXISTS</code>. See
        <a href="mysqlqb_statements.html#show-warnings" title="SHOW WARNINGS Syntax"><code class="literal">SHOW WARNINGS</code> Syntax</a>.
      </p><p>
        <code class="literal">RESTRICT</code> and <code class="literal">CASCADE</code> are
        allowed to make porting easier. In MySQL 5.0, they
        do nothing.
      </p><p>
        <span class="bold"><strong>Note</strong></span>: <code class="literal">DROP
        TABLE</code> automatically commits the current active
        transaction, unless you use the <code class="literal">TEMPORARY</code>
        keyword.
      </p><p>
        The <code class="literal">TEMPORARY</code> keyword has the following
        effects:
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            The statement drops only <code class="literal">TEMPORARY</code>
            tables.
          </p></li><li><p>
            The statement does not end an ongoing transaction.
          </p></li><li><p>
            No access rights are checked. (A
            <code class="literal">TEMPORARY</code> table is visible only to the
            client that created it, so no check is necessary.)
          </p></li></ul></div><p>
        Using <code class="literal">TEMPORARY</code> is a good way to ensure that
        you do not accidentally drop a non-<code class="literal">TEMPORARY</code>
        table.
      </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="rename-table"></a><code class="literal">RENAME TABLE</code> Syntax</h3></div></div></div><a id="id2865442" class="indexterm"></a><pre class="programlisting">RENAME TABLE <em class="replaceable"><code>tbl_name</code></em> TO <em class="replaceable"><code>new_tbl_name</code></em>
    [, <em class="replaceable"><code>tbl_name2</code></em> TO <em class="replaceable"><code>new_tbl_name2</code></em>] ...
</pre><p>
        This statement renames one or more tables.
      </p><p>
        The rename operation is done atomically, which means that no
        other thread can access any of the tables while the rename is
        running. For example, if you have an existing table
        <code class="literal">old_table</code>, you can create another table
        <code class="literal">new_table</code> that has the same structure but is
        empty, and then replace the existing table with the empty one as
        follows (assuming that <code class="literal">backup_table</code> does not
        already exist):
      </p><pre class="programlisting">CREATE TABLE new_table (...);
RENAME TABLE old_table TO backup_table, new_table TO old_table;
</pre><p>
        If the statement renames more than one table, renaming
        operations are done from left to right. If you want to swap two
        table names, you can do so like this (assuming that
        <code class="literal">tmp_table</code> does not already exist):
      </p><pre class="programlisting">RENAME TABLE old_table TO tmp_table,
             new_table TO old_table,
             tmp_table TO new_table;
</pre><p>
        As long as two databases are on the same filesystem, you can use
        <code class="literal">RENAME TABLE</code> to move a table from one
        database to another:
      </p><pre class="programlisting">RENAME TABLE <em class="replaceable"><code>current_db.tbl_name</code></em> TO <em class="replaceable"><code>other_db.tbl_name;</code></em>
</pre><p>
        Beginning with MySQL 5.0.2, if there are any triggers associated
        with a table which is moved to a different database using
        <code class="literal">RENAME TABLE</code>, then the statement fails with
        the error <span class="errortext">Trigger in wrong schema</span>.
      </p><p>
        As of MySQL 5.0.14, <code class="literal">RENAME TABLE</code> also works
        for views, as long as you do not try to rename a view into a
        different database.
      </p><p>
        Any privileges granted specifically for the renamed table or
        view are not migrated to the new name. They must be changed
        manually.
      </p><p>
        When you execute <code class="literal">RENAME</code>, you cannot have any
        locked tables or active transactions. You must also have the
        <code class="literal">ALTER</code> and <code class="literal">DROP</code> privileges
        on the original table, and the <code class="literal">CREATE</code> and
        <code class="literal">INSERT</code> privileges on the new table.
      </p><p>
        If MySQL encounters any errors in a multiple-table rename, it
        does a reverse rename for all renamed tables to return
        everything to its original state.
      </p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="data-manipulation"></a>Data Manipulation Statements</h2></div></div></div><div class="toc"><dl><dt><span class="section"><a href="mysqlqb_statements.html#delete"><code class="literal">DELETE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#do"><code class="literal">DO</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#handler"><code class="literal">HANDLER</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#insert"><code class="literal">INSERT</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#load-data"><code class="literal">LOAD DATA INFILE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#replace"><code class="literal">REPLACE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#select"><code class="literal">SELECT</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#subqueries">Subquery Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#truncate"><code class="literal">TRUNCATE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#update"><code class="literal">UPDATE</code> Syntax</a></span></dt></dl></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="delete"></a><code class="literal">DELETE</code> Syntax</h3></div></div></div><a id="id2865649" class="indexterm"></a><p>
        Single-table syntax:
      </p><pre class="programlisting">DELETE [LOW_PRIORITY] [QUICK] [IGNORE] FROM <em class="replaceable"><code>tbl_name</code></em>
    [WHERE <em class="replaceable"><code>where_condition</code></em>]
    [ORDER BY ...]
    [LIMIT <em class="replaceable"><code>row_count</code></em>]
</pre><p>
        Multiple-table syntax:
      </p><pre class="programlisting">DELETE [LOW_PRIORITY] [QUICK] [IGNORE]
    <em class="replaceable"><code>tbl_name</code></em>[.*] [, <em class="replaceable"><code>tbl_name</code></em>[.*]] ...
    FROM <em class="replaceable"><code>table_references</code></em>
    [WHERE <em class="replaceable"><code>where_condition</code></em>]
</pre><p>
        Or:
      </p><pre class="programlisting">DELETE [LOW_PRIORITY] [QUICK] [IGNORE]
    FROM <em class="replaceable"><code>tbl_name</code></em>[.*] [, <em class="replaceable"><code>tbl_name</code></em>[.*]] ...
    USING <em class="replaceable"><code>table_references</code></em>
    [WHERE <em class="replaceable"><code>where_condition</code></em>]
</pre><p>
        For the single-table syntax, the <code class="literal">DELETE</code>
        statement deletes rows from <em class="replaceable"><code>tbl_name</code></em>
        and returns the number of rows deleted. The
        <code class="literal">WHERE</code> clause, if given, specifies the
        conditions that identify which rows to delete. With no
        <code class="literal">WHERE</code> clause, all rows are deleted. If the
        <code class="literal">ORDER BY</code> clause is specified, the rows are
        deleted in the order that is specified. The
        <code class="literal">LIMIT</code> clause places a limit on the number of
        rows that can be deleted.
      </p><p>
        For the multiple-table syntax, <code class="literal">DELETE</code> deletes
        from each <em class="replaceable"><code>tbl_name</code></em> the rows that
        satisfy the conditions. In this case, <code class="literal">ORDER
        BY</code> and <code class="literal">LIMIT</code> cannot be used.
      </p><p>
        <em class="replaceable"><code>where_condition</code></em> is an expression that
        evaluates to true for each row to be deleted. It is specified as
        described in <a href="mysqlqb_statements.html#select" title="SELECT Syntax"><code class="literal">SELECT</code> Syntax</a>.
      </p><p>
        As stated, a <code class="literal">DELETE</code> statement with no
        <code class="literal">WHERE</code> clause deletes all rows. A faster way
        to do this, when you do not want to know the number of deleted
        rows, is to use <code class="literal">TRUNCATE TABLE</code>. See
        <a href="mysqlqb_statements.html#truncate" title="TRUNCATE Syntax"><code class="literal">TRUNCATE</code> Syntax</a>.
      </p><p>
        If you delete the row containing the maximum value for an
        <code class="literal">AUTO_INCREMENT</code> column, the value is reused
        later for a <code class="literal">BDB</code> table, but not for a
        <code class="literal">MyISAM</code> or <code class="literal">InnoDB</code> table. If
        you delete all rows in the table with <code class="literal">DELETE FROM
        <em class="replaceable"><code>tbl_name</code></em></code> (without a
        <code class="literal">WHERE</code> clause) in
        <code class="literal">AUTOCOMMIT</code> mode, the sequence starts over for
        all storage engines except <code class="literal">InnoDB</code> and
        <code class="literal">MyISAM</code>. There are some exceptions to this
        behavior for <code class="literal">InnoDB</code> tables, as discussed in
        <a href="http://dev.mysql.com/doc/refman/5.0/en/innodb-auto-increment-column.html" target="_top">How <code class="literal">AUTO_INCREMENT</code> Columns Work in  <code class="literal">InnoDB</code></a>.
      </p><p>
        For <code class="literal">MyISAM</code> and <code class="literal">BDB</code> tables,
        you can specify an <code class="literal">AUTO_INCREMENT</code> secondary
        column in a multiple-column key. In this case, reuse of values
        deleted from the top of the sequence occurs even for
        <code class="literal">MyISAM</code> tables. See
        <a href="http://dev.mysql.com/doc/refman/5.0/en/example-auto-increment.html" target="_top">Using <code class="literal">AUTO_INCREMENT</code></a>.
      </p><p>
        The <code class="literal">DELETE</code> statement supports the following
        modifiers:
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            If you specify <code class="literal">LOW_PRIORITY</code>, the server
            delays execution of the <code class="literal">DELETE</code> until no
            other clients are reading from the table.
          </p></li><li><p>
            For <code class="literal">MyISAM</code> tables, if you use the
            <code class="literal">QUICK</code> keyword, the storage engine does
            not merge index leaves during delete, which may speed up
            some kinds of delete operations.
          </p></li><li><p>
            The <code class="literal">IGNORE</code> keyword causes MySQL to ignore
            all errors during the process of deleting rows. (Errors
            encountered during the parsing stage are processed in the
            usual manner.) Errors that are ignored due to the use of
            <code class="literal">IGNORE</code> are returned as warnings.
          </p></li></ul></div><p>
        The speed of delete operations may also be affected by factors
        discussed in <a href="http://dev.mysql.com/doc/refman/5.0/en/delete-speed.html" target="_top">Speed of <code class="literal">DELETE</code> Statements</a>.
      </p><p>
        In <code class="literal">MyISAM</code> tables, deleted rows are maintained
        in a linked list and subsequent <code class="literal">INSERT</code>
        operations reuse old row positions. To reclaim unused space and
        reduce file sizes, use the <code class="literal">OPTIMIZE TABLE</code>
        statement or the <span><strong class="command">myisamchk</strong></span> utility to
        reorganize tables. <code class="literal">OPTIMIZE TABLE</code> is easier,
        but <span><strong class="command">myisamchk</strong></span> is faster. See
        <a href="mysqlqb_statements.html#optimize-table" title="OPTIMIZE TABLE Syntax"><code class="literal">OPTIMIZE TABLE</code> Syntax</a>, and
        <a href="http://dev.mysql.com/doc/refman/5.0/en/myisamchk.html" target="_top">myisamchk</a>.
      </p><p>
        The <code class="literal">QUICK</code> modifier affects whether index
        leaves are merged for delete operations. <code class="literal">DELETE
        QUICK</code> is most useful for applications where index
        values for deleted rows are replaced by similar index values
        from rows inserted later. In this case, the holes left by
        deleted values are reused.
      </p><p>
        <code class="literal">DELETE QUICK</code> is not useful when deleted
        values lead to underfilled index blocks spanning a range of
        index values for which new inserts occur again. In this case,
        use of <code class="literal">QUICK</code> can lead to wasted space in the
        index that remains unreclaimed. Here is an example of such a
        scenario:
      </p><div class="orderedlist"><ol type="1"><li><p>
            Create a table that contains an indexed
            <code class="literal">AUTO_INCREMENT</code> column.
          </p></li><li><p>
            Insert many rows into the table. Each insert results in an
            index value that is added to the high end of the index.
          </p></li><li><p>
            Delete a block of rows at the low end of the column range
            using <code class="literal">DELETE QUICK</code>.
          </p></li></ol></div><p>
        In this scenario, the index blocks associated with the deleted
        index values become underfilled but are not merged with other
        index blocks due to the use of <code class="literal">QUICK</code>. They
        remain underfilled when new inserts occur, because new rows do
        not have index values in the deleted range. Furthermore, they
        remain underfilled even if you later use
        <code class="literal">DELETE</code> without <code class="literal">QUICK</code>,
        unless some of the deleted index values happen to lie in index
        blocks within or adjacent to the underfilled blocks. To reclaim
        unused index space under these circumstances, use
        <code class="literal">OPTIMIZE TABLE</code>.
      </p><p>
        If you are going to delete many rows from a table, it might be
        faster to use <code class="literal">DELETE QUICK</code> followed by
        <code class="literal">OPTIMIZE TABLE</code>. This rebuilds the index
        rather than performing many index block merge operations.
      </p><p>
        The MySQL-specific <code class="literal">LIMIT
        <em class="replaceable"><code>row_count</code></em></code> option to
        <code class="literal">DELETE</code> tells the server the maximum number of
        rows to be deleted before control is returned to the client.
        This can be used to ensure that a given
        <code class="literal">DELETE</code> statement does not take too much time.
        You can simply repeat the <code class="literal">DELETE</code> statement
        until the number of affected rows is less than the
        <code class="literal">LIMIT</code> value.
      </p><p>
        If the <code class="literal">DELETE</code> statement includes an
        <code class="literal">ORDER BY</code> clause, the rows are deleted in the
        order specified by the clause. This is really useful only in
        conjunction with <code class="literal">LIMIT</code>. For example, the
        following statement finds rows matching the
        <code class="literal">WHERE</code> clause, sorts them by
        <code class="literal">timestamp_column</code>, and deletes the first
        (oldest) one:
      </p><pre class="programlisting">DELETE FROM somelog WHERE user = 'jcole'
ORDER BY timestamp_column LIMIT 1;
</pre><p>
        You can specify multiple tables in a <code class="literal">DELETE</code>
        statement to delete rows from one or more tables depending on
        the particular condition in the <code class="literal">WHERE</code> clause.
        However, you cannot use <code class="literal">ORDER BY</code> or
        <code class="literal">LIMIT</code> in a multiple-table
        <code class="literal">DELETE</code>. The
        <em class="replaceable"><code>table_references</code></em> clause lists the
        tables involved in the join. Its syntax is described in
        <a href="mysqlqb_statements.html#join" title="JOIN Syntax"><code class="literal">JOIN</code> Syntax</a>.
      </p><p>
        For the first multiple-table syntax, only matching rows from the
        tables listed before the <code class="literal">FROM</code> clause are
        deleted. For the second multiple-table syntax, only matching
        rows from the tables listed in the <code class="literal">FROM</code>
        clause (before the <code class="literal">USING</code> clause) are deleted.
        The effect is that you can delete rows from many tables at the
        same time and have additional tables that are used only for
        searching:
      </p><pre class="programlisting">DELETE t1, t2 FROM t1, t2, t3 WHERE t1.id=t2.id AND t2.id=t3.id;
</pre><p>
        Or:
      </p><pre class="programlisting">DELETE FROM t1, t2 USING t1, t2, t3 WHERE t1.id=t2.id AND t2.id=t3.id;
</pre><p>
        These statements use all three tables when searching for rows to
        delete, but delete matching rows only from tables
        <code class="literal">t1</code> and <code class="literal">t2</code>.
      </p><p>
        The preceding examples show inner joins that use the comma
        operator, but multiple-table <code class="literal">DELETE</code>
        statements can use any type of join allowed in
        <code class="literal">SELECT</code> statements, such as <code class="literal">LEFT
        JOIN</code>.
      </p><p>
        The syntax allows <code class="literal">.*</code> after the table names
        for compatibility with <span><strong class="command">Access</strong></span>.
      </p><p>
        If you use a multiple-table <code class="literal">DELETE</code> statement
        involving <code class="literal">InnoDB</code> tables for which there are
        foreign key constraints, the MySQL optimizer might process
        tables in an order that differs from that of their parent/child
        relationship. In this case, the statement fails and rolls back.
        Instead, you should delete from a single table and rely on the
        <code class="literal">ON DELETE</code> capabilities that
        <code class="literal">InnoDB</code> provides to cause the other tables to
        be modified accordingly.
      </p><p>
        <span class="bold"><strong>Note</strong></span>: If you provide an alias
        for a table, you must use the alias when referring to the table:
      </p><pre class="programlisting">DELETE t1 FROM test AS t1, test2 WHERE ...
</pre><p>
        Cross-database deletes are supported for multiple-table deletes,
        but in this case, you must refer to the tables without using
        aliases. For example:
      </p><pre class="programlisting">DELETE test1.tmp1, test2.tmp2 FROM test1.tmp1, test2.tmp2 WHERE ...
</pre><p>
        Currently, you cannot delete from a table and select from the
        same table in a subquery.
      </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="do"></a><code class="literal">DO</code> Syntax</h3></div></div></div><a id="id2866410" class="indexterm"></a><pre class="programlisting">DO <em class="replaceable"><code>expr</code></em> [, <em class="replaceable"><code>expr</code></em>] ...
</pre><p>
        <code class="literal">DO</code> executes the expressions but does not
        return any results. In most respects, <code class="literal">DO</code> is
        shorthand for <code class="literal">SELECT <em class="replaceable"><code>expr</code></em>,
        ...</code>, but has the advantage that it is slightly faster
        when you do not care about the result.
      </p><p>
        <code class="literal">DO</code> is useful primarily with functions that
        have side effects, such as <code class="literal">RELEASE_LOCK()</code>.
      </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="handler"></a><code class="literal">HANDLER</code> Syntax</h3></div></div></div><a id="id2866491" class="indexterm"></a><pre class="programlisting">HANDLER <em class="replaceable"><code>tbl_name</code></em> OPEN [ AS <em class="replaceable"><code>alias</code></em> ]
HANDLER <em class="replaceable"><code>tbl_name</code></em> READ <em class="replaceable"><code>index_name</code></em> { = | &gt;= | &lt;= | &lt; } (<em class="replaceable"><code>value1</code></em>,<em class="replaceable"><code>value2</code></em>,...)
    [ WHERE <em class="replaceable"><code>where_condition</code></em> ] [LIMIT ... ]
HANDLER <em class="replaceable"><code>tbl_name</code></em> READ <em class="replaceable"><code>index_name</code></em> { FIRST | NEXT | PREV | LAST }
    [ WHERE <em class="replaceable"><code>where_condition</code></em> ] [LIMIT ... ]
HANDLER <em class="replaceable"><code>tbl_name</code></em> READ { FIRST | NEXT }
    [ WHERE <em class="replaceable"><code>where_condition</code></em> ] [LIMIT ... ]
HANDLER <em class="replaceable"><code>tbl_name</code></em> CLOSE
</pre><p>
        The <code class="literal">HANDLER</code> statement provides direct access
        to table storage engine interfaces. It is available for
        <code class="literal">MyISAM</code> and <code class="literal">InnoDB</code> tables.
      </p><p>
        The <code class="literal">HANDLER ... OPEN</code> statement opens a table,
        making it accessible via subsequent <code class="literal">HANDLER ...
        READ</code> statements. This table object is not shared by
        other threads and is not closed until the thread calls
        <code class="literal">HANDLER ... CLOSE</code> or the thread terminates.
        If you open the table using an alias, further references to the
        open table with other <code class="literal">HANDLER</code> statements must
        use the alias rather than the table name.
      </p><p>
        The first <code class="literal">HANDLER ... READ</code> syntax fetches a
        row where the index specified satisfies the given values and the
        <code class="literal">WHERE</code> condition is met. If you have a
        multiple-column index, specify the index column values as a
        comma-separated list. Either specify values for all the columns
        in the index, or specify values for a leftmost prefix of the
        index columns. Suppose that an index <code class="literal">my_idx</code>
        includes three columns named <code class="literal">col_a</code>,
        <code class="literal">col_b</code>, and <code class="literal">col_c</code>, in that
        order. The <code class="literal">HANDLER</code> statement can specify
        values for all three columns in the index, or for the columns in
        a leftmost prefix. For example:
      </p><pre class="programlisting">HANDLER ... READ my_idx = (col_a_val,col_b_val,col_c_val) ...
HANDLER ... READ my_idx = (col_a_val,col_b_val) ...
HANDLER ... READ my_idx = (col_a_val) ...
</pre><p>
        To employ the <code class="literal">HANDLER</code> interface to refer to a
        table's <code class="literal">PRIMARY KEY</code>, use the quoted
        identifier <code class="literal">`PRIMARY`</code>:
      </p><pre class="programlisting">HANDLER <em class="replaceable"><code>tbl_name</code></em> READ `PRIMARY` ...
</pre><p>
        The second <code class="literal">HANDLER ... READ</code> syntax fetches a
        row from the table in index order that matches the
        <code class="literal">WHERE</code> condition.
      </p><p>
        The third <code class="literal">HANDLER ... READ</code> syntax fetches a
        row from the table in natural row order that matches the
        <code class="literal">WHERE</code> condition. It is faster than
        <code class="literal">HANDLER <em class="replaceable"><code>tbl_name</code></em> READ
        <em class="replaceable"><code>index_name</code></em></code> when a full
        table scan is desired. Natural row order is the order in which
        rows are stored in a <code class="literal">MyISAM</code> table data file.
        This statement works for <code class="literal">InnoDB</code> tables as
        well, but there is no such concept because there is no separate
        data file.
      </p><p>
        Without a <code class="literal">LIMIT</code> clause, all forms of
        <code class="literal">HANDLER ... READ</code> fetch a single row if one is
        available. To return a specific number of rows, include a
        <code class="literal">LIMIT</code> clause. It has the same syntax as for
        the <code class="literal">SELECT</code> statement. See
        <a href="mysqlqb_statements.html#select" title="SELECT Syntax"><code class="literal">SELECT</code> Syntax</a>.
      </p><p>
        <code class="literal">HANDLER ... CLOSE</code> closes a table that was
        opened with <code class="literal">HANDLER ... OPEN</code>.
      </p><p>
        <code class="literal">HANDLER</code> is a somewhat low-level statement.
        For example, it does not provide consistency. That is,
        <code class="literal">HANDLER ... OPEN</code> does
        <span class="emphasis"><em>not</em></span> take a snapshot of the table, and does
        <span class="emphasis"><em>not</em></span> lock the table. This means that after a
        <code class="literal">HANDLER ... OPEN</code> statement is issued, table
        data can be modified (by the current thread or other threads)
        and these modifications might be only partially visible to
        <code class="literal">HANDLER ... NEXT</code> or <code class="literal">HANDLER ...
        PREV</code> scans.
      </p><p>
        There are several reasons to use the <code class="literal">HANDLER</code>
        interface instead of normal <code class="literal">SELECT</code>
        statements:
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            <code class="literal">HANDLER</code> is faster than
            <code class="literal">SELECT</code>:
          </p><div class="itemizedlist"><ul type="circle"><li><p>
                A designated storage engine handler object is allocated
                for the <code class="literal">HANDLER ... OPEN</code>. The object
                is reused for subsequent <code class="literal">HANDLER</code>
                statements for that table; it need not be reinitialized
                for each one.
              </p></li><li><p>
                There is less parsing involved.
              </p></li><li><p>
                There is no optimizer or query-checking overhead.
              </p></li><li><p>
                The table does not have to be locked between two handler
                requests.
              </p></li><li><p>
                The handler interface does not have to provide a
                consistent look of the data (for example, dirty reads
                are allowed), so the storage engine can use
                optimizations that <code class="literal">SELECT</code> does not
                normally allow.
              </p></li></ul></div></li><li><p>
            For applications that use a low-level
            <code class="literal">ISAM</code>-like interface,
            <code class="literal">HANDLER</code> makes it much easier to port them
            to MySQL.
          </p></li><li><p>
            <code class="literal">HANDLER</code> enables you to traverse a
            database in a manner that is difficult (or even impossible)
            to accomplish with <code class="literal">SELECT</code>. The
            <code class="literal">HANDLER</code> interface is a more natural way
            to look at data when working with applications that provide
            an interactive user interface to the database.
          </p></li></ul></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="insert"></a><code class="literal">INSERT</code> Syntax</h3></div></div></div><div class="toc"><dl><dt><span class="section"><a href="mysqlqb_statements.html#insert-select"><code class="literal">INSERT ... SELECT</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#insert-delayed"><code class="literal">INSERT DELAYED</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#insert-on-duplicate"><code class="literal">INSERT ... ON DUPLICATE KEY UPDATE</code> Syntax</a></span></dt></dl></div><a id="id2866952" class="indexterm"></a><a id="id2866958" class="indexterm"></a><pre class="programlisting">INSERT [LOW_PRIORITY | DELAYED | HIGH_PRIORITY] [IGNORE]
    [INTO] <em class="replaceable"><code>tbl_name</code></em> [(<em class="replaceable"><code>col_name</code></em>,...)]
    VALUES ({<em class="replaceable"><code>expr</code></em> | DEFAULT},...),(...),...
    [ ON DUPLICATE KEY UPDATE <em class="replaceable"><code>col_name</code></em>=<em class="replaceable"><code>expr</code></em>, ... ]
</pre><p>
        Or:
      </p><pre class="programlisting">INSERT [LOW_PRIORITY | DELAYED | HIGH_PRIORITY] [IGNORE]
    [INTO] <em class="replaceable"><code>tbl_name</code></em>
    SET <em class="replaceable"><code>col_name</code></em>={<em class="replaceable"><code>expr</code></em> | DEFAULT}, ...
    [ ON DUPLICATE KEY UPDATE <em class="replaceable"><code>col_name</code></em>=<em class="replaceable"><code>expr</code></em>, ... ]
</pre><p>
        Or:
      </p><pre class="programlisting">INSERT [LOW_PRIORITY | HIGH_PRIORITY] [IGNORE]
    [INTO] <em class="replaceable"><code>tbl_name</code></em> [(<em class="replaceable"><code>col_name</code></em>,...)]
    SELECT ...
    [ ON DUPLICATE KEY UPDATE <em class="replaceable"><code>col_name</code></em>=<em class="replaceable"><code>expr</code></em>, ... ]
</pre><p>
        <code class="literal">INSERT</code> inserts new rows into an existing
        table. The <code class="literal">INSERT ... VALUES</code> and
        <code class="literal">INSERT ... SET</code> forms of the statement insert
        rows based on explicitly specified values. The <code class="literal">INSERT
        ... SELECT</code> form inserts rows selected from another
        table or tables. <code class="literal">INSERT ... SELECT</code> is
        discussed further in <a href="mysqlqb_statements.html#insert-select" title="INSERT ... SELECT Syntax"><code class="literal">INSERT ... SELECT</code> Syntax</a>.
      </p><p>
        You can use <code class="literal">REPLACE</code> instead of
        <code class="literal">INSERT</code> to overwrite old rows.
        <code class="literal">REPLACE</code> is the counterpart to <code class="literal">INSERT
        IGNORE</code> in the treatment of new rows that contain
        unique key values that duplicate old rows: The new rows are used
        to replace the old rows rather than being discarded. See
        <a href="mysqlqb_statements.html#replace" title="REPLACE Syntax"><code class="literal">REPLACE</code> Syntax</a>.
      </p><p>
        <em class="replaceable"><code>tbl_name</code></em> is the table into which rows
        should be inserted. The columns for which the statement provides
        values can be specified as follows:
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            You can provide a comma-separated list of column names
            following the table name. In this case, a value for each
            named column must be provided by the
            <code class="literal">VALUES</code> list or the
            <code class="literal">SELECT</code> statement.
          </p></li><li><p>
            If you do not specify a list of column names for
            <code class="literal">INSERT ... VALUES</code> or <code class="literal">INSERT ...
            SELECT</code>, values for every column in the table must
            be provided by the <code class="literal">VALUES</code> list or the
            <code class="literal">SELECT</code> statement. If you do not know the
            order of the columns in the table, use <code class="literal">DESCRIBE
            <em class="replaceable"><code>tbl_name</code></em></code> to find out.
          </p></li><li><p>
            The <code class="literal">SET</code> clause indicates the column names
            explicitly.
          </p></li></ul></div><p>
        Column values can be given in several ways:
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            <a id="id2867215" class="indexterm"></a>

            If you are not running in strict SQL mode, any column not
            explicitly given a value is set to its default (explicit or
            implicit) value. For example, if you specify a column list
            that does not name all the columns in the table, unnamed
            columns are set to their default values. Default value
            assignment is described in
            <a href="http://dev.mysql.com/doc/refman/5.0/en/data-type-defaults.html" target="_top">Data Type Default Values</a>. See also
            <a href="http://dev.mysql.com/doc/refman/5.0/en/constraint-invalid-data.html" target="_top">Constraints on Invalid Data</a>.
          </p><p>
            If you want an <code class="literal">INSERT</code> statement to
            generate an error unless you explicitly specify values for
            all columns that do not have a default value, you should use
            strict mode. See <a href="http://dev.mysql.com/doc/refman/5.0/en/server-sql-mode.html" target="_top">SQL Modes</a>.
          </p></li><li><p>
            Use the keyword <code class="literal">DEFAULT</code> to set a column
            explicitly to its default value. This makes it easier to
            write <code class="literal">INSERT</code> statements that assign
            values to all but a few columns, because it enables you to
            avoid writing an incomplete <code class="literal">VALUES</code> list
            that does not include a value for each column in the table.
            Otherwise, you would have to write out the list of column
            names corresponding to each value in the
            <code class="literal">VALUES</code> list.
          </p><p>
            You can also use
            <code class="literal">DEFAULT(<em class="replaceable"><code>col_name</code></em>)</code>
            as a more general form that can be used in expressions to
            produce a given column's default value.
          </p></li><li><p>
            If both the column list and the <code class="literal">VALUES</code>
            list are empty, <code class="literal">INSERT</code> creates a row with
            each column set to its default value:
          </p><pre class="programlisting">INSERT INTO <em class="replaceable"><code>tbl_name</code></em> () VALUES();
</pre><p>
            In strict mode, an error occurs if any column doesn't have a
            default value. Otherwise, MySQL uses the implicit default
            value for any column that does not have an explicitly
            defined default.
          </p></li><li><p>
            You can specify an expression
            <em class="replaceable"><code>expr</code></em> to provide a column value.
            This might involve type conversion if the type of the
            expression does not match the type of the column, and
            conversion of a given value can result in different inserted
            values depending on the data type. For example, inserting
            the string <code class="literal">'1999.0e-2'</code> into an
            <code class="literal">INT</code>, <code class="literal">FLOAT</code>,
            <code class="literal">DECIMAL(10,6)</code>, or <code class="literal">YEAR</code>
            column results in the values <code class="literal">1999</code>,
            <code class="literal">19.9921</code>, <code class="literal">19.992100</code>,
            and <code class="literal">1999</code> being inserted, respectively.
            The reason the value stored in the <code class="literal">INT</code>
            and <code class="literal">YEAR</code> columns is
            <code class="literal">1999</code> is that the string-to-integer
            conversion looks only at as much of the initial part of the
            string as may be considered a valid integer or year. For the
            floating-point and fixed-point columns, the
            string-to-floating-point conversion considers the entire
            string a valid floating-point value.
          </p><p>
            An expression <em class="replaceable"><code>expr</code></em> can refer to
            any column that was set earlier in a value list. For
            example, you can do this because the value for
            <code class="literal">col2</code> refers to <code class="literal">col1</code>,
            which has previously been assigned:
          </p><pre class="programlisting">INSERT INTO <em class="replaceable"><code>tbl_name</code></em> (col1,col2) VALUES(15,col1*2);
</pre><p>
            But the following is not legal, because the value for
            <code class="literal">col1</code> refers to <code class="literal">col2</code>,
            which is assigned after <code class="literal">col1</code>:
          </p><pre class="programlisting">INSERT INTO <em class="replaceable"><code>tbl_name</code></em> (col1,col2) VALUES(col2*2,15);
</pre><p>
            One exception involves columns that contain
            <code class="literal">AUTO_INCREMENT</code> values. Because the
            <code class="literal">AUTO_INCREMENT</code> value is generated after
            other value assignments, any reference to an
            <code class="literal">AUTO_INCREMENT</code> column in the assignment
            returns a <code class="literal">0</code>.
          </p></li></ul></div><p>
        <code class="literal">INSERT</code> statements that use
        <code class="literal">VALUES</code> syntax can insert multiple rows. To do
        this, include multiple lists of column values, each enclosed
        within parentheses and separated by commas. Example:
      </p><pre class="programlisting">INSERT INTO <em class="replaceable"><code>tbl_name</code></em> (a,b,c) VALUES(1,2,3),(4,5,6),(7,8,9);
</pre><p>
        The values list for each row must be enclosed within
        parentheses. The following statement is illegal because the
        number of values in the list does not match the number of column
        names:
      </p><pre class="programlisting">INSERT INTO <em class="replaceable"><code>tbl_name</code></em> (a,b,c) VALUES(1,2,3,4,5,6,7,8,9);
</pre><p>
        The rows-affected value for an <code class="literal">INSERT</code> can be
        obtained using the <code class="literal">mysql_affected_rows()</code> C
        API function. See <a href="http://dev.mysql.com/doc/refman/5.0/en/mysql-affected-rows.html" target="_top"><code class="literal">mysql_affected_rows()</code></a>.
      </p><p>
        If you use an <code class="literal">INSERT ... VALUES</code> statement
        with multiple value lists or <code class="literal">INSERT ...
        SELECT</code>, the statement returns an information string in
        this format:
      </p><pre class="programlisting">Records: 100 Duplicates: 0 Warnings: 0
</pre><p>
        <code class="literal">Records</code> indicates the number of rows
        processed by the statement. (This is not necessarily the number
        of rows actually inserted because <code class="literal">Duplicates</code>
        can be non-zero.) <code class="literal">Duplicates</code> indicates the
        number of rows that could not be inserted because they would
        duplicate some existing unique index value.
        <code class="literal">Warnings</code> indicates the number of attempts to
        insert column values that were problematic in some way. Warnings
        can occur under any of the following conditions:
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            Inserting <code class="literal">NULL</code> into a column that has
            been declared <code class="literal">NOT NULL</code>. For multiple-row
            <code class="literal">INSERT</code> statements or <code class="literal">INSERT INTO
            ... SELECT</code> statements, the column is set to the
            implicit default value for the column data type. This is
            <code class="literal">0</code> for numeric types, the empty string
            (<code class="literal">''</code>) for string types, and the
            “<span class="quote">zero</span>” value for date and time types.
            <code class="literal">INSERT INTO ... SELECT</code> statements are
            handled the same way as multiple-row inserts because the
            server does not examine the result set from the
            <code class="literal">SELECT</code> to see whether it returns a single
            row. (For a single-row <code class="literal">INSERT</code>, no warning
            occurs when <code class="literal">NULL</code> is inserted into a
            <code class="literal">NOT NULL</code> column. Instead, the statement
            fails with an error.)
          </p></li><li><p>
            Setting a numeric column to a value that lies outside the
            column's range. The value is clipped to the closest endpoint
            of the range.
          </p></li><li><p>
            Assigning a value such as <code class="literal">'10.34 a'</code> to a
            numeric column. The trailing non-numeric text is stripped
            off and the remaining numeric part is inserted. If the
            string value has no leading numeric part, the column is set
            to <code class="literal">0</code>.
          </p></li><li><p>
            Inserting a string into a string column
            (<code class="literal">CHAR</code>, <code class="literal">VARCHAR</code>,
            <code class="literal">TEXT</code>, or <code class="literal">BLOB</code>) that
            exceeds the column's maximum length. The value is truncated
            to the column's maximum length.
          </p></li><li><p>
            Inserting a value into a date or time column that is illegal
            for the data type. The column is set to the appropriate zero
            value for the type.
          </p></li></ul></div><a id="id2867715" class="indexterm"></a><p>
        If you are using the C API, the information string can be
        obtained by invoking the <code class="literal">mysql_info()</code>
        function. See <a href="http://dev.mysql.com/doc/refman/5.0/en/mysql-info.html" target="_top"><code class="literal">mysql_info()</code></a>.
      </p><p>
        If <code class="literal">INSERT</code> inserts a row into a table that has
        an <code class="literal">AUTO_INCREMENT</code> column, you can find the
        value used for that column by using the SQL
        <code class="literal">LAST_INSERT_ID()</code> function. From within the C
        API, use the <code class="literal">mysql_insert_id()</code> function.
        However, you should note that the two functions do not always
        behave identically. The behavior of <code class="literal">INSERT</code>
        statements with respect to <code class="literal">AUTO_INCREMENT</code>
        columns is discussed further in
        <a href="mysqlqb_functions.html#information-functions" title="Information Functions">Information Functions</a>, and
        <a href="http://dev.mysql.com/doc/refman/5.0/en/mysql-insert-id.html" target="_top"><code class="literal">mysql_insert_id()</code></a>.
      </p><p>
        The <code class="literal">INSERT</code> statement supports the following
        modifiers:
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            If you use the <code class="literal">DELAYED</code> keyword, the
            server puts the row or rows to be inserted into a buffer,
            and the client issuing the <code class="literal">INSERT DELAYED</code>
            statement can then continue immediately. If the table is in
            use, the server holds the rows. When the table is free, the
            server begins inserting rows, checking periodically to see
            whether there are any new read requests for the table. If
            there are, the delayed row queue is suspended until the
            table becomes free again. See
            <a href="mysqlqb_statements.html#insert-delayed" title="INSERT DELAYED Syntax"><code class="literal">INSERT DELAYED</code> Syntax</a>.
          </p><p>
            <code class="literal">DELAYED</code> is ignored with <code class="literal">INSERT
            ... SELECT</code> or <code class="literal">INSERT ... ON DUPLICATE KEY
            UPDATE</code>.
          </p></li><li><p>
            If you use the <code class="literal">LOW_PRIORITY</code> keyword,
            execution of the <code class="literal">INSERT</code> is delayed until
            no other clients are reading from the table. This includes
            other clients that began reading while existing clients are
            reading, and while the <code class="literal">INSERT
            LOW_PRIORITY</code> statement is waiting. It is possible,
            therefore, for a client that issues an <code class="literal">INSERT
            LOW_PRIORITY</code> statement to wait for a very long
            time (or even forever) in a read-heavy environment. (This is
            in contrast to <code class="literal">INSERT DELAYED</code>, which lets
            the client continue at once. Note that
            <code class="literal">LOW_PRIORITY</code> should normally not be used
            with <code class="literal">MyISAM</code> tables because doing so
            disables concurrent inserts. See
            <a href="http://dev.mysql.com/doc/refman/5.0/en/concurrent-inserts.html" target="_top">Concurrent Inserts</a>.
          </p></li><li><p>
            If you specify <code class="literal">HIGH_PRIORITY</code>, it
            overrides the effect of the
            <code class="option">--low-priority-updates</code> option if the server
            was started with that option. It also causes concurrent
            inserts not to be used. See
            <a href="http://dev.mysql.com/doc/refman/5.0/en/concurrent-inserts.html" target="_top">Concurrent Inserts</a>.
          </p></li><li><p>
            If you use the <code class="literal">IGNORE</code> keyword, errors
            that occur while executing the <code class="literal">INSERT</code>
            statement are treated as warnings instead. For example,
            without <code class="literal">IGNORE</code>, a row that duplicates an
            existing <code class="literal">UNIQUE</code> index or <code class="literal">PRIMARY
            KEY</code> value in the table causes a duplicate-key
            error and the statement is aborted. With
            <code class="literal">IGNORE</code>, the row still is not inserted,
            but no error is issued. Data conversions that would trigger
            errors abort the statement if <code class="literal">IGNORE</code> is
            not specified. With <code class="literal">IGNORE</code>, invalid
            values are adjusted to the closest values and inserted;
            warnings are produced but the statement does not abort. You
            can determine with the <code class="literal">mysql_info()</code> C API
            function how many rows were actually inserted into the
            table.
          </p></li><li><p>
            If you specify <code class="literal">ON DUPLICATE KEY UPDATE</code>,
            and a row is inserted that would cause a duplicate value in
            a <code class="literal">UNIQUE</code> index or <code class="literal">PRIMARY
            KEY</code>, an <code class="literal">UPDATE</code> of the old row
            is performed. See <a href="mysqlqb_statements.html#insert-on-duplicate" title="INSERT ... ON DUPLICATE KEY UPDATE Syntax"><code class="literal">INSERT ... ON DUPLICATE KEY UPDATE</code> Syntax</a>.
          </p></li></ul></div><a id="id2867999" class="indexterm"></a><a id="id2868006" class="indexterm"></a><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="insert-select"></a><code class="literal">INSERT ... SELECT</code> Syntax</h4></div></div></div><a id="id2868023" class="indexterm"></a><pre class="programlisting">INSERT [LOW_PRIORITY | HIGH_PRIORITY] [IGNORE]
    [INTO] <em class="replaceable"><code>tbl_name</code></em> [(<em class="replaceable"><code>col_name</code></em>,...)]
    SELECT ...
    [ ON DUPLICATE KEY UPDATE <em class="replaceable"><code>col_name</code></em>=<em class="replaceable"><code>expr</code></em>, ... ]
</pre><p>
          With <code class="literal">INSERT ... SELECT</code>, you can quickly
          insert many rows into a table from one or many tables. For
          example:
        </p><pre class="programlisting">INSERT INTO tbl_temp2 (fld_id)
  SELECT tbl_temp1.fld_order_id
  FROM tbl_temp1 WHERE tbl_temp1.fld_order_id &gt; 100;
</pre><p>
          The following conditions hold for a <code class="literal">INSERT ...
          SELECT</code> statements:
        </p><div class="itemizedlist"><ul type="disc"><li><p>
              Specify <code class="literal">IGNORE</code> to ignore rows that
              would cause duplicate-key violations.
            </p></li><li><p>
              <code class="literal">DELAYED</code> is ignored with <code class="literal">INSERT
              ... SELECT</code>.
            </p></li><li><p>
              The target table of the <code class="literal">INSERT</code>
              statement may appear in the <code class="literal">FROM</code> clause
              of the <code class="literal">SELECT</code> part of the query. (This
              was not possible in some older versions of MySQL.) In this
              case, MySQL creates a temporary table to hold the rows
              from the <code class="literal">SELECT</code> and then inserts those
              rows into the target table.
            </p></li><li><p>
              <code class="literal">AUTO_INCREMENT</code> columns work as usual.
            </p></li><li><p>
              To ensure that the binary log can be used to re-create the
              original tables, MySQL does not allow concurrent inserts
              for <code class="literal">INSERT ... SELECT</code> statements.
            </p></li><li><p>
              Currently, you cannot insert into a table and select from
              the same table in a subquery.
            </p></li><li><p>
              To avoid ambigious column reference problems when the
              <code class="literal">SELECT</code> and the
              <code class="literal">INSERT</code> refer to the same table, provide
              a unique alias for each table used in the
              <code class="literal">SELECT</code> part, and qualify column names
              in that part with the appropriate alias.
            </p></li></ul></div><p>
          In the values part of <code class="literal">ON DUPLICATE KEY
          UPDATE</code>, you can refer to columns in other tables, as
          long as you do not use <code class="literal">GROUP BY</code> in the
          <code class="literal">SELECT</code> part. One side effect is that you
          must qualify non-unique column names in the values part.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="insert-delayed"></a><code class="literal">INSERT DELAYED</code> Syntax</h4></div></div></div><a id="id2868237" class="indexterm"></a><a id="id2868244" class="indexterm"></a><a id="id2868250" class="indexterm"></a><pre class="programlisting">INSERT DELAYED ...
</pre><p>
          The <code class="literal">DELAYED</code> option for the
          <code class="literal">INSERT</code> statement is a MySQL extension to
          standard SQL that is very useful if you have clients that
          cannot or need not wait for the <code class="literal">INSERT</code> to
          complete. This is a common situation when you use MySQL for
          logging and you also periodically run
          <code class="literal">SELECT</code> and <code class="literal">UPDATE</code>
          statements that take a long time to complete.
        </p><p>
          When a client uses <code class="literal">INSERT DELAYED</code>, it gets
          an okay from the server at once, and the row is queued to be
          inserted when the table is not in use by any other thread.
        </p><p>
          Another major benefit of using <code class="literal">INSERT
          DELAYED</code> is that inserts from many clients are
          bundled together and written in one block. This is much faster
          than performing many separate inserts.
        </p><p>
          Note that <code class="literal">INSERT DELAYED</code> is slower than a
          normal <code class="literal">INSERT</code> if the table is not otherwise
          in use. There is also the additional overhead for the server
          to handle a separate thread for each table for which there are
          delayed rows. This means that you should use <code class="literal">INSERT
          DELAYED</code> only when you are really sure that you need
          it.
        </p><p>
          The queued rows are held only in memory until they are
          inserted into the table. This means that if you terminate
          <span><strong class="command">mysqld</strong></span> forcibly (for example, with
          <code class="literal">kill -9</code>) or if <span><strong class="command">mysqld</strong></span>
          dies unexpectedly, <span class="emphasis"><em>any queued rows that have not
          been written to disk are lost</em></span>.
        </p><p>
          There are some constraints on the use of
          <code class="literal">DELAYED</code>:
        </p><div class="itemizedlist"><ul type="disc"><li><p>
              <code class="literal">INSERT DELAYED</code> works only with
              <code class="literal">MyISAM</code>, <code class="literal">MEMORY</code>, and
              <code class="literal">ARCHIVE</code> tables. See
              <a href="http://dev.mysql.com/doc/refman/5.0/en/myisam-storage-engine.html" target="_top">The <code class="literal">MyISAM</code> Storage Engine</a>,
              <a href="http://dev.mysql.com/doc/refman/5.0/en/memory-storage-engine.html" target="_top">The <code class="literal">MEMORY</code> (<code class="literal">HEAP</code>) Storage Engine</a>, and
              <a href="http://dev.mysql.com/doc/refman/5.0/en/archive-storage-engine.html" target="_top">The <code class="literal">ARCHIVE</code> Storage Engine</a>.
            </p><p>
              For <code class="literal">MyISAM</code> tables, if there are no free
              blocks in the middle of the data file, concurrent
              <code class="literal">SELECT</code> and <code class="literal">INSERT</code>
              statements are supported. Under these circumstances, you
              very seldom need to use <code class="literal">INSERT DELAYED</code>
              with <code class="literal">MyISAM</code>.
            </p></li><li><p>
              <code class="literal">INSERT DELAYED</code> should be used only for
              <code class="literal">INSERT</code> statements that specify value
              lists. The server ignores <code class="literal">DELAYED</code> for
              <code class="literal">INSERT ... SELECT</code> or <code class="literal">INSERT
              ... ON DUPLICATE KEY UPDATE</code> statements.
            </p></li><li><p>
              Because the <code class="literal">INSERT DELAYED</code> statement
              returns immediately, before the rows are inserted, you
              cannot use <code class="literal">LAST_INSERT_ID()</code> to get the
              <code class="literal">AUTO_INCREMENT</code> value that the statement
              might generate.
            </p></li><li><p>
              <code class="literal">DELAYED</code> rows are not visible to
              <code class="literal">SELECT</code> statements until they actually
              have been inserted.
            </p></li><li><p>
              <code class="literal">DELAYED</code> is ignored on slave replication
              servers because it could cause the slave to have different
              data than the master.
            </p></li><li><p>
              Pending <code class="literal">INSERT DELAYED</code> statements are
              lost if a table is write locked and <code class="literal">ALTER
              TABLE</code> is used to modify the table structure.
            </p></li><li><p>
              <code class="literal">INSERT DELAYED</code> is not supported for
              views.
            </p></li></ul></div><p>
          The following describes in detail what happens when you use
          the <code class="literal">DELAYED</code> option to
          <code class="literal">INSERT</code> or <code class="literal">REPLACE</code>. In
          this description, the “<span class="quote">thread</span>” is the thread that
          received an <code class="literal">INSERT DELAYED</code> statement and
          “<span class="quote">handler</span>” is the thread that handles all
          <code class="literal">INSERT DELAYED</code> statements for a particular
          table.
        </p><div class="itemizedlist"><ul type="disc"><li><p>
              When a thread executes a <code class="literal">DELAYED</code>
              statement for a table, a handler thread is created to
              process all <code class="literal">DELAYED</code> statements for the
              table, if no such handler already exists.
            </p></li><li><p>
              The thread checks whether the handler has previously
              acquired a <code class="literal">DELAYED</code> lock; if not, it
              tells the handler thread to do so. The
              <code class="literal">DELAYED</code> lock can be obtained even if
              other threads have a <code class="literal">READ</code> or
              <code class="literal">WRITE</code> lock on the table. However, the
              handler waits for all <code class="literal">ALTER TABLE</code> locks
              or <code class="literal">FLUSH TABLES</code> statements to finish,
              to ensure that the table structure is up to date.
            </p></li><li><p>
              The thread executes the <code class="literal">INSERT</code>
              statement, but instead of writing the row to the table, it
              puts a copy of the final row into a queue that is managed
              by the handler thread. Any syntax errors are noticed by
              the thread and reported to the client program.
            </p></li><li><p>
              The client cannot obtain from the server the number of
              duplicate rows or the <code class="literal">AUTO_INCREMENT</code>
              value for the resulting row, because the
              <code class="literal">INSERT</code> returns before the insert
              operation has been completed. (If you use the C API, the
              <code class="literal">mysql_info()</code> function does not return
              anything meaningful, for the same reason.)
            </p></li><li><p>
              The binary log is updated by the handler thread when the
              row is inserted into the table. In case of multiple-row
              inserts, the binary log is updated when the first row is
              inserted.
            </p></li><li><p>
              <a id="id2868725" class="indexterm"></a>

              Each time that <code class="literal">delayed_insert_limit</code>
              rows are written, the handler checks whether any
              <code class="literal">SELECT</code> statements are still pending. If
              so, it allows these to execute before continuing.
            </p></li><li><p>
              <a id="id2868750" class="indexterm"></a>

              When the handler has no more rows in its queue, the table
              is unlocked. If no new <code class="literal">INSERT DELAYED</code>
              statements are received within
              <code class="literal">delayed_insert_timeout</code> seconds, the
              handler terminates.
            </p></li><li><p>
              If more than <code class="literal">delayed_queue_size</code> rows
              are pending in a specific handler queue, the thread
              requesting <code class="literal">INSERT DELAYED</code> waits until
              there is room in the queue. This is done to ensure that
              <span><strong class="command">mysqld</strong></span> does not use all memory for the
              delayed memory queue.
            </p></li><li><p>
              The handler thread shows up in the MySQL process list with
              <code class="literal">delayed_insert</code> in the
              <code class="literal">Command</code> column. It is killed if you
              execute a <code class="literal">FLUSH TABLES</code> statement or
              kill it with <code class="literal">KILL
              <em class="replaceable"><code>thread_id</code></em></code>. However,
              before exiting, it first stores all queued rows into the
              table. During this time it does not accept any new
              <code class="literal">INSERT</code> statements from other threads.
              If you execute an <code class="literal">INSERT DELAYED</code>
              statement after this, a new handler thread is created.
            </p><p>
              Note that this means that <code class="literal">INSERT
              DELAYED</code> statements have higher priority than
              normal <code class="literal">INSERT</code> statements if there is an
              <code class="literal">INSERT DELAYED</code> handler running. Other
              update statements have to wait until the <code class="literal">INSERT
              DELAYED</code> queue is empty, someone terminates the
              handler thread (with <code class="literal">KILL
              <em class="replaceable"><code>thread_id</code></em></code>), or
              someone executes a <code class="literal">FLUSH TABLES</code>.
            </p></li><li><p>
              The following status variables provide information about
              <code class="literal">INSERT DELAYED</code> statements:
            </p><div class="informaltable"><table border="1"><colgroup><col /><col /></colgroup><tbody><tr><td><span class="bold"><strong>Status Variable</strong></span></td><td><span class="bold"><strong>Meaning</strong></span></td></tr><tr><td><code class="literal">Delayed_insert_threads</code></td><td>Number of handler threads</td></tr><tr><td><code class="literal">Delayed_writes</code></td><td>Number of rows written with <code class="literal">INSERT DELAYED</code></td></tr><tr><td><code class="literal">Not_flushed_delayed_rows</code></td><td>Number of rows waiting to be written</td></tr></tbody></table></div><p>
              You can view these variables by issuing a <code class="literal">SHOW
              STATUS</code> statement or by executing a
              <span><strong class="command">mysqladmin extended-status</strong></span> command.
            </p></li></ul></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="insert-on-duplicate"></a><code class="literal">INSERT ... ON DUPLICATE KEY UPDATE</code> Syntax</h4></div></div></div><p>
          If you specify <code class="literal">ON DUPLICATE KEY UPDATE</code>, and
          a row is inserted that would cause a duplicate value in a
          <code class="literal">UNIQUE</code> index or <code class="literal">PRIMARY
          KEY</code>, an <code class="literal">UPDATE</code> of the old row is
          performed. For example, if column <code class="literal">a</code> is
          declared as <code class="literal">UNIQUE</code> and contains the value
          <code class="literal">1</code>, the following two statements have
          identical effect:
        </p><pre class="programlisting">INSERT INTO table (a,b,c) VALUES (1,2,3)
  ON DUPLICATE KEY UPDATE c=c+1;

UPDATE table SET c=c+1 WHERE a=1;
</pre><p>
          The rows-affected value is 1 if the row is inserted as a new
          record and 2 if an existing record is updated.
        </p><p>
          If column <code class="literal">b</code> is also unique, the
          <code class="literal">INSERT</code> is equivalent to this
          <code class="literal">UPDATE</code> statement instead:
        </p><pre class="programlisting">UPDATE table SET c=c+1 WHERE a=1 OR b=2 LIMIT 1;
</pre><p>
          If <code class="literal">a=1 OR b=2</code> matches several rows, only
          <span class="emphasis"><em>one</em></span> row is updated. In general, you
          should try to avoid using an <code class="literal">ON DUPLICATE
          KEY</code> clause on tables with multiple unique indexes.
        </p><p>
          You can use the
          <code class="literal">VALUES(<em class="replaceable"><code>col_name</code></em>)</code>
          function in the <code class="literal">UPDATE</code> clause to refer to
          column values from the <code class="literal">INSERT</code> portion of
          the <code class="literal">INSERT ... UPDATE</code> statement. In other
          words,
          <code class="literal">VALUES(<em class="replaceable"><code>col_name</code></em>)</code>
          in the <code class="literal">UPDATE</code> clause refers to the value of
          <em class="replaceable"><code>col_name</code></em> that would be inserted,
          had no duplicate-key conflict occurred. This function is
          especially useful in multiple-row inserts. The
          <code class="literal">VALUES()</code> function is meaningful only in
          <code class="literal">INSERT ... UPDATE</code> statements and returns
          <code class="literal">NULL</code> otherwise. Example:
        </p><pre class="programlisting">INSERT INTO table (a,b,c) VALUES (1,2,3),(4,5,6)
  ON DUPLICATE KEY UPDATE c=VALUES(a)+VALUES(b);
</pre><p>
          That statement is identical to the following two statements:
        </p><pre class="programlisting">INSERT INTO table (a,b,c) VALUES (1,2,3)
  ON DUPLICATE KEY UPDATE c=3;
INSERT INTO table (a,b,c) VALUES (4,5,6)
  ON DUPLICATE KEY UPDATE c=9;
</pre><p>
          If a table contains an <code class="literal">AUTO_INCREMENT</code>
          column and <code class="literal">INSERT ... UPDATE</code> inserts a row,
          the <code class="literal">LAST_INSERT_ID()</code> function returns the
          <code class="literal">AUTO_INCREMENT</code> value. If the statement
          updates a row instead, <code class="literal">LAST_INSERT_ID()</code> is
          not meaningful. However, you can work around this by using
          <code class="literal">LAST_INSERT_ID(<em class="replaceable"><code>expr</code></em>)</code>.
          Suppose that <code class="literal">id</code> is the
          <code class="literal">AUTO_INCREMENT</code> column. To make
          <code class="literal">LAST_INSERT_ID()</code> meaningful for updates,
          insert rows as follows:
        </p><pre class="programlisting">INSERT INTO table (a,b,c) VALUES (1,2,3)
  ON DUPLICATE KEY UPDATE id=LAST_INSERT_ID(id), c=3;
</pre><p>
          The <code class="literal">DELAYED</code> option is ignored when you use
          <code class="literal">ON DUPLICATE KEY UPDATE</code>.
        </p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="load-data"></a><code class="literal">LOAD DATA INFILE</code> Syntax</h3></div></div></div><a id="id2869208" class="indexterm"></a><pre class="programlisting">LOAD DATA [LOW_PRIORITY | CONCURRENT] [LOCAL] INFILE '<em class="replaceable"><code>file_name</code></em>'
    [REPLACE | IGNORE]
    INTO TABLE <em class="replaceable"><code>tbl_name</code></em>
    [CHARACTER SET <em class="replaceable"><code>charset_name</code></em>]
    [FIELDS
        [TERMINATED BY '<em class="replaceable"><code>string</code></em>']
        [[OPTIONALLY] ENCLOSED BY '<em class="replaceable"><code>char</code></em>']
        [ESCAPED BY '<em class="replaceable"><code>char</code></em>']
    ]
    [LINES
        [STARTING BY '<em class="replaceable"><code>string</code></em>']
        [TERMINATED BY '<em class="replaceable"><code>string</code></em>']
    ]
    [IGNORE <em class="replaceable"><code>number</code></em> LINES]
    [(<em class="replaceable"><code>col_name_or_user_var</code></em>,...)]
    [SET <em class="replaceable"><code>col_name</code></em> = <em class="replaceable"><code>expr</code></em>,...]
</pre><p>
        The <code class="literal">LOAD DATA INFILE</code> statement reads rows
        from a text file into a table at a very high speed. The filename
        must be given as a literal string.
      </p><p>
        <code class="literal">LOAD DATA INFILE</code> is the complement of
        <code class="literal">SELECT ... INTO OUTFILE</code>. (See
        <a href="mysqlqb_statements.html#select" title="SELECT Syntax"><code class="literal">SELECT</code> Syntax</a>.) To write data from a table to a file,
        use <code class="literal">SELECT ... INTO OUTFILE</code>. To read the file
        back into a table, use <code class="literal">LOAD DATA INFILE</code>. The
        syntax of the <code class="literal">FIELDS</code> and
        <code class="literal">LINES</code> clauses is the same for both
        statements. Both clauses are optional, but
        <code class="literal">FIELDS</code> must precede <code class="literal">LINES</code>
        if both are specified.
      </p><p>
        For more information about the efficiency of
        <code class="literal">INSERT</code> versus <code class="literal">LOAD DATA
        INFILE</code> and speeding up <code class="literal">LOAD DATA
        INFILE</code>, see <a href="http://dev.mysql.com/doc/refman/5.0/en/insert-speed.html" target="_top">Speed of <code class="literal">INSERT</code> Statements</a>.
      </p><p>
        The character set indicated by the
        <code class="literal">character_set_database</code> system variable is
        used to interpret the information in the file. <code class="literal">SET
        NAMES</code> and the setting of
        <code class="literal">character_set_client</code> do not affect
        interpretation of input. Beginning with MySQL 5.0.38, if the
        contents of the input file use a character set that differs from
        the default, it is possible (and usually preferable) to use the
        <code class="literal">CHARACTER SET</code> clause to specify the character
        set of the file.
      </p><p>
        Note that it is currently not possible to load data files that
        use the <code class="literal">ucs2</code> character set.
      </p><p>
        As of MySQL 5.0.19, the
        <code class="literal">character_set_filesystem</code> system variable
        controls the interpretation of the filename.
      </p><a id="id2869416" class="indexterm"></a><p>
        You can also load data files by using the
        <span><strong class="command">mysqlimport</strong></span> utility; it operates by sending a
        <code class="literal">LOAD DATA INFILE</code> statement to the server. The
        <code class="option">--local</code> option causes
        <span><strong class="command">mysqlimport</strong></span> to read data files from the
        client host. You can specify the <code class="option">--compress</code>
        option to get better performance over slow networks if the
        client and server support the compressed protocol. See
        <a href="http://dev.mysql.com/doc/refman/5.0/en/mysqlimport.html" target="_top">mysqlimport</a>.
      </p><p>
        If you use <code class="literal">LOW_PRIORITY</code>, execution of the
        <code class="literal">LOAD DATA</code> statement is delayed until no other
        clients are reading from the table.
      </p><p>
        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 threads can retrieve data from the table while
        <code class="literal">LOAD DATA</code> is executing. Using this option
        affects the performance of <code class="literal">LOAD DATA</code> a bit,
        even if no other thread is using the table at the same time.
      </p><p>
        The <code class="literal">LOCAL</code> keyword, if specified, is
        interpreted with respect to the client end of the connection:
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            If <code class="literal">LOCAL</code> is specified, the file is read
            by the client program on the client host and sent to the
            server. The file can be given as a full pathname to specify
            its exact location. If given as a relative pathname, the
            name is interpreted relative to the directory in which the
            client program was started.
          </p></li><li><p>
            If <code class="literal">LOCAL</code> is not specified, the file must
            be located on the server host and is read directly by the
            server. The server uses the following rules to locate the
            file:
          </p><div class="itemizedlist"><ul type="circle"><li><p>
                If the filename is an absolute pathname, the server uses
                it as given.
              </p></li><li><p>
                If the filename is a relative pathname with one or more
                leading components, the server searches for the file
                relative to the server's data directory.
              </p></li><li><p>
                If a filename with no leading components is given, the
                server looks for the file in the database directory of
                the default database.
              </p></li></ul></div></li></ul></div><p>
        Note that, in the non-<code class="literal">LOCAL</code> case, these rules
        mean that a file named as <code class="filename">./myfile.txt</code> is
        read from the server's data directory, whereas the file named as
        <code class="filename">myfile.txt</code> is read from the database
        directory of the default database. For example, if
        <code class="literal">db1</code> is the default database, the following
        <code class="literal">LOAD DATA</code> statement reads the file
        <code class="filename">data.txt</code> from the database directory for
        <code class="literal">db1</code>, even though the statement explicitly
        loads the file into a table in the <code class="literal">db2</code>
        database:
      </p><pre class="programlisting">LOAD DATA INFILE 'data.txt' INTO TABLE db2.my_table;
</pre><p>
        Windows pathnames are specified using forward slashes rather
        than backslashes. If you do use backslashes, you must double
        them.
      </p><p>
        For security reasons, when reading text files located on the
        server, the files must either reside in the database directory
        or be readable by all. Also, to use <code class="literal">LOAD DATA
        INFILE</code> on server files, you must have the
        <code class="literal">FILE</code> privilege. See
        <a href="http://dev.mysql.com/doc/refman/5.0/en/privileges-provided.html" target="_top">Privileges Provided by MySQL</a>.
      </p><p>
        Using <code class="literal">LOCAL</code> is a bit slower than letting the
        server access the files directly, because the contents of the
        file must be sent over the connection by the client to the
        server. On the other hand, you do not need the
        <code class="literal">FILE</code> privilege to load local files.
      </p><p>
        <code class="literal">LOCAL</code> works only if your server and your
        client both have been enabled to allow it. For example, if
        <span><strong class="command">mysqld</strong></span> was started with
        <code class="option">--local-infile=0</code>, <code class="literal">LOCAL</code> does
        not work. See <a href="http://dev.mysql.com/doc/refman/5.0/en/load-data-local.html" target="_top">Security Issues with <code class="literal">LOAD DATA LOCAL</code></a>.
      </p><p>
        On Unix, if you need <code class="literal">LOAD DATA</code> to read from a
        pipe, you can use the following technique (here we load the
        listing of the <code class="filename">/</code> directory into a table):
      </p><pre class="programlisting">mkfifo /mysql/db/x/x
chmod 666 /mysql/db/x/x
find / -ls &gt; /mysql/db/x/x &amp;
mysql -e "LOAD DATA INFILE 'x' INTO TABLE x" x
</pre><p>
        Note that you must run the command that generates the data to be
        loaded and the <span><strong class="command">mysql</strong></span> commands either on
        separate terminals, or run the data generation process in the
        background (as shown in the preceding example). If you do not do
        this, the pipe will block until data is read by the
        <span><strong class="command">mysql</strong></span> process.
      </p><p>
        The <code class="literal">REPLACE</code> and <code class="literal">IGNORE</code>
        keywords control handling of input rows that duplicate existing
        rows on unique key values:
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            If you specify <code class="literal">REPLACE</code>, input rows
            replace existing rows. In other words, rows that have the
            same value for a primary key or unique index as an existing
            row. See <a href="mysqlqb_statements.html#replace" title="REPLACE Syntax"><code class="literal">REPLACE</code> Syntax</a>.
          </p></li><li><p>
            If you specify <code class="literal">IGNORE</code>, input rows that
            duplicate an existing row on a unique key value are skipped.
            If you do not specify either option, the behavior depends on
            whether the <code class="literal">LOCAL</code> keyword is specified.
            Without <code class="literal">LOCAL</code>, an error occurs when a
            duplicate key value is found, and the rest of the text file
            is ignored. With <code class="literal">LOCAL</code>, the default
            behavior is the same as if <code class="literal">IGNORE</code> is
            specified; this is because the server has no way to stop
            transmission of the file in the middle of the operation.
          </p></li></ul></div><p>
        If you want to ignore foreign key constraints during the load
        operation, you can issue a <code class="literal">SET
        FOREIGN_KEY_CHECKS=0</code> statement before executing
        <code class="literal">LOAD DATA</code>.
      </p><p>
        If you use <code class="literal">LOAD DATA INFILE</code> on an empty
        <code class="literal">MyISAM</code> table, all non-unique indexes are
        created in a separate batch (as for <code class="literal">REPAIR
        TABLE</code>). Normally, this makes <code class="literal">LOAD DATA
        INFILE</code> much faster when you have many indexes. In some
        extreme cases, you can create the indexes even faster by turning
        them off with <code class="literal">ALTER TABLE ... DISABLE KEYS</code>
        before loading the file into the table and using <code class="literal">ALTER
        TABLE ... ENABLE KEYS</code> to re-create the indexes after
        loading the file. See <a href="http://dev.mysql.com/doc/refman/5.0/en/insert-speed.html" target="_top">Speed of <code class="literal">INSERT</code> Statements</a>.
      </p><p>
        For both the <code class="literal">LOAD DATA INFILE</code> and
        <code class="literal">SELECT ... INTO OUTFILE</code> statements, the
        syntax of the <code class="literal">FIELDS</code> and
        <code class="literal">LINES</code> clauses is the same. Both clauses are
        optional, but <code class="literal">FIELDS</code> must precede
        <code class="literal">LINES</code> if both are specified.
      </p><p>
        If you specify a <code class="literal">FIELDS</code> clause, each of its
        subclauses (<code class="literal">TERMINATED BY</code>,
        <code class="literal">[OPTIONALLY] ENCLOSED BY</code>, and
        <code class="literal">ESCAPED BY</code>) is also optional, except that you
        must specify at least one of them.
      </p><p>
        If you specify no <code class="literal">FIELDS</code> clause, the defaults
        are the same as if you had written this:
      </p><pre class="programlisting">FIELDS TERMINATED BY '\t' ENCLOSED BY '' ESCAPED BY '\\'
</pre><p>
        If you specify no <code class="literal">LINES</code> clause, the defaults
        are the same as if you had written this:
      </p><pre class="programlisting">LINES TERMINATED BY '\n' STARTING BY ''
</pre><p>
        In other words, the defaults cause <code class="literal">LOAD DATA
        INFILE</code> to act as follows when reading input:
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            Look for line boundaries at newlines.
          </p></li><li><p>
            Do not skip over any line prefix.
          </p></li><li><p>
            Break lines into fields at tabs.
          </p></li><li><p>
            Do not expect fields to be enclosed within any quoting
            characters.
          </p></li><li><p>
            Interpret occurrences of tab, newline, or
            ‘<code class="literal">\</code>’ preceded by
            ‘<code class="literal">\</code>’ as literal characters
            that are part of field values.
          </p></li></ul></div><p>
        Conversely, the defaults cause <code class="literal">SELECT ... INTO
        OUTFILE</code> to act as follows when writing output:
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            Write tabs between fields.
          </p></li><li><p>
            Do not enclose fields within any quoting characters.
          </p></li><li><p>
            Use ‘<code class="literal">\</code>’ to escape instances
            of tab, newline, or ‘<code class="literal">\</code>’ that
            occur within field values.
          </p></li><li><p>
            Write newlines at the ends of lines.
          </p></li></ul></div><p>
        Backslash is the MySQL escape character within strings, so to
        write <code class="literal">FIELDS ESCAPED BY '\\'</code>, you must
        specify two backslashes for the value to be interpreted as a
        single backslash.
      </p><p>
        <span class="bold"><strong>Note</strong></span>: If you have generated the
        text file on a Windows system, you might have to use
        <code class="literal">LINES TERMINATED BY '\r\n'</code> to read the file
        properly, because Windows programs typically use two characters
        as a line terminator. Some programs, such as
        <span><strong class="command">WordPad</strong></span>, might use <code class="literal">\r</code> as a
        line terminator when writing files. To read such files, use
        <code class="literal">LINES TERMINATED BY '\r'</code>.
      </p><p>
        If all the lines you want to read in have a common prefix that
        you want to ignore, you can use <code class="literal">LINES STARTING BY
        '<em class="replaceable"><code>prefix_string</code></em>'</code> to skip
        over the prefix, <span class="emphasis"><em>and anything before it</em></span>. If
        a line does not include the prefix, the entire line is skipped.
        Suppose that you issue the following statement:
      </p><pre class="programlisting">LOAD DATA INFILE '/tmp/test.txt' INTO TABLE test
  FIELDS TERMINATED BY ','  LINES STARTING BY 'xxx';
</pre><p>
        If the data file looks like this:
      </p><pre class="programlisting">xxx"abc",1
something xxx"def",2
"ghi",3
</pre><p>
        The resulting rows will be <code class="literal">("abc",1)</code> and
        <code class="literal">("def",2)</code>. The third row in the file is
        skipped because it does not contain the prefix.
      </p><p>
        The <code class="literal">IGNORE <em class="replaceable"><code>number</code></em>
        LINES</code> option can be used to ignore lines at the start
        of the file. For example, you can use <code class="literal">IGNORE 1
        LINES</code> to skip over an initial header line containing
        column names:
      </p><pre class="programlisting">LOAD DATA INFILE '/tmp/test.txt' INTO TABLE test IGNORE 1 LINES;
</pre><p>
        When you use <code class="literal">SELECT ... INTO OUTFILE</code> in
        tandem with <code class="literal">LOAD DATA INFILE</code> to write data
        from a database into a file and then read the file back into the
        database later, the field- and line-handling options for both
        statements must match. Otherwise, <code class="literal">LOAD DATA
        INFILE</code> will not interpret the contents of the file
        properly. Suppose that you use <code class="literal">SELECT ... INTO
        OUTFILE</code> to write a file with fields delimited by
        commas:
      </p><pre class="programlisting">SELECT * INTO OUTFILE 'data.txt'
  FIELDS TERMINATED BY ','
  FROM table2;
</pre><p>
        To read the comma-delimited file back in, the correct statement
        would be:
      </p><pre class="programlisting">LOAD DATA INFILE 'data.txt' INTO TABLE table2
  FIELDS TERMINATED BY ',';
</pre><p>
        If instead you tried to read in the file with the statement
        shown following, it wouldn't work because it instructs
        <code class="literal">LOAD DATA INFILE</code> to look for tabs between
        fields:
      </p><pre class="programlisting">LOAD DATA INFILE 'data.txt' INTO TABLE table2
  FIELDS TERMINATED BY '\t';
</pre><p>
        The likely result is that each input line would be interpreted
        as a single field.
      </p><a id="id2870210" class="indexterm"></a><a id="id2870217" class="indexterm"></a><p>
        <code class="literal">LOAD DATA INFILE</code> can be used to read files
        obtained from external sources. For example, many programs can
        export data in comma-separated values (CSV) format, such that
        lines have fields separated by commas and enclosed within double
        quotes. If lines in such a file are terminated by newlines, the
        statement shown here illustrates the field- and line-handling
        options you would use to load the file:
      </p><pre class="programlisting">LOAD DATA INFILE 'data.txt' INTO TABLE <em class="replaceable"><code>tbl_name</code></em>
  FIELDS TERMINATED BY ',' ENCLOSED BY '"'
  LINES TERMINATED BY '\n';
</pre><p>
        Any of the field- or line-handling options can specify an empty
        string (<code class="literal">''</code>). If not empty, the
        <code class="literal">FIELDS [OPTIONALLY] ENCLOSED BY</code> and
        <code class="literal">FIELDS ESCAPED BY</code> values must be a single
        character. The <code class="literal">FIELDS TERMINATED BY</code>,
        <code class="literal">LINES STARTING BY</code>, and <code class="literal">LINES
        TERMINATED BY</code> values can be more than one character.
        For example, to write lines that are terminated by carriage
        return/linefeed pairs, or to read a file containing such lines,
        specify a <code class="literal">LINES TERMINATED BY '\r\n'</code> clause.
      </p><p>
        To read a file containing jokes that are separated by lines
        consisting of <code class="literal">%%</code>, you can do this
      </p><pre class="programlisting">CREATE TABLE jokes
  (a INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
  joke TEXT NOT NULL);
LOAD DATA INFILE '/tmp/jokes.txt' INTO TABLE jokes
  FIELDS TERMINATED BY ''
  LINES TERMINATED BY '\n%%\n' (joke);
</pre><p>
        <code class="literal">FIELDS [OPTIONALLY] ENCLOSED BY</code> controls
        quoting of fields. For output (<code class="literal">SELECT ... INTO
        OUTFILE</code>), if you omit the word
        <code class="literal">OPTIONALLY</code>, all fields are enclosed by the
        <code class="literal">ENCLOSED BY</code> character. An example of such
        output (using a comma as the field delimiter) is shown here:
      </p><pre class="programlisting">"1","a string","100.20"
"2","a string containing a , comma","102.20"
"3","a string containing a \" quote","102.20"
"4","a string containing a \", quote and comma","102.20"
</pre><p>
        If you specify <code class="literal">OPTIONALLY</code>, the
        <code class="literal">ENCLOSED BY</code> character is used only to enclose
        values from columns that have a string data type (such as
        <code class="literal">CHAR</code>, <code class="literal">BINARY</code>,
        <code class="literal">TEXT</code>, or <code class="literal">ENUM</code>):
      </p><pre class="programlisting">1,"a string",100.20
2,"a string containing a , comma",102.20
3,"a string containing a \" quote",102.20
4,"a string containing a \", quote and comma",102.20
</pre><p>
        Note that occurrences of the <code class="literal">ENCLOSED BY</code>
        character within a field value are escaped by prefixing them
        with the <code class="literal">ESCAPED BY</code> character. Also note that
        if you specify an empty <code class="literal">ESCAPED BY</code> value, it
        is possible to inadvertently generate output that cannot be read
        properly by <code class="literal">LOAD DATA INFILE</code>. For example,
        the preceding output just shown would appear as follows if the
        escape character is empty. Observe that the second field in the
        fourth line contains a comma following the quote, which
        (erroneously) appears to terminate the field:
      </p><pre class="programlisting">1,"a string",100.20
2,"a string containing a , comma",102.20
3,"a string containing a " quote",102.20
4,"a string containing a ", quote and comma",102.20
</pre><p>
        For input, the <code class="literal">ENCLOSED BY</code> character, if
        present, is stripped from the ends of field values. (This is
        true regardless of whether <code class="literal">OPTIONALLY</code> is
        specified; <code class="literal">OPTIONALLY</code> has no effect on input
        interpretation.) Occurrences of the <code class="literal">ENCLOSED
        BY</code> character preceded by the <code class="literal">ESCAPED
        BY</code> character are interpreted as part of the current
        field value.
      </p><p>
        If the field begins with the <code class="literal">ENCLOSED BY</code>
        character, instances of that character are recognized as
        terminating a field value only if followed by the field or line
        <code class="literal">TERMINATED BY</code> sequence. To avoid ambiguity,
        occurrences of the <code class="literal">ENCLOSED BY</code> character
        within a field value can be doubled and are interpreted as a
        single instance of the character. For example, if
        <code class="literal">ENCLOSED BY '"'</code> is specified, quotes are
        handled as shown here:
      </p><pre class="programlisting">"The ""BIG"" boss"  -&gt; The "BIG" boss
The "BIG" boss      -&gt; The "BIG" boss
The ""BIG"" boss    -&gt; The ""BIG"" boss
</pre><p>
        <code class="literal">FIELDS ESCAPED BY</code> controls how to write or
        read special characters. If the <code class="literal">FIELDS ESCAPED
        BY</code> character is not empty, it is used to prefix the
        following characters on output:
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            The <code class="literal">FIELDS ESCAPED BY</code> character
          </p></li><li><p>
            The <code class="literal">FIELDS [OPTIONALLY] ENCLOSED BY</code>
            character
          </p></li><li><p>
            The first character of the <code class="literal">FIELDS TERMINATED
            BY</code> and <code class="literal">LINES TERMINATED BY</code>
            values
          </p></li><li><p>
            ASCII <code class="literal">0</code> (what is actually written
            following the escape character is ASCII
            ‘<code class="literal">0</code>’, not a zero-valued byte)
          </p></li></ul></div><p>
        If the <code class="literal">FIELDS ESCAPED BY</code> character is empty,
        no characters are escaped and <code class="literal">NULL</code> is output
        as <code class="literal">NULL</code>, not <code class="literal">\N</code>. It is
        probably not a good idea to specify an empty escape character,
        particularly if field values in your data contain any of the
        characters in the list just given.
      </p><p>
        For input, if the <code class="literal">FIELDS ESCAPED BY</code> character
        is not empty, occurrences of that character are stripped and the
        following character is taken literally as part of a field value.
        The exceptions are an escaped ‘<code class="literal">0</code>’
        or ‘<code class="literal">N</code>’ (for example,
        <code class="literal">\0</code> or <code class="literal">\N</code> if the escape
        character is ‘<code class="literal">\</code>’). These
        sequences are interpreted as ASCII NUL (a zero-valued byte) and
        <code class="literal">NULL</code>. The rules for <code class="literal">NULL</code>
        handling are described later in this section.
      </p><p>
        For more information about
        ‘<code class="literal">\</code>’-escape syntax, see
        <a href="http://dev.mysql.com/doc/refman/5.0/en/literals.html" target="_top">Literal Values</a>.
      </p><p>
        In certain cases, field- and line-handling options interact:
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            If <code class="literal">LINES TERMINATED BY</code> is an empty string
            and <code class="literal">FIELDS TERMINATED BY</code> is non-empty,
            lines are also terminated with <code class="literal">FIELDS TERMINATED
            BY</code>.
          </p></li><li><p>
            If the <code class="literal">FIELDS TERMINATED BY</code> and
            <code class="literal">FIELDS ENCLOSED BY</code> values are both empty
            (<code class="literal">''</code>), a fixed-row (non-delimited) format
            is used. With fixed-row format, no delimiters are used
            between fields (but you can still have a line terminator).
            Instead, column values are read and written using a field
            width wide enough to hold all values in the field. For
            <code class="literal">TINYINT</code>, <code class="literal">SMALLINT</code>,
            <code class="literal">MEDIUMINT</code>, <code class="literal">INT</code>, and
            <code class="literal">BIGINT</code>, the field widths are 4, 6, 8, 11,
            and 20, respectively, no matter what the declared display
            width is.
          </p><p>
            <code class="literal">LINES TERMINATED BY</code> is still used to
            separate lines. If a line does not contain all fields, the
            rest of the columns are set to their default values. If you
            do not have a line terminator, you should set this to
            <code class="literal">''</code>. In this case, the text file must
            contain all fields for each row.
          </p><p>
            Fixed-row format also affects handling of
            <code class="literal">NULL</code> values, as described later. Note
            that fixed-size format does not work if you are using a
            multi-byte character set.
          </p><p>
            <span class="bold"><strong>Note:</strong></span> Before MySQL 5.0.6,
            fixed-row format used the display width of the column. For
            example, <code class="literal">INT(4)</code> was read or written using
            a field with a width of 4. However, if the column contained
            wider values, they were dumped to their full width, leading
            to the possibility of a “<span class="quote">ragged</span>” field holding
            values of different widths. Using a field wide enough to
            hold all values in the field prevents this problem. However,
            data files written before this change was made might not be
            reloaded correctly with <code class="literal">LOAD DATA INFILE</code>
            for MySQL 5.0.6 and up. This change also affects data files
            read by <span><strong class="command">mysqlimport</strong></span> and written by
            <span><strong class="command">mysqldump --tab</strong></span>, which use <code class="literal">LOAD
            DATA INFILE</code> and <code class="literal">SELECT ... INTO
            OUTFILE</code>.
          </p></li></ul></div><p>
        Handling of <code class="literal">NULL</code> values varies according to
        the <code class="literal">FIELDS</code> and <code class="literal">LINES</code>
        options in use:
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            For the default <code class="literal">FIELDS</code> and
            <code class="literal">LINES</code> values, <code class="literal">NULL</code> is
            written as a field value of <code class="literal">\N</code> for
            output, and a field value of <code class="literal">\N</code> is read
            as <code class="literal">NULL</code> for input (assuming that the
            <code class="literal">ESCAPED BY</code> character is
            ‘<code class="literal">\</code>’).
          </p></li><li><p>
            If <code class="literal">FIELDS ENCLOSED BY</code> is not empty, a
            field containing the literal word <code class="literal">NULL</code> as
            its value is read as a <code class="literal">NULL</code> value. This
            differs from the word <code class="literal">NULL</code> enclosed
            within <code class="literal">FIELDS ENCLOSED BY</code> characters,
            which is read as the string <code class="literal">'NULL'</code>.
          </p></li><li><p>
            If <code class="literal">FIELDS ESCAPED BY</code> is empty,
            <code class="literal">NULL</code> is written as the word
            <code class="literal">NULL</code>.
          </p></li><li><p>
            With fixed-row format (which is used when <code class="literal">FIELDS
            TERMINATED BY</code> and <code class="literal">FIELDS ENCLOSED
            BY</code> are both empty), <code class="literal">NULL</code> is
            written as an empty string. Note that this causes both
            <code class="literal">NULL</code> values and empty strings in the
            table to be indistinguishable when written to the file
            because both are written as empty strings. If you need to be
            able to tell the two apart when reading the file back in,
            you should not use fixed-row format.
          </p></li></ul></div><p>
        An attempt to load <code class="literal">NULL</code> into a <code class="literal">NOT
        NULL</code> column causes assignment of the implicit default
        value for the column's data type and a warning, or an error in
        strict SQL mode. Implicit default values are discussed in
        <a href="http://dev.mysql.com/doc/refman/5.0/en/data-type-defaults.html" target="_top">Data Type Default Values</a>.
      </p><p>
        Some cases are not supported by <code class="literal">LOAD DATA
        INFILE</code>:
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            Fixed-size rows (<code class="literal">FIELDS TERMINATED BY</code> and
            <code class="literal">FIELDS ENCLOSED BY</code> both empty) and
            <code class="literal">BLOB</code> or <code class="literal">TEXT</code> columns.
          </p></li><li><p>
            If you specify one separator that is the same as or a prefix
            of another, <code class="literal">LOAD DATA INFILE</code> cannot
            interpret the input properly. For example, the following
            <code class="literal">FIELDS</code> clause would cause problems:
          </p><pre class="programlisting">FIELDS TERMINATED BY '"' ENCLOSED BY '"'
</pre></li><li><p>
            If <code class="literal">FIELDS ESCAPED BY</code> is empty, a field
            value that contains an occurrence of <code class="literal">FIELDS
            ENCLOSED BY</code> or <code class="literal">LINES TERMINATED
            BY</code> followed by the <code class="literal">FIELDS TERMINATED
            BY</code> value causes <code class="literal">LOAD DATA
            INFILE</code> to stop reading a field or line too early.
            This happens because <code class="literal">LOAD DATA INFILE</code>
            cannot properly determine where the field or line value
            ends.
          </p></li></ul></div><p>
        The following example loads all columns of the
        <code class="literal">persondata</code> table:
      </p><pre class="programlisting">LOAD DATA INFILE 'persondata.txt' INTO TABLE persondata;
</pre><p>
        By default, when no column list is provided at the end of the
        <code class="literal">LOAD DATA INFILE</code> statement, input lines are
        expected to contain a field for each table column. If you want
        to load only some of a table's columns, specify a column list:
      </p><pre class="programlisting">LOAD DATA INFILE 'persondata.txt' INTO TABLE persondata (col1,col2,...);
</pre><p>
        You must also specify a column list if the order of the fields
        in the input file differs from the order of the columns in the
        table. Otherwise, MySQL cannot tell how to match input fields
        with table columns.
      </p><p>
        Before MySQL 5.0.3, the column list must contain only names of
        columns in the table being loaded, and the
        <code class="literal">SET</code> clause is not supported. As of MySQL
        5.0.3, the column list can contain either column names or user
        variables. With user variables, the <code class="literal">SET</code>
        clause enables you to perform transformations on their values
        before assigning the result to columns.
      </p><p>
        User variables in the <code class="literal">SET</code> clause can be used
        in several ways. The following example uses the first input
        column directly for the value of <code class="literal">t1.column1</code>,
        and assigns the second input column to a user variable that is
        subjected to a division operation before being used for the
        value of <code class="literal">t1.column2</code>:
      </p><pre class="programlisting">LOAD DATA INFILE 'file.txt'
  INTO TABLE t1
  (column1, @var1)
  SET column2 = @var1/100;
</pre><p>
        The <code class="literal">SET</code> clause can be used to supply values
        not derived from the input file. The following statement sets
        <code class="literal">column3</code> to the current date and time:
      </p><pre class="programlisting">LOAD DATA INFILE 'file.txt'
  INTO TABLE t1
  (column1, column2)
  SET column3 = CURRENT_TIMESTAMP;
</pre><p>
        You can also discard an input value by assigning it to a user
        variable and not assigning the variable to a table column:
      </p><pre class="programlisting">LOAD DATA INFILE 'file.txt'
  INTO TABLE t1
  (column1, @dummy, column2, @dummy, column3);
</pre><p>
        Use of the column/variable list and <code class="literal">SET</code>
        clause is subject to the following restrictions:
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            Assignments in the <code class="literal">SET</code> clause should have
            only column names on the left hand side of assignment
            operators.
          </p></li><li><p>
            You can use subqueries in the right hand side of
            <code class="literal">SET</code> assignments. A subquery that returns
            a value to be assigned to a column may be a scalar subquery
            only. Also, you cannot use a subquery to select from the
            table that is being loaded.
          </p></li><li><p>
            Lines ignored by an <code class="literal">IGNORE</code> clause are not
            processed for the column/variable list or
            <code class="literal">SET</code> clause.
          </p></li><li><p>
            User variables cannot be used when loading data with
            fixed-row format because user variables do not have a
            display width.
          </p></li></ul></div><p>
        When processing an input line, <code class="literal">LOAD DATA</code>
        splits it into fields and uses the values according to the
        column/variable list and the <code class="literal">SET</code> clause, if
        they are present. Then the resulting row is inserted into the
        table. If there are <code class="literal">BEFORE INSERT</code> or
        <code class="literal">AFTER INSERT</code> triggers for the table, they are
        activated before or after inserting the row, respectively.
      </p><p>
        If an input line has too many fields, the extra fields are
        ignored and the number of warnings is incremented.
      </p><p>
        If an input line has too few fields, the table columns for which
        input fields are missing are set to their default values.
        Default value assignment is described in
        <a href="http://dev.mysql.com/doc/refman/5.0/en/data-type-defaults.html" target="_top">Data Type Default Values</a>.
      </p><p>
        An empty field value is interpreted differently than if the
        field value is missing:
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            For string types, the column is set to the empty string.
          </p></li><li><p>
            For numeric types, the column is set to
            <code class="literal">0</code>.
          </p></li><li><p>
            For date and time types, the column is set to the
            appropriate “<span class="quote">zero</span>” value for the type. See
            <a href="http://dev.mysql.com/doc/refman/5.0/en/date-and-time-types.html" target="_top">Date and Time Types</a>.
          </p></li></ul></div><p>
        These are the same values that result if you assign an empty
        string explicitly to a string, numeric, or date or time type
        explicitly in an <code class="literal">INSERT</code> or
        <code class="literal">UPDATE</code> statement.
      </p><p>
        <code class="literal">TIMESTAMP</code> columns are set to the current date
        and time only if there is a <code class="literal">NULL</code> value for
        the column (that is, <code class="literal">\N</code>), or if the
        <code class="literal">TIMESTAMP</code> column's default value is the
        current timestamp and it is omitted from the field list when a
        field list is specified.
      </p><p>
        <code class="literal">LOAD DATA INFILE</code> regards all input as
        strings, so you cannot use numeric values for
        <code class="literal">ENUM</code> or <code class="literal">SET</code> columns the
        way you can with <code class="literal">INSERT</code> statements. All
        <code class="literal">ENUM</code> and <code class="literal">SET</code> values must
        be specified as strings.
      </p><p>
        <code class="literal">BIT</code> values cannot be loaded using binary
        notation (for example, <code class="literal">b'011010'</code>). To work
        around this, specify the values as regular integers and use the
        <code class="literal">SET</code> clause to convert them so that MySQL
        performs a numeric type conversion and loads them into the
        <code class="literal">BIT</code> column properly:
      </p><pre class="programlisting">shell&gt; <strong class="userinput"><code>cat /tmp/bit_test.txt</code></strong>
2
127
shell&gt; <strong class="userinput"><code>mysql test</code></strong>
mysql&gt; <strong class="userinput"><code>LOAD DATA INFILE '/tmp/bit_test.txt'</code></strong>
    -&gt; <strong class="userinput"><code>INTO TABLE bit_test (@var1) SET b= CAST(@var1 AS SIGNED);</code></strong>
Query OK, 2 rows affected (0.00 sec)
Records: 2  Deleted: 0  Skipped: 0  Warnings: 0

mysql&gt; <strong class="userinput"><code>SELECT BIN(b+0) FROM bit_test;</code></strong>
+----------+
| bin(b+0) |
+----------+
| 10       |
| 1111111  |
+----------+
2 rows in set (0.00 sec)
</pre><p>
        When the <code class="literal">LOAD DATA INFILE</code> statement finishes,
        it returns an information string in the following format:
      </p><pre class="programlisting">Records: 1  Deleted: 0  Skipped: 0  Warnings: 0
</pre><a id="id2871394" class="indexterm"></a><p>
        If you are using the C API, you can get information about the
        statement by calling the <code class="literal">mysql_info()</code>
        function. See <a href="http://dev.mysql.com/doc/refman/5.0/en/mysql-info.html" target="_top"><code class="literal">mysql_info()</code></a>.
      </p><p>
        Warnings occur under the same circumstances as when values are
        inserted via the <code class="literal">INSERT</code> statement (see
        <a href="mysqlqb_statements.html#insert" title="INSERT Syntax"><code class="literal">INSERT</code> Syntax</a>), except that <code class="literal">LOAD DATA
        INFILE</code> also generates warnings when there are too few
        or too many fields in the input row. The warnings are not stored
        anywhere; the number of warnings can be used only as an
        indication of whether everything went well.
      </p><p>
        You can use <code class="literal">SHOW WARNINGS</code> to get a list of
        the first <code class="literal">max_error_count</code> warnings as
        information about what went wrong. See
        <a href="mysqlqb_statements.html#show-warnings" title="SHOW WARNINGS Syntax"><code class="literal">SHOW WARNINGS</code> Syntax</a>.
      </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="replace"></a><code class="literal">REPLACE</code> Syntax</h3></div></div></div><a id="id2871469" class="indexterm"></a><pre class="programlisting">REPLACE [LOW_PRIORITY | DELAYED]
    [INTO] <em class="replaceable"><code>tbl_name</code></em> [(<em class="replaceable"><code>col_name</code></em>,...)]
    VALUES ({<em class="replaceable"><code>expr</code></em> | DEFAULT},...),(...),...
</pre><p>
        Or:
      </p><pre class="programlisting">REPLACE [LOW_PRIORITY | DELAYED]
    [INTO] <em class="replaceable"><code>tbl_name</code></em>
    SET <em class="replaceable"><code>col_name</code></em>={<em class="replaceable"><code>expr</code></em> | DEFAULT}, ...
</pre><p>
        Or:
      </p><pre class="programlisting">REPLACE [LOW_PRIORITY | DELAYED]
    [INTO] <em class="replaceable"><code>tbl_name</code></em> [(<em class="replaceable"><code>col_name</code></em>,...)]
    SELECT ...
</pre><p>
        <code class="literal">REPLACE</code> works exactly like
        <code class="literal">INSERT</code>, except that if an old row in the
        table has the same value as a new row for a <code class="literal">PRIMARY
        KEY</code> or a <code class="literal">UNIQUE</code> index, the old row
        is deleted before the new row is inserted. See
        <a href="mysqlqb_statements.html#insert" title="INSERT Syntax"><code class="literal">INSERT</code> Syntax</a>.
      </p><p>
        <code class="literal">REPLACE</code> is a MySQL extension to the SQL
        standard. It either inserts, or <span class="emphasis"><em>deletes</em></span> and
        inserts. For another MySQL extension to standard SQL —
        that either inserts or <span class="emphasis"><em>updates</em></span> — see
        <a href="mysqlqb_statements.html#insert-on-duplicate" title="INSERT ... ON DUPLICATE KEY UPDATE Syntax"><code class="literal">INSERT ... ON DUPLICATE KEY UPDATE</code> Syntax</a>.
      </p><p>
        Note that unless the table has a <code class="literal">PRIMARY KEY</code>
        or <code class="literal">UNIQUE</code> index, using a
        <code class="literal">REPLACE</code> statement makes no sense. It becomes
        equivalent to <code class="literal">INSERT</code>, because there is no
        index to be used to determine whether a new row duplicates
        another.
      </p><p>
        Values for all columns are taken from the values specified in
        the <code class="literal">REPLACE</code> statement. Any missing columns
        are set to their default values, just as happens for
        <code class="literal">INSERT</code>. You cannot refer to values from the
        current row and use them in the new row. If you use an
        assignment such as <code class="literal">SET
        <em class="replaceable"><code>col_name</code></em> =
        <em class="replaceable"><code>col_name</code></em> + 1</code>, the reference
        to the column name on the right hand side is treated as
        <code class="literal">DEFAULT(<em class="replaceable"><code>col_name</code></em>)</code>,
        so the assignment is equivalent to <code class="literal">SET
        <em class="replaceable"><code>col_name</code></em> =
        DEFAULT(<em class="replaceable"><code>col_name</code></em>) + 1</code>.
      </p><p>
        To use <code class="literal">REPLACE</code>, you must have both the
        <code class="literal">INSERT</code> and <code class="literal">DELETE</code>
        privileges for the table.
      </p><p>
        The <code class="literal">REPLACE</code> statement returns a count to
        indicate the number of rows affected. This is the sum of the
        rows deleted and inserted. If the count is 1 for a single-row
        <code class="literal">REPLACE</code>, a row was inserted and no rows were
        deleted. If the count is greater than 1, one or more old rows
        were deleted before the new row was inserted. It is possible for
        a single row to replace more than one old row if the table
        contains multiple unique indexes and the new row duplicates
        values for different old rows in different unique indexes.
      </p><p>
        The affected-rows count makes it easy to determine whether
        <code class="literal">REPLACE</code> only added a row or whether it also
        replaced any rows: Check whether the count is 1 (added) or
        greater (replaced).
      </p><p>
        If you are using the C API, the affected-rows count can be
        obtained using the <code class="literal">mysql_affected_rows()</code>
        function.
      </p><p>
        Currently, you cannot replace into a table and select from the
        same table in a subquery.
      </p><p>
        MySQL uses the following algorithm for
        <code class="literal">REPLACE</code> (and <code class="literal">LOAD DATA ...
        REPLACE</code>):
      </p><div class="orderedlist"><ol type="1"><li><p>
            Try to insert the new row into the table
          </p></li><li><p>
            While the insertion fails because a duplicate-key error
            occurs for a primary key or unique index:
          </p><div class="orderedlist"><ol type="a"><li><p>
                Delete from the table the conflicting row that has the
                duplicate key value
              </p></li><li><p>
                Try again to insert the new row into the table
              </p></li></ol></div></li></ol></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="select"></a><code class="literal">SELECT</code> Syntax</h3></div></div></div><div class="toc"><dl><dt><span class="section"><a href="mysqlqb_statements.html#join"><code class="literal">JOIN</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#index-hints">Index Hint Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#union"><code class="literal">UNION</code> Syntax</a></span></dt></dl></div><a id="id2871800" class="indexterm"></a><pre class="programlisting">SELECT
    [ALL | DISTINCT | DISTINCTROW ]
      [HIGH_PRIORITY]
      [STRAIGHT_JOIN]
      [SQL_SMALL_RESULT] [SQL_BIG_RESULT] [SQL_BUFFER_RESULT]
      [SQL_CACHE | SQL_NO_CACHE] [SQL_CALC_FOUND_ROWS]
    <em class="replaceable"><code>select_expr</code></em>, ...
    [FROM <em class="replaceable"><code>table_references</code></em>
    [WHERE <em class="replaceable"><code>where_condition</code></em>]
    [GROUP BY {<em class="replaceable"><code>col_name</code></em> | <em class="replaceable"><code>expr</code></em> | <em class="replaceable"><code>position</code></em>}
      [ASC | DESC], ... [WITH ROLLUP]]
    [HAVING <em class="replaceable"><code>where_condition</code></em>]
    [ORDER BY {<em class="replaceable"><code>col_name</code></em> | <em class="replaceable"><code>expr</code></em> | <em class="replaceable"><code>position</code></em>}
      [ASC | DESC], ...]
    [LIMIT {[<em class="replaceable"><code>offset</code></em>,] <em class="replaceable"><code>row_count</code></em> | <em class="replaceable"><code>row_count</code></em> OFFSET <em class="replaceable"><code>offset</code></em>}]
    [PROCEDURE <em class="replaceable"><code>procedure_name</code></em>(<em class="replaceable"><code>argument_list</code></em>)]
    [INTO OUTFILE '<em class="replaceable"><code>file_name</code></em>' <em class="replaceable"><code>export_options</code></em>
      | INTO DUMPFILE '<em class="replaceable"><code>file_name</code></em>'
      | INTO <em class="replaceable"><code>var_name</code></em> [, <em class="replaceable"><code>var_name</code></em>]]
    [FOR UPDATE | LOCK IN SHARE MODE]]
</pre><p>
        <code class="literal">SELECT</code> is used to retrieve rows selected from
        one or more tables, and can include <code class="literal">UNION</code>
        statements and subqueries. See <a href="mysqlqb_statements.html#union" title="UNION Syntax"><code class="literal">UNION</code> Syntax</a>, and
        <a href="mysqlqb_statements.html#subqueries" title="Subquery Syntax">Subquery Syntax</a>.
      </p><p>
        The most commonly used clauses of <code class="literal">SELECT</code>
        statements are these:
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            Each <em class="replaceable"><code>select_expr</code></em> indicates a
            column that you want to retrieve. There must be at least one
            <em class="replaceable"><code>select_expr</code></em>.
          </p></li><li><p>
            <em class="replaceable"><code>table_references</code></em> indicates the
            table or tables from which to retrieve rows. Its syntax is
            described in <a href="mysqlqb_statements.html#join" title="JOIN Syntax"><code class="literal">JOIN</code> Syntax</a>.
          </p></li><li><p>
            The <code class="literal">WHERE</code> clause, if given, indicates the
            condition or conditions that rows must satisfy to be
            selected. <em class="replaceable"><code>where_condition</code></em> is an
            expression that evaluates to true for each row to be
            selected. The statement selects all rows if there is no
            <code class="literal">WHERE</code> clause.
          </p><p>
            In the <code class="literal">WHERE</code> clause, you can use any of
            the functions and operators that MySQL supports, except for
            aggregate (summary) functions. See
            <a href="mysqlqb_functions.html" title="Functions and Operators"><i>Functions and Operators</i></a>.
          </p></li></ul></div><p>
        <code class="literal">SELECT</code> can also be used to retrieve rows
        computed without reference to any table.
      </p><p>
        For example:
      </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SELECT 1 + 1;</code></strong>
        -&gt; 2
</pre><p>
        <a id="id2872066" class="indexterm"></a>

        You are allowed to specify <code class="literal">DUAL</code> as a dummy
        table name in situations where no tables are referenced:
      </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SELECT 1 + 1 FROM DUAL;</code></strong>
        -&gt; 2
</pre><p>
        <code class="literal">DUAL</code> is purely for the convenience of people
        who require that all <code class="literal">SELECT</code> statements should
        have <code class="literal">FROM</code> and possibly other clauses. MySQL
        may ignore the clauses. MySQL does not require <code class="literal">FROM
        DUAL</code> if no tables are referenced.
      </p><p>
        In general, clauses used must be given in exactly the order
        shown in the syntax description. For example, a
        <code class="literal">HAVING</code> clause must come after any
        <code class="literal">GROUP BY</code> clause and before any <code class="literal">ORDER
        BY</code> clause. The exception is that the
        <code class="literal">INTO</code> clause can appear either as shown in the
        syntax description or immediately preceding the
        <code class="literal">FROM</code> clause.
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            <a id="id2872149" class="indexterm"></a>

            <a id="id2872159" class="indexterm"></a>

            A <em class="replaceable"><code>select_expr</code></em> can be given an
            alias using <code class="literal">AS
            <em class="replaceable"><code>alias_name</code></em></code>. The alias
            is used as the expression's column name and can be used in
            <code class="literal">GROUP BY</code>, <code class="literal">ORDER BY</code>, or
            <code class="literal">HAVING</code> clauses. For example:
          </p><pre class="programlisting">SELECT CONCAT(last_name,', ',first_name) AS full_name
  FROM mytable ORDER BY full_name;
</pre><p>
            The <code class="literal">AS</code> keyword is optional when aliasing
            a <em class="replaceable"><code>select_expr</code></em>. The preceding
            example could have been written like this:
          </p><pre class="programlisting">SELECT CONCAT(last_name,', ',first_name) full_name
  FROM mytable ORDER BY full_name;
</pre><p>
            However, because the <code class="literal">AS</code> is optional, a
            subtle problem can occur if you forget the comma between two
            <em class="replaceable"><code>select_expr</code></em> expressions: MySQL
            interprets the second as an alias name. For example, in the
            following statement, <code class="literal">columnb</code> is treated
            as an alias name:
          </p><pre class="programlisting">SELECT columna columnb FROM mytable;
</pre><p>
            For this reason, it is good practice to be in the habit of
            using <code class="literal">AS</code> explicitly when specifying
            column aliases.
          </p></li><li><p>
            It is not allowable to use a column alias in a
            <code class="literal">WHERE</code> clause, because the column value
            might not yet be determined when the
            <code class="literal">WHERE</code> clause is executed. See
            <a href="http://dev.mysql.com/doc/refman/5.0/en/problems-with-alias.html" target="_top">Problems with Column Aliases</a>.
          </p></li><li><p>
            <a id="id2872275" class="indexterm"></a>

            <a id="id2872282" class="indexterm"></a>

            The <code class="literal">FROM
            <em class="replaceable"><code>table_references</code></em></code> clause
            indicates the table or tables from which to retrieve rows.
            If you name more than one table, you are performing a join.
            For information on join syntax, see <a href="mysqlqb_statements.html#join" title="JOIN Syntax"><code class="literal">JOIN</code> Syntax</a>.
            For each table specified, you can optionally specify an
            alias.
          </p><pre class="programlisting"><em class="replaceable"><code>tbl_name</code></em> [[AS] <em class="replaceable"><code>alias</code></em>] [<em class="replaceable"><code>index_hint</code></em>)]
</pre><a id="id2872318" class="indexterm"></a><a id="id2872325" class="indexterm"></a><p>
            The use of index hints provides the optimizer with
            information about how to choose indexes during query
            processing. For a description of the syntax for specifying
            these hints, see <a href="mysqlqb_statements.html#index-hints" title="Index Hint Syntax">Index Hint Syntax</a>.
          </p><p>
            You can use <code class="literal">SET
            max_seeks_for_key=<em class="replaceable"><code>value</code></em></code>
            as an alternative way to force MySQL to prefer key scans
            instead of table scans. See
            <a href="http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html" target="_top">System Variables</a>.
          </p></li><li><p>
            You can refer to a table within the default database as
            <em class="replaceable"><code>tbl_name</code></em>, or as
            <em class="replaceable"><code>db_name</code></em>.<em class="replaceable"><code>tbl_name</code></em>
            to specify a database explicitly. You can refer to a column
            as <em class="replaceable"><code>col_name</code></em>,
            <em class="replaceable"><code>tbl_name</code></em>.<em class="replaceable"><code>col_name</code></em>,
            or
            <em class="replaceable"><code>db_name</code></em>.<em class="replaceable"><code>tbl_name</code></em>.<em class="replaceable"><code>col_name</code></em>.
            You need not specify a <em class="replaceable"><code>tbl_name</code></em>
            or
            <em class="replaceable"><code>db_name</code></em>.<em class="replaceable"><code>tbl_name</code></em>
            prefix for a column reference unless the reference would be
            ambiguous. See <a href="http://dev.mysql.com/doc/refman/5.0/en/identifier-qualifiers.html" target="_top">Identifier Qualifiers</a>, for
            examples of ambiguity that require the more explicit column
            reference forms.
          </p></li><li><p>
            <a id="id2872437" class="indexterm"></a>

            <a id="id2872447" class="indexterm"></a>

            A table reference can be aliased using
            <code class="literal"><em class="replaceable"><code>tbl_name</code></em> AS
            <em class="replaceable"><code>alias_name</code></em></code> or
            <em class="replaceable"><code>tbl_name alias_name</code></em>:
          </p><pre class="programlisting">SELECT t1.name, t2.salary FROM employee AS t1, info AS t2
  WHERE t1.name = t2.name;

SELECT t1.name, t2.salary FROM employee t1, info t2
  WHERE t1.name = t2.name;
</pre></li><li><p>
            <a id="id2872480" class="indexterm"></a>

            Columns selected for output can be referred to in
            <code class="literal">ORDER BY</code> and <code class="literal">GROUP BY</code>
            clauses using column names, column aliases, or column
            positions. Column positions are integers and begin with 1:
          </p><pre class="programlisting">SELECT college, region, seed FROM tournament
  ORDER BY region, seed;

SELECT college, region AS r, seed AS s FROM tournament
  ORDER BY r, s;

SELECT college, region, seed FROM tournament
  ORDER BY 2, 3;
</pre><p>
            To sort in reverse order, add the <code class="literal">DESC</code>
            (descending) keyword to the name of the column in the
            <code class="literal">ORDER BY</code> clause that you are sorting by.
            The default is ascending order; this can be specified
            explicitly using the <code class="literal">ASC</code> keyword.
          </p><p>
            Use of column positions is deprecated because the syntax has
            been removed from the SQL standard.
          </p></li><li><p>
            <a id="id2872536" class="indexterm"></a>

            <a id="id2872546" class="indexterm"></a>

            If you use <code class="literal">GROUP BY</code>, output rows are
            sorted according to the <code class="literal">GROUP BY</code> columns
            as if you had an <code class="literal">ORDER BY</code> for the same
            columns. To avoid the overhead of sorting that
            <code class="literal">GROUP BY</code> produces, add <code class="literal">ORDER BY
            NULL</code>:
          </p><pre class="programlisting">SELECT a, COUNT(b) FROM test_table GROUP BY a ORDER BY NULL;
</pre></li><li><p>
            <a id="id2872589" class="indexterm"></a>

            MySQL extends the <code class="literal">GROUP BY</code> clause so that
            you can also specify <code class="literal">ASC</code> and
            <code class="literal">DESC</code> after columns named in the clause:
          </p><pre class="programlisting">SELECT a, COUNT(b) FROM test_table GROUP BY a DESC;
</pre></li><li><p>
            MySQL extends the use of <code class="literal">GROUP BY</code> to
            allow selecting fields that are not mentioned in the
            <code class="literal">GROUP BY</code> clause. If you are not getting
            the results that you expect from your query, please read the
            description of <code class="literal">GROUP BY</code> found in
            <a href="mysqlqb_functions.html#group-by-functions-and-modifiers" title="Functions and Modifiers for Use with GROUP BY Clauses">Functions and Modifiers for Use with <code class="literal">GROUP BY</code> Clauses</a>.
          </p></li><li><p>
            <code class="literal">GROUP BY</code> allows a <code class="literal">WITH
            ROLLUP</code> modifier. See
            <a href="mysqlqb_functions.html#group-by-modifiers" title="GROUP BY Modifiers"><code class="literal">GROUP BY</code> Modifiers</a>.
          </p></li><li><p>
            <a id="id2872671" class="indexterm"></a>

            The <code class="literal">HAVING</code> clause is applied nearly last,
            just before items are sent to the client, with no
            optimization. (<code class="literal">LIMIT</code> is applied after
            <code class="literal">HAVING</code>.)
          </p><p>
            A <code class="literal">HAVING</code> clause can refer to any column
            or alias named in a <em class="replaceable"><code>select_expr</code></em>
            in the <code class="literal">SELECT</code> list or in outer
            subqueries, and to aggregate functions. However, the SQL
            standard requires that <code class="literal">HAVING</code> must
            reference only columns in the <code class="literal">GROUP BY</code>
            clause or columns used in aggregate functions. To
            accommodate both standard SQL and the MySQL-specific
            behavior of being able to refer columns in the
            <code class="literal">SELECT</code> list, MySQL 5.0.2 and up allows
            <code class="literal">HAVING</code> to refer to columns in the
            <code class="literal">SELECT</code> list, columns in the
            <code class="literal">GROUP BY</code> clause, columns in outer
            subqueries, and to aggregate functions.
          </p><p>
            For example, the following statement works in MySQL 5.0.2
            but produces an error for earlier versions:
          </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SELECT COUNT(*) FROM t GROUP BY col1 HAVING col1 = 2;</code></strong>
</pre><p>
            If the <code class="literal">HAVING</code> clause refers to a column
            that is ambiguous, a warning occurs. In the following
            statement, <code class="literal">col2</code> is ambiguous because it
            is used as both an alias and a column name:
          </p><pre class="programlisting">SELECT COUNT(col1) AS col2 FROM t GROUP BY col2 HAVING col2 = 2;
</pre><p>
            Preference is given to standard SQL behavior, so if a
            <code class="literal">HAVING</code> column name is used both in
            <code class="literal">GROUP BY</code> and as an aliased column in the
            output column list, preference is given to the column in the
            <code class="literal">GROUP BY</code> column.
          </p></li><li><p>
            Do not use <code class="literal">HAVING</code> for items that should
            be in the <code class="literal">WHERE</code> clause. For example, do
            not write the following:
          </p><pre class="programlisting">SELECT <em class="replaceable"><code>col_name</code></em> FROM <em class="replaceable"><code>tbl_name</code></em> HAVING <em class="replaceable"><code>col_name</code></em> &gt; 0;
</pre><p>
            Write this instead:
          </p><pre class="programlisting">SELECT <em class="replaceable"><code>col_name</code></em> FROM <em class="replaceable"><code>tbl_name</code></em> WHERE <em class="replaceable"><code>col_name</code></em> &gt; 0;
</pre></li><li><p>
            The <code class="literal">HAVING</code> clause can refer to aggregate
            functions, which the <code class="literal">WHERE</code> clause cannot:
          </p><pre class="programlisting">SELECT user, MAX(salary) FROM users
  GROUP BY user HAVING MAX(salary) &gt; 10;
</pre><p>
            (This did not work in some older versions of MySQL.)
          </p></li><li><p>
            MySQL allows duplicate column names. That is, there can be
            more than one <em class="replaceable"><code>select_expr</code></em> with
            the same name. This is an extension to standard SQL. Because
            MySQL also allows <code class="literal">GROUP BY</code> and
            <code class="literal">HAVING</code> to refer to
            <em class="replaceable"><code>select_expr</code></em> values, this can
            result in an ambiguity:
          </p><pre class="programlisting">SELECT 12 AS a, a FROM t GROUP BY a;
</pre><p>
            In that statement, both columns have the name
            <code class="literal">a</code>. To ensure that the correct column is
            used for grouping, use different names for each
            <em class="replaceable"><code>select_expr</code></em>.
          </p></li><li><p>
            MySQL resolves unqualified column or alias references in
            <code class="literal">ORDER BY</code> clauses by searching in the
            <em class="replaceable"><code>select_expr</code></em> values, then in the
            columns of the tables in the <code class="literal">FROM</code> clause.
            For <code class="literal">GROUP BY</code> or <code class="literal">HAVING</code>
            clauses, it searches the <code class="literal">FROM</code> clause
            before searching in the
            <em class="replaceable"><code>select_expr</code></em> values. (For
            <code class="literal">GROUP BY</code> and <code class="literal">HAVING</code>,
            this differs from the pre-MySQL 5.0 behavior that used the
            same rules as for <code class="literal">ORDER BY</code>.)
          </p></li><li><p>
            <a id="id2872966" class="indexterm"></a>

            The <code class="literal">LIMIT</code> clause can be used to constrain
            the number of rows returned by the <code class="literal">SELECT</code>
            statement. <code class="literal">LIMIT</code> takes one or two numeric
            arguments, which must both be non-negative integer constants
            (except when using prepared statements).
          </p><p>
            With two arguments, the first argument specifies the offset
            of the first row to return, and the second specifies the
            maximum number of rows to return. The offset of the initial
            row is 0 (not 1):
          </p><pre class="programlisting">SELECT * FROM tbl LIMIT 5,10;  # Retrieve rows 6-15
</pre><p>
            To retrieve all rows from a certain offset up to the end of
            the result set, you can use some large number for the second
            parameter. This statement retrieves all rows from the 96th
            row to the last:
          </p><pre class="programlisting">SELECT * FROM tbl LIMIT 95,18446744073709551615;
</pre><p>
            With one argument, the value specifies the number of rows to
            return from the beginning of the result set:
          </p><pre class="programlisting">SELECT * FROM tbl LIMIT 5;     # Retrieve first 5 rows
</pre><p>
            In other words, <code class="literal">LIMIT
            <em class="replaceable"><code>row_count</code></em></code> is equivalent
            to <code class="literal">LIMIT 0,
            <em class="replaceable"><code>row_count</code></em></code>.
          </p><p>
            For prepared statements, you can use placeholders (supported
            as of MySQL version 5.0.7). The following statements will
            return one row from the <code class="literal">tbl</code> table:
          </p><pre class="programlisting">SET @a=1;
PREPARE STMT FROM 'SELECT * FROM tbl LIMIT ?';
EXECUTE STMT USING @a;
</pre><p>
            The following statements will return the second to sixth row
            from the <code class="literal">tbl</code> table:
          </p><pre class="programlisting">SET @skip=1; SET @numrows=5;
PREPARE STMT FROM 'SELECT * FROM tbl LIMIT ?, ?';
EXECUTE STMT USING @skip, @numrows;
</pre><p>
            For compatibility with PostgreSQL, MySQL also supports the
            <code class="literal">LIMIT <em class="replaceable"><code>row_count</code></em> OFFSET
            <em class="replaceable"><code>offset</code></em></code> syntax.
          </p></li><li><p>
            <a id="id2873088" class="indexterm"></a>

            <a id="id2873095" class="indexterm"></a>

            The <code class="literal">SELECT ... INTO OUTFILE
            '<em class="replaceable"><code>file_name</code></em>'</code> form of
            <code class="literal">SELECT</code> writes the selected rows to a
            file. The file is created on the server host, so you must
            have the <code class="literal">FILE</code> privilege to use this
            syntax. <em class="replaceable"><code>file_name</code></em> cannot be an
            existing file, which among other things prevents files such
            as <code class="filename">/etc/passwd</code> and database tables from
            being destroyed. As of MySQL 5.0.19, the
            <code class="literal">character_set_filesystem</code> system variable
            controls the interpretation of the filename.
          </p><p>
            The <code class="literal">SELECT ... INTO OUTFILE</code> statement is
            intended primarily to let you very quickly dump a table to a
            text file on the server machine. If you want to create the
            resulting file on some client host other than the server
            host, you cannot use <code class="literal">SELECT ... INTO
            OUTFILE</code>. In that case, you should instead use a
            command such as <code class="literal">mysql -e "SELECT ..." &gt;
            <em class="replaceable"><code>file_name</code></em></code> to generate
            the file on the client host.
          </p><p>
            <code class="literal">SELECT ... INTO OUTFILE</code> is the complement
            of <code class="literal">LOAD DATA INFILE</code>; the syntax for the
            <em class="replaceable"><code>export_options</code></em> part of the
            statement consists of the same <code class="literal">FIELDS</code> and
            <code class="literal">LINES</code> clauses that are used with the
            <code class="literal">LOAD DATA INFILE</code> statement. See
            <a href="mysqlqb_statements.html#load-data" title="LOAD DATA INFILE Syntax"><code class="literal">LOAD DATA INFILE</code> Syntax</a>.
          </p><p>
            <code class="literal">FIELDS ESCAPED BY</code> controls how to write
            special characters. If the <code class="literal">FIELDS ESCAPED
            BY</code> character is not empty, it is used as a prefix
            that precedes following characters on output:
          </p><div class="itemizedlist"><ul type="circle"><li><p>
                The <code class="literal">FIELDS ESCAPED BY</code> character
              </p></li><li><p>
                The <code class="literal">FIELDS [OPTIONALLY] ENCLOSED BY</code>
                character
              </p></li><li><p>
                The first character of the <code class="literal">FIELDS TERMINATED
                BY</code> and <code class="literal">LINES TERMINATED BY</code>
                values
              </p></li><li><p>
                ASCII <code class="literal">NUL</code> (the zero-valued byte; what
                is actually written following the escape character is
                ASCII ‘<code class="literal">0</code>’, not a
                zero-valued byte)
              </p></li></ul></div><p>
            The <code class="literal">FIELDS TERMINATED BY</code>,
            <code class="literal">ENCLOSED BY</code>, <code class="literal">ESCAPED
            BY</code>, or <code class="literal">LINES TERMINATED BY</code>
            characters <span class="emphasis"><em>must</em></span> be escaped so that you
            can read the file back in reliably. ASCII
            <code class="literal">NUL</code> is escaped to make it easier to view
            with some pagers.
          </p><p>
            The resulting file does not have to conform to SQL syntax,
            so nothing else need be escaped.
          </p><p>
            If the <code class="literal">FIELDS ESCAPED BY</code> character is
            empty, no characters are escaped and <code class="literal">NULL</code>
            is output as <code class="literal">NULL</code>, not
            <code class="literal">\N</code>. It is probably not a good idea to
            specify an empty escape character, particularly if field
            values in your data contain any of the characters in the
            list just given.
          </p><a id="id2873328" class="indexterm"></a><a id="id2873335" class="indexterm"></a><p>
            Here is an example that produces a file in the
            comma-separated values (CSV) format used by many programs:
          </p><pre class="programlisting">SELECT a,b,a+b INTO OUTFILE '/tmp/result.txt'
  FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
  LINES TERMINATED BY '\n'
  FROM test_table;
</pre></li><li><p>
            <a id="id2873359" class="indexterm"></a>

            If you use <code class="literal">INTO DUMPFILE</code> instead of
            <code class="literal">INTO OUTFILE</code>, MySQL writes only one row
            into the file, without any column or line termination and
            without performing any escape processing. This is useful if
            you want to store a <code class="literal">BLOB</code> value in a file.
          </p></li><li><p>
            The <code class="literal">INTO</code> clause can name a list of one or
            more variables, which can be user-defined variables, or
            parameters or local variables within a stored function or
            procedure body. The selected values are assigned to the
            variables. The number of variables must match the number of
            columns.
          </p><p>
            Within a stored routine, the variables can be routine
            parameters or local variables. See
            <a href="http://dev.mysql.com/doc/refman/5.0/en/select-into-statement.html" target="_top"><code class="literal">SELECT ... INTO</code> Statement</a>.
          </p></li><li><p>
            <span class="bold"><strong>Note</strong></span>: Any file created by
            <code class="literal">INTO OUTFILE</code> or <code class="literal">INTO
            DUMPFILE</code> is writable by all users on the server
            host. The reason for this is that the MySQL server cannot
            create a file that is owned by anyone other than the user
            under whose account it is running. (You should
            <span class="emphasis"><em>never</em></span> run <span><strong class="command">mysqld</strong></span> as
            <code class="literal">root</code> for this and other reasons.) The
            file thus must be world-writable so that you can manipulate
            its contents.
          </p></li><li><p>
            The <code class="literal">SELECT</code> syntax description at the
            beginning this section shows the <code class="literal">INTO</code>
            clause near the end of the statement. It is also possible to
            use <code class="literal">INTO OUTFILE</code> or <code class="literal">INTO
            DUMPFILE</code> immediately preceding the
            <code class="literal">FROM</code> clause.
          </p></li><li><p>
            <a id="id2873486" class="indexterm"></a>

            A <code class="literal">PROCEDURE</code> clause names a procedure that
            should process the data in the result set. For an example,
            see <a href="http://dev.mysql.com/doc/refman/5.0/en/procedure-analyse.html" target="_top">Procedure Analyse</a>.
          </p></li><li><p>
            <a id="id2873512" class="indexterm"></a>

            <a id="id2873519" class="indexterm"></a>

            If you use <code class="literal">FOR UPDATE</code> with a storage
            engine that uses page or row locks, rows examined by the
            query are write-locked until the end of the current
            transaction. Using <code class="literal">LOCK IN SHARE MODE</code>
            sets a shared lock that allows other transactions to read
            the examined rows but not to update or delete them. See
            <a href="http://dev.mysql.com/doc/refman/5.0/en/innodb-locking-reads.html" target="_top"><code class="literal">SELECT ... FOR UPDATE</code> and <code class="literal">SELECT ... LOCK IN  SHARE MODE</code> Locking Reads</a>.
          </p></li></ul></div><p>
        Following the <code class="literal">SELECT</code> keyword, you can use a
        number of options that affect the operation of the statement.
      </p><a id="id2873565" class="indexterm"></a><a id="id2873572" class="indexterm"></a><a id="id2873578" class="indexterm"></a><p>
        The <code class="literal">ALL</code>, <code class="literal">DISTINCT</code>, and
        <code class="literal">DISTINCTROW</code> options specify whether duplicate
        rows should be returned. If none of these options are given, the
        default is <code class="literal">ALL</code> (all matching rows are
        returned). <code class="literal">DISTINCT</code> and
        <code class="literal">DISTINCTROW</code> are synonyms and specify removal
        of duplicate rows from the result set.
      </p><p>
        <code class="literal">HIGH_PRIORITY</code>,
        <code class="literal">STRAIGHT_JOIN</code>, and options beginning with
        <code class="literal">SQL_</code> are MySQL extensions to standard SQL.
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            <a id="id2873637" class="indexterm"></a>

            <code class="literal">HIGH_PRIORITY</code> gives the
            <code class="literal">SELECT</code> higher priority than a statement
            that updates a table. You should use this only for queries
            that are very fast and must be done at once. A
            <code class="literal">SELECT HIGH_PRIORITY</code> query that is issued
            while the table is locked for reading runs even if there is
            an update statement waiting for the table to be free.
          </p><p>
            <code class="literal">HIGH_PRIORITY</code> cannot be used with
            <code class="literal">SELECT</code> statements that are part of a
            <code class="literal">UNION</code>.
          </p></li><li><p>
            <a id="id2873683" class="indexterm"></a>

            <code class="literal">STRAIGHT_JOIN</code> forces the optimizer to
            join the tables in the order in which they are listed in the
            <code class="literal">FROM</code> clause. You can use this to speed up
            a query if the optimizer joins the tables in non-optimal
            order. See <a href="http://dev.mysql.com/doc/refman/5.0/en/explain.html" target="_top">Optimizing Queries with <code class="literal">EXPLAIN</code></a>.
            <code class="literal">STRAIGHT_JOIN</code> also can be used in the
            <em class="replaceable"><code>table_references</code></em> list. See
            <a href="mysqlqb_statements.html#join" title="JOIN Syntax"><code class="literal">JOIN</code> Syntax</a>.
          </p></li><li><p>
            <a id="id2873730" class="indexterm"></a>

            <code class="literal">SQL_BIG_RESULT</code> can be used with
            <code class="literal">GROUP BY</code> or <code class="literal">DISTINCT</code>
            to tell the optimizer that the result set has many rows. In
            this case, MySQL directly uses disk-based temporary tables
            if needed, and prefers sorting to using a temporary table
            with a key on the <code class="literal">GROUP BY</code> elements.
          </p></li><li><p>
            <a id="id2873763" class="indexterm"></a>

            <code class="literal">SQL_BUFFER_RESULT</code> forces the result to be
            put into a temporary table. This helps MySQL free the table
            locks early and helps in cases where it takes a long time to
            send the result set to the client.
          </p></li><li><p>
            <a id="id2873784" class="indexterm"></a>

            <code class="literal">SQL_SMALL_RESULT</code> can be used with
            <code class="literal">GROUP BY</code> or <code class="literal">DISTINCT</code>
            to tell the optimizer that the result set is small. In this
            case, MySQL uses fast temporary tables to store the
            resulting table instead of using sorting. This should not
            normally be needed.
          </p></li><li><p>
            <a id="id2873813" class="indexterm"></a>

            <code class="literal">SQL_CALC_FOUND_ROWS</code> tells MySQL to
            calculate how many rows there would be in the result set,
            disregarding any <code class="literal">LIMIT</code> clause. The number
            of rows can then be retrieved with <code class="literal">SELECT
            FOUND_ROWS()</code>. See
            <a href="mysqlqb_functions.html#information-functions" title="Information Functions">Information Functions</a>.
          </p></li><li><p>
            <a id="id2873846" class="indexterm"></a>

            <code class="literal">SQL_CACHE</code> tells MySQL to store the query
            result in the query cache if you are using a
            <code class="literal">query_cache_type</code> value of
            <code class="literal">2</code> or <code class="literal">DEMAND</code>. For a
            query that uses <code class="literal">UNION</code> or subqueries, this
            option effects any <code class="literal">SELECT</code> in the query.
            See <a href="http://dev.mysql.com/doc/refman/5.0/en/query-cache.html" target="_top">The MySQL Query Cache</a>.
          </p></li><li><p>
            <a id="id2873892" class="indexterm"></a>

            <code class="literal">SQL_NO_CACHE</code> tells MySQL not to store the
            query result in the query cache. See
            <a href="http://dev.mysql.com/doc/refman/5.0/en/query-cache.html" target="_top">The MySQL Query Cache</a>. For a query that uses
            <code class="literal">UNION</code> or subqueries, this option effects
            any <code class="literal">SELECT</code> in the query.
          </p></li></ul></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="join"></a><code class="literal">JOIN</code> Syntax</h4></div></div></div><a id="id2873933" class="indexterm"></a><a id="id2873940" class="indexterm"></a><a id="id2873947" class="indexterm"></a><a id="id2873953" class="indexterm"></a><a id="id2873960" class="indexterm"></a><a id="id2873967" class="indexterm"></a><a id="id2873974" class="indexterm"></a><a id="id2873980" class="indexterm"></a><a id="id2873987" class="indexterm"></a><a id="id2873994" class="indexterm"></a><a id="id2874001" class="indexterm"></a><a id="id2874008" class="indexterm"></a><a id="id2874014" class="indexterm"></a><p>
          MySQL supports the following <code class="literal">JOIN</code> syntaxes
          for the <em class="replaceable"><code>table_references</code></em> part of
          <code class="literal">SELECT</code> statements and multiple-table
          <code class="literal">DELETE</code> and <code class="literal">UPDATE</code>
          statements:
        </p><pre class="programlisting"><em class="replaceable"><code>table_references:</code></em>
    <em class="replaceable"><code>table_reference</code></em> [, <em class="replaceable"><code>table_reference</code></em>] ...

<em class="replaceable"><code>table_reference</code></em>:
    <em class="replaceable"><code>table_factor</code></em>
  | <em class="replaceable"><code>join_table</code></em>

<em class="replaceable"><code>table_factor</code></em>:
    <em class="replaceable"><code>tbl_name</code></em> [[AS] <em class="replaceable"><code>alias</code></em>] [<em class="replaceable"><code>index_hint</code></em>)]
  | ( <em class="replaceable"><code>table_references</code></em> )
  | { OJ <em class="replaceable"><code>table_reference</code></em> LEFT OUTER JOIN <em class="replaceable"><code>table_reference</code></em>
        ON <em class="replaceable"><code>conditional_expr</code></em> }

<em class="replaceable"><code>join_table</code></em>:
    <em class="replaceable"><code>table_reference</code></em> [INNER | CROSS] JOIN <em class="replaceable"><code>table_factor</code></em> [<em class="replaceable"><code>join_condition</code></em>]
  | <em class="replaceable"><code>table_reference</code></em> STRAIGHT_JOIN <em class="replaceable"><code>table_factor</code></em>
  | <em class="replaceable"><code>table_reference</code></em> STRAIGHT_JOIN <em class="replaceable"><code>table_factor</code></em> ON <em class="replaceable"><code>condition</code></em>
  | <em class="replaceable"><code>table_reference</code></em> LEFT [OUTER] JOIN <em class="replaceable"><code>table_reference</code></em> <em class="replaceable"><code>join_condition</code></em>
  | <em class="replaceable"><code>table_reference</code></em> NATURAL [LEFT [OUTER]] JOIN <em class="replaceable"><code>table_factor</code></em>
  | <em class="replaceable"><code>table_reference</code></em> RIGHT [OUTER] JOIN <em class="replaceable"><code>table_reference</code></em> <em class="replaceable"><code>join_condition</code></em>
  | <em class="replaceable"><code>table_reference</code></em> NATURAL [RIGHT [OUTER]] JOIN <em class="replaceable"><code>table_factor</code></em>

<em class="replaceable"><code>join_condition</code></em>:
    ON <em class="replaceable"><code>conditional_expr</code></em>
  | USING (<em class="replaceable"><code>column_list</code></em>)

<em class="replaceable"><code>index_hint</code></em>:
    USE {INDEX|KEY} [FOR JOIN] (<em class="replaceable"><code>index_list</code></em>)]
  | IGNORE {INDEX|KEY} [FOR JOIN] (<em class="replaceable"><code>index_list</code></em>)]
  | FORCE {INDEX|KEY} [FOR JOIN] (<em class="replaceable"><code>index_list</code></em>)]

<em class="replaceable"><code>index_list</code></em>:
    <em class="replaceable"><code>index_name</code></em> [, <em class="replaceable"><code>index_name</code></em>] ...
</pre><p>
          A table reference is also known as a join expression.
        </p><p>
          The syntax of <em class="replaceable"><code>table_factor</code></em> is
          extended in comparison with the SQL Standard. The latter
          accepts only <em class="replaceable"><code>table_reference</code></em>, not a
          list of them inside a pair of parentheses.
        </p><p>
          This is a conservative extension if we consider each comma in
          a list of <em class="replaceable"><code>table_reference</code></em> items as
          equivalent to an inner join. For example:
        </p><pre class="programlisting">SELECT * FROM t1 LEFT JOIN (t2, t3, t4)
                 ON (t2.a=t1.a AND t3.b=t1.b AND t4.c=t1.c)
</pre><p>
          is equivalent to:
        </p><pre class="programlisting">SELECT * FROM t1 LEFT JOIN (t2 CROSS JOIN t3 CROSS JOIN t4)
                 ON (t2.a=t1.a AND t3.b=t1.b AND t4.c=t1.c)
</pre><p>
          In MySQL, <code class="literal">CROSS JOIN</code> is a syntactic
          equivalent to <code class="literal">INNER JOIN</code> (they can replace
          each other). In standard SQL, they are not equivalent.
          <code class="literal">INNER JOIN</code> is used with an
          <code class="literal">ON</code> clause, <code class="literal">CROSS JOIN</code> is
          used otherwise.
        </p><p>
          In versions of MySQL prior to 5.0.1, parentheses in
          <em class="replaceable"><code>table_references</code></em> were just omitted
          and all join operations were grouped to the left. In general,
          parentheses can be ignored in join expressions containing only
          inner join operations. As of 5.0.1, nested joins are allowed
          (see <a href="http://dev.mysql.com/doc/refman/5.0/en/nested-joins.html" target="_top">Nested Join Optimization</a>).
        </p><p>
          Further changes in join processing were made in 5.0.12 to make
          MySQL more compliant with standard SQL. These charges are
          described later in this section.
        </p><p>
          Index hints can be specified to affect how the MySQL optimizer
          makes use of indexes. For more information, see
          <a href="mysqlqb_statements.html#index-hints" title="Index Hint Syntax">Index Hint Syntax</a>.
        </p><p>
          The following list describes general factors to take into
          account when writing joins.
        </p><div class="itemizedlist"><ul type="disc"><li><p>
              A table reference can be aliased using
              <code class="literal"><em class="replaceable"><code>tbl_name</code></em> AS
              <em class="replaceable"><code>alias_name</code></em></code> or
              <em class="replaceable"><code>tbl_name alias_name</code></em>:
            </p><pre class="programlisting">SELECT t1.name, t2.salary
  FROM employee AS t1 INNER JOIN info AS t2 ON t1.name = t2.name;

SELECT t1.name, t2.salary
  FROM employee t1 INNER JOIN info t2 ON t1.name = t2.name;
</pre></li><li><p>
              <code class="literal">INNER JOIN</code> and <code class="literal">,</code>
              (comma) are semantically equivalent in the absence of a
              join condition: both produce a Cartesian product between
              the specified tables (that is, each and every row in the
              first table is joined to each and every row in the second
              table).
            </p><p>
              However, the precedence of the comma operator is less than
              of <code class="literal">INNER JOIN</code>, <code class="literal">CROSS
              JOIN</code>, <code class="literal">LEFT JOIN</code>, and so on.
              If you mix comma joins with the other join types when
              there is a join condition, an error of the form
              <code class="literal">Unknown column
              '<em class="replaceable"><code>col_name</code></em>' in 'on
              clause'</code> may occur. Information about dealing
              with this problem is given later in this section.
            </p></li><li><p>
              The <code class="literal">ON</code> conditional is any conditional
              expression of the form that can be used in a
              <code class="literal">WHERE</code> clause. Generally, you should use
              the <code class="literal">ON</code> clause for conditions that
              specify how to join tables, and the
              <code class="literal">WHERE</code> clause to restrict which rows you
              want in the result set.
            </p></li><li><p>
              If there is no matching row for the right table in the
              <code class="literal">ON</code> or <code class="literal">USING</code> part in
              a <code class="literal">LEFT JOIN</code>, a row with all columns set
              to <code class="literal">NULL</code> is used for the right table.
              You can use this fact to find rows in a table that have no
              counterpart in another table:
            </p><pre class="programlisting">SELECT table1.* FROM table1
  LEFT JOIN table2 ON table1.id=table2.id
  WHERE table2.id IS NULL;
</pre><p>
              This example finds all rows in <code class="literal">table1</code>
              with an <code class="literal">id</code> value that is not present in
              <code class="literal">table2</code> (that is, all rows in
              <code class="literal">table1</code> with no corresponding row in
              <code class="literal">table2</code>). This assumes that
              <code class="literal">table2.id</code> is declared <code class="literal">NOT
              NULL</code>. See
              <a href="http://dev.mysql.com/doc/refman/5.0/en/left-join-optimization.html" target="_top"><code class="literal">LEFT JOIN</code> and <code class="literal">RIGHT JOIN</code>  Optimization</a>.
            </p></li><li><p>
              The
              <code class="literal">USING(<em class="replaceable"><code>column_list</code></em>)</code>
              clause names a list of columns that must exist in both
              tables. If tables <code class="literal">a</code> and
              <code class="literal">b</code> both contain columns
              <code class="literal">c1</code>, <code class="literal">c2</code>, and
              <code class="literal">c3</code>, the following join compares
              corresponding columns from the two tables:
            </p><pre class="programlisting">a LEFT JOIN b USING (c1,c2,c3)
</pre></li><li><p>
              The <code class="literal">NATURAL [LEFT] JOIN</code> of two tables
              is defined to be semantically equivalent to an
              <code class="literal">INNER JOIN</code> or a <code class="literal">LEFT
              JOIN</code> with a <code class="literal">USING</code> clause that
              names all columns that exist in both tables.
            </p></li><li><p>
              <code class="literal">RIGHT JOIN</code> works analogously to
              <code class="literal">LEFT JOIN</code>. To keep code portable across
              databases, it is recommended that you use <code class="literal">LEFT
              JOIN</code> instead of <code class="literal">RIGHT JOIN</code>.
            </p></li><li><p>
              <a id="id2874624" class="indexterm"></a>

              <a id="id2874630" class="indexterm"></a>

              The <code class="literal">{ OJ ... LEFT OUTER JOIN ...}</code>
              syntax shown in the join syntax description exists only
              for compatibility with ODBC. The curly braces in the
              syntax should be written literally; they are not
              metasyntax as used elsewhere in syntax descriptions.
            </p></li><li><p>
              <code class="literal">STRAIGHT_JOIN</code> is identical to
              <code class="literal">JOIN</code>, except that the left table is
              always read before the right table. This can be used for
              those (few) cases for which the join optimizer puts the
              tables in the wrong order.
            </p></li></ul></div><p>
          Some join examples:
        </p><pre class="programlisting">SELECT * FROM table1, table2;

SELECT * FROM table1 INNER JOIN table2 ON table1.id=table2.id;

SELECT * FROM table1 LEFT JOIN table2 ON table1.id=table2.id;

SELECT * FROM table1 LEFT JOIN table2 USING (id);

SELECT * FROM table1 LEFT JOIN table2 ON table1.id=table2.id
  LEFT JOIN table3 ON table2.id=table3.id;
</pre><p>
          <span class="bold"><strong>Join Processing Changes in MySQL
          5.0.12</strong></span>
        </p><p>
          Beginning with MySQL 5.0.12, natural joins and joins with
          <code class="literal">USING</code>, including outer join variants, are
          processed according to the SQL:2003 standard. The goal was to
          align the syntax and semantics of MySQL with respect to
          <code class="literal">NATURAL JOIN</code> and <code class="literal">JOIN ...
          USING</code> according to SQL:2003. However, these changes
          in join processing can result in different output columns for
          some joins. Also, some queries that appeared to work correctly
          in older versions must be rewritten to comply with the
          standard.
        </p><p>
          These changes have five main aspects:
        </p><div class="itemizedlist"><ul type="disc"><li><p>
              The way that MySQL determines the result columns of
              <code class="literal">NATURAL</code> or <code class="literal">USING</code>
              join operations (and thus the result of the entire
              <code class="literal">FROM</code> clause).
            </p></li><li><p>
              Expansion of <code class="literal">SELECT *</code> and
              <code class="literal">SELECT
              <em class="replaceable"><code>tbl_name</code></em>.*</code> into a
              list of selected columns.
            </p></li><li><p>
              Resolution of column names in <code class="literal">NATURAL</code>
              or <code class="literal">USING</code> joins.
            </p></li><li><p>
              Transformation of <code class="literal">NATURAL</code> or
              <code class="literal">USING</code> joins into <code class="literal">JOIN ...
              ON</code>.
            </p></li><li><p>
              Resolution of column names in the <code class="literal">ON</code>
              condition of a <code class="literal">JOIN ... ON</code>.
            </p></li></ul></div><p>
          The following list provides more detail about several effects
          of the 5.0.12 change in join processing. The term
          “<span class="quote">previously</span>” means “<span class="quote">prior to MySQL
          5.0.12.</span>”
        </p><div class="itemizedlist"><ul type="disc"><li><p>
              The columns of a <code class="literal">NATURAL</code> join or a
              <code class="literal">USING</code> join may be different from
              previously. Specifically, redundant output columns no
              longer appear, and the order of columns for
              <code class="literal">SELECT *</code> expansion may be different
              from before.
            </p><p>
              Consider this set of statements:
            </p><pre class="programlisting">CREATE TABLE t1 (i INT, j INT);
CREATE TABLE t2 (k INT, j INT);
INSERT INTO t1 VALUES(1,1);
INSERT INTO t2 VALUES(1,1);
SELECT * FROM t1 NATURAL JOIN t2;
SELECT * FROM t1 JOIN t2 USING (j);
</pre><p>
              Previously, the statements produced this output:
            </p><pre class="programlisting">+------+------+------+------+
| i    | j    | k    | j    |
+------+------+------+------+
|    1 |    1 |    1 |    1 |
+------+------+------+------+
+------+------+------+------+
| i    | j    | k    | j    |
+------+------+------+------+
|    1 |    1 |    1 |    1 |
+------+------+------+------+
</pre><p>
              In the first <code class="literal">SELECT</code> statement, column
              <code class="literal">j</code> appears in both tables and thus
              becomes a join column, so, according to standard SQL, it
              should appear only once in the output, not twice.
              Similarly, in the second SELECT statement, column
              <code class="literal">j</code> is named in the
              <code class="literal">USING</code> clause and should appear only
              once in the output, not twice. But in both cases, the
              redundant column is not eliminated. Also, the order of the
              columns is not correct according to standard SQL.
            </p><p>
              Now the statements produce this output:
            </p><pre class="programlisting">+------+------+------+
| j    | i    | k    |
+------+------+------+
|    1 |    1 |    1 |
+------+------+------+
+------+------+------+
| j    | i    | k    |
+------+------+------+
|    1 |    1 |    1 |
+------+------+------+
</pre><p>
              The redundant column is eliminated and the column order is
              correct according to standard SQL:
            </p><div class="itemizedlist"><ul type="circle"><li><p>
                  First, coalesced common columns of the two joined
                  tables, in the order in which they occur in the first
                  table
                </p></li><li><p>
                  Second, columns unique to the first table, in order in
                  which they occur in that table
                </p></li><li><p>
                  Third, columns unique to the second table, in order in
                  which they occur in that table
                </p></li></ul></div><p>
              The single result column that replaces two common columns
              is defined via the coalesce operation. That is, for two
              <code class="literal">t1.a</code> and <code class="literal">t2.a</code> the
              resulting single join column <code class="literal">a</code> is
              defined as <code class="literal">a = COALESCE(t1.a, t2.a)</code>,
              where:
            </p><pre class="programlisting">COALESCE(x, y) = (CASE WHEN V1 IS NOT NULL THEN V1 ELSE V2 END)
</pre><p>
              If the join operation is any other join, the result
              columns of the join consists of the concatenation of all
              columns of the joined tables. This is the same as
              previously.
            </p><p>
              A consequence of the definition of coalesced columns is
              that, for outer joins, the coalesced column contains the
              value of the non-<code class="literal">NULL</code> column if one of
              the two columns is always <code class="literal">NULL</code>. If
              neither or both columns are <code class="literal">NULL</code>, both
              common columns have the same value, so it doesn't matter
              which one is chosen as the value of the coalesced column.
              A simple way to interpret this is to consider that a
              coalesced column of an outer join is represented by the
              common column of the inner table of a
              <code class="literal">JOIN</code>. Suppose that the tables
              <code class="literal">t1(a,b)</code> and <code class="literal">t2(a,c)</code>
              have the following contents:
            </p><pre class="programlisting">t1    t2
----  ----
1 x   2 z
2 y   3 w
</pre><p>
              Then:
            </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SELECT * FROM t1 NATURAL LEFT JOIN t2;</code></strong>
+------+------+------+
| a    | b    | c    |
+------+------+------+
|    1 | x    | NULL |
|    2 | y    | z    |
+------+------+------+
</pre><p>
              Here column <code class="literal">a</code> contains the values of
              <code class="literal">t1.a</code>.
            </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SELECT * FROM t1 NATURAL RIGHT JOIN t2;</code></strong>
+------+------+------+
| a    | c    | b    |
+------+------+------+
|    2 | z    | y    |
|    3 | w    | NULL |
+------+------+------+
</pre><p>
              Here column <code class="literal">a</code> contains the values of
              <code class="literal">t2.a</code>.
            </p><p>
              Compare these results to the otherwise equivalent queries
              with <code class="literal">JOIN ... ON</code>:
            </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SELECT * FROM t1 LEFT JOIN t2 ON (t1.a = t2.a);</code></strong>
+------+------+------+------+
| a    | b    | a    | c    |
+------+------+------+------+
|    1 | x    | NULL | NULL |
|    2 | y    |    2 | z    |
+------+------+------+------+
</pre><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SELECT * FROM t1 RIGHT JOIN t2 ON (t1.a = t2.a);</code></strong>
+------+------+------+------+
| a    | b    | a    | c    |
+------+------+------+------+
|    2 | y    |    2 | z    |
| NULL | NULL |    3 | w    |
+------+------+------+------+
</pre></li><li><p>
              Previously, a <code class="literal">USING</code> clause could be
              rewritten as an <code class="literal">ON</code> clause that compares
              corresponding columns. For example, the following two
              clauses were semantically identical:
            </p><pre class="programlisting">a LEFT JOIN b USING (c1,c2,c3)
a LEFT JOIN b ON a.c1=b.c1 AND a.c2=b.c2 AND a.c3=b.c3
</pre><p>
              Now the two clauses no longer are quite the same:
            </p><div class="itemizedlist"><ul type="circle"><li><p>
                  With respect to determining which rows satisfy the
                  join condition, both joins remain semantically
                  identical.
                </p></li><li><p>
                  With respect to determining which columns to display
                  for <code class="literal">SELECT *</code> expansion, the two
                  joins are not semantically identical. The
                  <code class="literal">USING</code> join selects the coalesced
                  value of corresponding columns, whereas the
                  <code class="literal">ON</code> join selects all columns from
                  all tables. For the preceding <code class="literal">USING</code>
                  join, <code class="literal">SELECT *</code> selects these
                  values:
                </p><pre class="programlisting">COALESCE(a.c1,b.c1), COALESCE(a.c2,b.c2), COALESCE(a.c3,b.c3)
</pre><p>
                  For the <code class="literal">ON</code> join, <code class="literal">SELECT
                  *</code> selects these values:
                </p><pre class="programlisting">a.c1, a.c2, a.c3, b.c1, b.c2, b.c3
</pre><p>
                  With an inner join,
                  <code class="literal">COALESCE(a.c1,b.c1)</code> is the same as
                  either <code class="literal">a.c1</code> or
                  <code class="literal">b.c1</code> because both columns will have
                  the same value. With an outer join (such as
                  <code class="literal">LEFT JOIN</code>), one of the two columns
                  can be <code class="literal">NULL</code>. That column will be
                  omitted from the result.
                </p></li></ul></div></li><li><p>
              The evaluation of multi-way natural joins differs in a
              very important way that affects the result of
              <code class="literal">NATURAL</code> or <code class="literal">USING</code>
              joins and that can require query rewriting. Suppose that
              you have three tables <code class="literal">t1(a,b)</code>,
              <code class="literal">t2(c,b)</code>, and <code class="literal">t3(a,c)</code>
              that each have one row: <code class="literal">t1(1,2)</code>,
              <code class="literal">t2(10,2)</code>, and
              <code class="literal">t3(7,10)</code>. Suppose also that you have
              this <code class="literal">NATURAL JOIN</code> on the three tables:
            </p><pre class="programlisting">SELECT ... FROM t1 NATURAL JOIN t2 NATURAL JOIN t3;
</pre><p>
              Previously, the left operand of the second join was
              considered to be <code class="literal">t2</code>, whereas it should
              be the nested join <code class="literal">(t1 NATURAL JOIN
              t2)</code>. As a result, the columns of
              <code class="literal">t3</code> are checked for common columns only
              in <code class="literal">t2</code>, and, if <code class="literal">t3</code>
              has common columns with <code class="literal">t1</code>, these
              columns are not used as equi-join columns. Thus,
              previously, the preceding query was transformed to the
              following equi-join:
            </p><pre class="programlisting">SELECT ... FROM t1, t2, t3
  WHERE t1.b = t2.b AND t2.c = t3.c;
</pre><p>
              That join is missing one more equi-join predicate
              <code class="literal">(t1.a = t3.a)</code>. As a result, it produces
              one row, not the empty result that it should. The correct
              equivalent query is this:
            </p><pre class="programlisting">SELECT ... FROM t1, t2, t3
  WHERE t1.b = t2.b AND t2.c = t3.c AND t1.a = t3.a;
</pre><p>
              If you require the same query result in current versions
              of MySQL as in older versions, rewrite the natural join as
              the first equi-join.
            </p></li><li><p>
              Previously, the comma operator (<code class="literal">,</code>) and
              <code class="literal">JOIN</code> both had the same precedence, so
              the join expression <code class="literal">t1, t2 JOIN t3</code> was
              interpreted as <code class="literal">((t1, t2) JOIN t3)</code>. Now
              <code class="literal">JOIN</code> has higher precedence, so the
              expression is interpreted as <code class="literal">(t1, (t2 JOIN
              t3))</code>. This change affects statements that use an
              <code class="literal">ON</code> clause, because that clause can
              refer only to columns in the operands of the join, and the
              change in precedence changes interpretation of what those
              operands are.
            </p><p>
              Example:
            </p><pre class="programlisting">CREATE TABLE t1 (i1 INT, j1 INT);
CREATE TABLE t2 (i2 INT, j2 INT);
CREATE TABLE t3 (i3 INT, j3 INT);
INSERT INTO t1 VALUES(1,1);
INSERT INTO t2 VALUES(1,1);
INSERT INTO t3 VALUES(1,1);
SELECT * FROM t1, t2 JOIN t3 ON (t1.i1 = t3.i3);
</pre><p>
              Previously, the <code class="literal">SELECT</code> was legal due to
              the implicit grouping of <code class="literal">t1,t2</code> as
              <code class="literal">(t1,t2)</code>. Now the
              <code class="literal">JOIN</code> takes precedence, so the operands
              for the <code class="literal">ON</code> clause are
              <code class="literal">t2</code> and <code class="literal">t3</code>. Because
              <code class="literal">t1.i1</code> is not a column in either of the
              operands, the result is an <code class="literal">Unknown column 't1.i1'
              in 'on clause'</code> error. To allow the join to be
              processed, group the first two tables explicitly with
              parentheses so that the operands for the
              <code class="literal">ON</code> clause are
              <code class="literal">(t1,t2)</code> and <code class="literal">t3</code>:
            </p><pre class="programlisting">SELECT * FROM (t1, t2) JOIN t3 ON (t1.i1 = t3.i3);
</pre><p>
              Alternatively, avoid the use of the comma operator and use
              <code class="literal">JOIN</code> instead:
            </p><pre class="programlisting">SELECT * FROM t1 JOIN t2 JOIN t3 ON (t1.i1 = t3.i3);
</pre><p>
              This change also applies to statements that mix the comma
              operator with <code class="literal">INNER JOIN</code>,
              <code class="literal">CROSS JOIN</code>, <code class="literal">LEFT
              JOIN</code>, and <code class="literal">RIGHT JOIN</code>, all of
              which now have higher precedence than the comma operator.
            </p></li><li><p>
              Previously, the <code class="literal">ON</code> clause could refer
              to columns in tables named to its right. Now an
              <code class="literal">ON</code> clause can refer only to its
              operands.
            </p><p>
              Example:
            </p><pre class="programlisting">CREATE TABLE t1 (i1 INT);
CREATE TABLE t2 (i2 INT);
CREATE TABLE t3 (i3 INT);
SELECT * FROM t1 JOIN t2 ON (i1 = i3) JOIN t3;
</pre><p>
              Previously, the <code class="literal">SELECT</code> statement was
              legal. Now the statement fails with an <code class="literal">Unknown
              column 'i3' in 'on clause'</code> error because
              <code class="literal">i3</code> is a column in
              <code class="literal">t3</code>, which is not an operand of the
              <code class="literal">ON</code> clause. The statement should be
              rewritten as follows:
            </p><pre class="programlisting">SELECT * FROM t1 JOIN t2 JOIN t3 ON (i1 = i3);
</pre></li><li><p>
              Resolution of column names in <code class="literal">NATURAL</code>
              or <code class="literal">USING</code> joins is different than
              previously. For column names that are outside the
              <code class="literal">FROM</code> clause, MySQL now handles a
              superset of the queries compared to previously. That is,
              in cases when MySQL formerly issued an error that some
              column is ambiguous, the query now is handled correctly.
              This is due to the fact that MySQL now treats the common
              columns of <code class="literal">NATURAL</code> or
              <code class="literal">USING</code> joins as a single column, so when
              a query refers to such columns, the query compiler does
              not consider them as ambiguous.
            </p><p>
              Example:
            </p><pre class="programlisting">SELECT * FROM t1 NATURAL JOIN t2 WHERE b &gt; 1;
</pre><p>
              Previously, this query would produce an error
              <code class="literal">ERROR 1052 (23000): Column 'b' in where clause is
              ambiguous</code>. Now the query produces the correct
              result:
            </p><pre class="programlisting">+------+------+------+
| b    | c    | y    |
+------+------+------+
|    4 |    2 |    3 |
+------+------+------+
</pre><p>
              One extension of MySQL compared to the SQL:2003 standard
              is that MySQL allows you to qualify the common (coalesced)
              columns of <code class="literal">NATURAL</code> or
              <code class="literal">USING</code> joins (just as previously), while
              the standard disallows that.
            </p></li></ul></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="index-hints"></a>Index Hint Syntax</h4></div></div></div><a id="id2875619" class="indexterm"></a><a id="id2875626" class="indexterm"></a><a id="id2875636" class="indexterm"></a><a id="id2875643" class="indexterm"></a><a id="id2875650" class="indexterm"></a><a id="id2875656" class="indexterm"></a><a id="id2875663" class="indexterm"></a><a id="id2875670" class="indexterm"></a><p>
          You can provide hints to give the optimizer information about
          how to choose indexes during query processing.
          <a href="mysqlqb_statements.html#join" title="JOIN Syntax"><code class="literal">JOIN</code> Syntax</a>, describes the general syntax for
          specifying tables in a <code class="literal">SELECT</code> statement.
          The syntax for an individual able, including that for index
          hints, looks like this:
        </p><pre class="programlisting"><em class="replaceable"><code>tbl_name</code></em> [[AS] <em class="replaceable"><code>alias</code></em>] [<em class="replaceable"><code>index_hint</code></em>)]

<em class="replaceable"><code>index_hint</code></em>:
    USE {INDEX|KEY} [FOR JOIN] (<em class="replaceable"><code>index_list</code></em>)]
  | IGNORE {INDEX|KEY} [FOR JOIN] (<em class="replaceable"><code>index_list</code></em>)]
  | FORCE {INDEX|KEY} [FOR JOIN] (<em class="replaceable"><code>index_list</code></em>)]

<em class="replaceable"><code>index_list</code></em>:
    <em class="replaceable"><code>index_name</code></em> [, <em class="replaceable"><code>index_name</code></em>] ...
</pre><p>
          By specifying <code class="literal">USE INDEX
          (<em class="replaceable"><code>index_list</code></em>)</code>, you can
          tell MySQL to use only one of the named indexes to find rows
          in the table. The alternative syntax <code class="literal">IGNORE INDEX
          (<em class="replaceable"><code>index_list</code></em>)</code> can be used
          to tell MySQL to not use some particular index or indexes.
          These hints are useful if <code class="literal">EXPLAIN</code> shows
          that MySQL is using the wrong index from the list of possible
          indexes.
        </p><p>
          You can also use <code class="literal">FORCE INDEX</code>, which acts
          like <code class="literal">USE INDEX
          (<em class="replaceable"><code>index_list</code></em>)</code> but with the
          addition that a table scan is assumed to be
          <span class="emphasis"><em>very</em></span> expensive. In other words, a table
          scan is used only if there is no way to use one of the given
          indexes to find rows in the table.
        </p><p>
          <code class="literal">USE KEY</code>, <code class="literal">IGNORE KEY</code>, and
          <code class="literal">FORCE KEY</code> are synonyms for <code class="literal">USE
          INDEX</code>, <code class="literal">IGNORE INDEX</code>, and
          <code class="literal">FORCE INDEX</code>.
        </p><p>
          Each hint requires the names of <span class="emphasis"><em>indexes</em></span>,
          not the names of columns. The name of a <code class="literal">PRIMARY
          KEY</code> is <code class="literal">PRIMARY</code>. To see the index
          names for a table, use <code class="literal">SHOW INDEX</code>.
        </p><p>
          <code class="literal">USE INDEX</code>, <code class="literal">IGNORE INDEX</code>,
          and <code class="literal">FORCE INDEX</code> affect only which indexes
          are used when MySQL decides how to find rows in the table and
          how to do the join. They do not affect whether an index is
          used when resolving an <code class="literal">ORDER BY</code> or
          <code class="literal">GROUP BY</code> clause. As of MySQL 5.0.40, the
          optional <code class="literal">FOR JOIN</code> clause can be added to
          make this explicit.
        </p><p>
          Examples:
        </p><pre class="programlisting">SELECT * FROM table1 USE INDEX (col1_index,col2_index)
  WHERE col1=1 AND col2=2 AND col3=3;

SELECT * FROM table1 IGNORE INDEX (col3_index)
  WHERE col1=1 AND col2=2 AND col3=3;
</pre></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="union"></a><code class="literal">UNION</code> Syntax</h4></div></div></div><a id="id2875884" class="indexterm"></a><pre class="programlisting">SELECT ...
UNION [ALL | DISTINCT] SELECT ...
[UNION [ALL | DISTINCT] SELECT ...]
</pre><p>
          <code class="literal">UNION</code> is used to combine the result from
          multiple <code class="literal">SELECT</code> statements into a single
          result set.
        </p><p>
          The column names from the first <code class="literal">SELECT</code>
          statement are used as the column names for the results
          returned. Selected columns listed in corresponding positions
          of each <code class="literal">SELECT</code> statement should have the
          same data type. (For example, the first column selected by the
          first statement should have the same type as the first column
          selected by the other statements.)
        </p><p>
          If the data types of corresponding <code class="literal">SELECT</code>
          columns do not match, the types and lengths of the columns in
          the <code class="literal">UNION</code> result take into account the
          values retrieved by all of the <code class="literal">SELECT</code>
          statements. For example, consider the following:
        </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SELECT REPEAT('a',1) UNION SELECT REPEAT('b',10);</code></strong>
+---------------+
| REPEAT('a',1) |
+---------------+
| a             |
| bbbbbbbbbb    |
+---------------+
</pre><p>
          (In some earlier versions of MySQL, only the type and length
          from the first <code class="literal">SELECT</code> would have been used
          and the second row would have been truncated to a length of
          1.)
        </p><p>
          The <code class="literal">SELECT</code> statements are normal select
          statements, but with the following restrictions:
        </p><div class="itemizedlist"><ul type="disc"><li><p>
              Only the last <code class="literal">SELECT</code> statement can use
              <code class="literal">INTO OUTFILE</code>.
            </p></li><li><p>
              <code class="literal">HIGH_PRIORITY</code> cannot be used with
              <code class="literal">SELECT</code> statements that are part of a
              <code class="literal">UNION</code>. If you specify it for the first
              <code class="literal">SELECT</code>, it has no effect. If you
              specify it for any subsequent <code class="literal">SELECT</code>
              statements, a syntax error results.
            </p></li></ul></div><p>
          The default behavior for <code class="literal">UNION</code> is that
          duplicate rows are removed from the result. The optional
          <code class="literal">DISTINCT</code> keyword has no effect other than
          the default because it also specifies duplicate-row removal.
          With the optional <code class="literal">ALL</code> keyword,
          duplicate-row removal does not occur and the result includes
          all matching rows from all the <code class="literal">SELECT</code>
          statements.
        </p><p>
          You can mix <code class="literal">UNION ALL</code> and <code class="literal">UNION
          DISTINCT</code> in the same query. Mixed
          <code class="literal">UNION</code> types are treated such that a
          <code class="literal">DISTINCT</code> union overrides any
          <code class="literal">ALL</code> union to its left. A
          <code class="literal">DISTINCT</code> union can be produced explicitly
          by using <code class="literal">UNION DISTINCT</code> or implicitly by
          using <code class="literal">UNION</code> with no following
          <code class="literal">DISTINCT</code> or <code class="literal">ALL</code> keyword.
        </p><p>
          To use an <code class="literal">ORDER BY</code> or
          <code class="literal">LIMIT</code> clause to sort or limit the entire
          <code class="literal">UNION</code> result, parenthesize the individual
          <code class="literal">SELECT</code> statements and place the
          <code class="literal">ORDER BY</code> or <code class="literal">LIMIT</code> after
          the last one. The following example uses both clauses:
        </p><pre class="programlisting">(SELECT a FROM t1 WHERE a=10 AND B=1)
UNION
(SELECT a FROM t2 WHERE a=11 AND B=2)
ORDER BY a LIMIT 10;
</pre><p>
          This kind of <code class="literal">ORDER BY</code> cannot use column
          references that include a table name (that is, names in
          <em class="replaceable"><code>tbl_name</code></em>.<em class="replaceable"><code>col_name</code></em>
          format). Instead, provide a column alias in the first
          <code class="literal">SELECT</code> statement and refer to the alias in
          the <code class="literal">ORDER BY</code>. (Alternatively, refer to the
          column in the <code class="literal">ORDER BY</code> using its column
          position. However, use of column positions is deprecated.)
        </p><p>
          Also, if a column to be sorted is aliased, the <code class="literal">ORDER
          BY</code> clause <span class="emphasis"><em>must</em></span> refer to the
          alias, not the column name. The first of the following
          statements will work, but the second will fail with an
          <code class="literal">Unknown column 'a' in 'order clause'</code> error:
        </p><pre class="programlisting">(SELECT a AS b FROM t) UNION (SELECT ...) ORDER BY b;
(SELECT a AS b FROM t) UNION (SELECT ...) ORDER BY a;
</pre><p>
          To apply <code class="literal">ORDER BY</code> or
          <code class="literal">LIMIT</code> to an individual
          <code class="literal">SELECT</code>, place the clause inside the
          parentheses that enclose the <code class="literal">SELECT</code>:
        </p><pre class="programlisting">(SELECT a FROM t1 WHERE a=10 AND B=1 ORDER BY a LIMIT 10)
UNION
(SELECT a FROM t2 WHERE a=11 AND B=2 ORDER BY a LIMIT 10);
</pre><p>
          Use of <code class="literal">ORDER BY</code> for individual
          <code class="literal">SELECT</code> statements implies nothing about the
          order in which the rows appear in the final result because
          <code class="literal">UNION</code> by default produces an unordered set
          of rows. If <code class="literal">ORDER BY</code> appears with
          <code class="literal">LIMIT</code>, it is used to determine the subset
          of the selected rows to retrieve for the
          <code class="literal">SELECT</code>, but does not necessarily affect the
          order of those rows in the final <code class="literal">UNION</code>
          result. If <code class="literal">ORDER BY</code> appears without
          <code class="literal">LIMIT</code> in a <code class="literal">SELECT</code>, it is
          optimized away because it will have no effect anyway.
        </p><p>
          To cause rows in a <code class="literal">UNION</code> result to consist
          of the sets of rows retrieved by each
          <code class="literal">SELECT</code> one after the other, select an
          additional column in each <code class="literal">SELECT</code> to use as
          a sort column and add an <code class="literal">ORDER BY</code> following
          the last <code class="literal">SELECT</code>:
        </p><pre class="programlisting">(SELECT 1 AS sort_col, col1a, col1b, ... FROM t1)
UNION
(SELECT 2, col2a, col2b, ... FROM t2) ORDER BY sort_col;
</pre><p>
          To additionally maintain sort order within individual
          <code class="literal">SELECT</code> results, add a secondary column to
          the <code class="literal">ORDER BY</code> clause:
        </p><pre class="programlisting">(SELECT 1 AS sort_col, col1a, col1b, ... FROM t1)
UNION
(SELECT 2, col2a, col2b, ... FROM t2) ORDER BY sort_col, col1a;
</pre></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="subqueries"></a>Subquery Syntax</h3></div></div></div><div class="toc"><dl><dt><span class="section"><a href="mysqlqb_statements.html#scalar-subqueries">The Subquery as Scalar Operand</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#comparisons-using-subqueries">Comparisons Using Subqueries</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#any-in-some-subqueries">Subqueries with <code class="literal">ANY</code>, <code class="literal">IN</code>, and
          <code class="literal">SOME</code></a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#all-subqueries">Subqueries with <code class="literal">ALL</code></a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#row-subqueries">Row Subqueries</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#exists-and-not-exists-subqueries"><code class="literal">EXISTS</code> and <code class="literal">NOT EXISTS</code></a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#correlated-subqueries">Correlated Subqueries</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#unnamed-views">Subqueries in the <code class="literal">FROM</code> clause</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#subquery-errors">Subquery Errors</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#optimizing-subqueries">Optimizing Subqueries</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#rewriting-subqueries">Rewriting Subqueries as Joins for Earlier MySQL Versions</a></span></dt></dl></div><a id="id2876339" class="indexterm"></a><a id="id2876345" class="indexterm"></a><a id="id2876352" class="indexterm"></a><a id="id2876359" class="indexterm"></a><p>
        A subquery is a <code class="literal">SELECT</code> statement within
        another statement.
      </p><p>
        Starting with MySQL 4.1, all subquery forms and operations that
        the SQL standard requires are supported, as well as a few
        features that are MySQL-specific.
      </p><p>
        Here is an example of a subquery:
      </p><pre class="programlisting">SELECT * FROM t1 WHERE column1 = (SELECT column1 FROM t2);
</pre><p>
        In this example, <code class="literal">SELECT * FROM t1 ...</code> is the
        <span class="emphasis"><em>outer query</em></span> (or <span class="emphasis"><em>outer
        statement</em></span>), and <code class="literal">(SELECT column1 FROM
        t2)</code> is the <span class="emphasis"><em>subquery</em></span>. We say that
        the subquery is <span class="emphasis"><em>nested</em></span> within the outer
        query, and in fact it is possible to nest subqueries within
        other subqueries, to a considerable depth. A subquery must
        always appear within parentheses.
      </p><p>
        The main advantages of subqueries are:
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            They allow queries that are <span class="emphasis"><em>structured</em></span>
            so that it is possible to isolate each part of a statement.
          </p></li><li><p>
            They provide alternative ways to perform operations that
            would otherwise require complex joins and unions.
          </p></li><li><p>
            They are, in many people's opinion, more readable than
            complex joins or unions. Indeed, it was the innovation of
            subqueries that gave people the original idea of calling the
            early SQL “<span class="quote">Structured Query Language.</span>”
          </p></li></ul></div><p>
        Here is an example statement that shows the major points about
        subquery syntax as specified by the SQL standard and supported
        in MySQL:
      </p><pre class="programlisting">DELETE FROM t1
WHERE s11 &gt; ANY
(SELECT COUNT(*) /* no hint */ FROM t2
WHERE NOT EXISTS
(SELECT * FROM t3
WHERE ROW(5*t2.s1,77)=
(SELECT 50,11*s1 FROM t4 UNION SELECT 50,77 FROM
(SELECT * FROM t5) AS t5)));
</pre><p>
        A subquery can return a scalar (a single value), a single row, a
        single column, or a table (one or more rows of one or more
        columns). These are called scalar, column, row, and table
        subqueries. Subqueries that return a particular kind of result
        often can be used only in certain contexts, as described in the
        following sections.
      </p><p>
        There are few restrictions on the type of statements in which
        subqueries can be used. A subquery can contain any of the
        keywords or clauses that an ordinary <code class="literal">SELECT</code>
        can contain: <code class="literal">DISTINCT</code>, <code class="literal">GROUP
        BY</code>, <code class="literal">ORDER BY</code>,
        <code class="literal">LIMIT</code>, joins, index hints,
        <code class="literal">UNION</code> constructs, comments, functions, and so
        on.
      </p><p>
        One restriction is that a subquery's outer statement must be one
        of: <code class="literal">SELECT</code>, <code class="literal">INSERT</code>,
        <code class="literal">UPDATE</code>, <code class="literal">DELETE</code>,
        <code class="literal">SET</code>, or <code class="literal">DO</code>. Another
        restriction is that currently you cannot modify a table and
        select from the same table in a subquery. This applies to
        statements such as <code class="literal">DELETE</code>,
        <code class="literal">INSERT</code>, <code class="literal">REPLACE</code>,
        <code class="literal">UPDATE</code>, and (because subqueries can be used
        in the <code class="literal">SET</code> clause) <code class="literal">LOAD DATA
        INFILE</code>.
      </p><p>
        A more comprehensive discussion of restrictions on subquery use,
        including performance issues for certain forms of subquery
        syntax, is given in <a href="http://dev.mysql.com/doc/refman/5.0/en/subquery-restrictions.html" target="_top">Restrictions on Subqueries</a>.
      </p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="scalar-subqueries"></a>The Subquery as Scalar Operand</h4></div></div></div><p>
          In its simplest form, a subquery is a scalar subquery that
          returns a single value. A scalar subquery is a simple operand,
          and you can use it almost anywhere a single column value or
          literal is legal, and you can expect it to have those
          characteristics that all operands have: a data type, a length,
          an indication whether it can be <code class="literal">NULL</code>, and
          so on. For example:
        </p><pre class="programlisting">CREATE TABLE t1 (s1 INT, s2 CHAR(5) NOT NULL);
INSERT INTO t1 VALUES(100, 'abcde');
SELECT (SELECT s2 FROM t1);
</pre><p>
          The subquery in this <code class="literal">SELECT</code> returns a
          single value (<code class="literal">'abcde'</code>) that has a data type
          of <code class="literal">CHAR</code>, a length of 5, a character set and
          collation equal to the defaults in effect at <code class="literal">CREATE
          TABLE</code> time, and an indication that the value in the
          column can be <code class="literal">NULL</code>. In fact, almost all
          subqueries can be <code class="literal">NULL</code>. If the table used
          in the example were empty, the value of the subquery would be
          <code class="literal">NULL</code>.
        </p><p>
          There are a few contexts in which a scalar subquery cannot be
          used. If a statement allows only a literal value, you cannot
          use a subquery. For example, <code class="literal">LIMIT</code> requires
          literal integer arguments, and <code class="literal">LOAD DATA
          INFILE</code> requires a literal string filename. You
          cannot use subqueries to supply these values.
        </p><p>
          When you see examples in the following sections that contain
          the rather spartan construct <code class="literal">(SELECT column1 FROM
          t1)</code>, imagine that your own code contains much more
          diverse and complex constructions.
        </p><p>
          Suppose that we make two tables:
        </p><pre class="programlisting">CREATE TABLE t1 (s1 INT);
INSERT INTO t1 VALUES (1);
CREATE TABLE t2 (s1 INT);
INSERT INTO t2 VALUES (2);
</pre><p>
          Then perform a <code class="literal">SELECT</code>:
        </p><pre class="programlisting">SELECT (SELECT s1 FROM t2) FROM t1;
</pre><p>
          The result is <code class="literal">2</code> because there is a row in
          <code class="literal">t2</code> containing a column
          <code class="literal">s1</code> that has a value of
          <code class="literal">2</code>.
        </p><p>
          A scalar subquery can be part of an expression, but remember
          the parentheses, even if the subquery is an operand that
          provides an argument for a function. For example:
        </p><pre class="programlisting">SELECT UPPER((SELECT s1 FROM t1)) FROM t2;
</pre></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="comparisons-using-subqueries"></a>Comparisons Using Subqueries</h4></div></div></div><p>
          The most common use of a subquery is in the form:
        </p><pre class="programlisting"><em class="replaceable"><code>non_subquery_operand</code></em> <em class="replaceable"><code>comparison_operator</code></em> (<em class="replaceable"><code>subquery</code></em>)
</pre><p>
          Where <em class="replaceable"><code>comparison_operator</code></em> is one of
          these operators:
        </p><pre class="programlisting">=  &gt;  &lt;  &gt;=  &lt;=  &lt;&gt;
</pre><p>
          For example:
        </p><pre class="programlisting">  ... 'a' = (SELECT column1 FROM t1)
</pre><p>
          At one time the only legal place for a subquery was on the
          right side of a comparison, and you might still find some old
          DBMSs that insist on this.
        </p><p>
          Here is an example of a common-form subquery comparison that
          you cannot do with a join. It finds all the values in table
          <code class="literal">t1</code> that are equal to a maximum value in
          table <code class="literal">t2</code>:
        </p><pre class="programlisting">SELECT column1 FROM t1
WHERE column1 = (SELECT MAX(column2) FROM t2);
</pre><p>
          Here is another example, which again is impossible with a join
          because it involves aggregating for one of the tables. It
          finds all rows in table <code class="literal">t1</code> containing a
          value that occurs twice in a given column:
        </p><pre class="programlisting">SELECT * FROM t1 AS t
WHERE 2 = (SELECT COUNT(*) FROM t1 WHERE t1.id = t.id);
</pre><p>
          For a comparison performed with one of these operators, the
          subquery must return a scalar, with the exception that
          <code class="literal">=</code> can be used with row subqueries. See
          <a href="mysqlqb_statements.html#row-subqueries" title="Row Subqueries">Row Subqueries</a>.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="any-in-some-subqueries"></a>Subqueries with <code class="literal">ANY</code>, <code class="literal">IN</code>, and
          <code class="literal">SOME</code></h4></div></div></div><a id="id2876846" class="indexterm"></a><a id="id2876856" class="indexterm"></a><a id="id2876862" class="indexterm"></a><a id="id2876869" class="indexterm"></a><p>
          Syntax:
        </p><pre class="programlisting"><em class="replaceable"><code>operand</code></em> <em class="replaceable"><code>comparison_operator</code></em> ANY (<em class="replaceable"><code>subquery</code></em>)
<em class="replaceable"><code>operand</code></em> IN (<em class="replaceable"><code>subquery</code></em>)
<em class="replaceable"><code>operand</code></em> <em class="replaceable"><code>comparison_operator</code></em> SOME (<em class="replaceable"><code>subquery</code></em>)
</pre><p>
          The <code class="literal">ANY</code> keyword, which must follow a
          comparison operator, means “<span class="quote">return
          <code class="literal">TRUE</code> if the comparison is
          <code class="literal">TRUE</code> for <code class="literal">ANY</code> of the
          values in the column that the subquery returns.</span>” For
          example:
        </p><pre class="programlisting">SELECT s1 FROM t1 WHERE s1 &gt; ANY (SELECT s1 FROM t2);
</pre><p>
          Suppose that there is a row in table <code class="literal">t1</code>
          containing <code class="literal">(10)</code>. The expression is
          <code class="literal">TRUE</code> if table <code class="literal">t2</code>
          contains <code class="literal">(21,14,7)</code> because there is a value
          <code class="literal">7</code> in <code class="literal">t2</code> that is less
          than <code class="literal">10</code>. The expression is
          <code class="literal">FALSE</code> if table <code class="literal">t2</code>
          contains <code class="literal">(20,10)</code>, or if table
          <code class="literal">t2</code> is empty. The expression is
          <span class="emphasis"><em>unknown</em></span> if table <code class="literal">t2</code>
          contains <code class="literal">(NULL,NULL,NULL)</code>.
        </p><p>
          When used with a subquery, the word <code class="literal">IN</code> is
          an alias for <code class="literal">= ANY</code>. Thus, these two
          statements are the same:
        </p><pre class="programlisting">SELECT s1 FROM t1 WHERE s1 = ANY (SELECT s1 FROM t2);
SELECT s1 FROM t1 WHERE s1 IN    (SELECT s1 FROM t2);
</pre><p>
          <code class="literal">IN</code> and <code class="literal">= ANY</code> are not
          synonyms when used with an expression list.
          <code class="literal">IN</code> can take an expression list, but
          <code class="literal">= ANY</code> cannot. See
          <a href="mysqlqb_functions.html#comparison-operators" title="Comparison Functions and Operators">Comparison Functions and Operators</a>.
        </p><p>
          <code class="literal">NOT IN</code> is not an alias for
          <code class="literal">&lt;&gt; ANY</code>, but for <code class="literal">&lt;&gt;
          ALL</code>. See <a href="mysqlqb_statements.html#all-subqueries" title="Subqueries with ALL">Subqueries with <code class="literal">ALL</code></a>.
        </p><p>
          The word <code class="literal">SOME</code> is an alias for
          <code class="literal">ANY</code>. Thus, these two statements are the
          same:
        </p><pre class="programlisting">SELECT s1 FROM t1 WHERE s1 &lt;&gt; ANY  (SELECT s1 FROM t2);
SELECT s1 FROM t1 WHERE s1 &lt;&gt; SOME (SELECT s1 FROM t2);
</pre><p>
          Use of the word <code class="literal">SOME</code> is rare, but this
          example shows why it might be useful. To most people's ears,
          the English phrase “<span class="quote">a is not equal to any b</span>”
          means “<span class="quote">there is no b which is equal to a,</span>” but
          that is not what is meant by the SQL syntax. The syntax means
          “<span class="quote">there is some b to which a is not equal.</span>” Using
          <code class="literal">&lt;&gt; SOME</code> instead helps ensure that
          everyone understands the true meaning of the query.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="all-subqueries"></a>Subqueries with <code class="literal">ALL</code></h4></div></div></div><a id="id2877122" class="indexterm"></a><a id="id2877133" class="indexterm"></a><p>
          Syntax:
        </p><pre class="programlisting"><em class="replaceable"><code>operand</code></em> <em class="replaceable"><code>comparison_operator</code></em> ALL (<em class="replaceable"><code>subquery</code></em>)
</pre><p>
          The word <code class="literal">ALL</code>, which must follow a
          comparison operator, means “<span class="quote">return
          <code class="literal">TRUE</code> if the comparison is
          <code class="literal">TRUE</code> for <code class="literal">ALL</code> of the
          values in the column that the subquery returns.</span>” For
          example:
        </p><pre class="programlisting">SELECT s1 FROM t1 WHERE s1 &gt; ALL (SELECT s1 FROM t2);
</pre><p>
          Suppose that there is a row in table <code class="literal">t1</code>
          containing <code class="literal">(10)</code>. The expression is
          <code class="literal">TRUE</code> if table <code class="literal">t2</code>
          contains <code class="literal">(-5,0,+5)</code> because
          <code class="literal">10</code> is greater than all three values in
          <code class="literal">t2</code>. The expression is
          <code class="literal">FALSE</code> if table <code class="literal">t2</code>
          contains <code class="literal">(12,6,NULL,-100)</code> because there is
          a single value <code class="literal">12</code> in table
          <code class="literal">t2</code> that is greater than
          <code class="literal">10</code>. The expression is
          <span class="emphasis"><em>unknown</em></span> (that is,
          <code class="literal">NULL</code>) if table <code class="literal">t2</code>
          contains <code class="literal">(0,NULL,1)</code>.
        </p><p>
          Finally, if table <code class="literal">t2</code> is empty, the result
          is <code class="literal">TRUE</code>. So, the following statement is
          <code class="literal">TRUE</code> when table <code class="literal">t2</code> is
          empty:
        </p><pre class="programlisting">SELECT * FROM t1 WHERE 1 &gt; ALL (SELECT s1 FROM t2);
</pre><p>
          But this statement is <code class="literal">NULL</code> when table
          <code class="literal">t2</code> is empty:
        </p><pre class="programlisting">SELECT * FROM t1 WHERE 1 &gt; (SELECT s1 FROM t2);
</pre><p>
          In addition, the following statement is
          <code class="literal">NULL</code> when table <code class="literal">t2</code> is
          empty:
        </p><pre class="programlisting">SELECT * FROM t1 WHERE 1 &gt; ALL (SELECT MAX(s1) FROM t2);
</pre><p>
          In general, <span class="emphasis"><em>tables containing
          <code class="literal">NULL</code> values</em></span> and <span class="emphasis"><em>empty
          tables</em></span> are “<span class="quote">edge cases.</span>” When writing
          subquery code, always consider whether you have taken those
          two possibilities into account.
        </p><p>
          <code class="literal">NOT IN</code> is an alias for <code class="literal">&lt;&gt;
          ALL</code>. Thus, these two statements are the same:
        </p><pre class="programlisting">SELECT s1 FROM t1 WHERE s1 &lt;&gt; ALL (SELECT s1 FROM t2);
SELECT s1 FROM t1 WHERE s1 NOT IN (SELECT s1 FROM t2);
</pre></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="row-subqueries"></a>Row Subqueries</h4></div></div></div><a id="id2877363" class="indexterm"></a><a id="id2877370" class="indexterm"></a><a id="id2877376" class="indexterm"></a><p>
          The discussion to this point has been of scalar or column
          subqueries; that is, subqueries that return a single value or
          a column of values. A <span class="emphasis"><em>row subquery</em></span> is a
          subquery variant that returns a single row and can thus return
          more than one column value. Here are two examples:
        </p><pre class="programlisting">SELECT * FROM t1 WHERE (1,2) = (SELECT column1, column2 FROM t2);
SELECT * FROM t1 WHERE ROW(1,2) = (SELECT column1, column2 FROM t2);
</pre><p>
          The queries here are both <code class="literal">TRUE</code> if table
          <code class="literal">t2</code> has a row where <code class="literal">column1 =
          1</code> and <code class="literal">column2 = 2</code>.
        </p><p>
          The expressions <code class="literal">(1,2)</code> and
          <code class="literal">ROW(1,2)</code> are sometimes called
          <em class="firstterm">row constructors</em>. The two are
          equivalent. They are legal in other contexts as well. For
          example, the following two statements are semantically
          equivalent (although the first one cannot be optimized until
          MySQL 5.0.26):
        </p><pre class="programlisting">  SELECT * FROM t1 WHERE (column1,column2) = (1,1);
  SELECT * FROM t1 WHERE column1 = 1 AND column2 = 1;
</pre><p>
          The normal use of row constructors is for comparisons with
          subqueries that return two or more columns. For example, the
          following query answers the request, “<span class="quote">find all rows in
          table <code class="literal">t1</code> that also exist in table
          <code class="literal">t2</code></span>”:
        </p><pre class="programlisting">SELECT column1,column2,column3
FROM t1
WHERE (column1,column2,column3) IN
(SELECT column1,column2,column3 FROM t2);
</pre></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="exists-and-not-exists-subqueries"></a><code class="literal">EXISTS</code> and <code class="literal">NOT EXISTS</code></h4></div></div></div><a id="id2877485" class="indexterm"></a><a id="id2877495" class="indexterm"></a><a id="id2877505" class="indexterm"></a><a id="id2877515" class="indexterm"></a><p>
          If a subquery returns any rows at all, <code class="literal">EXISTS
          <em class="replaceable"><code>subquery</code></em></code> is
          <code class="literal">TRUE</code>, and <code class="literal">NOT EXISTS
          <em class="replaceable"><code>subquery</code></em></code> is
          <code class="literal">FALSE</code>. For example:
        </p><pre class="programlisting">SELECT column1 FROM t1 WHERE EXISTS (SELECT * FROM t2);
</pre><p>
          Traditionally, an <code class="literal">EXISTS</code> subquery starts
          with <code class="literal">SELECT *</code>, but it could begin with
          <code class="literal">SELECT 5</code> or <code class="literal">SELECT
          column1</code> or anything at all. MySQL ignores the
          <code class="literal">SELECT</code> list in such a subquery, so it makes
          no difference.
        </p><p>
          For the preceding example, if <code class="literal">t2</code> contains
          any rows, even rows with nothing but <code class="literal">NULL</code>
          values, the <code class="literal">EXISTS</code> condition is
          <code class="literal">TRUE</code>. This is actually an unlikely example
          because a <code class="literal">[NOT] EXISTS</code> subquery almost
          always contains correlations. Here are some more realistic
          examples:
        </p><div class="itemizedlist"><ul type="disc"><li><p>
              What kind of store is present in one or more cities?
            </p><pre class="programlisting">SELECT DISTINCT store_type FROM stores
  WHERE EXISTS (SELECT * FROM cities_stores
                WHERE cities_stores.store_type = stores.store_type);
</pre></li><li><p>
              What kind of store is present in no cities?
            </p><pre class="programlisting">SELECT DISTINCT store_type FROM stores
  WHERE NOT EXISTS (SELECT * FROM cities_stores
                    WHERE cities_stores.store_type = stores.store_type);
</pre></li><li><p>
              What kind of store is present in all cities?
            </p><pre class="programlisting">SELECT DISTINCT store_type FROM stores s1
  WHERE NOT EXISTS (
    SELECT * FROM cities WHERE NOT EXISTS (
      SELECT * FROM cities_stores
       WHERE cities_stores.city = cities.city
       AND cities_stores.store_type = stores.store_type));
</pre></li></ul></div><p>
          The last example is a double-nested <code class="literal">NOT
          EXISTS</code> query. That is, it has a <code class="literal">NOT
          EXISTS</code> clause within a <code class="literal">NOT EXISTS</code>
          clause. Formally, it answers the question “<span class="quote">does a city
          exist with a store that is not in
          <code class="literal">Stores</code></span>”? But it is easier to say
          that a nested <code class="literal">NOT EXISTS</code> answers the
          question “<span class="quote">is <em class="replaceable"><code>x</code></em>
          <code class="literal">TRUE</code> for all
          <em class="replaceable"><code>y</code></em>?</span>”
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="correlated-subqueries"></a>Correlated Subqueries</h4></div></div></div><a id="id2877704" class="indexterm"></a><a id="id2877711" class="indexterm"></a><p>
          A <span class="emphasis"><em>correlated subquery</em></span> is a subquery that
          contains a reference to a table that also appears in the outer
          query. For example:
        </p><pre class="programlisting">SELECT * FROM t1 WHERE column1 = ANY
(SELECT column1 FROM t2 WHERE t2.column2 = t1.column2);
</pre><p>
          Notice that the subquery contains a reference to a column of
          <code class="literal">t1</code>, even though the subquery's
          <code class="literal">FROM</code> clause does not mention a table
          <code class="literal">t1</code>. So, MySQL looks outside the subquery,
          and finds <code class="literal">t1</code> in the outer query.
        </p><p>
          Suppose that table <code class="literal">t1</code> contains a row where
          <code class="literal">column1 = 5</code> and <code class="literal">column2 =
          6</code>; meanwhile, table <code class="literal">t2</code> contains a
          row where <code class="literal">column1 = 5</code> and <code class="literal">column2
          = 7</code>. The simple expression <code class="literal">... WHERE
          column1 = ANY (SELECT column1 FROM t2)</code> would be
          <code class="literal">TRUE</code>, but in this example, the
          <code class="literal">WHERE</code> clause within the subquery is
          <code class="literal">FALSE</code> (because <code class="literal">(5,6)</code> is
          not equal to <code class="literal">(5,7)</code>), so the subquery as a
          whole is <code class="literal">FALSE</code>.
        </p><p>
          <span class="bold"><strong>Scoping rule:</strong></span> MySQL evaluates
          from inside to outside. For example:
        </p><pre class="programlisting">SELECT column1 FROM t1 AS x
WHERE x.column1 = (SELECT column1 FROM t2 AS x
WHERE x.column1 = (SELECT column1 FROM t3
WHERE x.column2 = t3.column1));
</pre><p>
          In this statement, <code class="literal">x.column2</code> must be a
          column in table <code class="literal">t2</code> because <code class="literal">SELECT
          column1 FROM t2 AS x ...</code> renames
          <code class="literal">t2</code>. It is not a column in table
          <code class="literal">t1</code> because <code class="literal">SELECT column1 FROM t1
          ...</code> is an outer query that is <span class="emphasis"><em>farther
          out</em></span>.
        </p><p>
          For subqueries in <code class="literal">HAVING</code> or <code class="literal">ORDER
          BY</code> clauses, MySQL also looks for column names in the
          outer select list.
        </p><p>
          For certain cases, a correlated subquery is optimized. For
          example:
        </p><pre class="programlisting"><em class="replaceable"><code>val</code></em> IN (SELECT <em class="replaceable"><code>key_val</code></em> FROM <em class="replaceable"><code>tbl_name</code></em> WHERE <em class="replaceable"><code>correlated_condition</code></em>)
</pre><p>
          Otherwise, they are inefficient and likely to be slow.
          Rewriting the query as a join might improve performance.
        </p><p>
          Aggregate functions in correlated subqueries may contain outer
          references, provided the function contains nothing but outer
          references, and provided the function is not contained in
          another function or expression.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="unnamed-views"></a>Subqueries in the <code class="literal">FROM</code> clause</h4></div></div></div><a id="id2877923" class="indexterm"></a><a id="id2877930" class="indexterm"></a><p>
          Subqueries are legal in a <code class="literal">SELECT</code>
          statement's <code class="literal">FROM</code> clause. The actual syntax
          is:
        </p><pre class="programlisting">SELECT ... FROM (<em class="replaceable"><code>subquery</code></em>) [AS] <em class="replaceable"><code>name</code></em> ...
</pre><p>
          The <code class="literal">[AS] <em class="replaceable"><code>name</code></em></code>
          clause is mandatory, because every table in a
          <code class="literal">FROM</code> clause must have a name. Any columns
          in the <em class="replaceable"><code>subquery</code></em> select list must
          have unique names. You can find this syntax described
          elsewhere in this manual, where the term used is
          “<span class="quote">derived tables.</span>”
        </p><p>
          For the sake of illustration, assume that you have this table:
        </p><pre class="programlisting">CREATE TABLE t1 (s1 INT, s2 CHAR(5), s3 FLOAT);
</pre><p>
          Here is how to use a subquery in the <code class="literal">FROM</code>
          clause, using the example table:
        </p><pre class="programlisting">INSERT INTO t1 VALUES (1,'1',1.0);
INSERT INTO t1 VALUES (2,'2',2.0);
SELECT sb1,sb2,sb3
FROM (SELECT s1 AS sb1, s2 AS sb2, s3*2 AS sb3 FROM t1) AS sb
WHERE sb1 &gt; 1;
</pre><p>
          Result: <code class="literal">2, '2', 4.0</code>.
        </p><p>
          Here is another example: Suppose that you want to know the
          average of a set of sums for a grouped table. This does not
          work:
        </p><pre class="programlisting">SELECT AVG(SUM(column1)) FROM t1 GROUP BY column1;
</pre><p>
          However, this query provides the desired information:
        </p><pre class="programlisting">SELECT AVG(sum_column1)
FROM (SELECT SUM(column1) AS sum_column1
FROM t1 GROUP BY column1) AS t1;
</pre><p>
          Notice that the column name used within the subquery
          (<code class="literal">sum_column1</code>) is recognized in the outer
          query.
        </p><p>
          Subqueries in the <code class="literal">FROM</code> clause can return a
          scalar, column, row, or table. Subqueries in the
          <code class="literal">FROM</code> clause cannot be correlated
          subqueries, unless used within the <code class="literal">ON</code>
          clause of a <code class="literal">JOIN</code> operation.
        </p><p>
          Subqueries in the <code class="literal">FROM</code> clause are executed
          even for the <code class="literal">EXPLAIN</code> statement (that is,
          derived temporary tables are built). This occurs because
          upper-level queries need information about all tables during
          the optimization phase, and the table represented by a
          subquery in the <code class="literal">FROM</code> clause is unavailable
          unless the subquery is executed.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="subquery-errors"></a>Subquery Errors</h4></div></div></div><a id="id2878106" class="indexterm"></a><a id="id2878116" class="indexterm"></a><p>
          There are some errors that apply only to subqueries. This
          section describes them.
        </p><div class="itemizedlist"><ul type="disc"><li><p>
              Unsupported subquery syntax:
            </p><pre class="programlisting">ERROR 1235 (ER_NOT_SUPPORTED_YET)
SQLSTATE = 42000
Message = "This version of MySQL does not yet support
'LIMIT &amp; IN/ALL/ANY/SOME subquery'"
</pre><p>
              This means that statements of the following form do not
              work yet:
            </p><pre class="programlisting">SELECT * FROM t1 WHERE s1 IN (SELECT s2 FROM t2 ORDER BY s1 LIMIT 1)
</pre></li><li><p>
              Incorrect number of columns from subquery:
            </p><pre class="programlisting">ERROR 1241 (ER_OPERAND_COL)
SQLSTATE = 21000
Message = "Operand should contain 1 column(s)"
</pre><p>
              This error occurs in cases like this:
            </p><pre class="programlisting">SELECT (SELECT column1, column2 FROM t2) FROM t1;
</pre><p>
              You may use a subquery that returns multiple columns, if
              the purpose is comparison. In other contexts, the subquery
              must be a scalar operand. See
              <a href="mysqlqb_statements.html#row-subqueries" title="Row Subqueries">Row Subqueries</a>.
            </p></li><li><p>
              Incorrect number of rows from subquery:
            </p><pre class="programlisting">ERROR 1242 (ER_SUBSELECT_NO_1_ROW)
SQLSTATE = 21000
Message = "Subquery returns more than 1 row"
</pre><p>
              This error occurs for statements where the subquery
              returns more than one row. Consider the following example:
            </p><pre class="programlisting">SELECT * FROM t1 WHERE column1 = (SELECT column1 FROM t2);
</pre><p>
              If <code class="literal">SELECT column1 FROM t2</code> returns just
              one row, the previous query will work. If the subquery
              returns more than one row, error 1242 will occur. In that
              case, the query should be rewritten as:
            </p><pre class="programlisting">SELECT * FROM t1 WHERE column1 = ANY (SELECT column1 FROM t2);
</pre></li><li><p>
              Incorrectly used table in subquery:
            </p><pre class="programlisting">Error 1093 (ER_UPDATE_TABLE_USED)
SQLSTATE = HY000
Message = "You can't specify target table 'x'
for update in FROM clause"
</pre><p>
              This error occurs in cases such as the following:
            </p><pre class="programlisting">UPDATE t1 SET column2 = (SELECT MAX(column1) FROM t1);
</pre><p>
              You can use a subquery for assignment within an
              <code class="literal">UPDATE</code> statement because subqueries are
              legal in <code class="literal">UPDATE</code> and
              <code class="literal">DELETE</code> statements as well as in
              <code class="literal">SELECT</code> statements. However, you cannot
              use the same table (in this case, table
              <code class="literal">t1</code>) for both the subquery's
              <code class="literal">FROM</code> clause and the update target.
            </p></li></ul></div><p>
          For transactional storage engines, the failure of a subquery
          causes the entire statement to fail. For non-transactional
          storage engines, data modifications made before the error was
          encountered are preserved.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="optimizing-subqueries"></a>Optimizing Subqueries</h4></div></div></div><p>
          Development is ongoing, so no optimization tip is reliable for
          the long term. The following list provides some interesting
          tricks that you might want to play with:
        </p><div class="itemizedlist"><ul type="disc"><li><p>
              Use subquery clauses that affect the number or order of
              the rows in the subquery. For example:
            </p><pre class="programlisting">SELECT * FROM t1 WHERE t1.column1 IN
(SELECT column1 FROM t2 ORDER BY column1);
SELECT * FROM t1 WHERE t1.column1 IN
(SELECT DISTINCT column1 FROM t2);
SELECT * FROM t1 WHERE EXISTS
(SELECT * FROM t2 LIMIT 1);
</pre></li><li><p>
              Replace a join with a subquery. For example, try this:
            </p><pre class="programlisting">SELECT DISTINCT column1 FROM t1 WHERE t1.column1 IN (
SELECT column1 FROM t2);
</pre><p>
              Instead of this:
            </p><pre class="programlisting">SELECT DISTINCT t1.column1 FROM t1, t2
WHERE t1.column1 = t2.column1;
</pre></li><li><p>
              Some subqueries can be transformed to joins for
              compatibility with older versions of MySQL that do not
              support subqueries. However, in some cases, converting a
              subquery to a join may improve performance. See
              <a href="mysqlqb_statements.html#rewriting-subqueries" title="Rewriting Subqueries as Joins for Earlier MySQL Versions">Rewriting Subqueries as Joins for Earlier MySQL Versions</a>.
            </p></li><li><p>
              Move clauses from outside to inside the subquery. For
              example, use this query:
            </p><pre class="programlisting">SELECT * FROM t1
WHERE s1 IN (SELECT s1 FROM t1 UNION ALL SELECT s1 FROM t2);
</pre><p>
              Instead of this query:
            </p><pre class="programlisting">SELECT * FROM t1
WHERE s1 IN (SELECT s1 FROM t1) OR s1 IN (SELECT s1 FROM t2);
</pre><p>
              For another example, use this query:
            </p><pre class="programlisting">SELECT (SELECT column1 + 5 FROM t1) FROM t2;
</pre><p>
              Instead of this query:
            </p><pre class="programlisting">SELECT (SELECT column1 FROM t1) + 5 FROM t2;
</pre></li><li><p>
              Use a row subquery instead of a correlated subquery. For
              example, use this query:
            </p><pre class="programlisting">SELECT * FROM t1
WHERE (column1,column2) IN (SELECT column1,column2 FROM t2);
</pre><p>
              Instead of this query:
            </p><pre class="programlisting">SELECT * FROM t1
WHERE EXISTS (SELECT * FROM t2 WHERE t2.column1=t1.column1
AND t2.column2=t1.column2);
</pre></li><li><p>
              Use <code class="literal">NOT (a = ANY (...))</code> rather than
              <code class="literal">a &lt;&gt; ALL (...)</code>.
            </p></li><li><p>
              Use <code class="literal">x = ANY (<em class="replaceable"><code>table containing
              (1,2)</code></em>)</code> rather than <code class="literal">x=1 OR
              x=2</code>.
            </p></li><li><p>
              Use <code class="literal">= ANY</code> rather than
              <code class="literal">EXISTS</code>.
            </p></li><li><p>
              For uncorrelated subqueries that always return one row,
              <code class="literal">IN</code> is always slower than
              <code class="literal">=</code>. For example, use this query:
            </p><pre class="programlisting">SELECT * FROM t1 WHERE t1.<em class="replaceable"><code>col_name</code></em>
= (SELECT a FROM t2 WHERE b = <em class="replaceable"><code>some_const</code></em>);
</pre><p>
              Instead of this query:
            </p><pre class="programlisting">SELECT * FROM t1 WHERE t1.<em class="replaceable"><code>col_name</code></em>
IN (SELECT a FROM t2 WHERE b = <em class="replaceable"><code>some_const</code></em>);
</pre></li></ul></div><p>
          These tricks might cause programs to go faster or slower.
          Using MySQL facilities like the <code class="literal">BENCHMARK()</code>
          function, you can get an idea about what helps in your own
          situation. See <a href="mysqlqb_functions.html#information-functions" title="Information Functions">Information Functions</a>.
        </p><p>
          Some optimizations that MySQL itself makes are:
        </p><div class="itemizedlist"><ul type="disc"><li><p>
              MySQL executes non-correlated subqueries only once. Use
              <code class="literal">EXPLAIN</code> to make sure that a given
              subquery really is non-correlated.
            </p></li><li><p>
              MySQL rewrites <code class="literal">IN</code>,
              <code class="literal">ALL</code>, <code class="literal">ANY</code>, and
              <code class="literal">SOME</code> subqueries in an attempt to take
              advantage of the possibility that the select-list columns
              in the subquery are indexed.
            </p></li><li><p>
              MySQL replaces subqueries of the following form with an
              index-lookup function, which <code class="literal">EXPLAIN</code>
              describes as a special join type
              (<code class="literal">unique_subquery</code> or
              <code class="literal">index_subquery</code>):
            </p><pre class="programlisting">... IN (SELECT <em class="replaceable"><code>indexed_column</code></em> FROM <em class="replaceable"><code>single_table</code></em> ...)
</pre></li><li><p>
              MySQL enhances expressions of the following form with an
              expression involving <code class="literal">MIN()</code> or
              <code class="literal">MAX()</code>, unless <code class="literal">NULL</code>
              values or empty sets are involved:
            </p><pre class="programlisting"><em class="replaceable"><code>value</code></em> {ALL|ANY|SOME} {&gt; | &lt; | &gt;= | &lt;=} (<em class="replaceable"><code>non-correlated subquery</code></em>)
</pre><p>
              For example, this <code class="literal">WHERE</code> clause:
            </p><pre class="programlisting">WHERE 5 &gt; ALL (SELECT x FROM t)
</pre><p>
              might be treated by the optimizer like this:
            </p><pre class="programlisting">WHERE 5 &gt; (SELECT MAX(x) FROM t)
</pre></li></ul></div><p>
          There is a chapter titled “<span class="quote">How MySQL Transforms
          Subqueries</span>” in the MySQL Internals Manual, available at
          <a href="http://dev.mysql.com/doc/" target="_top">http://dev.mysql.com/doc/</a>.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="rewriting-subqueries"></a>Rewriting Subqueries as Joins for Earlier MySQL Versions</h4></div></div></div><a id="id2878684" class="indexterm"></a><p>
          In previous versions of MySQL (prior to MySQL 4.1), only
          nested queries of the form <code class="literal">INSERT ... SELECT
          ...</code> and <code class="literal">REPLACE ... SELECT ...</code>
          were supported. Although this is not the case in MySQL
          5.0, it is still true that there are sometimes
          other ways to test membership in a set of values. It is also
          true that on some occasions, it is not only possible to
          rewrite a query without a subquery, but it can be more
          efficient to make use of some of these techniques rather than
          to use subqueries. One of these is the <code class="literal">IN()</code>
          construct:
        </p><p>
          For example, this query:
        </p><pre class="programlisting">SELECT * FROM t1 WHERE id IN (SELECT id FROM t2);
</pre><p>
          Can be rewritten as:
        </p><pre class="programlisting">SELECT DISTINCT t1.* FROM t1, t2 WHERE t1.id=t2.id;
</pre><p>
          The queries:
        </p><pre class="programlisting">SELECT * FROM t1 WHERE id NOT IN (SELECT id FROM t2);
SELECT * FROM t1 WHERE NOT EXISTS (SELECT id FROM t2 WHERE t1.id=t2.id);
</pre><p>
          Can be rewritten using <code class="literal">IN()</code>:
        </p><pre class="programlisting">SELECT table1.* FROM table1 LEFT JOIN table2 ON table1.id=table2.id
WHERE table2.id IS NULL;
</pre><p>
          A <code class="literal">LEFT [OUTER] JOIN</code> can be faster than an
          equivalent subquery because the server might be able to
          optimize it better — a fact that is not specific to
          MySQL Server alone. Prior to SQL-92, outer joins did not
          exist, so subqueries were the only way to do certain things.
          Today, MySQL Server and many other modern database systems
          offer a wide range of outer join types.
        </p><p>
          MySQL Server supports multiple-table <code class="literal">DELETE</code>
          statements that can be used to efficiently delete rows based
          on information from one table or even from many tables at the
          same time. Multiple-table <code class="literal">UPDATE</code> statements
          are also supported. See <a href="mysqlqb_statements.html#delete" title="DELETE Syntax"><code class="literal">DELETE</code> Syntax</a>, and
          <a href="mysqlqb_statements.html#update" title="UPDATE Syntax"><code class="literal">UPDATE</code> Syntax</a>.
        </p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="truncate"></a><code class="literal">TRUNCATE</code> Syntax</h3></div></div></div><a id="id2878838" class="indexterm"></a><pre class="programlisting">TRUNCATE [TABLE] <em class="replaceable"><code>tbl_name</code></em>
</pre><p>
        <code class="literal">TRUNCATE TABLE</code> empties a table completely.
        Logically, this is equivalent to a <code class="literal">DELETE</code>
        statement that deletes all rows, but there are practical
        differences under some circumstances.
      </p><p>
        For <code class="literal">InnoDB</code> before version 5.0.3,
        <code class="literal">TRUNCATE TABLE</code> is mapped to
        <code class="literal">DELETE</code>, so there is no difference. Starting
        with MySQL 5.0.3, fast <code class="literal">TRUNCATE TABLE</code> is
        available. However, the operation is still mapped to
        <code class="literal">DELETE</code> if there are foreign key constraints
        that reference the table. (When fast truncate is used, it resets
        any <code class="literal">AUTO_INCREMENT</code> counter. From MySQL 5.0.13
        on, the <code class="literal">AUTO_INCREMENT</code> counter is reset by
        <code class="literal">TRUNCATE TABLE</code>, regardless of whether there
        is a foreign key constraint.)
      </p><p>
        For other storage engines, <code class="literal">TRUNCATE TABLE</code>
        differs from <code class="literal">DELETE</code> in the following ways in
        MySQL 5.0:
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            Truncate operations drop and re-create the table, which is
            much faster than deleting rows one by one.
          </p></li><li><p>
            Truncate operations are not transaction-safe; an error
            occurs when attempting one in the course of an active
            transaction or active table lock.
          </p></li><li><p>
            The number of deleted rows is not returned.
          </p></li><li><p>
            As long as the table format file
            <code class="filename"><em class="replaceable"><code>tbl_name</code></em>.frm</code>
            is valid, the table can be re-created as an empty table with
            <code class="literal">TRUNCATE TABLE</code>, even if the data or index
            files have become corrupted.
          </p></li><li><p>
            The table handler does not remember the last used
            <code class="literal">AUTO_INCREMENT</code> value, but starts counting
            from the beginning. This is true even for
            <code class="literal">MyISAM</code> and <code class="literal">InnoDB</code>,
            which normally do not reuse sequence values.
          </p></li><li><p>
            Since truncation of a table does not make any use of
            <code class="literal">DELETE</code>, the <code class="literal">TRUNCATE</code>
            statement does not invoke <code class="literal">ON DELETE</code>
            triggers.
          </p></li></ul></div><p>
        <code class="literal">TRUNCATE TABLE</code> is an Oracle SQL extension
        adopted in MySQL.
      </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="update"></a><code class="literal">UPDATE</code> Syntax</h3></div></div></div><a id="id2879050" class="indexterm"></a><p>
        Single-table syntax:
      </p><pre class="programlisting">UPDATE [LOW_PRIORITY] [IGNORE] <em class="replaceable"><code>tbl_name</code></em>
    SET <em class="replaceable"><code>col_name1</code></em>=<em class="replaceable"><code>expr1</code></em> [, <em class="replaceable"><code>col_name2</code></em>=<em class="replaceable"><code>expr2</code></em> ...]
    [WHERE <em class="replaceable"><code>where_condition</code></em>]
    [ORDER BY ...]
    [LIMIT <em class="replaceable"><code>row_count</code></em>]
</pre><p>
        Multiple-table syntax:
      </p><pre class="programlisting">UPDATE [LOW_PRIORITY] [IGNORE] <em class="replaceable"><code>table_references</code></em>
    SET <em class="replaceable"><code>col_name1</code></em>=<em class="replaceable"><code>expr1</code></em> [, <em class="replaceable"><code>col_name2</code></em>=<em class="replaceable"><code>expr2</code></em> ...]
    [WHERE <em class="replaceable"><code>where_condition</code></em>]
</pre><p>
        For the single-table syntax, the <code class="literal">UPDATE</code>
        statement updates columns of existing rows in
        <code class="literal">tbl_name</code> with new values. The
        <code class="literal">SET</code> clause indicates which columns to modify
        and the values they should be given. The
        <code class="literal">WHERE</code> clause, if given, specifies the
        conditions that identify which rows to update. With no
        <code class="literal">WHERE</code> clause, all rows are updated. If the
        <code class="literal">ORDER BY</code> clause is specified, the rows are
        updated in the order that is specified. The
        <code class="literal">LIMIT</code> clause places a limit on the number of
        rows that can be updated.
      </p><p>
        For the multiple-table syntax, <code class="literal">UPDATE</code> updates
        rows in each table named in
        <em class="replaceable"><code>table_references</code></em> that satisfy the
        conditions. In this case, <code class="literal">ORDER BY</code> and
        <code class="literal">LIMIT</code> cannot be used.
      </p><p>
        <em class="replaceable"><code>where_condition</code></em> is an expression that
        evaluates to true for each row to be updated. It is specified as
        described in <a href="mysqlqb_statements.html#select" title="SELECT Syntax"><code class="literal">SELECT</code> Syntax</a>.
      </p><p>
        The <code class="literal">UPDATE</code> statement supports the following
        modifiers:
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            If you use the <code class="literal">LOW_PRIORITY</code> keyword,
            execution of the <code class="literal">UPDATE</code> is delayed until
            no other clients are reading from the table.
          </p></li><li><p>
            If you use the <code class="literal">IGNORE</code> keyword, the update
            statement does not abort even if errors occur during the
            update. Rows for which duplicate-key conflicts occur are not
            updated. Rows for which columns are updated to values that
            would cause data conversion errors are updated to the
            closest valid values instead.
          </p></li></ul></div><p>
        If you access a column from <em class="replaceable"><code>tbl_name</code></em>
        in an expression, <code class="literal">UPDATE</code> uses the current
        value of the column. For example, the following statement sets
        the <code class="literal">age</code> column to one more than its current
        value:
      </p><pre class="programlisting">UPDATE persondata SET age=age+1;
</pre><p>
        Single-table <code class="literal">UPDATE</code> assignments are generally
        evaluated from left to right. For multiple-table updates, there
        is no guarantee that assignments are carried out in any
        particular order.
      </p><p>
        If you set a column to the value it currently has, MySQL notices
        this and does not update it.
      </p><p>
        If you update a column that has been declared <code class="literal">NOT
        NULL</code> by setting to <code class="literal">NULL</code>, the column
        is set to the default value appropriate for the data type and
        the warning count is incremented. The default value is
        <code class="literal">0</code> for numeric types, the empty string
        (<code class="literal">''</code>) for string types, and the
        “<span class="quote">zero</span>” value for date and time types.
      </p><a id="id2879333" class="indexterm"></a><p>
        <code class="literal">UPDATE</code> returns the number of rows that were
        actually changed. The <code class="literal">mysql_info()</code> C API
        function returns the number of rows that were matched and
        updated and the number of warnings that occurred during the
        <code class="literal">UPDATE</code>.
      </p><p>
        You can use <code class="literal">LIMIT
        <em class="replaceable"><code>row_count</code></em></code> to restrict the
        scope of the <code class="literal">UPDATE</code>. A
        <code class="literal">LIMIT</code> clause is a rows-matched restriction.
        The statement stops as soon as it has found
        <em class="replaceable"><code>row_count</code></em> rows that satisfy the
        <code class="literal">WHERE</code> clause, whether or not they actually
        were changed.
      </p><p>
        If an <code class="literal">UPDATE</code> statement includes an
        <code class="literal">ORDER BY</code> clause, the rows are updated in the
        order specified by the clause. This can be useful in certain
        situations that might otherwise result in an error. Suppose that
        a table <code class="literal">t</code> contains a column
        <code class="literal">id</code> that has a unique index. The following
        statement could fail with a duplicate-key error, depending on
        the order in which rows are updated:
      </p><pre class="programlisting">UPDATE t SET id = id + 1;
</pre><p>
        For example, if the table contains 1 and 2 in the
        <code class="literal">id</code> column and 1 is updated to 2 before 2 is
        updated to 3, an error occurs. To avoid this problem, add an
        <code class="literal">ORDER BY</code> clause to cause the rows with larger
        <code class="literal">id</code> values to be updated before those with
        smaller values:
      </p><pre class="programlisting">UPDATE t SET id = id + 1 ORDER BY id DESC;
</pre><p>
        You can also perform <code class="literal">UPDATE</code> operations
        covering multiple tables. However, you cannot use <code class="literal">ORDER
        BY</code> or <code class="literal">LIMIT</code> with a multiple-table
        <code class="literal">UPDATE</code>. The
        <em class="replaceable"><code>table_references</code></em> clause lists the
        tables involved in the join. Its syntax is described in
        <a href="mysqlqb_statements.html#join" title="JOIN Syntax"><code class="literal">JOIN</code> Syntax</a>. Here is an example:
      </p><pre class="programlisting">UPDATE items,month SET items.price=month.price
WHERE items.id=month.id;
</pre><p>
        The preceding example shows an inner join that uses the comma
        operator, but multiple-table <code class="literal">UPDATE</code>
        statements can use any type of join allowed in
        <code class="literal">SELECT</code> statements, such as <code class="literal">LEFT
        JOIN</code>.
      </p><p>
        You need the <code class="literal">UPDATE</code> privilege only for
        columns referenced in a multiple-table <code class="literal">UPDATE</code>
        that are actually updated. You need only the
        <code class="literal">SELECT</code> privilege for any columns that are
        read but not modified.
      </p><p>
        If you use a multiple-table <code class="literal">UPDATE</code> statement
        involving <code class="literal">InnoDB</code> tables for which there are
        foreign key constraints, the MySQL optimizer might process
        tables in an order that differs from that of their parent/child
        relationship. In this case, the statement fails and rolls back.
        Instead, update a single table and rely on the <code class="literal">ON
        UPDATE</code> capabilities that <code class="literal">InnoDB</code>
        provides to cause the other tables to be modified accordingly.
        See <a href="http://dev.mysql.com/doc/refman/5.0/en/innodb-foreign-key-constraints.html" target="_top"><code class="literal">FOREIGN KEY</code> Constraints</a>.
      </p><p>
        Currently, you cannot update a table and select from the same
        table in a subquery.
      </p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="basic-user-commands"></a>MySQL Utility Statements</h2></div></div></div><div class="toc"><dl><dt><span class="section"><a href="mysqlqb_statements.html#describe"><code class="literal">DESCRIBE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#help"><code class="literal">HELP</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#use"><code class="literal">USE</code> Syntax</a></span></dt></dl></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="describe"></a><code class="literal">DESCRIBE</code> Syntax</h3></div></div></div><a id="id2879569" class="indexterm"></a><a id="id2879575" class="indexterm"></a><pre class="programlisting">{DESCRIBE | DESC} <em class="replaceable"><code>tbl_name</code></em> [<em class="replaceable"><code>col_name</code></em> | <em class="replaceable"><code>wild</code></em>]
</pre><p>
        <code class="literal">DESCRIBE</code> provides information about the
        columns in a table. It is a shortcut for <code class="literal">SHOW COLUMNS
        FROM</code>. As of MySQL 5.0.1, these statements also display
        information for views. (See <a href="mysqlqb_statements.html#show-columns" title="SHOW COLUMNS Syntax"><code class="literal">SHOW COLUMNS</code> Syntax</a>.)
      </p><p>
        <em class="replaceable"><code>col_name</code></em> can be a column name, or a
        string containing the SQL ‘<code class="literal">%</code>’ and
        ‘<code class="literal">_</code>’ wildcard characters to obtain
        output only for the columns with names matching the string.
        There is no need to enclose the string within quotes unless it
        contains spaces or other special characters.
      </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>DESCRIBE city;</code></strong>
+------------+----------+------+-----+---------+----------------+
| Field      | Type     | Null | Key | Default | Extra          |
+------------+----------+------+-----+---------+----------------+
| Id         | int(11)  | NO   | PRI | NULL    | auto_increment |
| Name       | char(35) | NO   |     |         |                |
| Country    | char(3)  | NO   | UNI |         |                |
| District   | char(20) | YES  | MUL |         |                |
| Population | int(11)  | NO   |     | 0       |                |
+------------+----------+------+-----+---------+----------------+
5 rows in set (0.00 sec)
</pre><p>
        <code class="literal">Field</code> indicates the column name.
      </p><p>
        The <code class="literal">Null</code> field indicates whether
        <code class="literal">NULL</code> values can be stored in the column.
      </p><p>
        The <code class="literal">Key</code> field indicates whether the column is
        indexed. A value of <code class="literal">PRI</code> indicates that the
        column is part of the table's primary key.
        <code class="literal">UNI</code> indicates that the column is part of a
        <code class="literal">UNIQUE</code> index. The <code class="literal">MUL</code>
        value indicates that multiple occurrences of a given value are
        allowed within the column.
      </p><p>
        One reason for <code class="literal">MUL</code> to be displayed on a
        <code class="literal">UNIQUE</code> index is that several columns form a
        composite <code class="literal">UNIQUE</code> index; although the
        combination of the columns is unique, each column can still hold
        multiple occurrences of a given value. Note that in a composite
        index, only the leftmost column of the index has an entry in the
        <code class="literal">Key</code> field.
      </p><p>
        Before MySQL 5.0.11, if the column allows
        <code class="literal">NULL</code> values, the <code class="literal">Key</code> value
        can be <code class="literal">MUL</code> even when a
        <code class="literal">UNIQUE</code> index is used. The rationale was that
        multiple rows in a <code class="literal">UNIQUE</code> index can hold a
        <code class="literal">NULL</code> value if the column is not declared
        <code class="literal">NOT NULL</code>. As of MySQL 5.0.11, the display is
        <code class="literal">UNI</code> rather than <code class="literal">MUL</code>
        regardless of whether the column allows <code class="literal">NULL</code>;
        you can see from the <code class="literal">Null</code> field whether or
        not the column can contain <code class="literal">NULL</code>.
      </p><p>
        The <code class="literal">Default</code> field indicates the default value
        that is assigned to the column.
      </p><p>
        The <code class="literal">Extra</code> field contains any additional
        information that is available about a given column. In the
        example shown, the <code class="literal">Extra</code> field indicates that
        the <code class="literal">Id</code> column was created with the
        <code class="literal">AUTO_INCREMENT</code> keyword.
      </p><p>
        If the data types are different from what you expect them to be
        based on a <code class="literal">CREATE TABLE</code> statement, note that
        MySQL sometimes changes data types. See
        <a href="mysqlqb_statements.html#silent-column-changes" title="Silent Column Specification Changes">Silent Column Specification Changes</a>.
      </p><a id="id2879852" class="indexterm"></a><a id="id2879859" class="indexterm"></a><p>
        The <code class="literal">DESCRIBE</code> statement is provided for
        compatibility with Oracle.
      </p><p>
        The <code class="literal">SHOW CREATE TABLE</code> and <code class="literal">SHOW TABLE
        STATUS</code> statements also provide information about
        tables. See <a href="mysqlqb_statements.html#show" title="SHOW Syntax"><code class="literal">SHOW</code> Syntax</a>.
      </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="help"></a><code class="literal">HELP</code> Syntax</h3></div></div></div><a id="id2879906" class="indexterm"></a><pre class="programlisting">HELP '<em class="replaceable"><code>search_string</code></em>'
</pre><p>
        The <code class="literal">HELP</code> statement returns online information
        from the MySQL Reference manual. Its proper operation requires
        that the help tables in the <code class="literal">mysql</code> database be
        initialized with help topic information (see
        <a href="http://dev.mysql.com/doc/refman/5.0/en/server-side-help-support.html" target="_top">Server-Side Help</a>).
      </p><p>
        The <code class="literal">HELP</code> statement searches the help tables
        for the given search string and displays the result of the
        search. The search string is not case sensitive.
      </p><p>
        The HELP statement understands several types of search strings:
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            At the most general level, use <code class="literal">contents</code>
            to retrieve a list of the top-level help categories:
          </p><pre class="programlisting">HELP 'contents'
</pre></li><li><p>
            For a list of topics in a given help category, such as
            <code class="literal">Data Types</code>, use the category name:
          </p><pre class="programlisting">HELP 'data types'
</pre></li><li><p>
            For help on a specific help topic, such as the
            <code class="literal">ASCII()</code> function or the <code class="literal">CREATE
            TABLE</code> statement, use the associated keyword or
            keywords:
          </p><pre class="programlisting">HELP 'ascii'
HELP 'create table'
</pre></li></ul></div><p>
        In other words, the search string matches a category, many
        topics, or a single topic. You cannot necessarily tell in
        advance whether a given search string will return a list of
        items or the help information for a single help topic. However,
        you can tell what kind of response <code class="literal">HELP</code>
        returned by examining the number of rows and columns in the
        result set.
      </p><p>
        The following descriptions indicate the forms that the result
        set can take. Output for the example statements is shown using
        the familar “<span class="quote">tabular</span>” or “<span class="quote">vertical</span>”
        format that you see when using the <span><strong class="command">mysql</strong></span>
        client, but note that <span><strong class="command">mysql</strong></span> itself reformats
        <code class="literal">HELP</code> result sets in a different way.
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            Empty result set
          </p><p>
            No match could be found for the search string.
          </p></li><li><p>
            Result set containing a single row with three columns
          </p><p>
            This means that the search string yielded a hit for the help
            topic. The result has three columns:
          </p><div class="itemizedlist"><ul type="circle"><li><p>
                <code class="literal">name</code>: The topic name.
              </p></li><li><p>
                <code class="literal">description</code>: Descriptive help text
                for the topic.
              </p></li><li><p>
                <code class="literal">example</code>: Usage example or exmples.
                This column might be blank.
              </p></li></ul></div><p>
            Example: <code class="literal">HELP 'replace'</code>
          </p><p>
            Yields:
          </p><pre class="programlisting">name: REPLACE
description: Syntax:
REPLACE(str,from_str,to_str)

Returns the string str with all occurrences of the string from_str
replaced by the string to_str. REPLACE() performs a case-sensitive
match when searching for from_str.
example: mysql&gt; SELECT REPLACE('www.mysql.com', 'w', 'Ww');
        -&gt; 'WwWwWw.mysql.com'
</pre></li><li><p>
            Result set containing multiple rows with two columns
          </p><p>
            This means that the search string matched many help topics.
            The result set indicates the help topic names:
          </p><div class="itemizedlist"><ul type="circle"><li><p>
                <code class="literal">name</code>: The help topic name.
              </p></li><li><p>
                <code class="literal">is_it_category</code>: <code class="literal">Y</code>
                if the name represents a help category,
                <code class="literal">N</code> if it does not. If it does not, the
                <code class="literal">name</code> value when specified as the
                argument to the <code class="literal">HELP</code> statement should
                yield a single-row result set containing a description
                for the named item.
              </p></li></ul></div><p>
            Example: <code class="literal">HELP 'status'</code>
          </p><p>
            Yields:
          </p><pre class="programlisting">+-----------------------+----------------+
| name                  | is_it_category |
+-----------------------+----------------+
| SHOW                  | N              |
| SHOW ENGINE           | N              |
| SHOW INNODB STATUS    | N              |
| SHOW MASTER STATUS    | N              |
| SHOW PROCEDURE STATUS | N              |
| SHOW SLAVE STATUS     | N              |
| SHOW STATUS           | N              |
| SHOW TABLE STATUS     | N              |
+-----------------------+----------------+
</pre></li><li><p>
            Result set containing multiple rows with three columns
          </p><p>
            This means the search string matches a category. The result
            set contains category entries:
          </p><div class="itemizedlist"><ul type="circle"><li><p>
                <code class="literal">source_category_name</code>: The help
                category name.
              </p></li><li><p>
                <code class="literal">name</code>: The category or topic name
              </p></li><li><p>
                <code class="literal">is_it_category</code>: <code class="literal">Y</code>
                if the name represents a help category,
                <code class="literal">N</code> if it does not. If it does not, the
                <code class="literal">name</code> value when specified as the
                argument to the <code class="literal">HELP</code> statement should
                yield a single-row result set containing a description
                for the named item.
              </p></li></ul></div><p>
            Example: <code class="literal">HELP 'functions'</code>
          </p><p>
            Yields:
          </p><pre class="programlisting">+----------------------+-------------------------+----------------+
| source_category_name | name                    | is_it_category |
+----------------------+-------------------------+----------------+
| Functions            | CREATE FUNCTION         | N              |
| Functions            | DROP FUNCTION           | N              |
| Functions            | Bit Functions           | Y              |
| Functions            | Comparison operators    | Y              |
| Functions            | Control flow functions  | Y              |
| Functions            | Date and Time Functions | Y              |
| Functions            | Encryption Functions    | Y              |
| Functions            | Information Functions   | Y              |
| Functions            | Logical operators       | Y              |
| Functions            | Miscellaneous Functions | Y              |
| Functions            | Numeric Functions       | Y              |
| Functions            | String Functions        | Y              |
+----------------------+-------------------------+----------------+
</pre></li></ul></div><p>
        If you intend to use the <code class="literal">HELP()</code> statement
        while other tables are locked with <code class="literal">LOCK
        TABLES</code>, you must also lock the required
        <code class="literal">mysql.help_<em class="replaceable"><code>xxx</code></em></code>
        tables.
      </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="use"></a><code class="literal">USE</code> Syntax</h3></div></div></div><a id="id2880376" class="indexterm"></a><pre class="programlisting">USE <em class="replaceable"><code>db_name</code></em>
</pre><p>
        The <code class="literal">USE <em class="replaceable"><code>db_name</code></em></code>
        statement tells MySQL to use the
        <em class="replaceable"><code>db_name</code></em> database as the default
        (current) database for subsequent statements. The database
        remains the default until the end of the session or another
        <code class="literal">USE</code> statement is issued:
      </p><pre class="programlisting">USE db1;
SELECT COUNT(*) FROM mytable;   # selects from db1.mytable
USE db2;
SELECT COUNT(*) FROM mytable;   # selects from db2.mytable
</pre><p>
        Making a particular database the default by means of the
        <code class="literal">USE</code> statement does not preclude you from
        accessing tables in other databases. The following example
        accesses the <code class="literal">author</code> table from the
        <code class="literal">db1</code> database and the
        <code class="literal">editor</code> table from the <code class="literal">db2</code>
        database:
      </p><pre class="programlisting">USE db1;
SELECT author_name,editor_name FROM author,db2.editor
  WHERE author.editor_id = db2.editor.editor_id;
</pre><a id="id2880446" class="indexterm"></a><a id="id2880453" class="indexterm"></a><p>
        The <code class="literal">USE</code> statement is provided for
        compatibility with Sybase.
      </p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="transactional-commands"></a>MySQL Transactional and Locking Statements</h2></div></div></div><div class="toc"><dl><dt><span class="section"><a href="mysqlqb_statements.html#commit"><code class="literal">START TRANSACTION</code>, <code class="literal">COMMIT</code>, and
        <code class="literal">ROLLBACK</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#cannot-roll-back">Statements That Cannot Be Rolled Back</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#implicit-commit">Statements That Cause an Implicit Commit</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#savepoints"><code class="literal">SAVEPOINT</code> and <code class="literal">ROLLBACK TO
        SAVEPOINT</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#lock-tables"><code class="literal">LOCK TABLES</code> and <code class="literal">UNLOCK TABLES</code>
        Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#set-transaction"><code class="literal">SET TRANSACTION</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#xa">XA Transactions</a></span></dt></dl></div><p>
      MySQL supports local transactions (within a given client
      connection) through statements such as <code class="literal">SET
      AUTOCOMMIT</code>, <code class="literal">START TRANSACTION</code>,
      <code class="literal">COMMIT</code>, and <code class="literal">ROLLBACK</code>. See
      <a href="mysqlqb_statements.html#commit" title="START TRANSACTION, COMMIT, and&#10;        ROLLBACK Syntax"><code class="literal">START TRANSACTION</code>, <code class="literal">COMMIT</code>, and
        <code class="literal">ROLLBACK</code> Syntax</a>. Beginning with MySQL 5.0, XA transaction
      support is available, which enables MySQL to participate in
      distributed transactions as well. See <a href="mysqlqb_statements.html#xa" title="XA Transactions">XA Transactions</a>.
    </p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="commit"></a><code class="literal">START TRANSACTION</code>, <code class="literal">COMMIT</code>, and
        <code class="literal">ROLLBACK</code> Syntax</h3></div></div></div><a id="id2880539" class="indexterm"></a><a id="id2880546" class="indexterm"></a><a id="id2880552" class="indexterm"></a><a id="id2880559" class="indexterm"></a><pre class="programlisting">START TRANSACTION | BEGIN [WORK]
COMMIT [WORK] [AND [NO] CHAIN] [[NO] RELEASE]
ROLLBACK [WORK] [AND [NO] CHAIN] [[NO] RELEASE]
SET AUTOCOMMIT = {0 | 1}
</pre><p>
        The <code class="literal">START TRANSACTION</code> and
        <code class="literal">BEGIN</code> statement begin a new transaction.
        <code class="literal">COMMIT</code> commits the current transaction,
        making its changes permanent. <code class="literal">ROLLBACK</code> rolls
        back the current transaction, canceling its changes. The
        <code class="literal">SET AUTOCOMMIT</code> statement disables or enables
        the default autocommit mode for the current connection.
      </p><p>
        Beginning with MySQL 5.0.3, the optional <code class="literal">WORK</code>
        keyword is supported for <code class="literal">COMMIT</code> and
        <code class="literal">ROLLBACK</code>, as are the <code class="literal">CHAIN</code>
        and <code class="literal">RELEASE</code> clauses. <code class="literal">CHAIN</code>
        and <code class="literal">RELEASE</code> can be used for additional
        control over transaction completion. The value of the
        <code class="literal">completion_type</code> system variable determines
        the default completion behavior. See
        <a href="http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html" target="_top">System Variables</a>.
      </p><p>
        The <code class="literal">AND CHAIN</code> clause causes a new transaction
        to begin as soon as the current one ends, and the new
        transaction has the same isolation level as the just-terminated
        transaction. The <code class="literal">RELEASE</code> clause causes the
        server to disconnect the current client connection after
        terminating the current transaction. Including the
        <code class="literal">NO</code> keyword suppresses
        <code class="literal">CHAIN</code> or <code class="literal">RELEASE</code>
        completion, which can be useful if the
        <code class="literal">completion_type</code> system variable is set to
        cause chaining or release completion by default.
      </p><p>
        By default, MySQL runs with autocommit mode enabled. This means
        that as soon as you execute a statement that updates (modifies)
        a table, MySQL stores the update on disk.
      </p><p>
        If you are using a transaction-safe storage engine (such as
        <code class="literal">InnoDB</code>, <code class="literal">BDB</code>, or
        <code class="literal">NDB Cluster</code>), you can disable autocommit mode
        with the following statement:
      </p><pre class="programlisting">SET AUTOCOMMIT=0;
</pre><p>
        After disabling autocommit mode by setting the
        <code class="literal">AUTOCOMMIT</code> variable to zero, you must use
        <code class="literal">COMMIT</code> to store your changes to disk or
        <code class="literal">ROLLBACK</code> if you want to ignore the changes
        you have made since the beginning of your transaction.
      </p><p>
        To disable autocommit mode for a single series of statements,
        use the <code class="literal">START TRANSACTION</code> statement:
      </p><pre class="programlisting">START TRANSACTION;
SELECT @A:=SUM(salary) FROM table1 WHERE type=1;
UPDATE table2 SET summary=@A WHERE type=1;
COMMIT;
</pre><p>
        With <code class="literal">START TRANSACTION</code>, autocommit remains
        disabled until you end the transaction with
        <code class="literal">COMMIT</code> or <code class="literal">ROLLBACK</code>. The
        autocommit mode then reverts to its previous state.
      </p><p>
        <code class="literal">BEGIN</code> and <code class="literal">BEGIN WORK</code> are
        supported as aliases of <code class="literal">START TRANSACTION</code> for
        initiating a transaction. <code class="literal">START TRANSACTION</code>
        is standard SQL syntax and is the recommended way to start an
        ad-hoc transaction.
      </p><p>
        <span class="bold"><strong>Important</strong></span>: Many APIs used for
        writing MySQL client applications (such as JDBC) provide their
        own methods for starting transactions that can (and sometimes
        should) be used instead of sending a <code class="literal">START
        TRANSACTION</code> statement from the client. See
        <a href="http://dev.mysql.com/doc/refman/5.0/en/apis.html" target="_top">APIs and Libraries</a>, or the documentation for your API, for
        more information.
      </p><p>
        The <code class="literal">BEGIN</code> statement differs from the use of
        the <code class="literal">BEGIN</code> keyword that starts a
        <code class="literal">BEGIN ... END</code> compound statement. The latter
        does not begin a transaction. See <a href="http://dev.mysql.com/doc/refman/5.0/en/begin-end.html" target="_top"><code class="literal">BEGIN ... END</code> Compound Statement Syntax</a>.
      </p><p>
        You can also begin a transaction like this:
      </p><pre class="programlisting">START TRANSACTION WITH CONSISTENT SNAPSHOT;
</pre><p>
        The <code class="literal">WITH CONSISTENT SNAPSHOT</code> clause starts a
        consistent read for storage engines that are capable of it.
        Currently, this applies only to <code class="literal">InnoDB</code>. The
        effect is the same as issuing a <code class="literal">START
        TRANSACTION</code> followed by a <code class="literal">SELECT</code>
        from any <code class="literal">InnoDB</code> table. See
        <a href="http://dev.mysql.com/doc/refman/5.0/en/innodb-consistent-read.html" target="_top">Consistent Non-Locking Read</a>.
      </p><p>
        The <code class="literal">WITH CONSISTENT SNAPSHOT</code> clause does not
        change the current transaction isolation level, so it provides a
        consistent snapshot only if the current isolation level is one
        that allows consistent read (<code class="literal">REPEATABLE READ</code>
        or <code class="literal">SERIALIZABLE</code>).
      </p><p>
        Beginning a transaction causes any pending transaction to be
        committed. See <a href="mysqlqb_statements.html#implicit-commit" title="Statements That Cause an Implicit Commit">Statements That Cause an Implicit Commit</a>, for more
        information.
      </p><p>
        Beginning a transaction also causes table locks acquired with
        <code class="literal">LOCK TABLES</code> to be released, as though you had
        executed <code class="literal">UNLOCK TABLES</code>. Beginning a
        transaction does not release a global read lock acquired with
        <code class="literal">FLUSH TABLES WITH READ LOCK</code>.
      </p><p>
        For best results, transactions should be performed using only
        tables managed by a single transactional storage engine.
        Otherwise, the following problems can occur:
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            If you use tables from more than one transaction-safe
            storage engine (such as <code class="literal">InnoDB</code> and
            <code class="literal">BDB</code>), and the transaction isolation level
            is not <code class="literal">SERIALIZABLE</code>, it is possible that
            when one transaction commits, another ongoing transaction
            that uses the same tables will see only some of the changes
            made by the first transaction. That is, the atomicity of
            transactions is not guaranteed with mixed engines and
            inconsistencies can result. (If mixed-engine transactions
            are infrequent, you can use <code class="literal">SET TRANSACTION
            ISOLATION LEVEL</code> to set the isolation level to
            <code class="literal">SERIALIZABLE</code> on a per-transaction basis
            as necessary.)
          </p></li><li><p>
            If you use non-transaction-safe tables within a transaction,
            any changes to those tables are stored at once, regardless
            of the status of autocommit mode.
          </p><p>
            If you issue a <code class="literal">ROLLBACK</code> statement after
            updating a non-transactional table within a transaction, an
            <code class="literal">ER_WARNING_NOT_COMPLETE_ROLLBACK</code> warning
            occurs. Changes to transaction-safe tables are rolled back,
            but not changes to non-transaction-safe tables.
          </p></li></ul></div><p>
        Each transaction is stored in the binary log in one chunk, upon
        <code class="literal">COMMIT</code>. Transactions that are rolled back are
        not logged. (<span class="bold"><strong>Exception</strong></span>:
        Modifications to non-transactional tables cannot be rolled back.
        If a transaction that is rolled back includes modifications to
        non-transactional tables, the entire transaction is logged with
        a <code class="literal">ROLLBACK</code> statement at the end to ensure
        that the modifications to those tables are replicated.) See
        <a href="http://dev.mysql.com/doc/refman/5.0/en/binary-log.html" target="_top">The Binary Log</a>.
      </p><p>
        You can change the isolation level for transactions with
        <code class="literal">SET TRANSACTION ISOLATION LEVEL</code>. See
        <a href="mysqlqb_statements.html#set-transaction" title="SET TRANSACTION Syntax"><code class="literal">SET TRANSACTION</code> Syntax</a>.
      </p><p>
        Rolling back can be a slow operation that may occur without the
        user having explicitly asked for it (for example, when an error
        occurs). Because of this, <code class="literal">SHOW PROCESSLIST</code>
        displays <code class="literal">Rolling back</code> in the
        <code class="literal">State</code> column for the connection during
        implicit and explicit (<code class="literal">ROLLBACK</code> SQL
        statement) rollbacks.
      </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="cannot-roll-back"></a>Statements That Cannot Be Rolled Back</h3></div></div></div><p>
        Some statements cannot be rolled back. In general, these include
        data definition language (DDL) statements, such as those that
        create or drop databases, those that create, drop, or alter
        tables or stored routines.
      </p><p>
        You should design your transactions not to include such
        statements. If you issue a statement early in a transaction that
        cannot be rolled back, and then another statement later fails,
        the full effect of the transaction cannot be rolled back in such
        cases by issuing a <code class="literal">ROLLBACK</code> statement.
      </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="implicit-commit"></a>Statements That Cause an Implicit Commit</h3></div></div></div><p>
        Each of the following statements (and any synonyms for them)
        implicitly end a transaction, as if you had done a
        <code class="literal">COMMIT</code> before executing the statement:
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            <code class="literal">ALTER TABLE</code>, <code class="literal">BEGIN</code>,
            <code class="literal">CREATE INDEX</code>, <code class="literal">DROP
            INDEX</code>, <code class="literal">DROP TABLE</code>,
            <code class="literal">LOAD MASTER DATA</code>, <code class="literal">LOCK
            TABLES</code>, <code class="literal">LOAD DATA INFILE</code>,
            <code class="literal">RENAME TABLE</code>, <code class="literal">SET
            AUTOCOMMIT=1</code>, <code class="literal">START
            TRANSACTION</code>, <code class="literal">UNLOCK TABLES</code>.
          </p></li><li><p>
            Beginning with MySQL 5.0.8, The <code class="literal">CREATE
            TABLE</code>, <code class="literal">CREATE DATABASE</code>
            <code class="literal">DROP DATABASE</code>, and <code class="literal">TRUNCATE
            TABLE</code> statements cause an implicit commit.
            Beginning with MySQL 5.0.13, the <code class="literal">ALTER
            FUNCTION</code>, <code class="literal">ALTER PROCEDURE</code>,
            <code class="literal">CREATE FUNCTION</code>, <code class="literal">CREATE
            PROCEDURE</code>, <code class="literal">DROP FUNCTION</code>, and
            <code class="literal">DROP PROCEDURE</code> statements cause an
            implicit commit. Beginning with MySQL 5.0.15, the
            <code class="literal">ALTER VIEW</code>, <code class="literal">CREATE
            TRIGGER</code>, <code class="literal">CREATE USER</code>,
            <code class="literal">CREATE VIEW</code>, <code class="literal">DROP
            TRIGGER</code>, <code class="literal">DROP USER</code>,
            <code class="literal">DROP VIEW</code>, and <code class="literal">RENAME
            USER</code> statements cause an implicit commit.
          </p></li><li><p>
            <code class="literal">UNLOCK TABLES</code> commits a transaction only
            if any tables currently have been locked with <code class="literal">LOCK
            TABLES</code>. This does not occur for <code class="literal">UNLOCK
            TABLES</code> following <code class="literal">FLUSH TABLES WITH READ
            LOCK</code> because the latter statement does not acquire
            table-level locks.
          </p></li><li><p>
            The <code class="literal">CREATE TABLE</code> statement in
            <code class="literal">InnoDB</code> is processed as a single
            transaction. This means that a <code class="literal">ROLLBACK</code>
            from the user does not undo <code class="literal">CREATE TABLE</code>
            statements the user made during that transaction.
          </p></li><li><p>
            <code class="literal">CREATE TABLE</code> and <code class="literal">DROP
            TABLE</code> do not commit a transaction if the
            <code class="literal">TEMPORARY</code> keyword is used. (This does not
            apply to other operations on temporary tables such as
            <code class="literal">CREATE INDEX</code>, which do cause a commit.)
          </p></li><li><p>
            In MySQL 5.0.25 and earlier, <code class="literal">LOAD DATA
            INFILE</code> caused an implicit commit for all storage
            engines. Beginning with MySQL 5.0.26, it causes an implicit
            commit only for tables using the <code class="literal">NDB</code>
            storage engine. For more information, see <a href="http://bugs.mysql.com/11151" target="_top">Bug#11151</a>.
          </p></li></ul></div><p>
        Transactions cannot be nested. This is a consequence of the
        implicit <code class="literal">COMMIT</code> performed for any current
        transaction when you issue a <code class="literal">START
        TRANSACTION</code> statement or one of its synonyms.
      </p><p>
        Statements that cause implicit cannot be used in an XA
        transaction while the transaction is in an
        <code class="literal">ACTIVE</code> state.
      </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="savepoints"></a><code class="literal">SAVEPOINT</code> and <code class="literal">ROLLBACK TO
        SAVEPOINT</code> Syntax</h3></div></div></div><a id="id2881418" class="indexterm"></a><a id="id2881424" class="indexterm"></a><a id="id2881431" class="indexterm"></a><pre class="programlisting">SAVEPOINT <em class="replaceable"><code>identifier</code></em>
ROLLBACK [WORK] TO SAVEPOINT <em class="replaceable"><code>identifier</code></em>
RELEASE SAVEPOINT <em class="replaceable"><code>identifier</code></em>
</pre><p>
        <code class="literal">InnoDB</code> supports the SQL statements
        <code class="literal">SAVEPOINT</code> and <code class="literal">ROLLBACK TO
        SAVEPOINT</code>. Starting from MySQL 5.0.3, <code class="literal">RELEASE
        SAVEPOINT</code> and the optional <code class="literal">WORK</code>
        keyword for <code class="literal">ROLLBACK</code> are supported as well.
      </p><p>
        The <code class="literal">SAVEPOINT</code> statement sets a named
        transaction savepoint with a name of
        <em class="replaceable"><code>identifier</code></em>. If the current
        transaction has a savepoint with the same name, the old
        savepoint is deleted and a new one is set.
      </p><p>
        The <code class="literal">ROLLBACK TO SAVEPOINT</code> statement rolls
        back a transaction to the named savepoint. Modifications that
        the current transaction made to rows after the savepoint was set
        are undone in the rollback, but <code class="literal">InnoDB</code> does
        <span class="emphasis"><em>not</em></span> release the row locks that were stored
        in memory after the savepoint. (Note that for a new inserted
        row, the lock information is carried by the transaction ID
        stored in the row; the lock is not separately stored in memory.
        In this case, the row lock is released in the undo.) Savepoints
        that were set at a later time than the named savepoint are
        deleted.
      </p><p>
        If the <code class="literal">ROLLBACK TO SAVEPOINT</code> statement
        returns the following error, it means that no savepoint with the
        specified name exists:
      </p><pre class="programlisting">ERROR 1181: Got error 153 during ROLLBACK
</pre><p>
        The <code class="literal">RELEASE SAVEPOINT</code> statement removes the
        named savepoint from the set of savepoints of the current
        transaction. No commit or rollback occurs. It is an error if the
        savepoint does not exist.
      </p><p>
        All savepoints of the current transaction are deleted if you
        execute a <code class="literal">COMMIT</code>, or a
        <code class="literal">ROLLBACK</code> that does not name a savepoint.
      </p><p>
        Beginning with MySQL 5.0.17, a new savepoint level is created
        when a stored function is invoked or a trigger is activated. The
        savepoints on previous levels become unavailable and thus do not
        conflict with savepoints on the new level. When the function or
        trigger terminates, any savepoints it created are released and
        the previous savepoint level is restored.
      </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="lock-tables"></a><code class="literal">LOCK TABLES</code> and <code class="literal">UNLOCK TABLES</code>
        Syntax</h3></div></div></div><a id="id2881624" class="indexterm"></a><a id="id2881630" class="indexterm"></a><pre class="programlisting">LOCK TABLES
    <em class="replaceable"><code>tbl_name</code></em> [AS <em class="replaceable"><code>alias</code></em>]
      {READ [LOCAL] | [LOW_PRIORITY] WRITE}
    [, <em class="replaceable"><code>tbl_name</code></em> [AS <em class="replaceable"><code>alias</code></em>]
      {READ [LOCAL] | [LOW_PRIORITY] WRITE}] ...
UNLOCK TABLES
</pre><p>
        <code class="literal">LOCK TABLES</code> locks base tables (but not views)
        for the current thread. If any of the tables are locked by other
        threads, it blocks until all locks can be acquired.
      </p><p>
        <code class="literal">UNLOCK TABLES</code> explicitly releases any locks
        held by the current thread. All tables that are locked by the
        current thread are implicitly unlocked when the thread issues
        another <code class="literal">LOCK TABLES</code>, or when the connection
        to the server is closed. <code class="literal">UNLOCK TABLES</code> is
        also used after acquiring a global read lock with <code class="literal">FLUSH
        TABLES WITH READ LOCK</code> to release that lock. (You can
        lock all tables in all databases with read locks with the
        <code class="literal">FLUSH TABLES WITH READ LOCK</code> statement. See
        <a href="mysqlqb_statements.html#flush" title="FLUSH Syntax"><code class="literal">FLUSH</code> Syntax</a>. This is a very convenient way to get
        backups if you have a filesystem such as Veritas that can take
        snapshots in time.)
      </p><p>
        To use <code class="literal">LOCK TABLES</code>, you must have the
        <code class="literal">LOCK TABLES</code> privilege and the
        <code class="literal">SELECT</code> privilege for the involved tables.
      </p><p>
        The main reasons to use <code class="literal">LOCK TABLES</code> are to
        emulate transactions or to get more speed when updating tables.
        This is explained in more detail later.
      </p><p>
        A table lock protects only against inappropriate reads or writes
        by other clients. The client holding the lock, even a read lock,
        can perform table-level operations such as <code class="literal">DROP
        TABLE</code>. Truncate operations are not transaction-safe,
        so an error occurs if the client attempts one during an active
        transaction or while holding a table lock.
      </p><p>
        Note the following regarding the use of <code class="literal">LOCK
        TABLES</code> with transactional tables:
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            <code class="literal">LOCK TABLES</code> is not transaction-safe and
            implicitly commits any active transactions before attempting
            to lock the tables. Also, beginning a transaction (for
            example, with <code class="literal">START TRANSACTION</code>)
            implicitly performs an <code class="literal">UNLOCK TABLES</code>.
            (See <a href="mysqlqb_statements.html#implicit-commit" title="Statements That Cause an Implicit Commit">Statements That Cause an Implicit Commit</a>.)
          </p></li><li><p>
            The correct way to use <code class="literal">LOCK TABLES</code> with
            transactional tables, such as <code class="literal">InnoDB</code>
            tables, is to set <code class="literal">AUTOCOMMIT = 0</code> and not
            to call <code class="literal">UNLOCK TABLES</code> until you commit
            the transaction explicitly. When you call <code class="literal">LOCK
            TABLES</code>, <code class="literal">InnoDB</code> internally takes
            its own table lock, and MySQL takes its own table lock.
            <code class="literal">InnoDB</code> releases its table lock at the
            next commit, but for MySQL to release its table lock, you
            have to call <code class="literal">UNLOCK TABLES</code>. You should
            not have <code class="literal">AUTOCOMMIT = 1</code>, because then
            <code class="literal">InnoDB</code> releases its table lock
            immediately after the call of <code class="literal">LOCK
            TABLES</code>, and deadlocks can very easily happen. Note
            that we do not acquire the <code class="literal">InnoDB</code> table
            lock at all if <code class="literal">AUTOCOMMIT=1</code>, to help old
            applications avoid unnecessary deadlocks.
          </p></li><li><p>
            <code class="literal">ROLLBACK</code> does not release MySQL's
            non-transactional table locks.
          </p></li><li><p>
            <code class="literal">FLUSH TABLES WITH READ LOCK</code> acquires a
            global read lock and not table locks, so it is not subject
            to the same behavior as <code class="literal">LOCK TABLES</code> and
            <code class="literal">UNLOCK TABLES</code> with respect to table
            locking and implicit commits. See <a href="mysqlqb_statements.html#flush" title="FLUSH Syntax"><code class="literal">FLUSH</code> Syntax</a>.
          </p></li></ul></div><p>
        When you use <code class="literal">LOCK TABLES</code>, you must lock all
        tables that you are going to use in your statements. Because
        <code class="literal">LOCK TABLES</code> will not lock views, if the
        operation that you are performing uses any views, you must also
        lock all of the base tables on which those views depend. While
        the locks obtained with a <code class="literal">LOCK TABLES</code>
        statement are in effect, you cannot access any tables that were
        not locked by the statement. Also, you cannot use a locked table
        multiple times in a single query. Use aliases instead, in which
        case you must obtain a lock for each alias separately.
      </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>LOCK TABLE t WRITE, t AS t1 WRITE;</code></strong>
mysql&gt; <strong class="userinput"><code>INSERT INTO t SELECT * FROM t;</code></strong>
ERROR 1100: Table 't' was not locked with LOCK TABLES
mysql&gt; <strong class="userinput"><code>INSERT INTO t SELECT * FROM t AS t1;</code></strong>
</pre><p>
        If your statements refer to a table by means of an alias, you
        must lock the table using that same alias. It does not work to
        lock the table without specifying the alias:
      </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>LOCK TABLE t READ;</code></strong>
mysql&gt; <strong class="userinput"><code>SELECT * FROM t AS myalias;</code></strong>
ERROR 1100: Table 'myalias' was not locked with LOCK TABLES
</pre><p>
        Conversely, if you lock a table using an alias, you must refer
        to it in your statements using that alias:
      </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>LOCK TABLE t AS myalias READ;</code></strong>
mysql&gt; <strong class="userinput"><code>SELECT * FROM t;</code></strong>
ERROR 1100: Table 't' was not locked with LOCK TABLES
mysql&gt; <strong class="userinput"><code>SELECT * FROM t AS myalias;</code></strong>
</pre><p>
        If a thread obtains a <code class="literal">READ</code> lock on a table,
        that thread (and all other threads) can only read from the
        table. If a thread obtains a <code class="literal">WRITE</code> lock on a
        table, only the thread holding the lock can write to the table.
        Other threads are blocked from reading or writing the table
        until the lock has been released.
      </p><p>
        The difference between <code class="literal">READ LOCAL</code> and
        <code class="literal">READ</code> is that <code class="literal">READ LOCAL</code>
        allows non-conflicting <code class="literal">INSERT</code> 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.
        For <code class="literal">InnoDB</code> tables, <code class="literal">READ
        LOCAL</code> is the same as <code class="literal">READ</code> as of
        MySQL 5.0.13. (Before that, <code class="literal">READ LOCAL</code>
        essentially does nothing: It does not lock the table at all, so
        for <code class="literal">InnoDB</code> tables, the use of <code class="literal">READ
        LOCAL</code> is deprecated because a plain consistent-read
        <code class="literal">SELECT</code> does the same thing, and no locks are
        needed.)
      </p><p>
        <code class="literal">WRITE</code> locks normally have higher priority
        than <code class="literal">READ</code> locks to ensure that updates are
        processed as soon as possible. This means that if one thread
        obtains a <code class="literal">READ</code> lock and then another thread
        requests a <code class="literal">WRITE</code> lock, subsequent
        <code class="literal">READ</code> lock requests wait until the
        <code class="literal">WRITE</code> thread has gotten the lock and released
        it. You can use <code class="literal">LOW_PRIORITY WRITE</code> locks to
        allow other threads to obtain <code class="literal">READ</code> locks
        before the thread that is waiting for the
        <code class="literal">WRITE</code> lock. You should use
        <code class="literal">LOW_PRIORITY WRITE</code> locks only if you are sure
        that eventually there will be a time when no threads have a
        <code class="literal">READ</code> lock. (Exception: For
        <code class="literal">InnoDB</code> tables in transactional mode
        (autocommit = 0), a <code class="literal">LOW_PRIORITY WRITE</code> lock
        acts like a regular <code class="literal">WRITE</code> lock and precedes
        waiting <code class="literal">READ</code> locks.)
      </p><p>
        <code class="literal">LOCK TABLES</code> works as follows:
      </p><div class="orderedlist"><ol type="1"><li><p>
            Sort all tables to be locked in an internally defined order.
            From the user standpoint, this order is undefined.
          </p></li><li><p>
            If a table is to be locked with a read and a write lock, put
            the write lock before the read lock.
          </p></li><li><p>
            Lock one table at a time until the thread gets all locks.
          </p></li></ol></div><p>
        This policy ensures that table locking is deadlock free. There
        are, however, other things you need to be aware of about this
        policy: If you are using a <code class="literal">LOW_PRIORITY WRITE</code>
        lock for a table, it means only that MySQL waits for this
        particular lock until there are no threads that want a
        <code class="literal">READ</code> lock. When the thread has gotten the
        <code class="literal">WRITE</code> lock and is waiting to get the lock for
        the next table in the lock table list, all other threads wait
        for the <code class="literal">WRITE</code> lock to be released. If this
        becomes a serious problem with your application, you should
        consider converting some of your tables to transaction-safe
        tables.
      </p><p>
        You can safely use <code class="literal">KILL</code> to terminate a thread
        that is waiting for a table lock. See <a href="mysqlqb_statements.html#kill" title="KILL Syntax"><code class="literal">KILL</code> Syntax</a>.
      </p><p>
        Note that you should <span class="emphasis"><em>not</em></span> lock any tables
        that you are using with <code class="literal">INSERT DELAYED</code>
        because in that case the <code class="literal">INSERT</code> is performed
        by a separate thread.
      </p><p>
        Normally, you do not need to lock tables, because all single
        <code class="literal">UPDATE</code> statements are atomic; no other thread
        can interfere with any other currently executing SQL statement.
        However, there are a few cases when locking tables may provide
        an advantage:
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            If you are going to run many operations on a set of
            <code class="literal">MyISAM</code> tables, it is much faster to lock
            the tables you are going to use. Locking
            <code class="literal">MyISAM</code> tables speeds up inserting,
            updating, or deleting on them because MySQL does not flush
            the key cache for the locked tables until <code class="literal">UNLOCK
            TABLES</code> is called. Normally, the key cache is
            flushed after each SQL statement.
          </p><p>
            The downside to locking the tables is that no thread can
            update a <code class="literal">READ</code>-locked table (including the
            one holding the lock) and no thread can access a
            <code class="literal">WRITE</code>-locked table other than the one
            holding the lock.
          </p></li><li><p>
            If you are using tables for a non-transactional storage
            engine, you must use <code class="literal">LOCK TABLES</code> if you
            want to ensure that no other thread modifies the tables
            between a <code class="literal">SELECT</code> and an
            <code class="literal">UPDATE</code>. The example shown here requires
            <code class="literal">LOCK TABLES</code> to execute safely:
          </p><pre class="programlisting">LOCK TABLES trans READ, customer WRITE;
SELECT SUM(value) FROM trans WHERE customer_id=<em class="replaceable"><code>some_id</code></em>;
UPDATE customer
  SET total_value=<em class="replaceable"><code>sum_from_previous_statement</code></em>
  WHERE customer_id=<em class="replaceable"><code>some_id</code></em>;
UNLOCK TABLES;
</pre><p>
            Without <code class="literal">LOCK TABLES</code>, it is possible that
            another thread might insert a new row in the
            <code class="literal">trans</code> table between execution of the
            <code class="literal">SELECT</code> and <code class="literal">UPDATE</code>
            statements.
          </p></li></ul></div><p>
        You can avoid using <code class="literal">LOCK TABLES</code> in many cases
        by using relative updates (<code class="literal">UPDATE customer SET
        <em class="replaceable"><code>value</code></em>=<em class="replaceable"><code>value</code></em>+<em class="replaceable"><code>new_value</code></em></code>)
        or the <code class="literal">LAST_INSERT_ID()</code> function. See
        <a href="http://dev.mysql.com/doc/refman/5.0/en/ansi-diff-transactions.html" target="_top">Transactions and Atomic Operations</a>.
      </p><p>
        You can also avoid locking tables in some cases by using the
        user-level advisory lock functions <code class="literal">GET_LOCK()</code>
        and <code class="literal">RELEASE_LOCK()</code>. These locks are saved in
        a hash table in the server and implemented with
        <code class="literal">pthread_mutex_lock()</code> and
        <code class="literal">pthread_mutex_unlock()</code> for high speed. See
        <a href="mysqlqb_functions.html#miscellaneous-functions" title="Miscellaneous Functions">Miscellaneous Functions</a>.
      </p><p>
        See <a href="http://dev.mysql.com/doc/refman/5.0/en/internal-locking.html" target="_top">Internal Locking Methods</a>, for more information on
        locking policy.
      </p><p>
        <span class="bold"><strong>Note</strong></span>: If you use <code class="literal">ALTER
        TABLE</code> on a locked table, it may become unlocked. See
        <a href="http://dev.mysql.com/doc/refman/5.0/en/alter-table-problems.html" target="_top">Problems with <code class="literal">ALTER TABLE</code></a>.
      </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="set-transaction"></a><code class="literal">SET TRANSACTION</code> Syntax</h3></div></div></div><a id="id2882458" class="indexterm"></a><a id="id2882465" class="indexterm"></a><pre class="programlisting">SET [GLOBAL | SESSION] TRANSACTION ISOLATION LEVEL
{ READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE }
</pre><p>
        This statement sets the transaction isolation level for the next
        transaction, globally, or for the current session.
      </p><p>
        The default behavior of <code class="literal">SET TRANSACTION</code> is to
        set the isolation level for the next (not yet started)
        transaction. If you use the <code class="literal">GLOBAL</code> keyword,
        the statement sets the default transaction level globally for
        all new connections created from that point on. Existing
        connections are unaffected. You need the
        <code class="literal">SUPER</code> privilege to do this. Using the
        <code class="literal">SESSION</code> keyword sets the default transaction
        level for all future transactions performed on the current
        connection.
      </p><p>
        For descriptions of each <code class="literal">InnoDB</code> transaction
        isolation level, see
        <a href="http://dev.mysql.com/doc/refman/5.0/en/innodb-transaction-isolation.html" target="_top"><code class="literal">InnoDB</code> and <code class="literal">TRANSACTION ISOLATION  LEVEL</code></a>.
        <code class="literal">InnoDB</code> supports each of these levels in MySQL
        5.0. The default level is <code class="literal">REPEATABLE
        READ</code>.
      </p><p>
        To set the initial default global isolation level for
        <span><strong class="command">mysqld</strong></span>, use the
        <code class="option">--transaction-isolation</code> option. See
        <a href="http://dev.mysql.com/doc/refman/5.0/en/server-options.html" target="_top">Command Options</a>.
      </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="xa"></a>XA Transactions</h3></div></div></div><div class="toc"><dl><dt><span class="section"><a href="mysqlqb_statements.html#xa-statements">XA Transaction SQL Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#xa-states">XA Transaction States</a></span></dt></dl></div><a id="id2882595" class="indexterm"></a><p>
        MySQL 5.0.3 and up provides server-side support for XA
        transactions. Currently, this support is available for the
        <code class="literal">InnoDB</code> storage engine. The MySQL XA
        implementation is based on the X/Open CAE document
        <em class="citetitle">Distributed Transaction Processing: The XA
        Specification</em>. This document is published by The
        Open Group and available at
        <a href="http://www.opengroup.org/public/pubs/catalog/c193.htm" target="_top">http://www.opengroup.org/public/pubs/catalog/c193.htm</a>.
        Limitations of the current XA implementation are described in
        <a href="http://dev.mysql.com/doc/refman/5.0/en/xa-restrictions.html" target="_top">Restrictions on XA Transactions</a>.
      </p><p>
        On the client side, there are no special requirements. The XA
        interface to a MySQL server consists of SQL statements that
        begin with the <code class="literal">XA</code> keyword. MySQL client
        programs must be able to send SQL statements and to understand
        the semantics of the XA statement interface. They do not need be
        linked against a recent client library. Older client libraries
        also will work.
      </p><p>
        Currently, among the MySQL Connectors, MySQL Connector/J 5.0.0
        supports XA directly (by means of a class interface that handles
        the XA SQL statement interface for you).
      </p><p>
        XA supports distributed transactions; that is, the ability to
        allow multiple separate transactional resources to participate
        in a global transaction. Transactional resources often are
        RDBMSs but may be other kinds of resources.
      </p><p class="mnmas"><b>MySQL Enterprise. </b>
          For expert advice on XA Distributed Transaction Support
          subscribe to the MySQL Network Monitoring and Advisory
          Service. For more information see,
          <a href="http://www.mysql.com/products/enterprise/advisors.html" target="_top">http://www.mysql.com/products/enterprise/advisors.html</a>.
        </p><p>
        A global transaction involves several actions that are
        transactional in themselves, but that all must either complete
        successfully as a group, or all be rolled back as a group. In
        essence, this extends ACID properties “<span class="quote">up a level</span>”
        so that multiple ACID transactions can be executed in concert as
        components of a global operation that also has ACID properties.
        (However, for a distributed transaction, you must use the
        <code class="literal">SERIALIZABLE</code> isolation level to achieve ACID
        properties. It is enough to use <code class="literal">REPEATABLE
        READ</code> for a non-distributed transaction, but not for a
        distributed transaction.)
      </p><p>
        Some examples of distributed transactions:
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            An application may act as an integration tool that combines
            a messaging service with an RDBMS. The application makes
            sure that transactions dealing with message sending,
            retrieval, and processing that also involve a transactional
            database all happen in a global transaction. You can think
            of this as “<span class="quote">transactional email.</span>”
          </p></li><li><p>
            An application performs actions that involve different
            database servers, such as a MySQL server and an Oracle
            server (or multiple MySQL servers), where actions that
            involve multiple servers must happen as part of a global
            transaction, rather than as separate transactions local to
            each server.
          </p></li><li><p>
            A bank keeps account information in an RDBMS and distributes
            and receives money via automated teller machines (ATMs). It
            is necessary to ensure that ATM actions are correctly
            reflected in the accounts, but this cannot be done with the
            RDBMS alone. A global transaction manager integrates the ATM
            and database resources to ensure overall consistency of
            financial transactions.
          </p></li></ul></div><p>
        Applications that use global transactions involve one or more
        Resource Managers and a Transaction Manager:
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            A Resource Manager (RM) provides access to transactional
            resources. A database server is one kind of resource
            manager. It must be possible to either commit or roll back
            transactions managed by the RM.
          </p></li><li><p>
            A Transaction Manager (TM) coordinates the transactions that
            are part of a global transaction. It communicates with the
            RMs that handle each of these transactions. The individual
            transactions within a global transaction are
            “<span class="quote">branches</span>” of the global transaction. Global
            transactions and their branches are identified by a naming
            scheme described later.
          </p></li></ul></div><p>
        The MySQL implementation of XA MySQL enables a MySQL server to
        act as a Resource Manager that handles XA transactions within a
        global transaction. A client program that connects to the MySQL
        server acts as the Transaction Manager.
      </p><p>
        To carry out a global transaction, it is necessary to know which
        components are involved, and bring each component to a point
        when it can be committed or rolled back. Depending on what each
        component reports about its ability to succeed, they must all
        commit or roll back as an atomic group. That is, either all
        components must commit, or all components musts roll back. To
        manage a global transaction, it is necessary to take into
        account that any component or the connecting network might fail.
      </p><p>
        The process for executing a global transaction uses two-phase
        commit (2PC). This takes place after the actions performed by
        the branches of the global transaction have been executed.
      </p><div class="orderedlist"><ol type="1"><li><p>
            In the first phase, all branches are prepared. That is, they
            are told by the TM to get ready to commit. Typically, this
            means each RM that manages a branch records the actions for
            the branch in stable storage. The branches indicate whether
            they are able to do this, and these results are used for the
            second phase.
          </p></li><li><p>
            In the second phase, the TM tells the RMs whether to commit
            or roll back. If all branches indicated when they were
            prepared that they will be able to commit, all branches are
            told to commit. If any branch indicated when it was prepared
            that it will not be able to commit, all branches are told to
            roll back.
          </p></li></ol></div><p>
        In some cases, a global transaction might use one-phase commit
        (1PC). For example, when a Transaction Manager finds that a
        global transaction consists of only one transactional resource
        (that is, a single branch), that resource can be told to prepare
        and commit at the same time.
      </p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="xa-statements"></a>XA Transaction SQL Syntax</h4></div></div></div><a id="id2882874" class="indexterm"></a><a id="id2882881" class="indexterm"></a><a id="id2882891" class="indexterm"></a><a id="id2882898" class="indexterm"></a><a id="id2882908" class="indexterm"></a><a id="id2882915" class="indexterm"></a><a id="id2882925" class="indexterm"></a><a id="id2882932" class="indexterm"></a><a id="id2882942" class="indexterm"></a><a id="id2882948" class="indexterm"></a><a id="id2882959" class="indexterm"></a><a id="id2882965" class="indexterm"></a><a id="id2882976" class="indexterm"></a><a id="id2882986" class="indexterm"></a><p>
          To perform XA transactions in MySQL, use the following
          statements:
        </p><pre class="programlisting">XA {START|BEGIN} <em class="replaceable"><code>xid</code></em> [JOIN|RESUME]

XA END <em class="replaceable"><code>xid</code></em> [SUSPEND [FOR MIGRATE]]

XA PREPARE <em class="replaceable"><code>xid</code></em>

XA COMMIT <em class="replaceable"><code>xid</code></em> [ONE PHASE]

XA ROLLBACK <em class="replaceable"><code>xid</code></em>

XA RECOVER
</pre><p>
          For <code class="literal">XA START</code>, the <code class="literal">JOIN</code>
          and <code class="literal">RESUME</code> clauses are not supported.
        </p><p>
          For <code class="literal">XA END</code> the <code class="literal">SUSPEND [FOR
          MIGRATE]</code> clause is not supported.
        </p><p>
          Each XA statement begins with the <code class="literal">XA</code>
          keyword, and most of them require an
          <em class="replaceable"><code>xid</code></em> value. An
          <em class="replaceable"><code>xid</code></em> is an XA transaction
          identifier. It indicates which transaction the statement
          applies to. <em class="replaceable"><code>xid</code></em> values are supplied
          by the client, or generated by the MySQL server. An
          <em class="replaceable"><code>xid</code></em> value has from one to three
          parts:
        </p><pre class="programlisting"><em class="replaceable"><code>xid</code></em>: <em class="replaceable"><code>gtrid</code></em> [, <em class="replaceable"><code>bqual</code></em> [, <em class="replaceable"><code>formatID</code></em> ]]
</pre><p>
          <em class="replaceable"><code>gtrid</code></em> is a global transaction
          identifier, <em class="replaceable"><code>bqual</code></em> is a branch
          qualifier, and <em class="replaceable"><code>formatID</code></em> is a number
          that identifies the format used by the
          <em class="replaceable"><code>gtrid</code></em> and
          <em class="replaceable"><code>bqual</code></em> values. As indicated by the
          syntax, <em class="replaceable"><code>bqual</code></em> and
          <em class="replaceable"><code>formatID</code></em> are optional. The default
          <em class="replaceable"><code>bqual</code></em> value is
          <code class="literal">''</code> if not given. The default
          <em class="replaceable"><code>formatID</code></em> value is 1 if not given.
        </p><p>
          <em class="replaceable"><code>gtrid</code></em> and
          <em class="replaceable"><code>bqual</code></em> must be string literals, each
          up to 64 bytes (not characters) long.
          <em class="replaceable"><code>gtrid</code></em> and
          <em class="replaceable"><code>bqual</code></em> can be specified in several
          ways. You can use a quoted string (<code class="literal">'ab'</code>),
          hex string (<code class="literal">0x6162</code>,
          <code class="literal">X'ab'</code>), or bit value
          (<code class="literal">b'<em class="replaceable"><code>nnnn</code></em>'</code>).
        </p><p>
          <em class="replaceable"><code>formatID</code></em> is an unsigned integer.
        </p><p>
          The <em class="replaceable"><code>gtrid</code></em> and
          <em class="replaceable"><code>bqual</code></em> values are interpreted in
          bytes by the MySQL server's underlying XA support routines.
          However, while an SQL statement containing an XA statement is
          being parsed, the server works with some specific character
          set. To be safe, write <em class="replaceable"><code>gtrid</code></em> and
          <em class="replaceable"><code>bqual</code></em> as hex strings.
        </p><p>
          <em class="replaceable"><code>xid</code></em> values typically are generated
          by the Transaction Manager. Values generated by one TM must be
          different from values generated by other TMs. A given TM must
          be able to recognize its own <em class="replaceable"><code>xid</code></em>
          values in a list of values returned by the <code class="literal">XA
          RECOVER</code> statement.
        </p><p>
          <code class="literal">XA START <em class="replaceable"><code>xid</code></em></code>
          starts an XA transaction with the given
          <em class="replaceable"><code>xid</code></em> value. Each XA transaction must
          have a unique <em class="replaceable"><code>xid</code></em> value, so the
          value must not currently be used by another XA transaction.
          Uniqueness is assessed using the
          <em class="replaceable"><code>gtrid</code></em> and
          <em class="replaceable"><code>bqual</code></em> values. All following XA
          statements for the XA transaction must be specified using the
          same <em class="replaceable"><code>xid</code></em> value as that given in the
          <code class="literal">XA START</code> statement. If you use any of those
          statements but specify an <em class="replaceable"><code>xid</code></em> value
          that does not correspond to some existing XA transaction, an
          error occurs.
        </p><p>
          One or more XA transactions can be part of the same global
          transaction. All XA transactions within a given global
          transaction must use the same <em class="replaceable"><code>gtrid</code></em>
          value in the <em class="replaceable"><code>xid</code></em> value. For this
          reason, <em class="replaceable"><code>gtrid</code></em> values must be
          globally unique so that there is no ambiguity about which
          global transaction a given XA transaction is part of. The
          <em class="replaceable"><code>bqual</code></em> part of the
          <em class="replaceable"><code>xid</code></em> value must be different for
          each XA transaction within a global transaction. (The
          requirement that <em class="replaceable"><code>bqual</code></em> values be
          different is a limitation of the current MySQL XA
          implementation. It is not part of the XA specification.)
        </p><p>
          The <code class="literal">XA RECOVER</code> statement returns
          information for those XA transactions on the MySQL server that
          are in the <code class="literal">PREPARED</code> state. (See
          <a href="mysqlqb_statements.html#xa-states" title="XA Transaction States">XA Transaction States</a>.) The output includes a row for
          each such XA transaction on the server, regardless of which
          client started it.
        </p><p>
          <code class="literal">XA RECOVER</code> output rows look like this (for
          an example <em class="replaceable"><code>xid</code></em> value consisting of
          the parts <code class="literal">'abc'</code>, <code class="literal">'def'</code>,
          and <code class="literal">7</code>):
        </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>XA RECOVER;</code></strong>
+----------+--------------+--------------+--------+
| formatID | gtrid_length | bqual_length | data   |
+----------+--------------+--------------+--------+
|        7 |            3 |            3 | abcdef |
+----------+--------------+--------------+--------+
</pre><p>
          The output columns have the following meanings:
        </p><div class="itemizedlist"><ul type="disc"><li><p>
              <code class="literal">formatID</code> is the
              <em class="replaceable"><code>formatID</code></em> part of the
              transaction <em class="replaceable"><code>xid</code></em>
            </p></li><li><p>
              <code class="literal">gtrid_length</code> is the length in bytes of
              the <em class="replaceable"><code>gtrid</code></em> part of the
              <em class="replaceable"><code>xid</code></em>
            </p></li><li><p>
              <code class="literal">bqual_length</code> is the length in bytes of
              the <em class="replaceable"><code>bqual</code></em> part of the
              <em class="replaceable"><code>xid</code></em>
            </p></li><li><p>
              <code class="literal">data</code> is the concatenation of the
              <em class="replaceable"><code>gtrid</code></em> and
              <em class="replaceable"><code>bqual</code></em> parts of the
              <em class="replaceable"><code>xid</code></em>
            </p></li></ul></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="xa-states"></a>XA Transaction States</h4></div></div></div><p>
          An XA transaction progresses through the following states:
        </p><div class="orderedlist"><ol type="1"><li><p>
              Use <code class="literal">XA START</code> to start an XA transaction
              and put it in the <code class="literal">ACTIVE</code> state.
            </p></li><li><p>
              For an <code class="literal">ACTIVE</code> XA transaction, issue the
              SQL statements that make up the transaction, and then
              issue an <code class="literal">XA END</code> statement. <code class="literal">XA
              END</code> puts the transaction in the
              <code class="literal">IDLE</code> state.
            </p></li><li><p>
              For an <code class="literal">IDLE</code> XA transaction, you can
              issue either an <code class="literal">XA PREPARE</code> statement or
              an <code class="literal">XA COMMIT ... ONE PHASE</code> statement:
            </p><div class="itemizedlist"><ul type="disc"><li><p>
                  <code class="literal">XA PREPARE</code> puts the transaction in
                  the <code class="literal">PREPARED</code> state. An <code class="literal">XA
                  RECOVER</code> statement at this point will include
                  the transaction's <em class="replaceable"><code>xid</code></em> value
                  in its output, because <code class="literal">XA RECOVER</code>
                  lists all XA transactions that are in the
                  <code class="literal">PREPARED</code> state.
                </p></li><li><p>
                  <code class="literal">XA COMMIT ... ONE PHASE</code> prepares
                  and commits the transaction. The
                  <em class="replaceable"><code>xid</code></em> value will not be
                  listed by <code class="literal">XA RECOVER</code> because the
                  transaction terminates.
                </p></li></ul></div></li><li><p>
              For a <code class="literal">PREPARED</code> XA transaction, you can
              issue an <code class="literal">XA COMMIT</code> statement to commit
              and terminate the transaction, or <code class="literal">XA
              ROLLBACK</code> to roll back and terminate the
              transaction.
            </p></li></ol></div><p>
          Here is a simple XA transaction that inserts a row into a
          table as part of a global transaction:
        </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>XA START 'xatest';</code></strong>
Query OK, 0 rows affected (0.00 sec)

mysql&gt; <strong class="userinput"><code>INSERT INTO mytable (i) VALUES(10);</code></strong>
Query OK, 1 row affected (0.04 sec)

mysql&gt; <strong class="userinput"><code>XA END 'xatest';</code></strong>
Query OK, 0 rows affected (0.00 sec)

mysql&gt; <strong class="userinput"><code>XA PREPARE 'xatest';</code></strong>
Query OK, 0 rows affected (0.00 sec)

mysql&gt; <strong class="userinput"><code>XA COMMIT 'xatest';</code></strong>
Query OK, 0 rows affected (0.00 sec)
</pre><p>
          Within the context of a given client connection, XA
          transactions and local (non-XA) transactions are mutually
          exclusive. For example, if <code class="literal">XA START</code> has
          been issued to begin an XA transaction, a local transaction
          cannot be started until the XA transaction has been committed
          or rolled back. Conversely, if a local transaction has been
          started with <code class="literal">START TRANSACTION</code>, no XA
          statements can be used until the transaction has been
          committed or rolled back.
        </p><p>
          Note that if an XA transaction is in the
          <code class="literal">ACTIVE</code> state, you cannot issue any
          statements that cause an implicit commit. That would violate
          the XA contract because you could not roll back the XA
          transaction. You will receive the following error if you try
          to execute such a statement:
        </p><pre class="programlisting">ERROR 1399 (XAE07): XAER_RMFAIL: The command cannot be executed
when global transaction is in the ACTIVE state
</pre><p>
          Statements to which the preceding remark applies are listed at
          <a href="mysqlqb_statements.html#implicit-commit" title="Statements That Cause an Implicit Commit">Statements That Cause an Implicit Commit</a>.
        </p></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="database-administration-statements"></a>Database Administration Statements</h2></div></div></div><div class="toc"><dl><dt><span class="section"><a href="mysqlqb_statements.html#account-management-sql">Account Management Statements</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#table-maintenance-sql">Table Maintenance Statements</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#set-option"><code class="literal">SET</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#show"><code class="literal">SHOW</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#other-administrative-sql">Other Administrative Statements</a></span></dt></dl></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="account-management-sql"></a>Account Management Statements</h3></div></div></div><div class="toc"><dl><dt><span class="section"><a href="mysqlqb_statements.html#create-user"><code class="literal">CREATE USER</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#drop-user"><code class="literal">DROP USER</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#grant"><code class="literal">GRANT</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#rename-user"><code class="literal">RENAME USER</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#revoke"><code class="literal">REVOKE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#set-password"><code class="literal">SET PASSWORD</code> Syntax</a></span></dt></dl></div><p>
        MySQL account information is stored in the tables of the
        <code class="literal">mysql</code> database. This database and the access
        control system are discussed extensively in
        <a href="http://dev.mysql.com/doc/refman/5.0/en/database-administration.html" target="_top">Database Administration</a>, which you should
        consult for additional details.
      </p><p>
        <span class="bold"><strong>Important</strong></span>: Some releases of
        MySQL introduce changes to the structure of the grant tables to
        add new privileges or features. Whenever you update to a new
        version of MySQL, you should update your grant tables to make
        sure that they have the current structure so that you can take
        advantage of any new capabilities. See
        <a href="http://dev.mysql.com/doc/refman/5.0/en/mysql-upgrade.html" target="_top">mysql-upgrade</a>.
      </p><p class="mnmas"><b>MySQL Enterprise. </b>
          In a production environment it is always prudent to examine
          any changes to users' accounts. The MySQL Network Monitoring
          and Advisory Service provides notification whenever users'
          privileges are altered. For more information see,
          <a href="http://www.mysql.com/products/enterprise/advisors.html" target="_top">http://www.mysql.com/products/enterprise/advisors.html</a>.
        </p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="create-user"></a><code class="literal">CREATE USER</code> Syntax</h4></div></div></div><a id="id2883800" class="indexterm"></a><a id="id2883807" class="indexterm"></a><a id="id2883817" class="indexterm"></a><pre class="programlisting">CREATE USER <em class="replaceable"><code>user</code></em> [IDENTIFIED BY [PASSWORD] '<em class="replaceable"><code>password</code></em>']
    [, <em class="replaceable"><code>user</code></em> [IDENTIFIED BY [PASSWORD] '<em class="replaceable"><code>password</code></em>']] ...
</pre><p>
          The <code class="literal">CREATE USER</code> statement was added in
          MySQL 5.0.2. This statement creates new MySQL accounts. To use
          it, you must have the global <code class="literal">CREATE USER</code>
          privilege or the <code class="literal">INSERT</code> privilege for the
          <code class="literal">mysql</code> database. For each account,
          <code class="literal">CREATE USER</code> creates a new record in the
          <code class="literal">mysql.user</code> table that has no privileges. An
          error occurs if the account already exists. Each account is
          named using the same format as for the
          <code class="literal">GRANT</code> statement; for example,
          <code class="literal">'jeffrey'@'localhost'</code>. If you specify only
          the username part of the account name, a hostname part of
          <code class="literal">'%'</code> is used. For additional information
          about specifying account names, see <a href="mysqlqb_statements.html#grant" title="GRANT Syntax"><code class="literal">GRANT</code> Syntax</a>.
        </p><p>
          The account can be given a password with the optional
          <code class="literal">IDENTIFIED BY</code> clause. The
          <em class="replaceable"><code>user</code></em> value and the password are
          given the same way as for the <code class="literal">GRANT</code>
          statement. In particular, to specify the password in plain
          text, omit the <code class="literal">PASSWORD</code> keyword. To specify
          the password as the hashed value as returned by the
          <code class="literal">PASSWORD()</code> function, include the
          <code class="literal">PASSWORD</code> keyword. See
          <a href="mysqlqb_statements.html#grant" title="GRANT Syntax"><code class="literal">GRANT</code> Syntax</a>.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="drop-user"></a><code class="literal">DROP USER</code> Syntax</h4></div></div></div><a id="id2883964" class="indexterm"></a><a id="id2883970" class="indexterm"></a><a id="id2883980" class="indexterm"></a><a id="id2883990" class="indexterm"></a><a id="id2884001" class="indexterm"></a><a id="id2884011" class="indexterm"></a><a id="id2884021" class="indexterm"></a><a id="id2884031" class="indexterm"></a><a id="id2884041" class="indexterm"></a><pre class="programlisting">DROP USER <em class="replaceable"><code>user</code></em> [, <em class="replaceable"><code>user</code></em>] ...
</pre><p>
          The <code class="literal">DROP USER</code> statement removes one or more
          MySQL accounts. To use it, you must have the global
          <code class="literal">CREATE USER</code> privilege or the
          <code class="literal">DELETE</code> privilege for the
          <code class="literal">mysql</code> database. Each account is named using
          the same format as for the <code class="literal">GRANT</code> statement;
          for example, <code class="literal">'jeffrey'@'localhost'</code>. If you
          specify only the username part of the account name, a hostname
          part of <code class="literal">'%'</code> is used. For additional
          information about specifying account names, see
          <a href="mysqlqb_statements.html#grant" title="GRANT Syntax"><code class="literal">GRANT</code> Syntax</a>.
        </p><p>
          <code class="literal">DROP USER</code> as present in MySQL 5.0.0 removes
          only accounts that have no privileges. In MySQL 5.0.2, it was
          modified to remove account privileges as well. This means that
          the procedure for removing an account depends on your version
          of MySQL.
        </p><p>
          As of MySQL 5.0.2, you can remove an account and its
          privileges as follows:
        </p><pre class="programlisting">DROP USER <em class="replaceable"><code>user</code></em>;
</pre><p>
          The statement removes privilege rows for the account from all
          grant tables.
        </p><p>
          In MySQL 5.0.0 and 5.0.1, <code class="literal">DROP USER</code> deletes
          only MySQL accounts that have no privileges. In these MySQL
          versions, it serves only to remove each account record from
          the <code class="literal">user</code> table. To remove a MySQL account
          completely (including all of its privileges), you should use
          the following procedure, performing these steps in the order
          shown:
        </p><div class="orderedlist"><ol type="1"><li><p>
              Use <code class="literal">SHOW GRANTS</code> to determine what
              privileges the account has. See
              <a href="mysqlqb_statements.html#show-grants" title="SHOW GRANTS Syntax"><code class="literal">SHOW GRANTS</code> Syntax</a>.
            </p></li><li><p>
              Use <code class="literal">REVOKE</code> to revoke the privileges
              displayed by <code class="literal">SHOW GRANTS</code>. This removes
              rows for the account from all the grant tables except the
              <code class="literal">user</code> table, and revokes any global
              privileges listed in the <code class="literal">user</code> table.
              See <a href="mysqlqb_statements.html#grant" title="GRANT Syntax"><code class="literal">GRANT</code> Syntax</a>.
            </p></li><li><p>
              Delete the account by using <code class="literal">DROP USER</code>
              to remove the <code class="literal">user</code> table record.
            </p></li></ol></div><p>
          <span class="emphasis"><em>Important</em></span>: <code class="literal">DROP USER</code>
          does not automatically close any open user sessions. Rather,
          in the event that a user with an open session is dropped, the
          statement does not take effect until that user's session is
          closed. Once the session is closed, the user is dropped, and
          that user's next attempt to log in will fail. <span class="emphasis"><em>This
          is by design</em></span>.
        </p><p>
          <code class="literal">DROP USER</code> does not automatically delete or
          invalidate any database objects that the user created. This
          applies to tables, views, stored routines, and triggers.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="grant"></a><code class="literal">GRANT</code> Syntax</h4></div></div></div><a id="id2884283" class="indexterm"></a><a id="id2884290" class="indexterm"></a><a id="id2884300" class="indexterm"></a><a id="id2884307" class="indexterm"></a><pre class="programlisting">GRANT <em class="replaceable"><code>priv_type</code></em> [(<em class="replaceable"><code>column_list</code></em>)] [, <em class="replaceable"><code>priv_type</code></em> [(<em class="replaceable"><code>column_list</code></em>)]] ...
    ON [<em class="replaceable"><code>object_type</code></em>] {<em class="replaceable"><code>tbl_name</code></em> | * | *.* | <em class="replaceable"><code>db_name</code></em>.*}
    TO <em class="replaceable"><code>user</code></em> [IDENTIFIED BY [PASSWORD] '<em class="replaceable"><code>password</code></em>']
        [, <em class="replaceable"><code>user</code></em> [IDENTIFIED BY [PASSWORD] '<em class="replaceable"><code>password</code></em>']] ...
    [REQUIRE
        NONE |
        [{SSL| X509}]
        [CIPHER '<em class="replaceable"><code>cipher</code></em>' [AND]]
        [ISSUER '<em class="replaceable"><code>issuer</code></em>' [AND]]
        [SUBJECT '<em class="replaceable"><code>subject</code></em>']]
    [WITH <em class="replaceable"><code>with_option</code></em> [<em class="replaceable"><code>with_option</code></em>] ...]

<em class="replaceable"><code>object_type</code></em> =
    TABLE
  | FUNCTION
  | PROCEDURE

<em class="replaceable"><code>with_option</code></em> =
    GRANT OPTION
  | MAX_QUERIES_PER_HOUR <em class="replaceable"><code>count</code></em>
  | MAX_UPDATES_PER_HOUR <em class="replaceable"><code>count</code></em>
  | MAX_CONNECTIONS_PER_HOUR <em class="replaceable"><code>count</code></em>
  | MAX_USER_CONNECTIONS <em class="replaceable"><code>count</code></em>
</pre><p>
          The <code class="literal">GRANT</code> statement enables system
          administrators to create MySQL user accounts and to grant
          rights to from accounts. To use <code class="literal">GRANT</code>, you
          must have the <code class="literal">GRANT OPTION</code> privilege, and
          you must have the privileges that you are granting. The
          <code class="literal">REVOKE</code> statement is related and enables
          administrators to remove account privileges. See
          <a href="mysqlqb_statements.html#revoke" title="REVOKE Syntax"><code class="literal">REVOKE</code> Syntax</a>.
        </p><p>
          MySQL account information is stored in the tables of the
          <code class="literal">mysql</code> database. This database and the
          access control system are discussed extensively in
          <a href="http://dev.mysql.com/doc/refman/5.0/en/database-administration.html" target="_top">Database Administration</a>, which you should
          consult for additional details.
        </p><p>
          <span class="bold"><strong>Important</strong></span>: Some releases of
          MySQL introduce changes to the structure of the grant tables
          to add new privileges or features. Whenever you update to a
          new version of MySQL, you should update your grant tables to
          make sure that they have the current structure so that you can
          take advantage of any new capabilities. See
          <a href="http://dev.mysql.com/doc/refman/5.0/en/mysql-upgrade.html" target="_top">mysql-upgrade</a>.
        </p><p>
          If the grant tables hold privilege rows that contain
          mixed-case database or table names and the
          <code class="literal">lower_case_table_names</code> system variable is
          set to a non-zero value, <code class="literal">REVOKE</code> cannot be
          used to revoke these privileges. It will be necessary to
          manipulate the grant tables directly.
          (<code class="literal">GRANT</code> will not create such rows when
          <code class="literal">lower_case_table_names</code> is set, but such
          rows might have been created prior to setting the variable.)
        </p><p>
          Privileges can be granted at several levels:
        </p><div class="itemizedlist"><ul type="disc"><li><p>
              <span class="bold"><strong>Global level</strong></span>
            </p><p>
              Global privileges apply to all databases on a given
              server. These privileges are stored in the
              <code class="literal">mysql.user</code> table. <code class="literal">GRANT ALL ON
              *.*</code> and <code class="literal">REVOKE ALL ON *.*</code>
              grant and revoke only global privileges.
            </p></li><li><p>
              <span class="bold"><strong>Database level</strong></span>
            </p><p>
              Database privileges apply to all objects in a given
              database. These privileges are stored in the
              <code class="literal">mysql.db</code> and
              <code class="literal">mysql.host</code> tables. <code class="literal">GRANT ALL
              ON <em class="replaceable"><code>db_name</code></em>.*</code> and
              <code class="literal">REVOKE ALL ON
              <em class="replaceable"><code>db_name</code></em>.*</code> grant and
              revoke only database privileges.
            </p></li><li><p>
              <span class="bold"><strong>Table level</strong></span>
            </p><p>
              Table privileges apply to all columns in a given table.
              These privileges are stored in the
              <code class="literal">mysql.tables_priv</code> table. <code class="literal">GRANT
              ALL ON
              <em class="replaceable"><code>db_name.tbl_name</code></em></code> and
              <code class="literal">REVOKE ALL ON
              <em class="replaceable"><code>db_name.tbl_name</code></em></code>
              grant and revoke only table privileges.
            </p></li><li><p>
              <span class="bold"><strong>Column level</strong></span>
            </p><p>
              Column privileges apply to single columns in a given
              table. These privileges are stored in the
              <code class="literal">mysql.columns_priv</code> table. When using
              <code class="literal">REVOKE</code>, you must specify the same
              columns that were granted.
            </p></li><li><p>
              <span class="bold"><strong>Routine level</strong></span>
            </p><p>
              The <code class="literal">CREATE ROUTINE</code>, <code class="literal">ALTER
              ROUTINE</code>, <code class="literal">EXECUTE</code>, and
              <code class="literal">GRANT</code> privileges apply to stored
              routines (functions and procedures). They can be granted
              at the global and database levels. Also, except for
              <code class="literal">CREATE ROUTINE</code>, these privileges can be
              granted at the routine level for individual routines and
              are stored in the <code class="literal">mysql.procs_priv</code>
              table.
            </p></li></ul></div><p>
          The <em class="replaceable"><code>object_type</code></em> clause was added in
          MySQL 5.0.6. It should be specified as
          <code class="literal">TABLE</code>, <code class="literal">FUNCTION</code>, or
          <code class="literal">PROCEDURE</code> when the following object is a
          table, a stored function, or a stored procedure.
        </p><p>
          For the <code class="literal">GRANT</code> and <code class="literal">REVOKE</code>
          statements, <em class="replaceable"><code>priv_type</code></em> can be
          specified as any of the following:
        </p><div class="informaltable"><table border="1"><colgroup><col /><col /></colgroup><tbody><tr><td><span class="bold"><strong>Privilege</strong></span></td><td><span class="bold"><strong>Meaning</strong></span></td></tr><tr><td><code class="literal">ALL [PRIVILEGES]</code></td><td>Sets all simple privileges except <code class="literal">GRANT OPTION</code></td></tr><tr><td><code class="literal">ALTER</code></td><td>Enables use of <code class="literal">ALTER TABLE</code></td></tr><tr><td><code class="literal">ALTER ROUTINE</code></td><td>Enables stored routines to be altered or dropped</td></tr><tr><td><code class="literal">CREATE</code></td><td>Enables use of <code class="literal">CREATE TABLE</code></td></tr><tr><td><code class="literal">CREATE ROUTINE</code></td><td>Enables creation of stored routines</td></tr><tr><td><code class="literal">CREATE TEMPORARY TABLES</code></td><td>Enables use of <code class="literal">CREATE TEMPORARY TABLE</code></td></tr><tr><td><code class="literal">CREATE USER</code></td><td>Enables use of <code class="literal">CREATE USER</code>, <code class="literal">DROP
                  USER</code>, <code class="literal">RENAME USER</code>, and
                  <code class="literal">REVOKE ALL PRIVILEGES</code>.</td></tr><tr><td><code class="literal">CREATE VIEW</code></td><td>Enables use of <code class="literal">CREATE VIEW</code></td></tr><tr><td><code class="literal">DELETE</code></td><td>Enables use of <code class="literal">DELETE</code></td></tr><tr><td><code class="literal">DROP</code></td><td>Enables use of <code class="literal">DROP TABLE</code></td></tr><tr><td><code class="literal">EXECUTE</code></td><td>Enables the user to run stored routines</td></tr><tr><td><code class="literal">FILE</code></td><td>Enables use of <code class="literal">SELECT ... INTO OUTFILE</code> and
                  <code class="literal">LOAD DATA INFILE</code></td></tr><tr><td><code class="literal">INDEX</code></td><td>Enables use of <code class="literal">CREATE INDEX</code> and <code class="literal">DROP
                  INDEX</code></td></tr><tr><td><code class="literal">INSERT</code></td><td>Enables use of <code class="literal">INSERT</code></td></tr><tr><td><code class="literal">LOCK TABLES</code></td><td>Enables use of <code class="literal">LOCK TABLES</code> on tables for which you
                  have the <code class="literal">SELECT</code> privilege</td></tr><tr><td><code class="literal">PROCESS</code></td><td>Enables use of <code class="literal">SHOW FULL PROCESSLIST</code></td></tr><tr><td><code class="literal">REFERENCES</code></td><td>Not implemented</td></tr><tr><td><code class="literal">RELOAD</code></td><td>Enables use of <code class="literal">FLUSH</code></td></tr><tr><td><code class="literal">REPLICATION CLIENT</code></td><td>Enables the user to ask where slave or master servers are</td></tr><tr><td><code class="literal">REPLICATION SLAVE</code></td><td>Needed for replication slaves (to read binary log events from the
                  master)</td></tr><tr><td><code class="literal">SELECT</code></td><td>Enables use of <code class="literal">SELECT</code></td></tr><tr><td><code class="literal">SHOW DATABASES</code></td><td><code class="literal">SHOW DATABASES</code> shows all databases</td></tr><tr><td><code class="literal">SHOW VIEW</code></td><td>Enables use of <code class="literal">SHOW CREATE VIEW</code></td></tr><tr><td><code class="literal">SHUTDOWN</code></td><td>Enables use of <span><strong class="command">mysqladmin shutdown</strong></span></td></tr><tr><td><code class="literal">SUPER</code></td><td>Enables use of <code class="literal">CHANGE MASTER</code>,
                  <code class="literal">KILL</code>, <code class="literal">PURGE MASTER
                  LOGS</code>, and <code class="literal">SET GLOBAL</code>
                  statements, the <span><strong class="command">mysqladmin debug</strong></span>
                  command; allows you to connect (once) even if
                  <code class="literal">max_connections</code> is reached</td></tr><tr><td><code class="literal">UPDATE</code></td><td>Enables use of <code class="literal">UPDATE</code></td></tr><tr><td><code class="literal">USAGE</code></td><td>Synonym for “<span class="quote">no privileges</span>”</td></tr><tr><td><code class="literal">GRANT OPTION</code></td><td>Enables privileges to be granted</td></tr></tbody></table></div><p>
          The <code class="literal">EXECUTE</code> privilege is not operational
          until MySQL 5.0.3. <code class="literal">CREATE VIEW</code> and
          <code class="literal">SHOW VIEW</code> were added in MySQL 5.0.1.
          <code class="literal">CREATE USER</code>, <code class="literal">CREATE
          ROUTINE</code>, and <code class="literal">ALTER ROUTINE</code> were
          added in MySQL 5.0.3.
        </p><p>
          The <code class="literal">REFERENCES</code> privilege currently is
          unused.
        </p><p>
          <code class="literal">USAGE</code> can be specified when you want to
          create a user that has no privileges.
        </p><p>
          Use <code class="literal">SHOW GRANTS</code> to determine what
          privileges an account has. See <a href="mysqlqb_statements.html#show-grants" title="SHOW GRANTS Syntax"><code class="literal">SHOW GRANTS</code> Syntax</a>.
        </p><p>
          You can assign global privileges by using <code class="literal">ON
          *.*</code> syntax or database-level privileges by using
          <code class="literal">ON <em class="replaceable"><code>db_name</code></em>.*</code>
          syntax. If you specify <code class="literal">ON *</code> and you have
          selected a default database, the privileges are granted in
          that database. (<span class="bold"><strong>Warning:</strong></span> If
          you specify <code class="literal">ON *</code> and you have
          <span class="emphasis"><em>not</em></span> selected a default database, the
          privileges granted are global.)
        </p><p>
          The <code class="literal">FILE</code>, <code class="literal">PROCESS</code>,
          <code class="literal">RELOAD</code>, <code class="literal">REPLICATION
          CLIENT</code>, <code class="literal">REPLICATION SLAVE</code>,
          <code class="literal">SHOW DATABASES</code>,
          <code class="literal">SHUTDOWN</code>, and <code class="literal">SUPER</code>
          privileges are administrative privileges that can only be
          granted globally (using <code class="literal">ON *.*</code> syntax).
        </p><p>
          Other privileges can be granted globally or at more specific
          levels.
        </p><p>
          The <em class="replaceable"><code>priv_type</code></em> values that you can
          specify for a table are <code class="literal">SELECT</code>,
          <code class="literal">INSERT</code>, <code class="literal">UPDATE</code>,
          <code class="literal">DELETE</code>, <code class="literal">CREATE</code>,
          <code class="literal">DROP</code>, <code class="literal">GRANT OPTION</code>,
          <code class="literal">INDEX</code>, <code class="literal">ALTER</code>,
          <code class="literal">CREATE VIEW</code> and <code class="literal">SHOW
          VIEW</code>.
        </p><p>
          The <em class="replaceable"><code>priv_type</code></em> values that you can
          specify for a column (that is, when you use a
          <em class="replaceable"><code>column_list</code></em> clause) are
          <code class="literal">SELECT</code>, <code class="literal">INSERT</code>, and
          <code class="literal">UPDATE</code>.
        </p><p>
          The <em class="replaceable"><code>priv_type</code></em> values that you can
          specify at the routine level are <code class="literal">ALTER
          ROUTINE</code>, <code class="literal">EXECUTE</code>, and
          <code class="literal">GRANT OPTION</code>. <code class="literal">CREATE
          ROUTINE</code> is not a routine-level privilege because you
          must have this privilege to create a routine in the first
          place.
        </p><p>
          For the global, database, table, and routine levels,
          <code class="literal">GRANT ALL</code> assigns only the privileges that
          exist at the level you are granting. For example,
          <code class="literal">GRANT ALL ON
          <em class="replaceable"><code>db_name</code></em>.*</code> is a
          database-level statement, so it does not grant any global-only
          privileges such as <code class="literal">FILE</code>.
        </p><p>
          MySQL allows you to grant privileges even on database objects
          that do not exist. In such cases, the privileges to be granted
          must include the <code class="literal">CREATE</code> privilege.
          <span class="emphasis"><em>This behavior is by design</em></span>, and is
          intended to enable the database administrator to prepare user
          accounts and privileges for database objects that are to be
          created at a later time.
        </p><p>
          <span class="bold"><strong>Important</strong></span>: <span class="emphasis"><em>MySQL
          does not automatically revoke any privileges when you drop a
          table or database</em></span>. However, if you drop a routine,
          any routine-level privileges granted for that routine are
          revoked.
        </p><p>
          <span class="bold"><strong>Note</strong></span>: the
          ‘<code class="literal">_</code>’ and
          ‘<code class="literal">%</code>’ wildcards are allowed when
          specifying database names in <code class="literal">GRANT</code>
          statements that grant privileges at the global or database
          levels. This means, for example, that if you want to use a
          ‘<code class="literal">_</code>’ character as part of a
          database name, you should specify it as
          ‘<code class="literal">\_</code>’ in the
          <code class="literal">GRANT</code> statement, to prevent the user from
          being able to access additional databases matching the
          wildcard pattern; for example, <code class="literal">GRANT ... ON
          `foo\_bar`.* TO ...</code>.
        </p><p>
          To accommodate granting rights to users from arbitrary hosts,
          MySQL supports specifying the <em class="replaceable"><code>user</code></em>
          value in the form
          <code class="literal"><em class="replaceable"><code>user_name</code></em>@<em class="replaceable"><code>host_name</code></em></code>.
          If a <em class="replaceable"><code>user_name</code></em> or
          <em class="replaceable"><code>host_name</code></em> value is legal as an
          unquoted identifier, you need not quote it. However, quotes
          are necessary to specify a
          <em class="replaceable"><code>user_name</code></em> string containing special
          characters (such as ‘<code class="literal">-</code>’), or a
          <em class="replaceable"><code>host_name</code></em> string containing special
          characters or wildcard characters (such as
          ‘<code class="literal">%</code>’); for example,
          <code class="literal">'test-user'@'test-hostname'</code>. Quote the
          username and hostname separately.
        </p><p>
          You can specify wildcards in the hostname. For example,
          <code class="literal"><em class="replaceable"><code>user_name</code></em>@'%.loc.gov'</code>
          applies to <em class="replaceable"><code>user_name</code></em> for any host
          in the <code class="literal">loc.gov</code> domain, and
          <code class="literal"><em class="replaceable"><code>user_name</code></em>@'144.155.166.%'</code>
          applies to <em class="replaceable"><code>user_name</code></em> for any host
          in the <code class="literal">144.155.166</code> class C subnet.
        </p><p>
          The simple form <em class="replaceable"><code>user_name</code></em> is a
          synonym for
          <code class="literal"><em class="replaceable"><code>user_name</code></em>@'%'</code>.
        </p><p>
          <span class="emphasis"><em>MySQL does not support wildcards in
          usernames</em></span>. Anonymous users are defined by inserting
          entries with <code class="literal">User=''</code> into the
          <code class="literal">mysql.user</code> table or by creating a user with
          an empty name with the <code class="literal">GRANT</code> statement:
        </p><pre class="programlisting">GRANT ALL ON test.* TO ''@'localhost' ...
</pre><p>
          When specifying quoted values, quote database, table, column,
          and routine names as identifiers, using backticks
          (‘<code class="literal">`</code>’). Quote hostnames,
          usernames, and passwords as strings, using single quotes
          (‘<code class="literal">'</code>’).
        </p><p>
          <span class="bold"><strong>Warning:</strong></span> If you allow
          anonymous users to connect to the MySQL server, you should
          also grant privileges to all local users as
          <code class="literal"><em class="replaceable"><code>user_name</code></em>@localhost</code>.
          Otherwise, the anonymous user account for
          <code class="literal">localhost</code> in the
          <code class="literal">mysql.user</code> table (created during MySQL
          installation) is used when named users try to log in to the
          MySQL server from the local machine. For details, see
          <a href="http://dev.mysql.com/doc/refman/5.0/en/connection-access.html" target="_top">Access Control, Stage 1: Connection Verification</a>.
        </p><p>
          You can determine whether this applies to you by executing the
          following query, which lists any anonymous users:
        </p><pre class="programlisting">SELECT Host, User FROM mysql.user WHERE User='';
</pre><p>
          If you want to delete the local anonymous user account to
          avoid the problem just described, use these statements:
        </p><pre class="programlisting">DELETE FROM mysql.user WHERE Host='localhost' AND User='';
FLUSH PRIVILEGES;
</pre><p>
          <code class="literal">GRANT</code> supports hostnames up to 60
          characters long. Database, table, column, and routine names
          can be up to 64 characters. Usernames can be up to 16
          characters. <span class="bold"><strong>Note</strong></span>:
          <span class="emphasis"><em>The allowable length for usernames cannot be changed
          by altering the <code class="literal">mysql.user</code> table, and
          attempting to do so results in unpredictable behavior which
          may even make it impossible for users to log in to the MySQL
          server</em></span>. You should never alter any of the tables in
          the <code class="literal">mysql</code> database in any manner whatsoever
          except by means of the procedure prescribed by MySQL AB that
          is described in <a href="http://dev.mysql.com/doc/refman/5.0/en/mysql-upgrade.html" target="_top">mysql-upgrade</a>.
        </p><p>
          The privileges for a table, column, or routine are formed
          additively as the logical <code class="literal">OR</code> of the
          privileges at each of the privilege levels. For example, if
          the <code class="literal">mysql.user</code> table specifies that a user
          has a global <code class="literal">SELECT</code> privilege, the
          privilege cannot be denied by an entry at the database, table,
          or column level.
        </p><p>
          The privileges for a column can be calculated as follows:
        </p><pre class="programlisting">global privileges
OR (database privileges AND host privileges)
OR table privileges
OR column privileges
OR routine privileges
</pre><p>
          In most cases, you grant rights to a user at only one of the
          privilege levels, so life is not normally this complicated.
          The details of the privilege-checking procedure are presented
          in <a href="http://dev.mysql.com/doc/refman/5.0/en/privilege-system.html" target="_top">The MySQL Access Privilege System</a>.
        </p><p>
          If you grant privileges for a username/hostname combination
          that does not exist in the <code class="literal">mysql.user</code>
          table, an entry is added and remains there until deleted with
          a <code class="literal">DELETE</code> statement. In other words,
          <code class="literal">GRANT</code> may create <code class="literal">user</code>
          table entries, but <code class="literal">REVOKE</code> does not remove
          them; you must do that explicitly using <code class="literal">DROP
          USER</code> or <code class="literal">DELETE</code>.
        </p><p>
          <span class="bold"><strong>Warning</strong></span>: If you create a new
          user but do not specify an <code class="literal">IDENTIFIED BY</code>
          clause, the user has no password. This is very insecure. As of
          MySQL 5.0.2, you can enable the
          <code class="literal">NO_AUTO_CREATE_USER</code> SQL mode to prevent
          <code class="literal">GRANT</code> from creating a new user if it would
          otherwise do so, unless <code class="literal">IDENTIFIED BY</code> is
          given to provide the new user a non-empty password.
        </p><a id="id2885918" class="indexterm"></a><p class="mnmas"><b>MySQL Enterprise. </b>
            The MySQL Network Monitoring and Advisory Service
            specifically guards against user accounts with no passwords.
            To find out more see,
            <a href="http://www.mysql.com/products/enterprise/advisors.html" target="_top">http://www.mysql.com/products/enterprise/advisors.html</a>.
          </p><p>
          If a new user is created or if you have global grant
          privileges, the user's password is set to the password
          specified by the <code class="literal">IDENTIFIED BY</code> clause, if
          one is given. If the user already had a password, this is
          replaced by the new one.
        </p><p>
          Passwords can also be set with the <code class="literal">SET
          PASSWORD</code> statement. See
          <a href="mysqlqb_statements.html#set-password" title="SET PASSWORD Syntax"><code class="literal">SET PASSWORD</code> Syntax</a>.
        </p><p>
          In the <code class="literal">IDENTIFIED BY</code> clause, the password
          should be given as the literal password value. It is
          unnecessary to use the <code class="literal">PASSWORD()</code> function
          as it is for the <code class="literal">SET PASSWORD</code> statement.
          For example:
        </p><pre class="programlisting">GRANT ... IDENTIFIED BY 'mypass';
</pre><p>
          If you do not want to send the password in clear text and you
          know the hashed value that <code class="literal">PASSWORD()</code> would
          return for the password, you can specify the hashed value
          preceded by the keyword <code class="literal">PASSWORD</code>:
        </p><pre class="programlisting">GRANT ...
IDENTIFIED BY PASSWORD '*6C8989366EAF75BB670AD8EA7A7FC1176A95CEF4';
</pre><p>
          In a C program, you can get the hashed value by using the
          <code class="literal">make_scrambled_password()</code> C API function.
        </p><p>
          If you grant privileges for a database, an entry in the
          <code class="literal">mysql.db</code> table is created if needed. If all
          privileges for the database are removed with
          <code class="literal">REVOKE</code>, this entry is deleted.
        </p><p>
          The <code class="literal">SHOW DATABASES</code> privilege enables the
          account to see database names by issuing the <code class="literal">SHOW
          DATABASE</code> statement. Accounts that do not have this
          privilege see only databases for which they have some
          privileges, and cannot use the statement at all if the server
          was started with the <code class="option">--skip-show-database</code>
          option.
        </p><p class="mnmas"><b>MySQL Enterprise. </b>
            The <code class="literal">SHOW DATABASES</code> privilege should be
            granted only to users who need to see all the databases on a
            MySQL server. Subscribers to the MySQL Network Monitoring
            and Advisory Service are alerted when servers are started
            without the <code class="option">--skip-show-database</code> option.
            For more information see,
            <a href="http://www.mysql.com/products/enterprise/advisors.html" target="_top">http://www.mysql.com/products/enterprise/advisors.html</a>.
          </p><p>
          If a user has no privileges for a table, the table name is not
          displayed when the user requests a list of tables (for
          example, with a <code class="literal">SHOW TABLES</code> statement).
        </p><p>
          The <code class="literal">WITH GRANT OPTION</code> clause gives the user
          the ability to give to other users any privileges the user has
          at the specified privilege level. You should be careful to
          whom you give the <code class="literal">GRANT OPTION</code> privilege,
          because two users with different privileges may be able to
          join privileges!
        </p><p>
          You cannot grant another user a privilege which you yourself
          do not have; the <code class="literal">GRANT OPTION</code> privilege
          enables you to assign only those privileges which you yourself
          possess.
        </p><p>
          Be aware that when you grant a user the <code class="literal">GRANT
          OPTION</code> privilege at a particular privilege level,
          any privileges the user possesses (or may be given in the
          future) at that level can also be granted by that user to
          other users. Suppose that you grant a user the
          <code class="literal">INSERT</code> privilege on a database. If you then
          grant the <code class="literal">SELECT</code> privilege on the database
          and specify <code class="literal">WITH GRANT OPTION</code>, that user
          can give to other users not only the <code class="literal">SELECT</code>
          privilege, but also <code class="literal">INSERT</code>. If you then
          grant the <code class="literal">UPDATE</code> privilege to the user on
          the database, the user can grant <code class="literal">INSERT</code>,
          <code class="literal">SELECT</code>, and <code class="literal">UPDATE</code>.
        </p><p>
          For a non-administrative user, you should not grant the
          <code class="literal">ALTER</code> privilege globally or for the
          <code class="literal">mysql</code> database. If you do that, the user
          can try to subvert the privilege system by renaming tables!
        </p><p>
          The <code class="literal">MAX_QUERIES_PER_HOUR
          <em class="replaceable"><code>count</code></em></code>,
          <code class="literal">MAX_UPDATES_PER_HOUR
          <em class="replaceable"><code>count</code></em></code>, and
          <code class="literal">MAX_CONNECTIONS_PER_HOUR
          <em class="replaceable"><code>count</code></em></code> options limit the
          number of queries, updates, and logins a user can perform
          during any given one-hour period. (Queries for which results
          are served from the query cache do not count against the
          <code class="literal">MAX_QUERIES_PER_HOUR</code> limit.) If
          <em class="replaceable"><code>count</code></em> is <code class="literal">0</code> (the
          default), this means that there is no limitation for that
          user.
        </p><p>
          The <code class="literal">MAX_USER_CONNECTIONS
          <em class="replaceable"><code>count</code></em></code> option, implemented
          in MySQL 5.0.3, limits the maximum number of simultaneous
          connections that the account can make. If
          <em class="replaceable"><code>count</code></em> is <code class="literal">0</code> (the
          default), the <code class="literal">max_user_connections</code> system
          variable determines the number of simultaneous connections for
          the account.
        </p><p>
          Note: To specify any of these resource-limit options for an
          existing user without affecting existing privileges, use
          <code class="literal">GRANT USAGE ON *.* ... WITH MAX_...</code>.
        </p><p>
          See <a href="http://dev.mysql.com/doc/refman/5.0/en/user-resources.html" target="_top">Limiting Account Resources</a>.
        </p><a id="id2886284" class="indexterm"></a><a id="id2886291" class="indexterm"></a><p>
          MySQL can check X509 certificate attributes in addition to the
          usual authentication that is based on the username and
          password. To specify SSL-related options for a MySQL account,
          use the <code class="literal">REQUIRE</code> clause of the
          <code class="literal">GRANT</code> statement. (For background
          information on the use of SSL with MySQL, see
          <a href="http://dev.mysql.com/doc/refman/5.0/en/secure-connections.html" target="_top">Using Secure Connections</a>.)
        </p><p>
          There are a number of different possibilities for limiting
          connection types for a given account:
        </p><div class="itemizedlist"><ul type="disc"><li><p>
              <code class="literal">REQUIRE NONE</code> indicates that the account
              has no SSL or X509 requirements. This is the default if no
              SSL-related <code class="literal">REQUIRE</code> options are
              specified. Unencrypted connections are allowed if the
              username and password are valid. However, encrypted
              connections can also be used, at the client's option, if
              the client has the proper certificate and key files. That
              is, the client need not specify any SSL commmand options,
              in which case the connection will be unencrypted. To use
              an encrypted connection, the client must specify either
              the <code class="option">--ssl-ca</code> option, or all three of the
              <code class="option">--ssl-ca</code>, <code class="option">--ssl-key</code>, and
              <code class="option">--ssl-cert</code> options.
            </p></li><li><p>
              The <code class="literal">REQUIRE SSL</code> option tells the server
              to allow only SSL-encrypted connections for the account.
            </p><pre class="programlisting">GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost'
  IDENTIFIED BY 'goodsecret' REQUIRE SSL;
</pre><p>
              To connect, the client must specify the
              <code class="option">--ssl-ca</code> option, and may additionally
              specify the <code class="option">--ssl-key</code> and
              <code class="option">--ssl-cert</code> options.
            </p></li><li><p>
              <code class="literal">REQUIRE X509</code> means that the client must
              have a valid certificate but that the exact certificate,
              issuer, and subject do not matter. The only requirement is
              that it should be possible to verify its signature with
              one of the CA certificates.
            </p><pre class="programlisting">GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost'
  IDENTIFIED BY 'goodsecret' REQUIRE X509;
</pre><p>
              To connect, the client must specify the
              <code class="option">--ssl-ca</code>, <code class="option">--ssl-key</code>, and
              <code class="option">--ssl-cert</code> options. This is also true for
              <code class="literal">ISSUER</code> and <code class="literal">SUBJECT</code>
              because those <code class="literal">REQUIRE</code> options imply
              <code class="literal">X509</code>.
            </p></li><li><p>
              <code class="literal">REQUIRE ISSUER
              '<em class="replaceable"><code>issuer</code></em>'</code> places the
              restriction on connection attempts that the client must
              present a valid X509 certificate issued by CA
              <code class="literal">'<em class="replaceable"><code>issuer</code></em>'</code>. If
              the client presents a certificate that is valid but has a
              different issuer, the server rejects the connection. Use
              of X509 certificates always implies encryption, so the
              <code class="literal">SSL</code> option is unnecessary in this case.
            </p><pre class="programlisting">GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost'
  IDENTIFIED BY 'goodsecret'
  REQUIRE ISSUER '/C=FI/ST=Some-State/L=Helsinki/
    O=MySQL Finland AB/CN=Tonu Samuel/Email=tonu@example.com';
</pre><p>
              Note that the
              <code class="literal">'<em class="replaceable"><code>issuer</code></em>'</code>
              value should be entered as a single string.
            </p></li><li><p>
              <code class="literal">REQUIRE SUBJECT
              '<em class="replaceable"><code>subject</code></em>'</code> places the
              restriction on connection attempts that the client must
              present a valid X509 certificate containing the subject
              <em class="replaceable"><code>subject</code></em>. If the client presents
              a certificate that is valid but has a different subject,
              the server rejects the connection.
            </p><pre class="programlisting">GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost'
  IDENTIFIED BY 'goodsecret'
  REQUIRE SUBJECT '/C=EE/ST=Some-State/L=Tallinn/
    O=MySQL demo client certificate/
    CN=Tonu Samuel/Email=tonu@example.com';
</pre><p>
              Note that the
              <code class="literal">'<em class="replaceable"><code>subject</code></em>'</code>
              value should be entered as a single string.
            </p></li><li><p>
              <code class="literal">REQUIRE CIPHER
              '<em class="replaceable"><code>cipher</code></em>'</code> is needed to
              ensure that ciphers and key lengths of sufficient strength
              are used. SSL itself can be weak if old algorithms using
              short encryption keys are used. Using this option, you can
              ask that a specific cipher method is used to allow a
              connection.
            </p><pre class="programlisting">GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost'
  IDENTIFIED BY 'goodsecret'
  REQUIRE CIPHER 'EDH-RSA-DES-CBC3-SHA';
</pre></li></ul></div><p>
          The <code class="literal">SUBJECT</code>, <code class="literal">ISSUER</code>, and
          <code class="literal">CIPHER</code> options can be combined in the
          <code class="literal">REQUIRE</code> clause like this:
        </p><pre class="programlisting">GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost'
  IDENTIFIED BY 'goodsecret'
  REQUIRE SUBJECT '/C=EE/ST=Some-State/L=Tallinn/
    O=MySQL demo client certificate/
    CN=Tonu Samuel/Email=tonu@example.com'
  AND ISSUER '/C=FI/ST=Some-State/L=Helsinki/
    O=MySQL Finland AB/CN=Tonu Samuel/Email=tonu@example.com'
  AND CIPHER 'EDH-RSA-DES-CBC3-SHA';
</pre><p>
          The <code class="literal">AND</code> keyword is optional between
          <code class="literal">REQUIRE</code> options.
        </p><p>
          The order of the options does not matter, but no option can be
          specified twice.
        </p><p>
          When <span><strong class="command">mysqld</strong></span> starts, all privileges are read
          into memory. For details, see
          <a href="http://dev.mysql.com/doc/refman/5.0/en/privilege-changes.html" target="_top">When Privilege Changes Take Effect</a>.
        </p><p>
          Note that if you are using table, column, or routine
          privileges for even one user, the server examines table,
          column, and routine privileges for all users and this slows
          down MySQL a bit. Similarly, if you limit the number of
          queries, updates, or connections for any users, the server
          must monitor these values.
        </p><a id="id2886652" class="indexterm"></a><p>
          The biggest differences between the standard SQL and MySQL
          versions of <code class="literal">GRANT</code> are:
        </p><div class="itemizedlist"><ul type="disc"><li><p>
              In MySQL, privileges are associated with the combination
              of a hostname and username and not with only a username.
            </p></li><li><p>
              Standard SQL does not have global or database-level
              privileges, nor does it support all the privilege types
              that MySQL supports.
            </p></li><li><p>
              MySQL does not support the standard SQL
              <code class="literal">TRIGGER</code> or <code class="literal">UNDER</code>
              privileges.
            </p></li><li><p>
              Standard SQL privileges are structured in a hierarchical
              manner. If you remove a user, all privileges the user has
              been granted are revoked. This is also true in MySQL 5.0.2
              and up if you use <code class="literal">DROP USER</code>. Before
              5.0.2, the granted privileges are not automatically
              revoked; you must revoke them yourself. See
              <a href="mysqlqb_statements.html#drop-user" title="DROP USER Syntax"><code class="literal">DROP USER</code> Syntax</a>.
            </p></li><li><p>
              In standard SQL, when you drop a table, all privileges for
              the table are revoked. In standard SQL, when you revoke a
              privilege, all privileges that were granted based on that
              privilege are also revoked. In MySQL, privileges can be
              dropped only with explicit <code class="literal">REVOKE</code>
              statements or by manipulating values stored in the MySQL
              grant tables.
            </p></li><li><p>
              In MySQL, it is possible to have the
              <code class="literal">INSERT</code> privilege for only some of the
              columns in a table. In this case, you can still execute
              <code class="literal">INSERT</code> statements on the table,
              provided that you omit those columns for which you do not
              have the <code class="literal">INSERT</code> privilege. The omitted
              columns are set to their implicit default values if strict
              SQL mode is not enabled. In strict mode, the statement is
              rejected if any of the omitted columns have no default
              value. (Standard SQL requires you to have the
              <code class="literal">INSERT</code> privilege on all columns.)
              <a href="http://dev.mysql.com/doc/refman/5.0/en/server-sql-mode.html" target="_top">SQL Modes</a>, discusses strict mode.
              <a href="http://dev.mysql.com/doc/refman/5.0/en/data-type-defaults.html" target="_top">Data Type Default Values</a>, discusses implicit
              default values.
            </p></li></ul></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="rename-user"></a><code class="literal">RENAME USER</code> Syntax</h4></div></div></div><a id="id2886813" class="indexterm"></a><a id="id2886819" class="indexterm"></a><a id="id2886830" class="indexterm"></a><pre class="programlisting">RENAME USER <em class="replaceable"><code>old_user</code></em> TO <em class="replaceable"><code>new_user</code></em>
    [, <em class="replaceable"><code>old_user</code></em> TO <em class="replaceable"><code>new_user</code></em>] ...
</pre><p>
          The <code class="literal">RENAME USER</code> statement renames existing
          MySQL accounts. To use it, you must have the global
          <code class="literal">CREATE USER</code> privilege or the
          <code class="literal">UPDATE</code> privilege for the
          <code class="literal">mysql</code> database. An error occurs if any old
          account does not exist or any new account exists. Each account
          is named using the same format as for the
          <code class="literal">GRANT</code> statement; for example,
          <code class="literal">'jeffrey'@'localhost'</code>. If you specify only
          the username part of the account name, a hostname part of
          <code class="literal">'%'</code> is used. For additional information
          about specifying account names, see <a href="mysqlqb_statements.html#grant" title="GRANT Syntax"><code class="literal">GRANT</code> Syntax</a>.
        </p><p>
          <code class="literal">RENAME USER</code> does not automatically migrate
          any database objects that the user created, nor does it
          migrate any privileges that the user had prior to the
          renaming. This applies to tables, views, stored routines, and
          triggers.
        </p><p>
          The <code class="literal">RENAME USER</code> statement was added in
          MySQL 5.0.2.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="revoke"></a><code class="literal">REVOKE</code> Syntax</h4></div></div></div><a id="id2886956" class="indexterm"></a><a id="id2886962" class="indexterm"></a><a id="id2886972" class="indexterm"></a><a id="id2886979" class="indexterm"></a><pre class="programlisting">REVOKE <em class="replaceable"><code>priv_type</code></em> [(<em class="replaceable"><code>column_list</code></em>)] [, <em class="replaceable"><code>priv_type</code></em> [(<em class="replaceable"><code>column_list</code></em>)]] ...
    ON [<em class="replaceable"><code>object_type</code></em>] {<em class="replaceable"><code>tbl_name</code></em> | * | *.* | <em class="replaceable"><code>db_name</code></em>.*}
    FROM <em class="replaceable"><code>user</code></em> [, <em class="replaceable"><code>user</code></em>] ...

REVOKE ALL PRIVILEGES, GRANT OPTION FROM <em class="replaceable"><code>user</code></em> [, <em class="replaceable"><code>user</code></em>] ...
</pre><p>
          The <code class="literal">REVOKE</code> statement enables system
          administrators to revoke privileges from MySQL accounts. To
          use <code class="literal">REVOKE</code>, you must have the
          <code class="literal">GRANT OPTION</code> privilege, and you must have
          the privileges that you are revoking.
        </p><p>
          Each account is named using the same format as for the
          <code class="literal">GRANT</code> statement; for example,
          <code class="literal">'jeffrey'@'localhost'</code>. If you specify only
          the username part of the account name, a hostname part of
          <code class="literal">'%'</code> is used. For additional information
          about specifying account names, see <a href="mysqlqb_statements.html#grant" title="GRANT Syntax"><code class="literal">GRANT</code> Syntax</a>.
        </p><p>
          For details on the levels at which privileges exist, the
          allowable <em class="replaceable"><code>priv_type</code></em> values, and the
          syntax for specifying users and passwords, see
          <a href="mysqlqb_statements.html#grant" title="GRANT Syntax"><code class="literal">GRANT</code> Syntax</a>
        </p><p>
          If the grant tables hold privilege rows that contain
          mixed-case database or table names and the
          <code class="literal">lower_case_table_names</code> system variable is
          set to a non-zero value, <code class="literal">REVOKE</code> cannot be
          used to revoke these privileges. It will be necessary to
          manipulate the grant tables directly.
          (<code class="literal">GRANT</code> will not create such rows when
          <code class="literal">lower_case_table_names</code> is set, but such
          rows might have been created prior to setting the variable.)
        </p><p>
          To revoke all privileges, use the following syntax, which
          drops all global, database-, table-, and column-level
          privileges for the named user or users:
        </p><pre class="programlisting">REVOKE ALL PRIVILEGES, GRANT OPTION FROM <em class="replaceable"><code>user</code></em> [, <em class="replaceable"><code>user</code></em>] ...
</pre><p>
          To use this <code class="literal">REVOKE</code> syntax, you must have
          the global <code class="literal">CREATE USER</code> privilege or the
          <code class="literal">UPDATE</code> privilege for the
          <code class="literal">mysql</code> database.
        </p><p>
          <code class="literal">REVOKE</code> removes privileges, but does not
          drop <code class="literal">user</code> table entries. You must do that
          explicitly using <code class="literal">DELETE</code> or <code class="literal">DROP
          USER</code> (see <a href="mysqlqb_statements.html#drop-user" title="DROP USER Syntax"><code class="literal">DROP USER</code> Syntax</a>).
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="set-password"></a><code class="literal">SET PASSWORD</code> Syntax</h4></div></div></div><a id="id2887222" class="indexterm"></a><a id="id2887229" class="indexterm"></a><a id="id2887239" class="indexterm"></a><pre class="programlisting">SET PASSWORD [FOR <em class="replaceable"><code>user</code></em>] = PASSWORD('<em class="replaceable"><code>some password</code></em>')
</pre><p>
          The <code class="literal">SET PASSWORD</code> statement assigns a
          password to an existing MySQL user account.
        </p><p>
          With no <code class="literal">FOR</code> clause, this statement sets the
          password for the current user. Any client that has connected
          to the server using a non-anonymous account can change the
          password for that account.
        </p><p>
          With a <code class="literal">FOR</code> clause, this statement sets the
          password for a specific account on the current server host.
          Only clients that have the <code class="literal">UPDATE</code> privilege
          for the <code class="literal">mysql</code> database can do this. The
          <em class="replaceable"><code>user</code></em> value should be given in
          <code class="literal"><em class="replaceable"><code>user_name</code></em>@<em class="replaceable"><code>host_name</code></em></code>
          format, where <em class="replaceable"><code>user_name</code></em> and
          <em class="replaceable"><code>host_name</code></em> are exactly as they are
          listed in the <code class="literal">User</code> and
          <code class="literal">Host</code> columns of the
          <code class="literal">mysql.user</code> table entry. For example, if you
          had an entry with <code class="literal">User</code> and
          <code class="literal">Host</code> column values of
          <code class="literal">'bob'</code> and <code class="literal">'%.loc.gov'</code>,
          you would write the statement like this:
        </p><pre class="programlisting">SET PASSWORD FOR 'bob'@'%.loc.gov' = PASSWORD('<em class="replaceable"><code>newpass</code></em>');
</pre><p>
          That is equivalent to the following statements:
        </p><pre class="programlisting">UPDATE mysql.user SET Password=PASSWORD('<em class="replaceable"><code>newpass</code></em>')
  WHERE User='bob' AND Host='%.loc.gov';
FLUSH PRIVILEGES;
</pre><p>
          <span class="bold"><strong>Note</strong></span>: If you are connecting
          to a MySQL 4.1 or later server using a pre-4.1 client program,
          do not use the preceding <code class="literal">SET PASSWORD</code> or
          <code class="literal">UPDATE</code> statement without reading
          <a href="http://dev.mysql.com/doc/refman/5.0/en/password-hashing.html" target="_top">Password Hashing as of MySQL 4.1</a>, first. The password format
          changed in MySQL 4.1, and under certain circumstances it is
          possible that if you change your password, you might not be
          able to connect to the server afterward.
        </p><p>
          You can see which account the server authenticated you as by
          executing <code class="literal">SELECT CURRENT_USER()</code>.
        </p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="table-maintenance-sql"></a>Table Maintenance Statements</h3></div></div></div><div class="toc"><dl><dt><span class="section"><a href="mysqlqb_statements.html#analyze-table"><code class="literal">ANALYZE TABLE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#backup-table"><code class="literal">BACKUP TABLE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#check-table"><code class="literal">CHECK TABLE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#checksum-table"><code class="literal">CHECKSUM TABLE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#optimize-table"><code class="literal">OPTIMIZE TABLE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#repair-table"><code class="literal">REPAIR TABLE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#restore-table"><code class="literal">RESTORE TABLE</code> Syntax</a></span></dt></dl></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="analyze-table"></a><code class="literal">ANALYZE TABLE</code> Syntax</h4></div></div></div><a id="id2887454" class="indexterm"></a><pre class="programlisting">ANALYZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE <em class="replaceable"><code>tbl_name</code></em> [, <em class="replaceable"><code>tbl_name</code></em>] ...
</pre><p>
          <code class="literal">ANALYZE TABLE</code> analyzes and stores the key
          distribution for a table. During the analysis, the table is
          locked with a read lock for <code class="literal">MyISAM</code> and
          <code class="literal">BDB</code>. For <code class="literal">InnoDB</code> the
          table is locked with a write lock. This statement works with
          <code class="literal">MyISAM</code>, <code class="literal">BDB</code>, and
          <code class="literal">InnoDB</code> tables. For
          <code class="literal">MyISAM</code> tables, this statement is equivalent
          to using <span><strong class="command">myisamchk --analyze</strong></span>.
        </p><p>
          For more information on how the analysis works
          within<code class="literal">InnoDB</code>, see
          <a href="http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html" target="_top">Restrictions on <code class="literal">InnoDB</code> Tables</a>.
        </p><p>
          MySQL uses the stored key distribution to decide the order in
          which tables should be joined when you perform a join on
          something other than a constant.
        </p><p>
          This statement requires <code class="literal">SELECT</code> and
          <code class="literal">INSERT</code> privileges for the table.
        </p><p>
          <code class="literal">ANALYZE TABLE</code> returns a result set with the
          following columns:
        </p><div class="informaltable"><table border="1"><colgroup><col /><col /></colgroup><tbody><tr><td><span class="bold"><strong>Column</strong></span></td><td><span class="bold"><strong>Value</strong></span></td></tr><tr><td><code class="literal">Table</code></td><td>The table name</td></tr><tr><td><code class="literal">Op</code></td><td>Always <code class="literal">analyze</code></td></tr><tr><td><code class="literal">Msg_type</code></td><td>One of <code class="literal">status</code>, <code class="literal">error</code>,
                  <code class="literal">info</code>, or <code class="literal">warning</code></td></tr><tr><td><code class="literal">Msg_text</code></td><td>The message</td></tr></tbody></table></div><p>
          You can check the stored key distribution with the
          <code class="literal">SHOW INDEX</code> statement. See
          <a href="mysqlqb_statements.html#show-index" title="SHOW INDEX Syntax"><code class="literal">SHOW INDEX</code> Syntax</a>.
        </p><p>
          If the table has not changed since the last <code class="literal">ANALYZE
          TABLE</code> statement, the table is not analyzed again.
        </p><p>
          <code class="literal">ANALYZE TABLE</code> statements are written to the
          binary log unless the optional
          <code class="literal">NO_WRITE_TO_BINLOG</code> keyword (or its alias
          <code class="literal">LOCAL</code>) is used. This is done so that
          <code class="literal">ANALYZE TABLE</code> statements used on a MySQL
          server acting as a replication master will be replicated by
          default to the replication slave.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="backup-table"></a><code class="literal">BACKUP TABLE</code> Syntax</h4></div></div></div><a id="id2887740" class="indexterm"></a><a id="id2887747" class="indexterm"></a><pre class="programlisting">BACKUP TABLE <em class="replaceable"><code>tbl_name</code></em> [, <em class="replaceable"><code>tbl_name</code></em>] ... TO '<em class="replaceable"><code>/path/to/backup/directory</code></em>'
</pre><p>
          <span class="bold"><strong>Note</strong></span>: This statement is
          deprecated. We are working on a better replacement for it that
          will provide online backup capabilities. In the meantime, the
          <span><strong class="command">mysqlhotcopy</strong></span> script can be used instead.
        </p><p>
          <code class="literal">BACKUP TABLE</code> copies to the backup directory
          the minimum number of table files needed to restore the table,
          after flushing any buffered changes to disk. The statement
          works only for <code class="literal">MyISAM</code> tables. It copies the
          <code class="filename">.frm</code> definition and
          <code class="filename">.MYD</code> data files. The
          <code class="filename">.MYI</code> index file can be rebuilt from those
          two files. The directory should be specified as a full
          pathname. To restore the table, use <code class="literal">RESTORE
          TABLE</code>.
        </p><p>
          During the backup, a read lock is held for each table, one at
          time, as they are being backed up. If you want to back up
          several tables as a snapshot (preventing any of them from
          being changed during the backup operation), issue a
          <code class="literal">LOCK TABLES</code> statement first, to obtain a
          read lock for all tables in the group.
        </p><p>
          <code class="literal">BACKUP TABLE</code> returns a result set with the
          following columns:
        </p><div class="informaltable"><table border="1"><colgroup><col /><col /></colgroup><tbody><tr><td><span class="bold"><strong>Column</strong></span></td><td><span class="bold"><strong>Value</strong></span></td></tr><tr><td><code class="literal">Table</code></td><td>The table name</td></tr><tr><td><code class="literal">Op</code></td><td>Always <code class="literal">backup</code></td></tr><tr><td><code class="literal">Msg_type</code></td><td>One of <code class="literal">status</code>, <code class="literal">error</code>,
                  <code class="literal">info</code>, or <code class="literal">warning</code></td></tr><tr><td><code class="literal">Msg_text</code></td><td>The message</td></tr></tbody></table></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="check-table"></a><code class="literal">CHECK TABLE</code> Syntax</h4></div></div></div><a id="id2887982" class="indexterm"></a><pre class="programlisting">CHECK TABLE <em class="replaceable"><code>tbl_name</code></em> [, <em class="replaceable"><code>tbl_name</code></em>] ... [<em class="replaceable"><code>option</code></em>] ...

<em class="replaceable"><code>option</code></em> = {FOR UPGRADE | QUICK | FAST | MEDIUM | EXTENDED | CHANGED}
</pre><p>
          <code class="literal">CHECK TABLE</code> checks a table or tables for
          errors. <code class="literal">CHECK TABLE</code> works for
          <code class="literal">MyISAM</code>, <code class="literal">InnoDB</code>, and (as
          of MySQL 5.0.16) <code class="literal">ARCHIVE</code> tables. For
          <code class="literal">MyISAM</code> tables, the key statistics are
          updated as well.
        </p><p>
          As of MySQL 5.0.2, <code class="literal">CHECK TABLE</code> can also
          check views for problems, such as tables that are referenced
          in the view definition that no longer exist.
        </p><p>
          <code class="literal">CHECK TABLE</code> returns a result set with the
          following columns:
        </p><div class="informaltable"><table border="1"><colgroup><col /><col /></colgroup><tbody><tr><td><span class="bold"><strong>Column</strong></span></td><td><span class="bold"><strong>Value</strong></span></td></tr><tr><td><code class="literal">Table</code></td><td>The table name</td></tr><tr><td><code class="literal">Op</code></td><td>Always <code class="literal">check</code></td></tr><tr><td><code class="literal">Msg_type</code></td><td>One of <code class="literal">status</code>, <code class="literal">error</code>,
                  <code class="literal">info</code>, or <code class="literal">warning</code></td></tr><tr><td><code class="literal">Msg_text</code></td><td>The message</td></tr></tbody></table></div><p>
          Note that the statement might produce many rows of information
          for each checked table. The last row has a
          <code class="literal">Msg_type</code> value of <code class="literal">status</code>
          and the <code class="literal">Msg_text</code> normally should be
          <code class="literal">OK</code>. If you don't get <code class="literal">OK</code>,
          or <code class="literal">Table is already up to date</code> you should
          normally run a repair of the table. See
          <a href="http://dev.mysql.com/doc/refman/5.0/en/table-maintenance.html" target="_top">Table Maintenance and Crash Recovery</a>. <code class="literal">Table is already
          up to date</code> means that the storage engine for the
          table indicated that there was no need to check the table.
        </p><p>
          The <code class="literal">FOR UPGRADE</code> option checks whether the
          named tables are compatible with the current version of MySQL.
          This option was added in MySQL 5.0.19. With <code class="literal">FOR
          UPGRADE</code>, the server checks each table to determine
          whether there have been any incompatible changes in any of the
          table's data types or indexes since the table was created. If
          not, the check succeeds. Otherwise, if there is a possible
          incompatibility, the server runs a full check on the table
          (which might take some time). If the full check succeeds, the
          server marks the table's <code class="filename">.frm</code> file with
          the current MySQL version number. Marking the
          <code class="filename">.frm</code> file ensures that further checks for
          the table with the same version of the server will be fast.
        </p><p>
          Incompatibilities might occur because the storage format for a
          data type has changed or because its sort order has changed.
          Our aim is to avoid these changes, but occasionally they are
          necessary to correct problems that would be worse than an
          incompatibility between releases.
        </p><p>
          Currently, <code class="literal">FOR UPGRADE</code> discovers these
          incompatibilities:
        </p><div class="itemizedlist"><ul type="disc"><li><p>
              The indexing order for end-space in
              <code class="literal">TEXT</code> columns for
              <code class="literal">InnoDB</code> and <code class="literal">MyISAM</code>
              tables changed between MySQL 4.1 and 5.0.
            </p></li><li><p>
              The storage method of the new <code class="literal">DECIMAL</code>
              data type changed between MySQL 5.0.3 and 5.0.5.
            </p></li></ul></div><p>
          The other check options that can be given are shown in the
          following table. These options apply only to checking
          <code class="literal">MyISAM</code> tables and are ignored for
          <code class="literal">InnoDB</code> tables and views.
        </p><div class="informaltable"><table border="1"><colgroup><col /><col /></colgroup><tbody><tr><td><span class="bold"><strong>Type</strong></span></td><td><span class="bold"><strong>Meaning</strong></span></td></tr><tr><td><code class="literal">QUICK</code></td><td>Do not scan the rows to check for incorrect links.</td></tr><tr><td><code class="literal">FAST</code></td><td>Check only tables that have not been closed properly.</td></tr><tr><td><code class="literal">CHANGED</code></td><td>Check only tables that have been changed since the last check or that
                  have not been closed properly.</td></tr><tr><td><code class="literal">MEDIUM</code></td><td>Scan rows to verify that deleted links are valid. This also calculates a
                  key checksum for the rows and verifies this with a
                  calculated checksum for the keys.</td></tr><tr><td><code class="literal">EXTENDED</code></td><td>Do a full key lookup for all keys for each row. This ensures that the
                  table is 100% consistent, but takes a long time.</td></tr></tbody></table></div><p>
          If none of the options <code class="literal">QUICK</code>,
          <code class="literal">MEDIUM</code>, or <code class="literal">EXTENDED</code> are
          specified, the default check type for dynamic-format
          <code class="literal">MyISAM</code> tables is <code class="literal">MEDIUM</code>.
          This has the same result as running <span><strong class="command">myisamchk
          --medium-check <em class="replaceable"><code>tbl_name</code></em></strong></span>
          on the table. The default check type also is
          <code class="literal">MEDIUM</code> for static-format
          <code class="literal">MyISAM</code> tables, unless
          <code class="literal">CHANGED</code> or <code class="literal">FAST</code> is
          specified. In that case, the default is
          <code class="literal">QUICK</code>. The row scan is skipped for
          <code class="literal">CHANGED</code> and <code class="literal">FAST</code> because
          the rows are very seldom corrupted.
        </p><p>
          You can combine check options, as in the following example
          that does a quick check on the table to determine whether it
          was closed properly:
        </p><pre class="programlisting">CHECK TABLE test_table FAST QUICK;
</pre><p>
          <span class="bold"><strong>Note</strong></span>: In some cases,
          <code class="literal">CHECK TABLE</code> changes the table. This happens
          if the table is marked as “<span class="quote">corrupted</span>” or
          “<span class="quote">not closed properly</span>” but <code class="literal">CHECK
          TABLE</code> does not find any problems in the table. In
          this case, <code class="literal">CHECK TABLE</code> marks the table as
          okay.
        </p><p>
          If a table is corrupted, it is most likely that the problem is
          in the indexes and not in the data part. All of the preceding
          check types check the indexes thoroughly and should thus find
          most errors.
        </p><p>
          If you just want to check a table that you assume is okay, you
          should use no check options or the <code class="literal">QUICK</code>
          option. The latter should be used when you are in a hurry and
          can take the very small risk that <code class="literal">QUICK</code>
          does not find an error in the data file. (In most cases, under
          normal usage, MySQL should find any error in the data file. If
          this happens, the table is marked as “<span class="quote">corrupted</span>”
          and cannot be used until it is repaired.)
        </p><p>
          <code class="literal">FAST</code> and <code class="literal">CHANGED</code> are
          mostly intended to be used from a script (for example, to be
          executed from <span><strong class="command">cron</strong></span>) if you want to check
          tables from time to time. In most cases,
          <code class="literal">FAST</code> is to be preferred over
          <code class="literal">CHANGED</code>. (The only case when it is not
          preferred is when you suspect that you have found a bug in the
          <code class="literal">MyISAM</code> code.)
        </p><p>
          <code class="literal">EXTENDED</code> is to be used only after you have
          run a normal check but still get strange errors from a table
          when MySQL tries to update a row or find a row by key. This is
          very unlikely if a normal check has succeeded.
        </p><p>
          Some problems reported by <code class="literal">CHECK TABLE</code>
          cannot be corrected automatically:
        </p><div class="itemizedlist"><ul type="disc"><li><p>
              <code class="literal">Found row where the auto_increment column has the
              value 0</code>.
            </p><p>
              This means that you have a row in the table where the
              <code class="literal">AUTO_INCREMENT</code> index column contains
              the value 0. (It is possible to create a row where the
              <code class="literal">AUTO_INCREMENT</code> column is 0 by
              explicitly setting the column to 0 with an
              <code class="literal">UPDATE</code> statement.)
            </p><p>
              This is not an error in itself, but could cause trouble if
              you decide to dump the table and restore it or do an
              <code class="literal">ALTER TABLE</code> on the table. In this case,
              the <code class="literal">AUTO_INCREMENT</code> column changes value
              according to the rules of
              <code class="literal">AUTO_INCREMENT</code> columns, which could
              cause problems such as a duplicate-key error.
            </p><p>
              To get rid of the warning, simply execute an
              <code class="literal">UPDATE</code> statement to set the column to
              some value other than 0.
            </p></li></ul></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="checksum-table"></a><code class="literal">CHECKSUM TABLE</code> Syntax</h4></div></div></div><a id="id2888679" class="indexterm"></a><pre class="programlisting">CHECKSUM TABLE <em class="replaceable"><code>tbl_name</code></em> [, <em class="replaceable"><code>tbl_name</code></em>] ... [ QUICK | EXTENDED ]
</pre><p>
          <code class="literal">CHECKSUM TABLE</code> reports a table checksum.
        </p><p>
          With <code class="literal">QUICK</code>, the live table checksum is
          reported if it is available, or <code class="literal">NULL</code>
          otherwise. This is very fast. A live checksum is enabled by
          specifying the <code class="literal">CHECKSUM=1</code> table option when
          you create the table; currently, this is supported only for
          <code class="literal">MyISAM</code> tables. See
          <a href="mysqlqb_statements.html#create-table" title="CREATE TABLE Syntax"><code class="literal">CREATE TABLE</code> Syntax</a>.
        </p><p>
          With <code class="literal">EXTENDED</code>, the entire table is read row
          by row and the checksum is calculated. This can be very slow
          for large tables.
        </p><p>
          If neither <code class="literal">QUICK</code> nor
          <code class="literal">EXTENDED</code> is specified, MySQL returns a live
          checksum if the table storage engine supports it and scans the
          table otherwise.
        </p><p>
          For a non-existent table, <code class="literal">CHECKSUM TABLE</code>
          returns <code class="literal">NULL</code> and, as of MySQL 5.0.3,
          generates a warning.
        </p><p>
          The checksum value depends on the table row format. If the row
          format changes, the checksum will change. For example, the
          storage format for <code class="literal">VARCHAR</code> changed between
          MySQL 4.1 and 5.0, so if a 4.1 table is upgraded to MySQL 5.0,
          the checksum value may change.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="optimize-table"></a><code class="literal">OPTIMIZE TABLE</code> Syntax</h4></div></div></div><a id="id2888818" class="indexterm"></a><a id="id2888825" class="indexterm"></a><a id="id2888836" class="indexterm"></a><pre class="programlisting">OPTIMIZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE <em class="replaceable"><code>tbl_name</code></em> [, <em class="replaceable"><code>tbl_name</code></em>] ...
</pre><p>
          <code class="literal">OPTIMIZE TABLE</code> should be used if you have
          deleted a large part of a table or if you have made many
          changes to a table with variable-length rows (tables that have
          <code class="literal">VARCHAR</code>, <code class="literal">VARBINARY</code>,
          <code class="literal">BLOB</code>, or <code class="literal">TEXT</code> columns).
          Deleted rows are maintained in a linked list and subsequent
          <code class="literal">INSERT</code> operations reuse old row positions.
          You can use <code class="literal">OPTIMIZE TABLE</code> to reclaim the
          unused space and to defragment the data file.
        </p><p>
          This statement requires <code class="literal">SELECT</code> and
          <code class="literal">INSERT</code> privileges for the table.
        </p><p>
          In most setups, you need not run <code class="literal">OPTIMIZE
          TABLE</code> at all. Even if you do a lot of updates to
          variable-length rows, it is not likely that you need to do
          this more than once a week or month and only on certain
          tables.
        </p><p>
          <code class="literal">OPTIMIZE TABLE</code> works
          <span class="emphasis"><em>only</em></span> for <code class="literal">MyISAM</code>,
          <code class="literal">InnoDB</code>, and (as of MySQL 5.0.16)
          <code class="literal">ARCHIVE</code> tables. It does
          <span class="emphasis"><em>not</em></span> work for tables created using any
          other storage engine.
        </p><p>
          For <code class="literal">MyISAM</code> tables, <code class="literal">OPTIMIZE
          TABLE</code> works as follows:
        </p><div class="orderedlist"><ol type="1"><li><p>
              If the table has deleted or split rows, repair the table.
            </p></li><li><p>
              If the index pages are not sorted, sort them.
            </p></li><li><p>
              If the table's statistics are not up to date (and the
              repair could not be accomplished by sorting the index),
              update them.
            </p></li></ol></div><p>
          For <code class="literal">BDB</code> tables, <code class="literal">OPTIMIZE
          TABLE</code> currently is mapped to <code class="literal">ANALYZE
          TABLE</code>. See <a href="mysqlqb_statements.html#analyze-table" title="ANALYZE TABLE Syntax"><code class="literal">ANALYZE TABLE</code> Syntax</a>.
        </p><p>
          For <code class="literal">InnoDB</code> tables, <code class="literal">OPTIMIZE
          TABLE</code> is mapped to <code class="literal">ALTER TABLE</code>,
          which rebuilds the table to update index statistics and free
          unused space in the clustered index.
        </p><p>
          You can make <code class="literal">OPTIMIZE TABLE</code> work on other
          storage engines by starting <span><strong class="command">mysqld</strong></span> with the
          <code class="option">--skip-new</code> or <code class="option">--safe-mode</code>
          option. In this case, <code class="literal">OPTIMIZE TABLE</code> is
          just mapped to <code class="literal">ALTER TABLE</code>.
        </p><p>
          <code class="literal">OPTIMIZE TABLE</code> returns a result set with
          the following columns:
        </p><div class="informaltable"><table border="1"><colgroup><col /><col /></colgroup><tbody><tr><td><span class="bold"><strong>Column</strong></span></td><td><span class="bold"><strong>Value</strong></span></td></tr><tr><td><code class="literal">Table</code></td><td>The table name</td></tr><tr><td><code class="literal">Op</code></td><td>Always <code class="literal">optimize</code></td></tr><tr><td><code class="literal">Msg_type</code></td><td>One of <code class="literal">status</code>, <code class="literal">error</code>,
                  <code class="literal">info</code>, or <code class="literal">warning</code></td></tr><tr><td><code class="literal">Msg_text</code></td><td>The message</td></tr></tbody></table></div><p>
          Note that MySQL locks the table during the time
          <code class="literal">OPTIMIZE TABLE</code> is running.
        </p><p>
          <code class="literal">OPTIMIZE TABLE</code> statements are written to
          the binary log unless the optional
          <code class="literal">NO_WRITE_TO_BINLOG</code> keyword(or its alias
          <code class="literal">LOCAL</code>) is used. This is done so that
          <code class="literal">OPTIMIZE TABLE</code> statements used on a MySQL
          server acting as a replication master will be replicated by
          default to the replication slave.
        </p><p>
          <code class="literal">OPTIMIZE TABLE</code> does not sort R-tree
          indexes, such as spatial indexes on <code class="literal">POINT</code>
          columns. (<a href="http://bugs.mysql.com/23578" target="_top">Bug#23578</a>)
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="repair-table"></a><code class="literal">REPAIR TABLE</code> Syntax</h4></div></div></div><a id="id2889244" class="indexterm"></a><pre class="programlisting">REPAIR [LOCAL | NO_WRITE_TO_BINLOG] TABLE
    <em class="replaceable"><code>tbl_name</code></em> [, <em class="replaceable"><code>tbl_name</code></em>] ... [QUICK] [EXTENDED] [USE_FRM]
</pre><p>
          <code class="literal">REPAIR TABLE</code> repairs a possibly corrupted
          table. By default, it has the same effect as
          <span><strong class="command">myisamchk --recover
          <em class="replaceable"><code>tbl_name</code></em></strong></span>. <code class="literal">REPAIR
          TABLE</code> works for <code class="literal">MyISAM</code> and for
          <code class="literal">ARCHIVE</code> tables. See
          <a href="http://dev.mysql.com/doc/refman/5.0/en/myisam-storage-engine.html" target="_top">The <code class="literal">MyISAM</code> Storage Engine</a>, and
          <a href="http://dev.mysql.com/doc/refman/5.0/en/archive-storage-engine.html" target="_top">The <code class="literal">ARCHIVE</code> Storage Engine</a>.
        </p><p>
          This statement requires <code class="literal">SELECT</code> and
          <code class="literal">INSERT</code> privileges for the table.
        </p><p>
          Normally, you should never have to run this statement.
          However, if disaster strikes, <code class="literal">REPAIR TABLE</code>
          is very likely to get back all your data from a
          <code class="literal">MyISAM</code> table. If your tables become
          corrupted often, you should try to find the reason for it, to
          eliminate the need to use <code class="literal">REPAIR TABLE</code>. See
          <a href="http://dev.mysql.com/doc/refman/5.0/en/crashing.html" target="_top">What to Do If MySQL Keeps Crashing</a>, and
          <a href="http://dev.mysql.com/doc/refman/5.0/en/myisam-table-problems.html" target="_top"><code class="literal">MyISAM</code> Table Problems</a>.
        </p><p>
          <span class="bold"><strong>Warning:</strong></span> If the server dies
          during a <code class="literal">REPAIR TABLE</code> operation, it is
          essential after restarting it that you immediately execute
          another <code class="literal">REPAIR TABLE</code> statement for the
          table before performing any other operations on it. (It is
          always a good idea to start by making a backup.) In the worst
          case, you might have a new clean index file without
          information about the data file, and then the next operation
          you perform could overwrite the data file. This is an unlikely
          but possible scenario.
        </p><p>
          <code class="literal">REPAIR TABLE</code> returns a result set with the
          following columns:
        </p><div class="informaltable"><table border="1"><colgroup><col /><col /></colgroup><tbody><tr><td><span class="bold"><strong>Column</strong></span></td><td><span class="bold"><strong>Value</strong></span></td></tr><tr><td><code class="literal">Table</code></td><td>The table name</td></tr><tr><td><code class="literal">Op</code></td><td>Always <code class="literal">repair</code></td></tr><tr><td><code class="literal">Msg_type</code></td><td>One of <code class="literal">status</code>, <code class="literal">error</code>,
                  <code class="literal">info</code>, or <code class="literal">warning</code></td></tr><tr><td><code class="literal">Msg_text</code></td><td>The message</td></tr></tbody></table></div><p>
          The <code class="literal">REPAIR TABLE</code> statement might produce
          many rows of information for each repaired table. The last row
          has a <code class="literal">Msg_type</code> value of
          <code class="literal">status</code> and <code class="literal">Msg_test</code>
          normally should be <code class="literal">OK</code>. If you do not get
          <code class="literal">OK</code>, you should try repairing the table with
          <span><strong class="command">myisamchk --safe-recover</strong></span>. (<code class="literal">REPAIR
          TABLE</code> does not yet implement all the options of
          <span><strong class="command">myisamchk</strong></span>.) With <span><strong class="command">myisamchk
          --safe-recover</strong></span>, you can also use options that
          <code class="literal">REPAIR TABLE</code> does not support, such as
          <code class="option">--max-record-length</code>.
        </p><p>
          If <code class="literal">QUICK</code> is given, <code class="literal">REPAIR
          TABLE</code> tries to repair only the index tree. This type
          of repair is like that done by <span><strong class="command">myisamchk --recover
          --quick</strong></span>.
        </p><p>
          If you use <code class="literal">EXTENDED</code>, MySQL creates the
          index row by row instead of creating one index at a time with
          sorting. This type of repair is like that done by
          <span><strong class="command">myisamchk --safe-recover</strong></span>.
        </p><p>
          There is also a <code class="literal">USE_FRM</code> mode available for
          <code class="literal">REPAIR TABLE</code>. Use this if the
          <code class="filename">.MYI</code> index file is missing or if its
          header is corrupted. In this mode, MySQL re-creates the
          <code class="filename">.MYI</code> file using information from the
          <code class="filename">.frm</code> file. This kind of repair cannot be
          done with <span><strong class="command">myisamchk</strong></span>.
          <span class="bold"><strong>Note</strong></span>: Use this mode
          <span class="emphasis"><em>only</em></span> if you cannot use regular
          <code class="literal">REPAIR</code> modes. The <code class="filename">.MYI</code>
          header contains important table metadata (in particular,
          current <code class="literal">AUTO_INCREMENT</code> value and
          <code class="literal">Delete link</code>) that are lost in
          <code class="literal">REPAIR ... USE_FRM</code>. Don't use
          <code class="literal">USE_FRM</code> if the table is compressed because
          this information is also stored in the
          <code class="filename">.MYI</code> file.
        </p><p>
          <code class="literal">REPAIR TABLE</code> statements are written to the
          binary log unless the optional
          <code class="literal">NO_WRITE_TO_BINLOG</code> keyword (or its alias
          <code class="literal">LOCAL</code>) is used. This is done so that
          <code class="literal">REPAIR TABLE</code> statements used on a MySQL
          server acting as a replication master will be replicated by
          default to the replication slave.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="restore-table"></a><code class="literal">RESTORE TABLE</code> Syntax</h4></div></div></div><a id="id2889709" class="indexterm"></a><pre class="programlisting">RESTORE TABLE <em class="replaceable"><code>tbl_name</code></em> [, <em class="replaceable"><code>tbl_name</code></em>] ... FROM '<em class="replaceable"><code>/path/to/backup/directory</code></em>'
</pre><p>
          <code class="literal">RESTORE TABLE</code> restores the table or tables
          from a backup that was made with <code class="literal">BACKUP
          TABLE</code>. The directory should be specified as a full
          pathname.
        </p><p>
          Existing tables are not overwritten; if you try to restore
          over an existing table, an error occurs. Just as for
          <code class="literal">BACKUP TABLE</code>, <code class="literal">RESTORE
          TABLE</code> currently works only for
          <code class="literal">MyISAM</code> tables. Restored tables are not
          replicated from master to slave.
        </p><p>
          The backup for each table consists of its
          <code class="filename">.frm</code> format file and
          <code class="filename">.MYD</code> data file. The restore operation
          restores those files, and then uses them to rebuild the
          <code class="filename">.MYI</code> index file. Restoring takes longer
          than backing up due to the need to rebuild the indexes. The
          more indexes the table has, the longer it takes.
        </p><p>
          <code class="literal">RESTORE TABLE</code> returns a result set with the
          following columns:
        </p><div class="informaltable"><table border="1"><colgroup><col /><col /></colgroup><tbody><tr><td><span class="bold"><strong>Column</strong></span></td><td><span class="bold"><strong>Value</strong></span></td></tr><tr><td><code class="literal">Table</code></td><td>The table name</td></tr><tr><td><code class="literal">Op</code></td><td>Always <code class="literal">restore</code></td></tr><tr><td><code class="literal">Msg_type</code></td><td>One of <code class="literal">status</code>, <code class="literal">error</code>,
                  <code class="literal">info</code>, or <code class="literal">warning</code></td></tr><tr><td><code class="literal">Msg_text</code></td><td>The message</td></tr></tbody></table></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="set-option"></a><code class="literal">SET</code> Syntax</h3></div></div></div><a id="id2889922" class="indexterm"></a><a id="id2889928" class="indexterm"></a><a id="id2889935" class="indexterm"></a><a id="id2889947" class="indexterm"></a><a id="id2889959" class="indexterm"></a><a id="id2889971" class="indexterm"></a><a id="id2889983" class="indexterm"></a><a id="id2889995" class="indexterm"></a><a id="id2890007" class="indexterm"></a><a id="id2890019" class="indexterm"></a><a id="id2890031" class="indexterm"></a><a id="id2890043" class="indexterm"></a><a id="id2890055" class="indexterm"></a><a id="id2890067" class="indexterm"></a><a id="id2890080" class="indexterm"></a><a id="id2890092" class="indexterm"></a><a id="id2890104" class="indexterm"></a><a id="id2890116" class="indexterm"></a><a id="id2890128" class="indexterm"></a><a id="id2890140" class="indexterm"></a><a id="id2890152" class="indexterm"></a><a id="id2890164" class="indexterm"></a><a id="id2890176" class="indexterm"></a><a id="id2890188" class="indexterm"></a><a id="id2890201" class="indexterm"></a><a id="id2890213" class="indexterm"></a><pre class="programlisting">SET <em class="replaceable"><code>variable_assignment</code></em> [, <em class="replaceable"><code>variable_assignment</code></em>] ...

<em class="replaceable"><code>variable_assignment</code></em>:
      <em class="replaceable"><code>user_var_name</code></em> = <em class="replaceable"><code>expr</code></em>
    | [GLOBAL | SESSION] <em class="replaceable"><code>system_var_name</code></em> = <em class="replaceable"><code>expr</code></em>
    | [@@global. | @@session. | @@]<em class="replaceable"><code>system_var_name</code></em> = <em class="replaceable"><code>expr</code></em>
</pre><p>
        The <code class="literal">SET</code> statement assigns values to different
        types of variables that affect the operation of the server or
        your client. Older versions of MySQL employed <code class="literal">SET
        OPTION</code>, but this syntax is deprecated in favor of
        <code class="literal">SET</code> without <code class="literal">OPTION</code>.
      </p><p>
        This section describes use of <code class="literal">SET</code> for
        assigning values to system variables or user variables. For
        general information about these types of variables, see
        <a href="http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html" target="_top">System Variables</a>, and
        <a href="http://dev.mysql.com/doc/refman/5.0/en/user-variables.html" target="_top">User-Defined Variables</a>. System variables also can be
        set at server startup, as described in
        <a href="http://dev.mysql.com/doc/refman/5.0/en/using-system-variables.html" target="_top">Using System Variables</a>.
      </p><p>
        Some variants of <code class="literal">SET</code> syntax are used in other
        contexts:
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            <code class="literal">SET PASSWORD</code> assigns account passwords.
            See <a href="mysqlqb_statements.html#set-password" title="SET PASSWORD Syntax"><code class="literal">SET PASSWORD</code> Syntax</a>.
          </p></li><li><p>
            <code class="literal">SET TRANSACTION ISOLATION LEVEL</code> sets the
            isolation level for transaction processing. See
            <a href="mysqlqb_statements.html#set-transaction" title="SET TRANSACTION Syntax"><code class="literal">SET TRANSACTION</code> Syntax</a>.
          </p></li><li><p>
            <code class="literal">SET</code> is used within stored routines to
            assign values to local routine variables. See
            <a href="http://dev.mysql.com/doc/refman/5.0/en/set-statement.html" target="_top">Variable <code class="literal">SET</code> Statement</a>.
          </p></li></ul></div><p>
        The following discussion shows the different
        <code class="literal">SET</code> syntaxes that you can use to set
        variables. The examples use the <code class="literal">=</code> assignment
        operator, but the <code class="literal">:=</code> operator also is
        allowable.
      </p><p>
        A user variable is written as
        <code class="literal">@<em class="replaceable"><code>var_name</code></em></code> and can
        be set as follows:
      </p><pre class="programlisting">SET @<em class="replaceable"><code>var_name</code></em> = <em class="replaceable"><code>expr</code></em>;
</pre><p>
        Many system variables are dynamic and can be changed while the
        server runs by using the <code class="literal">SET</code> statement. For a
        list, see <a href="http://dev.mysql.com/doc/refman/5.0/en/dynamic-system-variables.html" target="_top">Dynamic System Variables</a>. To change
        a system variable with <code class="literal">SET</code>, refer to it as
        <em class="replaceable"><code>var_name</code></em>, optionally preceded by a
        modifier:
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            To indicate explicitly that a variable is a global variable,
            precede its name by <code class="literal">GLOBAL</code> or
            <code class="literal">@@global.</code>. The <code class="literal">SUPER</code>
            privilege is required to set global variables.
          </p></li><li><p>
            To indicate explicitly that a variable is a session
            variable, precede its name by <code class="literal">SESSION</code>,
            <code class="literal">@@session.</code>, or <code class="literal">@@</code>.
            Setting a session variable requires no special privilege,
            but a client can change only its own session variables, not
            those of any other client.
          </p></li><li><p>
            <code class="literal">LOCAL</code> and <code class="literal">@@local.</code> are
            synonyms for <code class="literal">SESSION</code> and
            <code class="literal">@@session.</code>.
          </p></li><li><p>
            If no modifier is present, <code class="literal">SET</code> changes
            the session variable.
          </p></li></ul></div><p>
        A <code class="literal">SET</code> statement can contain multiple variable
        assignments, separated by commas. If you set several system
        variables, the most recent <code class="literal">GLOBAL</code> or
        <code class="literal">SESSION</code> modifier in the statement is used for
        following variables that have no modifier specified.
      </p><p>
        Examples:
      </p><pre class="programlisting">SET sort_buffer_size=10000;
SET @@local.sort_buffer_size=10000;
SET GLOBAL sort_buffer_size=1000000, SESSION sort_buffer_size=1000000;
SET @@sort_buffer_size=1000000;
SET @@global.sort_buffer_size=1000000, @@local.sort_buffer_size=1000000;
</pre><p>
        When you assign a value to a system variable with
        <code class="literal">SET</code>, you cannot use suffix letters in the
        value (as can be done with startup options). However, the value
        can take the form of an expression:
      </p><pre class="programlisting">SET sort_buffer_size = 10 * 1024 * 1024;
</pre><p>
        The <code class="literal">@@<em class="replaceable"><code>var_name</code></em></code>
        syntax for system variables is supported for compatibility with
        some other database systems.
      </p><p>
        If you change a session system variable, the value remains in
        effect until your session ends or until you change the variable
        to a different value. The change is not visible to other
        clients.
      </p><p>
        If you change a global system variable, the value is remembered
        and used for new connections until the server restarts. (To make
        a global system variable setting permanent, you should set it in
        an option file.) The change is visible to any client that
        accesses that global variable. However, the change affects the
        corresponding session variable only for clients that connect
        after the change. The global variable change does not affect the
        session variable for any client that is currently connected (not
        even that of the client that issues the <code class="literal">SET
        GLOBAL</code> statement).
      </p><p>
        To prevent incorrect usage, MySQL produces an error if you use
        <code class="literal">SET GLOBAL</code> with a variable that can only be
        used with <code class="literal">SET SESSION</code> or if you do not
        specify <code class="literal">GLOBAL</code> (or
        <code class="literal">@@global.</code>) when setting a global variable.
      </p><p>
        To set a <code class="literal">SESSION</code> variable to the
        <code class="literal">GLOBAL</code> value or a <code class="literal">GLOBAL</code>
        value to the compiled-in MySQL default value, use the
        <code class="literal">DEFAULT</code> keyword. For example, the following
        two statements are identical in setting the session value of
        <code class="literal">max_join_size</code> to the global value:
      </p><pre class="programlisting">SET max_join_size=DEFAULT;
SET @@session.max_join_size=@@global.max_join_size;
</pre><p>
        Not all system variables can be set to
        <code class="literal">DEFAULT</code>. In such cases, use of
        <code class="literal">DEFAULT</code> results in an error.
      </p><p>
        You can refer to the values of specific global or sesson system
        variables in expressions by using one of the
        <code class="literal">@@</code>-modifiers. For example, you can retrieve
        values in a <code class="literal">SELECT</code> statement like this:
      </p><pre class="programlisting">SELECT @@global.sql_mode, @@session.sql_mode, @@sql_mode;
</pre><p>
        When you refer to a system variable in an expression as
        <code class="literal">@@<em class="replaceable"><code>var_name</code></em></code> (that
        is, when you do not specify <code class="literal">@@global.</code> or
        <code class="literal">@@session.</code>), MySQL returns the session value
        if it exists and the global value otherwise. (This differs from
        <code class="literal">SET @@<em class="replaceable"><code>var_name</code></em> =
        <em class="replaceable"><code>value</code></em></code>, which always refers
        to the session value.)
      </p><p>
        To display system variables names and values, use the
        <code class="literal">SHOW VARIABLES</code> statement. (See
        <a href="mysqlqb_statements.html#show-variables" title="SHOW VARIABLES Syntax"><code class="literal">SHOW VARIABLES</code> Syntax</a>.)
      </p><p>
        The following list describes options that have non-standard
        syntax or that are not described in the list of system variables
        found in <a href="http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html" target="_top">System Variables</a>. Although the
        options described here are not displayed by <code class="literal">SHOW
        VARIABLES</code>, you can obtain their values with
        <code class="literal">SELECT</code> (with the exception of
        <code class="literal">CHARACTER SET</code> and <code class="literal">SET
        NAMES</code>). For example:
      </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SELECT @@AUTOCOMMIT;</code></strong>
+--------------+
| @@AUTOCOMMIT |
+--------------+
|            1 |
+--------------+
</pre><p>
        The lettercase of thse options does not matter.
      </p><div class="itemizedlist"><ul type="disc"><li><p>
            <code class="literal">AUTOCOMMIT = {0 | 1}</code>
          </p><p>
            Set the autocommit mode. If set to 1, all changes to a table
            take effect immediately. If set to 0 you have to use
            <code class="literal">COMMIT</code> to accept a transaction or
            <code class="literal">ROLLBACK</code> to cancel it. By default, client
            connections begin with <code class="literal">AUTOCOMMIT</code> set to
            1. If you change <code class="literal">AUTOCOMMIT</code> mode from 0
            to 1, MySQL performs an automatic <code class="literal">COMMIT</code>
            of any open transaction. Another way to begin a transaction
            is to use a <code class="literal">START TRANSACTION</code> or
            <code class="literal">BEGIN</code> statement. See
            <a href="mysqlqb_statements.html#commit" title="START TRANSACTION, COMMIT, and&#10;        ROLLBACK Syntax"><code class="literal">START TRANSACTION</code>, <code class="literal">COMMIT</code>, and
        <code class="literal">ROLLBACK</code> Syntax</a>.
          </p></li><li><p>
            <code class="literal">BIG_TABLES = {0 | 1}</code>
          </p><p>
            <a id="id2890890" class="indexterm"></a>

            If set to 1, all temporary tables are stored on disk rather
            than in memory. This is a little slower, but the error
            <code class="literal">The table <em class="replaceable"><code>tbl_name</code></em> is
            full</code> does not occur for <code class="literal">SELECT</code>
            operations that require a large temporary table. The default
            value for a new connection is 0 (use in-memory temporary
            tables). Normally, you should never need to set this
            variable, because in-memory tables are automatically
            converted to disk-based tables as required.
            (<span class="bold"><strong>Note</strong></span>: This variable was
            formerly named <code class="literal">SQL_BIG_TABLES</code>.)
          </p></li><li><p>
            <code class="literal">CHARACTER SET
            {<em class="replaceable"><code>charset_name</code></em> |
            DEFAULT}</code>
          </p><p>
            This maps all strings from and to the client with the given
            mapping. You can add new mappings by editing
            <code class="filename">sql/convert.cc</code> in the MySQL source
            distribution. <code class="literal">SET CHARACTER SET</code> sets
            three session system variables:
            <code class="literal">character_set_client</code> and
            <code class="literal">character_set_results</code> are set to the
            given character set, and
            <code class="literal">character_set_connection</code> to the value of
            <code class="literal">character_set_database</code>. See
            <a href="http://dev.mysql.com/doc/refman/5.0/en/charset-connection.html" target="_top">Connection Character Sets and Collations</a>.
          </p><p>
            The default mapping can be restored by using the value
            <code class="literal">DEFAULT</code>. The default depends on the
            server configuration.
          </p><p>
            Note that the syntax for <code class="literal">SET CHARACTER
            SET</code> differs from that for setting most other
            options.
          </p></li><li><p>
            <code class="literal">FOREIGN_KEY_CHECKS = {0 | 1}</code>
          </p><p>
            If set to 1 (the default), foreign key constraints for
            <code class="literal">InnoDB</code> tables are checked. If set to 0,
            they are ignored. Disabling foreign key checking can be
            useful for reloading <code class="literal">InnoDB</code> tables in an
            order different from that required by their parent/child
            relationships. See
            <a href="http://dev.mysql.com/doc/refman/5.0/en/innodb-foreign-key-constraints.html" target="_top"><code class="literal">FOREIGN KEY</code> Constraints</a>.
          </p><p>
            Setting <code class="literal">FOREIGN_KEY_CHECKS</code> to 0 also
            affects data definition statements: <code class="literal">DROP
            DATABASE</code> drops a database even if it contains
            tables that have foreign keys that are referred to by tables
            outside the database, and <code class="literal">DROP TABLE</code>
            drops tables that have foreign keys that are referred to by
            other tables.
          </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>
              Setting <code class="literal">FOREIGN_KEY_CHECKS</code> to 1 does
              not trigger a scan of the existing table data. Therefore,
              rows added to the table while
              <code class="literal">FOREIGN_KEY_CHECKS=0</code> will not be
              verified for consistency.
            </p></div></li><li><p>
            <code class="literal">IDENTITY =
            <em class="replaceable"><code>value</code></em></code>
          </p><p>
            This variable is a synonym for the
            <code class="literal">LAST_INSERT_ID</code> variable. It exists for
            compatibility with other database systems. You can read its
            value with <code class="literal">SELECT @@IDENTITY</code>, and set it
            using <code class="literal">SET IDENTITY</code>.
          </p></li><li><p>
            <code class="literal">INSERT_ID =
            <em class="replaceable"><code>value</code></em></code>
          </p><p>
            Set the value to be used by the following
            <code class="literal">INSERT</code> or <code class="literal">ALTER TABLE</code>
            statement when inserting an
            <code class="literal">AUTO_INCREMENT</code> value. This is mainly used
            with the binary log.
          </p></li><li><p>
            <code class="literal">LAST_INSERT_ID =
            <em class="replaceable"><code>value</code></em></code>
          </p><p>
            Set the value to be returned from
            <code class="literal">LAST_INSERT_ID()</code>. This is stored in the
            binary log when you use <code class="literal">LAST_INSERT_ID()</code>
            in a statement that updates a table. Setting this variable
            does not update the value returned by the
            <code class="literal">mysql_insert_id()</code> C API function.
          </p></li><li><p>
            <code class="literal">NAMES {'<em class="replaceable"><code>charset_name</code></em>'
            [COLLATE '<em class="replaceable"><code>collation_name</code></em>'} |
            DEFAULT}</code>
          </p><p>
            <code class="literal">SET NAMES</code> sets the three session system
            variables <code class="literal">character_set_client</code>,
            <code class="literal">character_set_connection</code>, and
            <code class="literal">character_set_results</code> to the given
            character set. Setting
            <code class="literal">character_set_connection</code> to
            <code class="literal">charset_name</code> also sets
            <code class="literal">collation_connection</code> to the default
            collation for <code class="literal">charset_name</code>. The optional
            <code class="literal">COLLATE</code> clause may be used to specify a
            collation explicitly. See
            <a href="http://dev.mysql.com/doc/refman/5.0/en/charset-connection.html" target="_top">Connection Character Sets and Collations</a>.
          </p><p>
            The default mapping can be restored by using a value of
            <code class="literal">DEFAULT</code>. The default depends on the
            server configuration.
          </p><p>
            Note that the syntax for <code class="literal">SET NAMES</code>
            differs from that for setting most other options.
          </p></li><li><p>
            <code class="literal">ONE_SHOT</code>
          </p><p>
            This option is a modifier, not a variable. It can be used to
            influence the effect of variables that set the character
            set, the collation, and the time zone.
            <code class="literal">ONE_SHOT</code> is primarily used for
            replication purposes: <span><strong class="command">mysqlbinlog</strong></span> uses
            <code class="literal">SET ONE_SHOT</code> to modify temporarily the
            values of character set, collation, and time zone variables
            to reflect at rollforward what they were originally.
            <code class="literal">ONE_SHOT</code> is for internal use only and is
            deprecated for MySQL 5.0 and up.
          </p><p>
            You cannot use <code class="literal">ONE_SHOT</code> with other than
            the allowed set of variables; if you try, you get an error
            like this:
          </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SET ONE_SHOT max_allowed_packet = 1;</code></strong>
ERROR 1382 (HY000): The 'SET ONE_SHOT' syntax is reserved for purposes
internal to the MySQL server
</pre><p>
            If <code class="literal">ONE_SHOT</code> is used with the allowed
            variables, it changes the variables as requested, but only
            for the next non-<code class="literal">SET</code> statement. After
            that, the server resets all character set, collation, and
            time zone-related system variables to their previous values.
            Example:
          </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SET ONE_SHOT character_set_connection = latin5;</code></strong>

mysql&gt; <strong class="userinput"><code>SET ONE_SHOT collation_connection = latin5_turkish_ci;</code></strong>

mysql&gt; <strong class="userinput"><code>SHOW VARIABLES LIKE '%_connection';</code></strong>
+--------------------------+-------------------+
| Variable_name            | Value             |
+--------------------------+-------------------+
| character_set_connection | latin5            |
| collation_connection     | latin5_turkish_ci |
+--------------------------+-------------------+

mysql&gt; <strong class="userinput"><code>SHOW VARIABLES LIKE '%_connection';</code></strong>
+--------------------------+-------------------+
| Variable_name            | Value             |
+--------------------------+-------------------+
| character_set_connection | latin1            |
| collation_connection     | latin1_swedish_ci |
+--------------------------+-------------------+
</pre></li><li><p>
            <code class="literal">PROFILING = {0 | 1}</code>
          </p><p>
            If set to 0 (the default), statement profiling is disabled.
            If set to 1, statement profiling is enabled and the
            <code class="literal">SHOW PROFILES</code> and <code class="literal">SHOW
            PROFILE</code> statements provide access to profiling
            information. See <a href="mysqlqb_statements.html#show-profiles" title="SHOW PROFILES and SHOW PROFILE&#10;          Syntax"><code class="literal">SHOW PROFILES</code> and <code class="literal">SHOW PROFILE</code>
          Syntax</a>. This
            variable was added in MySQL 5.0.37.
          </p></li><li><p>
            <code class="literal">PROFILING_HISTORY_SIZE =
            <em class="replaceable"><code>value</code></em></code>
          </p><p>
            The number of statements for which to maintain profiling
            information if <code class="literal">PROFILING</code> is enabled. The
            default value is 15. The maximum value is 100. Setting the
            value to 0 effectively disables profiling. See
            <a href="mysqlqb_statements.html#show-profiles" title="SHOW PROFILES and SHOW PROFILE&#10;          Syntax"><code class="literal">SHOW PROFILES</code> and <code class="literal">SHOW PROFILE</code>
          Syntax</a>. This variable was added in
            MySQL 5.0.37.
          </p></li><li><p>
            <code class="literal">SQL_AUTO_IS_NULL = {0 | 1}</code>
          </p><p>
            If set to 1 (the default), you can find the last inserted
            row for a table that contains an
            <code class="literal">AUTO_INCREMENT</code> column by using the
            following construct:
          </p><pre class="programlisting">WHERE <em class="replaceable"><code>auto_increment_column</code></em> IS NULL
</pre><p>
            This behavior is used by some ODBC programs, such as Access.
          </p></li><li><p>
            <code class="literal">SQL_BIG_SELECTS = {0 | 1}</code>
          </p><p>
            If set to 0, MySQL aborts <code class="literal">SELECT</code>
            statements that are likely to take a very long time to
            execute (that is, statements for which the optimizer
            estimates that the number of examined rows exceeds the value
            of <code class="literal">max_join_size</code>). This is useful when an
            inadvisable <code class="literal">WHERE</code> statement has been
            issued. The default value for a new connection is 1, which
            allows all <code class="literal">SELECT</code> statements.
          </p><p>
            If you set the <code class="literal">max_join_size</code> system
            variable to a value other than <code class="literal">DEFAULT</code>,
            <code class="literal">SQL_BIG_SELECTS</code> is set to 0.
          </p></li><li><p>
            <code class="literal">SQL_BUFFER_RESULT = {0 | 1}</code>
          </p><p>
            If set to 1, <code class="literal">SQL_BUFFER_RESULT</code> forces
            results from <code class="literal">SELECT</code> statements to be put
            into temporary tables. This helps MySQL free the table locks
            early and can be beneficial in cases where it takes a long
            time to send results to the client. The default value is 0.
          </p></li><li><p>
            <code class="literal">SQL_LOG_BIN = {0 | 1}</code>
          </p><p>
            If set to 0, no logging is done to the binary log for the
            client. The client must have the <code class="literal">SUPER</code>
            privilege to set this option. The default value is 1.
          </p></li><li><p>
            <code class="literal">SQL_LOG_OFF = {0 | 1}</code>
          </p><p>
            If set to 1, no logging is done to the general query log for
            this client. The client must have the
            <code class="literal">SUPER</code> privilege to set this option. The
            default value is 0.
          </p></li><li><p>
            <code class="literal">SQL_LOG_UPDATE = {0 | 1}</code>
          </p><p>
            This variable is deprecated, and is mapped to
            <code class="literal">SQL_LOG_BIN</code>.
          </p></li><li><p>
            <code class="literal">SQL_NOTES = {0 | 1}</code>
          </p><p>
            If set to 1 (the default), warnings of
            <code class="literal">Note</code> level are recorded. If set to 0,
            <code class="literal">Note</code> warnings are suppressed.
            <span><strong class="command">mysqldump</strong></span> includes output to set this
            variable to 0 so that reloading the dump file does not
            produce warnings for events that do not affect the integrity
            of the reload operation. <code class="literal">SQL_NOTES</code> was
            added in MySQL 5.0.3.
          </p></li><li><p>
            <code class="literal">SQL_QUOTE_SHOW_CREATE = {0 | 1}</code>
          </p><p>
            If set to 1 (the default), the server quotes identifiers for
            <code class="literal">SHOW CREATE TABLE</code> and <code class="literal">SHOW
            CREATE DATABASE</code> statements. If set to 0, quoting
            is disabled. This option is enabled by default so that
            replication works for identifiers that require quoting. See
            <a href="mysqlqb_statements.html#show-create-table" title="SHOW CREATE TABLE Syntax"><code class="literal">SHOW CREATE TABLE</code> Syntax</a>, and
            <a href="mysqlqb_statements.html#show-create-database" title="SHOW CREATE DATABASE Syntax"><code class="literal">SHOW CREATE DATABASE</code> Syntax</a>.
          </p></li><li><p>
            <code class="literal">SQL_SAFE_UPDATES = {0 | 1}</code>
          </p><p>
            If set to 1, MySQL aborts <code class="literal">UPDATE</code> or
            <code class="literal">DELETE</code> statements that do not use a key
            in the <code class="literal">WHERE</code> clause or a
            <code class="literal">LIMIT</code> clause. This makes it possible to
            catch <code class="literal">UPDATE</code> or <code class="literal">DELETE</code>
            statements where keys are not used properly and that would
            probably change or delete a large number of rows. The
            default value is 0.
          </p></li><li><p>
            <code class="literal">SQL_SELECT_LIMIT =
            {<em class="replaceable"><code>value</code></em> | DEFAULT}</code>
          </p><p>
            The maximum number of rows to return from
            <code class="literal">SELECT</code> statements. The default value for
            a new connection is “<span class="quote">unlimited.</span>” If you have
            changed the limit, the default value can be restored by
            using a <code class="literal">SQL_SELECT_LIMIT</code> value of
            <code class="literal">DEFAULT</code>.
          </p><p>
            If a <code class="literal">SELECT</code> has a
            <code class="literal">LIMIT</code> clause, the
            <code class="literal">LIMIT</code> takes precedence over the value of
            <code class="literal">SQL_SELECT_LIMIT</code>.
          </p><p>
            <code class="literal">SQL_SELECT_LIMIT</code> does not apply to
            <code class="literal">SELECT</code> statements executed within stored
            routines. It also does not apply to
            <code class="literal">SELECT</code> statements that do not produce a
            result set to be returned to the client. These include
            <code class="literal">SELECT</code> statements in subqueries,
            <code class="literal">CREATE TABLE ... SELECT</code>, and
            <code class="literal">INSERT INTO ... SELECT</code>.
          </p></li><li><p>
            <code class="literal">SQL_WARNINGS = {0 | 1}</code>
          </p><p>
            This variable controls whether single-row
            <code class="literal">INSERT</code> statements produce an information
            string if warnings occur. The default is 0. Set the value to
            1 to produce an information string.
          </p></li><li><p>
            <code class="literal">TIMESTAMP =
            {<em class="replaceable"><code>timestamp_value</code></em> |
            DEFAULT}</code>
          </p><p>
            Set the time for this client. This is used to get the
            original timestamp if you use the binary log to restore
            rows. <code class="literal">timestamp_value</code> should be a Unix
            epoch timestamp, not a MySQL timestamp.
          </p><p>
            <code class="literal">SET TIMESTAMP</code> affects the value returned
            by <code class="literal">NOW()</code> but not by
            <code class="literal">SYSDATE()</code>. This means that timestamp
            settings in the binary log have no effect on invocations of
            <code class="literal">SYSDATE()</code>. The server can be started with
            the <code class="option">--sysdate-is-now</code> option to cause
            <code class="literal">SYSDATE()</code> to be an alias for
            <code class="literal">NOW()</code>, in which case <code class="literal">SET
            TIMESTAMP</code> affects both functions.
          </p></li><li><p>
            <code class="literal">UNIQUE_CHECKS = {0 | 1}</code>
          </p><p>
            If set to 1 (the default), uniqueness checks for secondary
            indexes in <code class="literal">InnoDB</code> tables are performed.
            If set to 0, storage engines are allowed to assume that
            duplicate keys are not present in input data. If you know
            for certain that your data does not contain uniqueness
            violations, you can set this to 0 to speed up large table
            imports to <code class="literal">InnoDB</code>.
          </p><p>
            Note that setting this variable to 0 does not
            <span class="emphasis"><em>require</em></span> storage engines to ignore
            duplicate keys. An engine is still allowed to check for them
            and issue duplicate-key errors if it detects them.
          </p></li></ul></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="show"></a><code class="literal">SHOW</code> Syntax</h3></div></div></div><div class="toc"><dl><dt><span class="section"><a href="mysqlqb_statements.html#show-character-set"><code class="literal">SHOW CHARACTER SET</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#show-collation"><code class="literal">SHOW COLLATION</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#show-columns"><code class="literal">SHOW COLUMNS</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#show-create-database"><code class="literal">SHOW CREATE DATABASE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#show-create-procedure"><code class="literal">SHOW CREATE PROCEDURE</code> and <code class="literal">SHOW CREATE
          FUNCTION</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#show-create-table"><code class="literal">SHOW CREATE TABLE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#show-create-view"><code class="literal">SHOW CREATE VIEW</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#show-databases"><code class="literal">SHOW DATABASES</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#show-engine"><code class="literal">SHOW ENGINE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#show-engines"><code class="literal">SHOW ENGINES</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#show-errors"><code class="literal">SHOW ERRORS</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#show-grants"><code class="literal">SHOW GRANTS</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#show-index"><code class="literal">SHOW INDEX</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#show-innodb-status"><code class="literal">SHOW INNODB STATUS</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#show-logs"><code class="literal">SHOW LOGS</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#show-mutex-status"><code class="literal">SHOW MUTEX STATUS</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#show-open-tables"><code class="literal">SHOW OPEN TABLES</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#show-privileges"><code class="literal">SHOW PRIVILEGES</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#show-procedure-code"><code class="literal">SHOW PROCEDURE CODE</code> and <code class="literal">SHOW FUNCTION
          CODE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#show-procedure-status"><code class="literal">SHOW PROCEDURE STATUS</code> and <code class="literal">SHOW FUNCTION
          STATUS</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#show-processlist"><code class="literal">SHOW PROCESSLIST</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#show-profiles"><code class="literal">SHOW PROFILES</code> and <code class="literal">SHOW PROFILE</code>
          Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#show-status"><code class="literal">SHOW STATUS</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#show-table-status"><code class="literal">SHOW TABLE STATUS</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#show-tables"><code class="literal">SHOW TABLES</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#show-triggers"><code class="literal">SHOW TRIGGERS</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#show-variables"><code class="literal">SHOW VARIABLES</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#show-warnings"><code class="literal">SHOW WARNINGS</code> Syntax</a></span></dt></dl></div><a id="id2891940" class="indexterm"></a><a id="id2891954" class="indexterm"></a><a id="id2891965" class="indexterm"></a><a id="id2891971" class="indexterm"></a><a id="id2891978" class="indexterm"></a><a id="id2891985" class="indexterm"></a><a id="id2891992" class="indexterm"></a><a id="id2891999" class="indexterm"></a><a id="id2892006" class="indexterm"></a><a id="id2892013" class="indexterm"></a><a id="id2892019" class="indexterm"></a><a id="id2892026" class="indexterm"></a><a id="id2892033" class="indexterm"></a><a id="id2892040" class="indexterm"></a><a id="id2892046" class="indexterm"></a><a id="id2892053" class="indexterm"></a><a id="id2892060" class="indexterm"></a><a id="id2892067" class="indexterm"></a><a id="id2892073" class="indexterm"></a><a id="id2892080" class="indexterm"></a><a id="id2892087" class="indexterm"></a><a id="id2892094" class="indexterm"></a><a id="id2892100" class="indexterm"></a><a id="id2892107" class="indexterm"></a><a id="id2892114" class="indexterm"></a><a id="id2892121" class="indexterm"></a><a id="id2892128" class="indexterm"></a><a id="id2892134" class="indexterm"></a><a id="id2892141" class="indexterm"></a><a id="id2892148" class="indexterm"></a><a id="id2892155" class="indexterm"></a><a id="id2892161" class="indexterm"></a><a id="id2892168" class="indexterm"></a><a id="id2892175" class="indexterm"></a><a id="id2892182" class="indexterm"></a><a id="id2892189" class="indexterm"></a><p>
        <code class="literal">SHOW</code> has many forms that provide information
        about databases, tables, columns, or status information about
        the server. This section describes those following:
      </p><pre class="programlisting">SHOW [FULL] COLUMNS FROM <em class="replaceable"><code>tbl_name</code></em> [FROM <em class="replaceable"><code>db_name</code></em>] [LIKE '<em class="replaceable"><code>pattern</code></em>']
SHOW CREATE DATABASE <em class="replaceable"><code>db_name</code></em>
SHOW CREATE FUNCTION <em class="replaceable"><code>funcname</code></em>
SHOW CREATE PROCEDURE <em class="replaceable"><code>procname</code></em>
SHOW CREATE TABLE <em class="replaceable"><code>tbl_name</code></em>
SHOW DATABASES [LIKE '<em class="replaceable"><code>pattern</code></em>']
SHOW ENGINE <em class="replaceable"><code>engine_name</code></em> {LOGS | STATUS }
SHOW [STORAGE] ENGINES
SHOW ERRORS [LIMIT [<em class="replaceable"><code>offset</code></em>,] <em class="replaceable"><code>row_count</code></em>]
SHOW FUNCTION CODE <em class="replaceable"><code>sp_name</code></em>
SHOW FUNCTION STATUS [LIKE '<em class="replaceable"><code>pattern</code></em>']
SHOW GRANTS FOR <em class="replaceable"><code>user</code></em>
SHOW INDEX FROM <em class="replaceable"><code>tbl_name</code></em> [FROM <em class="replaceable"><code>db_name</code></em>]
SHOW INNODB STATUS
SHOW PROCEDURE CODE <em class="replaceable"><code>sp_name</code></em>
SHOW PROCEDURE STATUS [LIKE '<em class="replaceable"><code>pattern</code></em>']
SHOW [BDB] LOGS
SHOW MUTEX STATUS
SHOW PRIVILEGES
SHOW [FULL] PROCESSLIST
SHOW PROFILE [<em class="replaceable"><code>types</code></em>] [FOR QUERY <em class="replaceable"><code>n</code></em>] [OFFSET <em class="replaceable"><code>n</code></em>] [LIMIT <em class="replaceable"><code>n</code></em>]
SHOW PROFILES
SHOW [GLOBAL | SESSION] STATUS [LIKE '<em class="replaceable"><code>pattern</code></em>']
SHOW TABLE STATUS [FROM <em class="replaceable"><code>db_name</code></em>] [LIKE '<em class="replaceable"><code>pattern</code></em>']
SHOW [OPEN] TABLES [FROM <em class="replaceable"><code>db_name</code></em>] [LIKE '<em class="replaceable"><code>pattern</code></em>']
SHOW TRIGGERS
SHOW [GLOBAL | SESSION] VARIABLES [LIKE '<em class="replaceable"><code>pattern</code></em>']
SHOW WARNINGS [LIMIT [<em class="replaceable"><code>offset</code></em>,] <em class="replaceable"><code>row_count</code></em>]
</pre><a id="id2892355" class="indexterm"></a><a id="id2892362" class="indexterm"></a><a id="id2892369" class="indexterm"></a><a id="id2892376" class="indexterm"></a><a id="id2892382" class="indexterm"></a><p>
        The <code class="literal">SHOW</code> statement also has forms that
        provide information about replication master and slave servers
        and are described in <a href="mysqlqb_statements.html#replication-sql" title="Replication Statements">Replication Statements</a>:
      </p><pre class="programlisting">SHOW BINARY LOGS
SHOW BINLOG EVENTS
SHOW MASTER STATUS
SHOW SLAVE HOSTS
SHOW SLAVE STATUS
</pre><p>
        If the syntax for a given <code class="literal">SHOW</code> statement
        includes a <code class="literal">LIKE
        '<em class="replaceable"><code>pattern</code></em>'</code> part,
        <code class="literal">'<em class="replaceable"><code>pattern</code></em>'</code> is a
        string that can contain the SQL
        ‘<code class="literal">%</code>’ and
        ‘<code class="literal">_</code>’ wildcard characters. The
        pattern is useful for restricting statement output to matching
        values.
      </p><p>
        Several <code class="literal">SHOW</code> statements also accept a
        <code class="literal">WHERE</code> clause that provides more flexibility
        in specifying which rows to display. See
        <a href="http://dev.mysql.com/doc/refman/5.0/en/extended-show.html" target="_top">Extensions to <code class="literal">SHOW</code> Statements</a>.
      </p><p>
        Many MySQL APIs (such as PHP) allow you to treat the result
        returned from a <code class="literal">SHOW</code> statement as you would a
        result set from a <code class="literal">SELECT</code>; see
        <a href="http://dev.mysql.com/doc/refman/5.0/en/apis.html" target="_top">APIs and Libraries</a>, or your API documentation for more
        information. In addition, you can work in SQL with results from
        queries on tables in the <code class="literal">INFORMATION_SCHEMA</code>
        database, which you cannot easily do with results from
        <code class="literal">SHOW</code> statements. See
        <a href="http://dev.mysql.com/doc/refman/5.0/en/information-schema.html" target="_top">The <code class="literal">INFORMATION_SCHEMA</code> Database</a>.
      </p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="show-character-set"></a><code class="literal">SHOW CHARACTER SET</code> Syntax</h4></div></div></div><a id="id2892522" class="indexterm"></a><pre class="programlisting">SHOW CHARACTER SET [LIKE '<em class="replaceable"><code>pattern</code></em>']
</pre><p>
          The <code class="literal">SHOW CHARACTER SET</code> statement shows all
          available character sets. It takes an optional
          <code class="literal">LIKE</code> clause that indicates which character
          set names to match. For example:
        </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SHOW CHARACTER SET LIKE 'latin%';</code></strong>
+---------+-----------------------------+-------------------+--------+
| Charset | Description                 | Default collation | Maxlen |
+---------+-----------------------------+-------------------+--------+
| latin1  | cp1252 West European        | latin1_swedish_ci |      1 |
| latin2  | ISO 8859-2 Central European | latin2_general_ci |      1 |
| latin5  | ISO 8859-9 Turkish          | latin5_turkish_ci |      1 |
| latin7  | ISO 8859-13 Baltic          | latin7_general_ci |      1 |
+---------+-----------------------------+-------------------+--------+
</pre><p>
          The <code class="literal">Maxlen</code> column shows the maximum number
          of bytes required to store one character.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="show-collation"></a><code class="literal">SHOW COLLATION</code> Syntax</h4></div></div></div><a id="id2892615" class="indexterm"></a><pre class="programlisting">SHOW COLLATION [LIKE '<em class="replaceable"><code>pattern</code></em>']
</pre><p>
          The output from <code class="literal">SHOW COLLATION</code> includes all
          available character sets. It takes an optional
          <code class="literal">LIKE</code> clause whose
          <em class="replaceable"><code>pattern</code></em> indicates which collation
          names to match. For example:
        </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SHOW COLLATION LIKE 'latin1%';</code></strong>
+-------------------+---------+----+---------+----------+---------+
| Collation         | Charset | Id | Default | Compiled | Sortlen |
+-------------------+---------+----+---------+----------+---------+
| latin1_german1_ci | latin1  |  5 |         |          |       0 |
| latin1_swedish_ci | latin1  |  8 | Yes     | Yes      |       0 |
| latin1_danish_ci  | latin1  | 15 |         |          |       0 |
| latin1_german2_ci | latin1  | 31 |         | Yes      |       2 |
| latin1_bin        | latin1  | 47 |         | Yes      |       0 |
| latin1_general_ci | latin1  | 48 |         |          |       0 |
| latin1_general_cs | latin1  | 49 |         |          |       0 |
| latin1_spanish_ci | latin1  | 94 |         |          |       0 |
+-------------------+---------+----+---------+----------+---------+
</pre><p>
          The <code class="literal">Default</code> column indicates whether a
          collation is the default for its character set.
          <code class="literal">Compiled</code> indicates whether the character
          set is compiled into the server. <code class="literal">Sortlen</code> is
          related to the amount of memory required to sort strings
          expressed in the character set.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="show-columns"></a><code class="literal">SHOW COLUMNS</code> Syntax</h4></div></div></div><a id="id2892732" class="indexterm"></a><a id="id2892747" class="indexterm"></a><pre class="programlisting">SHOW [FULL] COLUMNS FROM <em class="replaceable"><code>tbl_name</code></em> [FROM <em class="replaceable"><code>db_name</code></em>] [LIKE '<em class="replaceable"><code>pattern</code></em>']
</pre><p>
          <code class="literal">SHOW COLUMNS</code> displays information about the
          columns in a given table. It also works for views as of MySQL
          5.0.1.
        </p><p>
          If the data types differ from what you expect them to be based
          on your <code class="literal">CREATE TABLE</code> statement, note that
          MySQL sometimes changes data types when you create or alter a
          table. The conditions for which this occurs are described in
          <a href="mysqlqb_statements.html#silent-column-changes" title="Silent Column Specification Changes">Silent Column Specification Changes</a>.
        </p><p>
          The <code class="literal">FULL</code> keyword causes the output to
          include the privileges you have as well as any per-column
          comments for each column.
        </p><p>
          You can use <em class="replaceable"><code>db_name.tbl_name</code></em> as an
          alternative to the
          <code class="literal"><em class="replaceable"><code>tbl_name</code></em> FROM
          <em class="replaceable"><code>db_name</code></em></code> syntax. In other
          words, these two statements are equivalent:
        </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SHOW COLUMNS FROM mytable FROM mydb;</code></strong>
mysql&gt; <strong class="userinput"><code>SHOW COLUMNS FROM mydb.mytable;</code></strong>
</pre><p>
          <code class="literal">SHOW FIELDS</code> is a synonym for <code class="literal">SHOW
          COLUMNS</code>. You can also list a table's columns with
          the <span><strong class="command">mysqlshow <em class="replaceable"><code>db_name</code></em>
          <em class="replaceable"><code>tbl_name</code></em></strong></span> command.
        </p><p>
          The <code class="literal">DESCRIBE</code> statement provides information
          similar to <code class="literal">SHOW COLUMNS</code>. See
          <a href="mysqlqb_statements.html#describe" title="DESCRIBE Syntax"><code class="literal">DESCRIBE</code> Syntax</a>.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="show-create-database"></a><code class="literal">SHOW CREATE DATABASE</code> Syntax</h4></div></div></div><a id="id2892910" class="indexterm"></a><a id="id2892917" class="indexterm"></a><pre class="programlisting">SHOW CREATE {DATABASE | SCHEMA} <em class="replaceable"><code>db_name</code></em>
</pre><p>
          Shows the <code class="literal">CREATE DATABASE</code> statement that
          creates the given database. <code class="literal">SHOW CREATE
          SCHEMA</code> is a synonym for <code class="literal">SHOW CREATE
          DATABASE</code> as of MySQL 5.0.2.
        </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SHOW CREATE DATABASE test\G</code></strong>
*************************** 1. row ***************************
       Database: test
Create Database: CREATE DATABASE `test`
                 /*!40100 DEFAULT CHARACTER SET latin1 */

mysql&gt; <strong class="userinput"><code>SHOW CREATE SCHEMA test\G</code></strong>
*************************** 1. row ***************************
       Database: test
Create Database: CREATE DATABASE `test`
                 /*!40100 DEFAULT CHARACTER SET latin1 */
</pre><p>
          <code class="literal">SHOW CREATE DATABASE</code> quotes table and
          column names according to the value of the
          <code class="literal">SQL_QUOTE_SHOW_CREATE</code> option. See
          <a href="mysqlqb_statements.html#set-option" title="SET Syntax"><code class="literal">SET</code> Syntax</a>.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="show-create-procedure"></a><code class="literal">SHOW CREATE PROCEDURE</code> and <code class="literal">SHOW CREATE
          FUNCTION</code> Syntax</h4></div></div></div><a id="id2893039" class="indexterm"></a><a id="id2893046" class="indexterm"></a><pre class="programlisting">SHOW CREATE {PROCEDURE | FUNCTION} <em class="replaceable"><code>sp_name</code></em>
</pre><p>
          These statements are MySQL extensions. Similar to
          <code class="literal">SHOW CREATE TABLE</code>, they return the exact
          string that can be used to re-create the named routine. The
          statements require that you be the owner of the routine or
          have <code class="literal">SELECT</code> access to the
          <code class="literal">mysql.proc</code> table.
        </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SHOW CREATE FUNCTION test.hello\G</code></strong>
*************************** 1. row ***************************
       Function: hello
       sql_mode:
Create Function: CREATE FUNCTION `test`.`hello`(s CHAR(20)) RETURNS CHAR(50)
                 RETURN CONCAT('Hello, ',s,'!')
</pre></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="show-create-table"></a><code class="literal">SHOW CREATE TABLE</code> Syntax</h4></div></div></div><a id="id2893134" class="indexterm"></a><pre class="programlisting">SHOW CREATE TABLE <em class="replaceable"><code>tbl_name</code></em>
</pre><p>
          Shows the <code class="literal">CREATE TABLE</code> statement that
          creates the given table. As of MySQL 5.0.1, this statement
          also works with views.
        </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SHOW CREATE TABLE t\G</code></strong>
*************************** 1. row ***************************
       Table: t
Create Table: CREATE TABLE t (
  id INT(11) default NULL auto_increment,
  s char(60) default NULL,
  PRIMARY KEY (id)
) ENGINE=MyISAM

</pre><p>
          <code class="literal">SHOW CREATE TABLE</code> quotes table and column
          names according to the value of the
          <code class="literal">SQL_QUOTE_SHOW_CREATE</code> option. See
          <a href="mysqlqb_statements.html#set-option" title="SET Syntax"><code class="literal">SET</code> Syntax</a>.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="show-create-view"></a><code class="literal">SHOW CREATE VIEW</code> Syntax</h4></div></div></div><a id="id2893243" class="indexterm"></a><pre class="programlisting">SHOW CREATE VIEW <em class="replaceable"><code>view_name</code></em>
</pre><p>
          This statement shows a <code class="literal">CREATE VIEW</code>
          statement that creates the given view.
        </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SHOW CREATE VIEW v;</code></strong>
+------+----------------------------------------------------+
| View | Create View                                        |
+------+----------------------------------------------------+
| v    | CREATE VIEW `test`.`v` AS select 1 AS `a`,2 AS `b` |
+------+----------------------------------------------------+
</pre><p>
          This statement was added in MySQL 5.0.1.
        </p><p>
          Prior to MySQL 5.0.11, the output columns from this statement
          were shown as <code class="literal">Table</code> and <code class="literal">Create
          Table</code>.
        </p><p>
          Use of <code class="literal">SHOW CREATE VIEW</code> requires the
          <code class="literal">SHOW VIEW</code> privilege and the
          <code class="literal">SELECT</code> privilege for the view in question.
        </p><p>
          You can also obtain information about view objects from
          <code class="literal">INFORMATION_SCHEMA</code>, which contains a
          <code class="literal">VIEWS</code> table. See
          <a href="http://dev.mysql.com/doc/refman/5.0/en/views-table.html" target="_top">The <code class="literal">INFORMATION_SCHEMA VIEWS</code> Table</a>.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="show-databases"></a><code class="literal">SHOW DATABASES</code> Syntax</h4></div></div></div><a id="id2893367" class="indexterm"></a><a id="id2893374" class="indexterm"></a><pre class="programlisting">SHOW {DATABASES | SCHEMAS} [LIKE '<em class="replaceable"><code>pattern</code></em>']
</pre><p>
          <code class="literal">SHOW DATABASES</code> lists the databases on the
          MySQL server host. <code class="literal">SHOW SCHEMAS</code> is a
          synonym for <code class="literal">SHOW DATABASES</code> as of MySQL
          5.0.2.
        </p><p>
          You see only those databases for which you have some kind of
          privilege, unless you have the global <code class="literal">SHOW
          DATABASES</code> privilege. You can also get this list
          using the <span><strong class="command">mysqlshow</strong></span> command.
        </p><p>
          If the server was started with the
          <code class="option">--skip-show-database</code> option, you cannot use
          this statement at all unless you have the <code class="literal">SHOW
          DATABASES</code> privilege.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="show-engine"></a><code class="literal">SHOW ENGINE</code> Syntax</h4></div></div></div><a id="id2893470" class="indexterm"></a><a id="id2893477" class="indexterm"></a><a id="id2893484" class="indexterm"></a><a id="id2893491" class="indexterm"></a><pre class="programlisting">SHOW ENGINE <em class="replaceable"><code>engine_name</code></em> {LOGS | STATUS }
</pre><p>
          <code class="literal">SHOW ENGINE</code> displays log or status
          information about a storage engine. The following statements
          currently are supported:
        </p><pre class="programlisting">SHOW ENGINE BDB LOGS
SHOW ENGINE INNODB STATUS
SHOW ENGINE NDB STATUS
SHOW ENGINE NDBCLUSTER STATUS
</pre><p>
          <code class="literal">SHOW ENGINE BDB LOGS</code> displays status
          information about existing <code class="literal">BDB</code> log files.
          It returns the following fields:
        </p><div class="itemizedlist"><ul type="disc"><li><p>
              <code class="literal">File</code>
            </p><p>
              The full path to the log file.
            </p></li><li><p>
              <code class="literal">Type</code>
            </p><p>
              The log file type (<code class="literal">BDB</code> for Berkeley DB
              log files).
            </p></li><li><p>
              <code class="literal">Status</code>
            </p><p>
              The status of the log file (<code class="literal">FREE</code> if the
              file can be removed, or <code class="literal">IN USE</code> if the
              file is needed by the transaction subsystem)
            </p></li></ul></div><p>
          <code class="literal">SHOW ENGINE INNODB STATUS</code> displays
          extensive information about the state of the
          <code class="literal">InnoDB</code> storage engine.
        </p><p>
          The <code class="literal">InnoDB</code> Monitors provide additional
          information about <code class="literal">InnoDB</code> processing. See
          <a href="http://dev.mysql.com/doc/refman/5.0/en/innodb-monitor.html" target="_top"><code class="literal">SHOW ENGINE INNODB STATUS</code> and the  <code class="literal">InnoDB</code> Monitors</a>.
        </p><p>
          Older (and now deprecated) synonyms for <code class="literal">SHOW ENGINE
          BDB LOGS</code> and <code class="literal">SHOW ENGINE INNODB
          STATUS</code> are <code class="literal">SHOW [BDB] LOGS</code> and
          <code class="literal">SHOW INNODB STATUS</code>, respectively.
        </p><p>
          If the server has the <code class="literal">NDBCLUSTER</code> storage
          engine enabled, <code class="literal">SHOW ENGINE NDB STATUS</code> can
          be used to display cluster status information. Sample output
          from this statement is shown here:
        </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SHOW ENGINE NDB STATUS;</code></strong>
+-----------------------+---------+------+--------+
| free_list             | created | free | sizeof |
+-----------------------+---------+------+--------+
| NdbTransaction        |       5 |    0 |    208 |
| NdbOperation          |       4 |    4 |    660 |
| NdbIndexScanOperation |       1 |    1 |    736 |
| NdbIndexOperation     |       0 |    0 |   1060 |
| NdbRecAttr            |     645 |  645 |     72 |
| NdbApiSignal          |      16 |   16 |    136 |
| NdbLabel              |       0 |    0 |    196 |
| NdbBranch             |       0 |    0 |     24 |
| NdbSubroutine         |       0 |    0 |     68 |
| NdbCall               |       0 |    0 |     16 |
| NdbBlob               |       2 |    2 |    204 |
| NdbReceiver           |       2 |    0 |     68 |
+-----------------------+---------+------+--------+
12 rows in set (0.00 sec)
</pre><p>
          The most useful of the rows from the output of this statement
          are described in the following list:
        </p><div class="itemizedlist"><ul type="disc"><li><p>
              <code class="literal">NdbTransaction</code>: The number and size of
              <code class="literal">NdbTransaction</code> objects that have been
              created. An <code class="literal">NdbTransaction</code> is created
              each time a table schema operation (such as
              <code class="literal">CREATE TABLE</code> or <code class="literal">ALTER
              TABLE</code>) is performed on an <code class="literal">NDB</code>
              table.
            </p></li><li><p>
              <code class="literal">NdbOperation</code>: The number and size of
              <code class="literal">NdbOperation</code> objects that have been
              created.
            </p></li><li><p>
              <code class="literal">NdbIndexScanOperation</code>: The number and
              size of <code class="literal">NdbIndexScanOperation</code> objects
              that have been created.
            </p></li><li><p>
              <code class="literal">NdbIndexOperation</code>: The number and size
              of <code class="literal">NdbIndexOperation</code> objects that have
              been created.
            </p></li><li><p>
              <code class="literal">NdbRecAttr</code>: The number and size of
              <code class="literal">NdbRecAttr</code> objects that have been
              created. In general, one of these is created each time a
              data manipulation statement is performed by an SQL node.
            </p></li><li><p>
              <code class="literal">NdbBlob</code>: The number and size of
              <code class="literal">NdbBlob</code> objects that have been created.
              An <code class="literal">NdbBlob</code> is created for each new
              operation involving a <code class="literal">BLOB</code> column in an
              <code class="literal">NDB</code> table.
            </p></li><li><p>
              <code class="literal">NdbReceiver</code>: The number and size of any
              <code class="literal">NdbReceiver</code> object that have been
              created. The number in the <code class="literal">created</code>
              column is the same as the number of data nodes in the
              cluster to which the MySQL server has connected.
            </p></li></ul></div><p>
          <span class="bold"><strong>Note</strong></span>: <code class="literal">SHOW ENGINE
          NDB STATUS</code> returns an empty result if no operations
          involving <code class="literal">NDB</code> tables have been performed by
          the MySQL client accessing the SQL node on which this
          statement is run.
        </p><p>
          <code class="literal">SHOW ENGINE NDBCLUSTER STATUS</code> is a synonym
          for <code class="literal">SHOW ENGINE NDB STATUS</code>.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="show-engines"></a><code class="literal">SHOW ENGINES</code> Syntax</h4></div></div></div><a id="id2893914" class="indexterm"></a><a id="id2893921" class="indexterm"></a><a id="id2893928" class="indexterm"></a><pre class="programlisting">SHOW [STORAGE] ENGINES
</pre><p>
          <code class="literal">SHOW ENGINES</code> displays status information
          about the server's storage engines. This is particularly
          useful for checking whether a storage engine is supported, or
          to see what the default engine is. <code class="literal">SHOW TABLE
          TYPES</code> is a deprecated synonym.
        </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SHOW ENGINES\G</code></strong>
*************************** 1. row ***************************
 Engine: MyISAM
Support: DEFAULT
Comment: Default engine as of MySQL 3.23 with great performance
*************************** 2. row ***************************
 Engine: MEMORY
Support: YES
Comment: Hash based, stored in memory, useful for temporary tables
*************************** 3. row ***************************
 Engine: HEAP
Support: YES
Comment: Alias for MEMORY
*************************** 4. row ***************************
 Engine: MERGE
Support: YES
Comment: Collection of identical MyISAM tables
*************************** 5. row ***************************
 Engine: MRG_MYISAM
Support: YES
Comment: Alias for MERGE
*************************** 6. row ***************************
 Engine: ISAM
Support: NO
Comment: Obsolete storage engine, now replaced by MyISAM
*************************** 7. row ***************************
 Engine: MRG_ISAM
Support: NO
Comment: Obsolete storage engine, now replaced by MERGE
*************************** 8. row ***************************
 Engine: InnoDB
Support: YES
Comment: Supports transactions, row-level locking, and foreign keys
*************************** 9. row ***************************
 Engine: INNOBASE
Support: YES
Comment: Alias for INNODB
*************************** 10. row ***************************
 Engine: BDB
Support: YES
Comment: Supports transactions and page-level locking
*************************** 11. row ***************************
 Engine: BERKELEYDB
Support: YES
Comment: Alias for BDB
*************************** 12. row ***************************
 Engine: NDBCLUSTER
Support: NO
Comment: Clustered, fault-tolerant, memory-based tables
*************************** 13. row ***************************
 Engine: NDB
Support: NO
Comment: Alias for NDBCLUSTER
*************************** 14. row ***************************
 Engine: EXAMPLE
Support: NO
Comment: Example storage engine
*************************** 15. row ***************************
 Engine: ARCHIVE
Support: YES
Comment: Archive storage engine
*************************** 16. row ***************************
 Engine: CSV
Support: NO
Comment: CSV storage engine
*************************** 17. row ***************************
 Engine: FEDERATED
Support: YES
Comment: Federated MySQL storage engine
*************************** 18. row ***************************
 Engine: BLACKHOLE
Support: YES
Comment: /dev/null storage engine (anything you write to it disappears)
</pre><p>
          The output from <code class="literal">SHOW ENGINES</code> may vary
          according to the MySQL version used and other factors. The
          values shown in the <code class="literal">Support</code> column indicate
          the server's level of support for different features, as shown
          here:
        </p><div class="informaltable"><table border="1"><colgroup><col /><col /></colgroup><tbody><tr><td><span class="bold"><strong>Value</strong></span></td><td><span class="bold"><strong>Meaning</strong></span></td></tr><tr><td><code class="literal">YES</code></td><td>The feature is supported and is active.</td></tr><tr><td><code class="literal">NO</code></td><td>The feature is not supported.</td></tr><tr><td><code class="literal">DISABLED</code></td><td>The feature is supported but has been disabled.</td></tr></tbody></table></div><p>
          A value of <code class="literal">NO</code> means that the server was
          compiled without support for the feature, so it cannot be
          activated at runtime.
        </p><p>
          A value of <code class="literal">DISABLED</code> occurs either because
          the server was started with an option that disables the
          feature, or because not all options required to enable it were
          given. In the latter case, the error log file should contain a
          reason indicating why the option is disabled. See
          <a href="http://dev.mysql.com/doc/refman/5.0/en/error-log.html" target="_top">The Error Log</a>.
        </p><p>
          You might also see <code class="literal">DISABLED</code> for a storage
          engine if the server was compiled to support it, but was
          started with a
          <code class="option">--skip-<em class="replaceable"><code>engine</code></em></code>
          option. For example, <code class="option">--skip-innodb</code> disables
          the <code class="literal">InnoDB</code> engine. For the <code class="literal">NDB
          Cluster</code> storage engine, <code class="literal">DISABLED</code>
          means the server was compiled with support for MySQL Cluster,
          but was not started with the <code class="option">--ndb-cluster</code>
          option.
        </p><p>
          All MySQL servers support <code class="literal">MyISAM</code> tables,
          because <code class="literal">MyISAM</code> is the default storage
          engine.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="show-errors"></a><code class="literal">SHOW ERRORS</code> Syntax</h4></div></div></div><a id="id2894251" class="indexterm"></a><pre class="programlisting">SHOW ERRORS [LIMIT [<em class="replaceable"><code>offset</code></em>,] <em class="replaceable"><code>row_count</code></em>]
SHOW COUNT(*) ERRORS
</pre><p>
          This statement is similar to <code class="literal">SHOW WARNINGS</code>,
          except that instead of displaying errors, warnings, and notes,
          it displays only errors.
        </p><p>
          The <code class="literal">LIMIT</code> clause has the same syntax as for
          the <code class="literal">SELECT</code> statement. See
          <a href="mysqlqb_statements.html#select" title="SELECT Syntax"><code class="literal">SELECT</code> Syntax</a>.
        </p><p>
          The <code class="literal">SHOW COUNT(*) ERRORS</code> statement displays
          the number of errors. You can also retrieve this number from
          the <code class="literal">error_count</code> variable:
        </p><pre class="programlisting">SHOW COUNT(*) ERRORS;
SELECT @@error_count;
</pre><p>
          For more information, see <a href="mysqlqb_statements.html#show-warnings" title="SHOW WARNINGS Syntax"><code class="literal">SHOW WARNINGS</code> Syntax</a>.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="show-grants"></a><code class="literal">SHOW GRANTS</code> Syntax</h4></div></div></div><a id="id2894360" class="indexterm"></a><a id="id2894370" class="indexterm"></a><a id="id2894376" class="indexterm"></a><pre class="programlisting">SHOW GRANTS [FOR <em class="replaceable"><code>user</code></em>]
</pre><p>
          This statement lists the <code class="literal">GRANT</code> statement or
          statements that must be issued to duplicate the privileges
          that are granted to a MySQL user account. The account is named
          using the same format as for the <code class="literal">GRANT</code>
          statement; for example,
          <code class="literal">'jeffrey'@'localhost'</code>. If you specify only
          the username part of the account name, a hostname part of
          <code class="literal">'%'</code> is used. For additional information
          about specifying account names, see <a href="mysqlqb_statements.html#grant" title="GRANT Syntax"><code class="literal">GRANT</code> Syntax</a>.
        </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SHOW GRANTS FOR 'root'@'localhost';</code></strong>
+---------------------------------------------------------------------+
| Grants for root@localhost                                           |
+---------------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' WITH GRANT OPTION |
+---------------------------------------------------------------------+
</pre><p>
          To list the privileges granted to the account that you are
          using to connect to the server, you can use any of the
          following statements:
        </p><pre class="programlisting">SHOW GRANTS;
SHOW GRANTS FOR CURRENT_USER;
SHOW GRANTS FOR CURRENT_USER();
</pre><p>
          As of MySQL 5.0.24, if <code class="literal">SHOW GRANTS FOR
          CURRENT_USER</code> (or any of the equivalent syntaxes) is
          used in <code class="literal">DEFINER</code> context, such as within a
          stored procedure that is defined with <code class="literal">SQL SECURITY
          DEFINER</code>), the grants displayed are those of the
          definer and not the invoker.
        </p><p>
          <code class="literal">SHOW GRANTS</code> displays only the privileges
          granted explicitly to the named account. Other privileges
          might be available to the account, but they are not displayed.
          For example, if an anonymous account exists, the named account
          might be able to use its privileges, but <code class="literal">SHOW
          GRANTS</code> will not display them.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="show-index"></a><code class="literal">SHOW INDEX</code> Syntax</h4></div></div></div><a id="id2894518" class="indexterm"></a><a id="id2894533" class="indexterm"></a><a id="id2894540" class="indexterm"></a><pre class="programlisting">SHOW INDEX FROM <em class="replaceable"><code>tbl_name</code></em> [FROM <em class="replaceable"><code>db_name</code></em>]
</pre><p>
          <code class="literal">SHOW INDEX</code> returns table index information.
          The format resembles that of the
          <code class="literal">SQLStatistics</code> call in ODBC.
        </p><p>
          <code class="literal">SHOW INDEX</code> returns the following fields:
        </p><div class="itemizedlist"><ul type="disc"><li><p>
              <code class="literal">Table</code>
            </p><p>
              The name of the table.
            </p></li><li><p>
              <code class="literal">Non_unique</code>
            </p><p>
              0 if the index cannot contain duplicates, 1 if it can.
            </p></li><li><p>
              <code class="literal">Key_name</code>
            </p><p>
              The name of the index.
            </p></li><li><p>
              <code class="literal">Seq_in_index</code>
            </p><p>
              The column sequence number in the index, starting with 1.
            </p></li><li><p>
              <code class="literal">Column_name</code>
            </p><p>
              The column name.
            </p></li><li><p>
              <a id="id2894681" class="indexterm"></a>

              <code class="literal">Collation</code>
            </p><p>
              How the column is sorted in the index. In MySQL, this can
              have values ‘<code class="literal">A</code>’ (Ascending)
              or <code class="literal">NULL</code> (Not sorted).
            </p></li><li><p>
              <a id="id2894719" class="indexterm"></a>

              <code class="literal">Cardinality</code>
            </p><p>
              An estimate of the number of unique values in the index.
              This is updated by running <code class="literal">ANALYZE
              TABLE</code> or <span><strong class="command">myisamchk -a</strong></span>.
              <code class="literal">Cardinality</code> is counted based on
              statistics stored as integers, so the value is not
              necessarily exact even for small tables. The higher the
              cardinality, the greater the chance that MySQL uses the
              index when doing joins.
            </p></li><li><p>
              <code class="literal">Sub_part</code>
            </p><p>
              The number of indexed characters if the column is only
              partly indexed, <code class="literal">NULL</code> if the entire
              column is indexed.
            </p></li><li><p>
              <code class="literal">Packed</code>
            </p><p>
              Indicates how the key is packed. <code class="literal">NULL</code>
              if it is not.
            </p></li><li><p>
              <code class="literal">Null</code>
            </p><p>
              Contains <code class="literal">YES</code> if the column may contain
              <code class="literal">NULL</code>. If not, the column contains
              <code class="literal">NO</code> as of MySQL 5.0.3, and
              <code class="literal">''</code> before that.
            </p></li><li><p>
              <code class="literal">Index_type</code>
            </p><p>
              The index method used (<code class="literal">BTREE</code>,
              <code class="literal">FULLTEXT</code>, <code class="literal">HASH</code>,
              <code class="literal">RTREE</code>).
            </p></li><li><p>
              <code class="literal">Comment</code>
            </p><p>
              Various remarks.
            </p></li></ul></div><p>
          You can use
          <em class="replaceable"><code>db_name</code></em>.<em class="replaceable"><code>tbl_name</code></em>
          as an alternative to the
          <code class="literal"><em class="replaceable"><code>tbl_name</code></em> FROM
          <em class="replaceable"><code>db_name</code></em></code> syntax. These two
          statements are equivalent:
        </p><pre class="programlisting">SHOW INDEX FROM mytable FROM mydb;
SHOW INDEX FROM mydb.mytable;
</pre><p>
          <code class="literal">SHOW KEYS</code> is a synonym for <code class="literal">SHOW
          INDEX</code>. You can also list a table's indexes with the
          <span><strong class="command">mysqlshow -k <em class="replaceable"><code>db_name</code></em>
          <em class="replaceable"><code>tbl_name</code></em></strong></span> command.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="show-innodb-status"></a><code class="literal">SHOW INNODB STATUS</code> Syntax</h4></div></div></div><pre class="programlisting">SHOW INNODB STATUS
</pre><p>
          In MySQL 5.0, this is a deprecated synonym for
          <code class="literal">SHOW ENGINE INNODB STATUS</code>. See
          <a href="mysqlqb_statements.html#show-engine" title="SHOW ENGINE Syntax"><code class="literal">SHOW ENGINE</code> Syntax</a>.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="show-logs"></a><code class="literal">SHOW LOGS</code> Syntax</h4></div></div></div><pre class="programlisting">SHOW [BDB] LOGS
</pre><p>
          In MySQL 5.0, this is a deprecated synonym for
          <code class="literal">SHOW ENGINE BDB LOGS</code>. See
          <a href="mysqlqb_statements.html#show-engine" title="SHOW ENGINE Syntax"><code class="literal">SHOW ENGINE</code> Syntax</a>.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="show-mutex-status"></a><code class="literal">SHOW MUTEX STATUS</code> Syntax</h4></div></div></div><pre class="programlisting">SHOW MUTEX STATUS
</pre><p>
          <code class="literal">SHOW MUTEX STATUS</code> displays
          <code class="literal">InnoDB</code> mutex statistics. The output fields
          are:
        </p><div class="itemizedlist"><ul type="disc"><li><p>
              <code class="literal">Mutex</code>
            </p><p>
              The mutex name. The name indicates the mutex purpose. For
              example, the <code class="literal">log_sys</code> mutex is used by
              the <code class="literal">InnoDB</code> logging subsystem and
              indicates how intensive logging activity is. The
              <code class="literal">buf_pool</code> mutex protects the
              <code class="literal">InnoDB</code> buffer pool.
            </p></li><li><p>
              <code class="literal">Module</code>
            </p><p>
              The source file where the mutex is implemented.
            </p></li><li><p>
              <code class="literal">Count</code> indicates how many times the
              mutex was requested.
            </p></li><li><p>
              <code class="literal">Spin_waits</code> indicates how many times the
              spinlock had to run.
            </p></li><li><p>
              <code class="literal">Spin_rounds</code> indicates the number of
              spinlock rounds. (<code class="literal">spin_rounds</code> divided
              by <code class="literal">spin_waits</code> provides the average
              round count.)
            </p></li><li><p>
              <code class="literal">OS_waits</code> indicates the number of
              operating system waits. This occurs when the spinlock did
              not work (the mutex was not locked during the spinlock and
              it was necessary to yield to the operating system and
              wait).
            </p></li><li><p>
              <code class="literal">OS_yields</code> indicates the number of times
              that a thread trying to lock a mutex gave up its timeslice
              and yielded to the operating system (on the presumption
              that allowing other threads to run will free the mutex so
              that it can be locked).
            </p></li><li><p>
              <code class="literal">OS_waits_time</code>
              <code class="literal">os_wait_times</code> indicates the amount of
              time (in ms) spent in operating system waits, if the
              <code class="literal">timed_mutexes</code> system variable is 1
              (<code class="literal">ON</code>). If
              <code class="literal">timed_mutexes</code> is 0
              (<code class="literal">OFF</code>), timing is disabled, so
              <code class="literal">OS_waits_time</code> is 0.
              <code class="literal">timed_mutexes</code> is off by default.
            </p></li></ul></div><p>
          Information from this statement can be used to diagnose system
          problems. For example, large values of
          <code class="literal">spin_waits</code> and
          <code class="literal">spin_rounds</code> may indicate scalability
          problems.
        </p><p>
          <code class="literal">SHOW MUTEX STATUS</code> was added in MySQL 5.0.3.
          In MySQL 5.1, <code class="literal">SHOW MUTEX STATUS</code>
          is renamed to <code class="literal">SHOW ENGINE INNODB MUTEX</code>. The
          latter statement displays similar information but in a
          somewhat different output format.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="show-open-tables"></a><code class="literal">SHOW OPEN TABLES</code> Syntax</h4></div></div></div><a id="id2895298" class="indexterm"></a><a id="id2895313" class="indexterm"></a><pre class="programlisting">SHOW OPEN TABLES [FROM <em class="replaceable"><code>db_name</code></em>] [LIKE '<em class="replaceable"><code>pattern</code></em>']
</pre><p>
          <code class="literal">SHOW OPEN TABLES</code> lists the
          non-<code class="literal">TEMPORARY</code> tables that are currently
          open in the table cache. See <a href="http://dev.mysql.com/doc/refman/5.0/en/table-cache.html" target="_top">How MySQL Opens and Closes Tables</a>.
        </p><p>
          <code class="literal">SHOW OPEN TABLES</code> returns the following
          fields:
        </p><div class="itemizedlist"><ul type="disc"><li><p>
              <code class="literal">Database</code>
            </p><p>
              The database containing the table.
            </p></li><li><p>
              <code class="literal">Table</code>
            </p><p>
              The table name.
            </p></li><li><p>
              <code class="literal">In_use</code>
            </p><p>
              The number of table locks or lock requests there are for
              the table. For example, if one client acquires a lock for
              a table using <code class="literal">LOCK TABLE t1 WRITE</code>,
              <code class="literal">In_use</code> will be 1. If another client
              issues <code class="literal">LOCK TABLE t1 WRITE</code> while the
              table remains locked, the client will block waiting for
              the lock, but the lock request causes
              <code class="literal">In_use</code> to be 2. If the count is zero,
              the table is open but not currently being used.
            </p></li><li><p>
              <code class="literal">Name_locked</code>
            </p><p>
              Whether the table name is locked. Name locking is used for
              operations such as dropping or renaming tables.
            </p></li></ul></div><p>
          The <code class="literal">FROM</code> and <code class="literal">LIKE</code>
          clauses may be used as of MySQL 5.0.12.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="show-privileges"></a><code class="literal">SHOW PRIVILEGES</code> Syntax</h4></div></div></div><a id="id2895491" class="indexterm"></a><pre class="programlisting">SHOW PRIVILEGES
</pre><p>
          <code class="literal">SHOW PRIVILEGES</code> shows the list of system
          privileges that the MySQL server supports. The exact list of
          privileges depends on the version of your server.
        </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SHOW PRIVILEGES\G</code></strong>
*************************** 1. row ***************************
Privilege: Alter
Context: Tables
Comment: To alter the table
*************************** 2. row ***************************
Privilege: Alter routine
Context: Functions,Procedures
Comment: To alter or drop stored functions/procedures
*************************** 3. row ***************************
Privilege: Create
Context: Databases,Tables,Indexes
Comment: To create new databases and tables
*************************** 4. row ***************************
Privilege: Create routine
Context: Functions,Procedures
Comment: To use CREATE FUNCTION/PROCEDURE
*************************** 5. row ***************************
Privilege: Create temporary tables
Context: Databases
Comment: To use CREATE TEMPORARY TABLE
...
</pre></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="show-procedure-code"></a><code class="literal">SHOW PROCEDURE CODE</code> and <code class="literal">SHOW FUNCTION
          CODE</code> Syntax</h4></div></div></div><a id="id2895579" class="indexterm"></a><a id="id2895586" class="indexterm"></a><pre class="programlisting">SHOW {PROCEDURE | FUNCTION} CODE <em class="replaceable"><code>sp_name</code></em>
</pre><p>
          These statements are MySQL extensions that are available only
          for servers that have been built with debugging support. They
          display a representation of the internal implementation of the
          named routine. The statements require that you be the owner of
          the routine or have <code class="literal">SELECT</code> access to the
          <code class="literal">mysql.proc</code> table.
        </p><p>
          If the named routine is available, each statement produces a
          result set. Each row in the result set corresponds to one
          “<span class="quote">instruction</span>” in the routine. The first column is
          <code class="literal">Pos</code>, which is an ordinal number beginning
          with 0. The second column is <code class="literal">Instruction</code>,
          which contains an SQL statement (usually changed from the
          original source), or a directive which has meaning only to the
          stored-routine handler.
        </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>DELIMITER //</code></strong>
mysql&gt; <strong class="userinput"><code>CREATE PROCEDURE p1 ()</code></strong>
    -&gt; <strong class="userinput"><code>BEGIN</code></strong>
    -&gt;   <strong class="userinput"><code>DECLARE fanta INT DEFAULT 55;</code></strong>
    -&gt;   <strong class="userinput"><code>DROP TABLE t2;</code></strong>
    -&gt;   <strong class="userinput"><code>LOOP</code></strong>
    -&gt;     <strong class="userinput"><code>INSERT INTO t3 VALUES (fanta);</code></strong>
    -&gt;     <strong class="userinput"><code>END LOOP;</code></strong>
    -&gt;   <strong class="userinput"><code>END//</code></strong>
Query OK, 0 rows affected (0.00 sec)

mysql&gt; <strong class="userinput"><code>SHOW PROCEDURE CODE p1//</code></strong>
+-----+----------------------------------------+
| Pos | Instruction                            |
+-----+----------------------------------------+
|   0 | set fanta@0 55                         |
|   1 | stmt 9 "DROP TABLE t2"                 |
|   2 | stmt 5 "INSERT INTO t3 VALUES (fanta)" |
|   3 | jump 2                                 |
+-----+----------------------------------------+
4 rows in set (0.00 sec)
</pre><p>
          In this example, the non-executable <code class="literal">BEGIN</code>
          and <code class="literal">END</code> statements have disappeared, and
          for the <code class="literal">DECLARE
          <em class="replaceable"><code>variable_name</code></em></code> statement,
          only the executable part appears (the part where the default
          is assigned). For each statement that is taken from source,
          there is a code word <code class="literal">stmt</code> followed by a
          type (9 means <code class="literal">DROP</code>, 5 means
          <code class="literal">INSERT</code>, and so on). The final row contains
          an instruction <code class="literal">jump 2</code>, meaning
          <code class="literal">GOTO instruction #2</code>.
        </p><p>
          These statements were added in MySQL 5.0.17.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="show-procedure-status"></a><code class="literal">SHOW PROCEDURE STATUS</code> and <code class="literal">SHOW FUNCTION
          STATUS</code> Syntax</h4></div></div></div><a id="id2895784" class="indexterm"></a><a id="id2895791" class="indexterm"></a><pre class="programlisting">SHOW {PROCEDURE | FUNCTION} STATUS [LIKE '<em class="replaceable"><code>pattern</code></em>']
</pre><p>
          These statements are MySQL extensions. They return
          characteristics of routines, such as the database, name, type,
          creator, and creation and modification dates. If no pattern is
          specified, the information for all stored procedures or all
          stored functions is listed, depending on which statement you
          use.
        </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SHOW FUNCTION STATUS LIKE 'hello'\G</code></strong>
*************************** 1. row ***************************
           Db: test
         Name: hello
         Type: FUNCTION
      Definer: testuser@localhost
     Modified: 2004-08-03 15:29:37
      Created: 2004-08-03 15:29:37
Security_type: DEFINER
      Comment:
</pre><p>
          You can also get information about stored routines from the
          <code class="literal">ROUTINES</code> table in
          <code class="literal">INFORMATION_SCHEMA</code>. See
          <a href="http://dev.mysql.com/doc/refman/5.0/en/routines-table.html" target="_top">The <code class="literal">INFORMATION_SCHEMA ROUTINES</code> Table</a>.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="show-processlist"></a><code class="literal">SHOW PROCESSLIST</code> Syntax</h4></div></div></div><a id="id2895900" class="indexterm"></a><a id="id2895907" class="indexterm"></a><a id="id2895914" class="indexterm"></a><a id="id2895920" class="indexterm"></a><a id="id2895931" class="indexterm"></a><pre class="programlisting">SHOW [FULL] PROCESSLIST
</pre><p>
          <code class="literal">SHOW PROCESSLIST</code> shows you which threads
          are running. You can also get this information using the
          <span><strong class="command">mysqladmin processlist</strong></span> command. If you have
          the <code class="literal">PROCESS</code> privilege, you can see all
          threads. Otherwise, you can see only your own threads (that
          is, threads associated with the MySQL account that you are
          using). See <a href="mysqlqb_statements.html#kill" title="KILL Syntax"><code class="literal">KILL</code> Syntax</a>. If you do not use the
          <code class="literal">FULL</code> keyword, only the first 100 characters
          of each statement are shown in the <code class="literal">Info</code>
          field.
        </p><p class="mnmas"><b>MySQL Enterprise. </b>
            Subscribers to MySQL Network Monitoring and Advisory Service
            receive instant notification and expert advice on resolution
            when there are too many concurrent processes. For more
            information see,
            <a href="http://www.mysql.com/products/enterprise/advisors.html" target="_top">http://www.mysql.com/products/enterprise/advisors.html</a>.
          </p><p>
          This statement is very useful if you get the “<span class="quote">too many
          connections</span>” error message and want to find out what is
          going on. MySQL reserves one extra connection to be used by
          accounts that have the <code class="literal">SUPER</code> privilege, to
          ensure that administrators should always be able to connect
          and check the system (assuming that you are not giving this
          privilege to all your users).
        </p><p>
          The output of <code class="literal">SHOW PROCESSLIST</code> may look
          like this:
        </p><pre class="programlisting">mysql&gt; SHOW FULL PROCESSLIST\G
*************************** 1. row ***************************
Id: 1
User: system user
Host:
db: NULL
Command: Connect
Time: 1030455
State: Waiting for master to send event
Info: NULL
*************************** 2. row ***************************
Id: 2
User: system user
Host:
db: NULL
Command: Connect
Time: 1004
State: Has read all relay log; waiting for the slave I/O thread to update it
Info: NULL
*************************** 3. row ***************************
Id: 3112
User: replikator
Host: artemis:2204
db: NULL
Command: Binlog Dump
Time: 2144
State: Has sent all binlog to slave; waiting for binlog to be updated
Info: NULL
*************************** 4. row ***************************
Id: 3113
User: replikator
Host: iconnect2:45781
db: NULL
Command: Binlog Dump
Time: 2086
State: Has sent all binlog to slave; waiting for binlog to be updated
Info: NULL
*************************** 5. row ***************************
Id: 3123
User: stefan
Host: localhost
db: apollon
Command: Query
Time: 0
State: NULL
Info: SHOW FULL PROCESSLIST
5 rows in set (0.00 sec)
</pre><p>
          The columns have the following meaning:
        </p><div class="itemizedlist"><ul type="disc"><li><p>
              <code class="literal">Id</code>
            </p><p>
              The connection identifier.
            </p></li><li><p>
              <code class="literal">User</code>
            </p><p>
              The MySQL user who issued the statement. If this is
              <code class="literal">system user</code>, it refers to a non-client
              thread spawned by the server to handle tasks internally.
              This could be the I/O or SQL thread used on replication
              slaves or a delayed-row handler. For <code class="literal">system
              user</code>, there is no host specified in the
              <code class="literal">Host</code> column.
            </p></li><li><p>
              <code class="literal">Host</code>
            </p><p>
              The hostname of the client issuing the statement (except
              for <code class="literal">system user</code> where there is no
              host). <code class="literal">SHOW PROCESSLIST</code> reports the
              hostname for TCP/IP connections in
              <code class="literal"><em class="replaceable"><code>host_name</code></em>:<em class="replaceable"><code>client_port</code></em></code>
              format to make it easier to determine which client is
              doing what.
            </p></li><li><p>
              <code class="literal">db</code>
            </p><p>
              The default database, if one is selected, otherwise
              <code class="literal">NULL</code>.
            </p></li><li><p>
              <code class="literal">Command</code>
            </p><p>
              The value of that column corresponds to the
              <code class="literal">COM_<em class="replaceable"><code>xxx</code></em></code>
              commands of the client/server protocol. See
              <a href="http://dev.mysql.com/doc/refman/5.0/en/server-status-variables.html" target="_top">Status Variables</a>
            </p><p>
              The <code class="literal">Command</code> value may be one of the
              following: <code class="literal">Binlog Dump</code>, <code class="literal">Change
              user</code>, <code class="literal">Close stmt</code>,
              <code class="literal">Connect</code>, <code class="literal">Connect
              Out</code>, <code class="literal">Create DB</code>,
              <code class="literal">Daemon</code>, <code class="literal">Debug</code>,
              <code class="literal">Delayed insert</code>, <code class="literal">Drop
              DB</code>, <code class="literal">Error</code>,
              <code class="literal">Execute</code>, <code class="literal">Fetch</code>,
              <code class="literal">Field List</code>, <code class="literal">Init DB</code>,
              <code class="literal">Kill</code>, <code class="literal">Long Data</code>,
              <code class="literal">Ping</code>, <code class="literal">Prepare</code>,
              <code class="literal">Processlist</code>, <code class="literal">Query</code>,
              <code class="literal">Quit</code>, <code class="literal">Refresh</code>,
              <code class="literal">Register Slave</code>, <code class="literal">Reset
              stmt</code>, <code class="literal">Set option</code>,
              <code class="literal">Shutdown</code>, <code class="literal">Sleep</code>,
              <code class="literal">Statistics</code>, <code class="literal">Table
              Dump</code>, <code class="literal">Time</code>
            </p></li><li><p>
              <code class="literal">Time</code>
            </p><p>
              The time in seconds that the thread has been in its
              current state.
            </p></li><li><p>
              <code class="literal">State</code>
            </p><p>
              An action, event, or state, which can be one of the
              following: <code class="literal">After create</code>,
              <code class="literal">Analyzing</code>, <code class="literal">Changing
              master</code>, <code class="literal">Checking master
              version</code>, <code class="literal">Checking table</code>,
              <code class="literal">Connecting to master</code>, <code class="literal">Copying
              to group table</code>, <code class="literal">Copying to tmp
              table</code>, <code class="literal">Creating delayed
              handler</code>, <code class="literal">Creating index</code>,
              <code class="literal">Creating sort index</code>, <code class="literal">Creating
              table from master dump</code>, <code class="literal">Creating tmp
              table</code>, <code class="literal">Execution of
              init_command</code>, <code class="literal">FULLTEXT
              initialization</code>, <code class="literal">Finished reading one
              binlog; switching to next binlog</code>,
              <code class="literal">Flushing tables</code>,
              <code class="literal">Killed</code>, <code class="literal">Killing
              slave</code>, <code class="literal">Locked</code>,
              <code class="literal">Making temp file </code>, <code class="literal">Opening
              master dump table</code>, <code class="literal">Opening
              table</code>, <code class="literal">Opening tables</code>,
              <code class="literal">Processing request</code>, <code class="literal">Purging
              old relay logs</code>, <code class="literal">Queueing master event
              to the relay log</code>, <code class="literal">Reading event from
              the relay log</code>, <code class="literal">Reading from
              net</code>, <code class="literal">Reading master dump table
              data</code>, <code class="literal">Rebuilding the index on master
              dump table</code>, <code class="literal">Reconnecting after a failed
              binlog dump request</code>, <code class="literal">Reconnecting after
              a failed master event read</code>, <code class="literal">Registering
              slave on master</code>, <code class="literal">Removing
              duplicates</code>, <code class="literal">Reopen tables</code>,
              <code class="literal">Repair by sorting</code>, <code class="literal">Repair
              done</code>, <code class="literal">Repair with keycache</code>,
              <code class="literal">Requesting binlog dump</code>,
              <code class="literal">Rolling back</code>, <code class="literal">Saving
              state</code>, <code class="literal">Searching rows for
              update</code>, <code class="literal">Sending binlog event to
              slave</code>, <code class="literal">Sending data</code>,
              <code class="literal">Sorting for group</code>, <code class="literal">Sorting for
              order</code>, <code class="literal">Sorting index</code>,
              <code class="literal">Sorting result</code>, <code class="literal">System
              lock</code>, <code class="literal">Table lock</code>,
              <code class="literal">Thread initialized</code>,
              <code class="literal">Updating</code>, <code class="literal">User lock</code>,
              <code class="literal">Waiting for INSERT</code>, <code class="literal">Waiting
              for master to send event</code>, <code class="literal">Waiting for
              master update</code>, <code class="literal">Waiting for slave mutex
              on exit</code>, <code class="literal">Waiting for table</code>,
              <code class="literal">Waiting for tables</code>, <code class="literal">Waiting
              for the next event in relay log</code>,
              <code class="literal">Waiting on cond</code>, <code class="literal">Waiting to
              finalize termination</code>, <code class="literal">Waiting to
              reconnect after a failed binlog dump request</code>,
              <code class="literal">Waiting to reconnect after a failed master event
              read</code>, <code class="literal">Writing to net</code>,
              <code class="literal">allocating local table</code>,
              <code class="literal">cleaning up</code>, <code class="literal">closing
              tables</code>, <code class="literal">converting HEAP to
              MyISAM</code>, <code class="literal">copy to tmp table</code>,
              <code class="literal">creating table</code>, <code class="literal">deleting from
              main table</code>, <code class="literal">deleting from reference
              tables</code>,
              <code class="literal">discard_or_import_tablespace</code>,
              <code class="literal">end</code>, <code class="literal">freeing items</code>,
              <code class="literal">got handler lock</code>, <code class="literal">got old
              table</code>, <code class="literal">info</code>,
              <code class="literal">init</code>, <code class="literal">insert</code>,
              <code class="literal">logging slow query</code>,
              <code class="literal">login</code>, <code class="literal">preparing</code>,
              <code class="literal">purging old relay logs</code>, <code class="literal">query
              end</code>, <code class="literal">removing tmp table</code>,
              <code class="literal">rename</code>, <code class="literal">rename result
              table</code>, <code class="literal">reschedule</code>,
              <code class="literal">setup</code>, <code class="literal">starting
              slave</code>, <code class="literal">statistics</code>,
              <code class="literal">storing row into queue</code>,
              <code class="literal">unauthenticated user</code>,
              <code class="literal">update</code>, <code class="literal">updating</code>,
              <code class="literal">updating main table</code>, <code class="literal">updating
              reference tables</code>, <code class="literal">upgrading
              lock</code>, <code class="literal">waiting for delay_list</code>,
              <code class="literal">waiting for handler insert</code>,
              <code class="literal">waiting for handler lock</code>,
              <code class="literal">waiting for handler open</code>,
              <code class="literal">Waiting for event from ndbcluster</code>
            </p><p>
              The most common <code class="literal">State</code> values are
              described in the rest of this section. Most of the other
              <code class="literal">State</code> values are useful only for
              finding bugs in the server. See also
              <a href="http://dev.mysql.com/doc/refman/5.0/en/replication-implementation-details.html" target="_top">Replication Implementation Details</a>, for
              additional information about process states for
              replication servers.
            </p><p>
              For the <code class="literal">SHOW PROCESSLIST</code> statement, the
              value of <code class="literal">State</code> is
              <code class="literal">NULL</code>.
            </p></li><li><p>
              <code class="literal">Info</code>
            </p><p>
              The statement that the thread is executing, or
              <code class="literal">NULL</code> if it is not executing any
              statement.
            </p></li></ul></div><p>
          Some <code class="literal">State</code> values commonly seen in the
          output from <code class="literal">SHOW PROCESSLIST</code>:
        </p><div class="itemizedlist"><ul type="disc"><li><p>
              <code class="literal">Checking table</code>
            </p><p>
              The thread is performing a table check operation.
            </p></li><li><p>
              <code class="literal">Closing tables</code>
            </p><p>
              Means that the thread is flushing the changed table data
              to disk and closing the used tables. This should be a fast
              operation. If not, you should verify that you do not have
              a full disk and that the disk is not in very heavy use.
            </p></li><li><p>
              <code class="literal">Connect Out</code>
            </p><p>
              A replication slave is connecting to its master.
            </p></li><li><p>
              <code class="literal">Copying to group table</code>
            </p><p>
              If a statement has different <code class="literal">ORDER BY</code>
              and <code class="literal">GROUP BY</code> criteria, the rows are
              sorted by group and copied to a temporary table.
            </p></li><li><p>
              <code class="literal">Copying to tmp table</code>
            </p><p>
              The server is copying to a temporary table in memory.
            </p></li><li><p>
              <code class="literal">Copying to tmp table on disk</code>
            </p><p>
              The server is copying to a temporary table on disk. The
              temporary result set was larger than
              <code class="literal">tmp_table_size</code> and the thread is
              changing the temporary table from in-memory to disk-based
              format to save memory.
            </p></li><li><p>
              <code class="literal">Creating tmp table</code>
            </p><p>
              The thread is creating a temporary table to hold a part of
              the result for the query.
            </p></li><li><p>
              <code class="literal">deleting from main table</code>
            </p><p>
              The server is executing the first part of a multiple-table
              delete. It is deleting only from the first table, and
              saving fields and offsets to be used for deleting from the
              other (reference) tables.
            </p></li><li><p>
              <code class="literal">deleting from reference tables</code>
            </p><p>
              The server is executing the second part of a
              multiple-table delete and deleting the matched rows from
              the other tables.
            </p></li><li><p>
              <code class="literal">Flushing tables</code>
            </p><p>
              The thread is executing <code class="literal">FLUSH TABLES</code>
              and is waiting for all threads to close their tables.
            </p></li><li><p>
              <code class="literal">FULLTEXT initialization</code>
            </p><p>
              The server is preparing to perform a natural-language
              full-text search.
            </p></li><li><p>
              <code class="literal">Killed</code>
            </p><p>
              Someone has sent a <code class="literal">KILL</code> statement to
              the thread and it should abort next time it checks the
              kill flag. The flag is checked in each major loop in
              MySQL, but in some cases it might still take a short time
              for the thread to die. If the thread is locked by some
              other thread, the kill takes effect as soon as the other
              thread releases its lock.
            </p></li><li><p>
              <code class="literal">Locked</code>
            </p><p>
              The query is locked by another query.
            </p></li><li><p>
              <code class="literal">Sending data</code>
            </p><p>
              The thread is processing rows for a
              <code class="literal">SELECT</code> statement and also is sending
              data to the client.
            </p></li><li><p>
              <code class="literal">Sorting for group</code>
            </p><p>
              The thread is doing a sort to satisfy a <code class="literal">GROUP
              BY</code>.
            </p></li><li><p>
              <code class="literal">Sorting for order</code>
            </p><p>
              The thread is doing a sort to satisfy a <code class="literal">ORDER
              BY</code>.
            </p></li><li><p>
              <code class="literal">Opening tables</code>
            </p><p>
              The thread is trying to open a table. This is should be
              very fast procedure, unless something prevents opening.
              For example, an <code class="literal">ALTER TABLE</code> or a
              <code class="literal">LOCK TABLE</code> statement can prevent
              opening a table until the statement is finished.
            </p></li><li><p>
              <code class="literal">Reading from net</code>
            </p><p>
              The server is reading a packet from the network.
            </p></li><li><p>
              <code class="literal">Removing duplicates</code>
            </p><p>
              The query was using <code class="literal">SELECT DISTINCT</code> in
              such a way that MySQL could not optimize away the distinct
              operation at an early stage. Because of this, MySQL
              requires an extra stage to remove all duplicated rows
              before sending the result to the client.
            </p></li><li><p>
              <code class="literal">Reopen table</code>
            </p><p>
              The thread got a lock for the table, but noticed after
              getting the lock that the underlying table structure
              changed. It has freed the lock, closed the table, and is
              trying to reopen it.
            </p></li><li><p>
              <code class="literal">Repair by sorting</code>
            </p><p>
              The repair code is using a sort to create indexes.
            </p></li><li><p>
              <code class="literal">Repair with keycache</code>
            </p><p>
              The repair code is using creating keys one by one through
              the key cache. This is much slower than <code class="literal">Repair by
              sorting</code>.
            </p></li><li><p>
              <code class="literal">Searching rows for update</code>
            </p><p>
              The thread is doing a first phase to find all matching
              rows before updating them. This has to be done if the
              <code class="literal">UPDATE</code> is changing the index that is
              used to find the involved rows.
            </p></li><li><p>
              <code class="literal">Sleeping</code>
            </p><p>
              The thread is waiting for the client to send a new
              statement to it.
            </p></li><li><p>
              <code class="literal">statistics</code>
            </p><p>
              The server is calculating statistics to develop a query
              execution plan.
            </p></li><li><p>
              <a id="id2897321" class="indexterm"></a>

              <a id="id2897328" class="indexterm"></a>

              <code class="literal">System lock</code>
            </p><p>
              The thread is waiting to get an external system lock for
              the table. If you are not using multiple
              <span><strong class="command">mysqld</strong></span> servers that are accessing the
              same tables, you can disable system locks with the
              <code class="option">--skip-external-locking</code> option.
            </p></li><li><p>
              <code class="literal">unauthenticated user</code>
            </p><p>
              The state of a thread that has become associated with a
              client connection but for which authentication of the
              client user has not yet been done.
            </p></li><li><p>
              <code class="literal">Upgrading lock</code>
            </p><p>
              The <code class="literal">INSERT DELAYED</code> handler is trying to
              get a lock for the table to insert rows.
            </p></li><li><p>
              <code class="literal">Updating</code>
            </p><p>
              The thread is searching for rows to update and is updating
              them.
            </p></li><li><p>
              <code class="literal">updating main table</code>
            </p><p>
              The server is executing the first part of a multiple-table
              update. It is updating only the first table, and saving
              fields and offsets to be used for updating the other
              (reference) tables.
            </p></li><li><p>
              <code class="literal">updating reference tables</code>
            </p><p>
              The server is executing the second part of a
              multiple-table update and updating the matched rows from
              the other tables.
            </p></li><li><p>
              <code class="literal">User Lock</code>
            </p><p>
              The thread is waiting on a <code class="literal">GET_LOCK()</code>.
            </p></li><li><p>
              <code class="literal">Waiting for event from ndbcluster</code>
            </p><p>
              The server is acting as an SQL node in a MySQL Cluster,
              and is connected to a cluster management node.
            </p></li><li><p>
              <code class="literal">Waiting for tables</code>
            </p><p>
              The thread got a notification that the underlying
              structure for a table has changed and it needs to reopen
              the table to get the new structure. However, to reopen the
              table, it must wait until all other threads have closed
              the table in question.
            </p><p>
              This notification takes place if another thread has used
              <code class="literal">FLUSH TABLES</code> or one of the following
              statements on the table in question: <code class="literal">FLUSH TABLES
              <em class="replaceable"><code>tbl_name</code></em></code>,
              <code class="literal">ALTER TABLE</code>, <code class="literal">RENAME
              TABLE</code>, <code class="literal">REPAIR TABLE</code>,
              <code class="literal">ANALYZE TABLE</code>, or <code class="literal">OPTIMIZE
              TABLE</code>.
            </p></li><li><p>
              <code class="literal">waiting for handler insert</code>
            </p><p>
              The <code class="literal">INSERT DELAYED</code> handler has
              processed all pending inserts and is waiting for new ones.
            </p></li><li><p>
              <code class="literal">Writing to net</code>
            </p><p>
              The server is writing a packet to the network.
            </p></li></ul></div><p>
          Most states correspond to very quick operations. If a thread
          stays in any of these states for many seconds, there might be
          a problem that needs to be investigated.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="show-profiles"></a><code class="literal">SHOW PROFILES</code> and <code class="literal">SHOW PROFILE</code>
          Syntax</h4></div></div></div><p class="cs">This section does not apply to MySQL Enterprise Server users.</p><a id="id2897598" class="indexterm"></a><a id="id2897604" class="indexterm"></a><pre class="programlisting">SHOW PROFILES

SHOW PROFILE [<em class="replaceable"><code>type</code></em> [, <em class="replaceable"><code>type</code></em>] ... ]
    [FOR QUERY <em class="replaceable"><code>n</code></em>]
    [LIMIT <em class="replaceable"><code>n</code></em> [OFFSET <em class="replaceable"><code>n</code></em>]]

<em class="replaceable"><code>type</code></em>:
    ALL
  | BLOCK IO
  | CONTEXT SWITCHES
  | CPU
  | IPC
  | MEMORY
  | PAGE FAULTS
  | SOURCE
  | SWAPS
</pre><p>
          The <code class="literal">SHOW PROFILES</code> and <code class="literal">SHOW
          PROFILE</code> statements display profiling information
          that indicates resource usage for statements executed during
          the course of the current session.
        </p><p>
          Profiling is controlled by the <code class="literal">profiling</code>
          session variable, which has a default value of 0
          (<code class="literal">OFF</code>). Profiling is enabled by setting
          <code class="literal">profiling</code> to 1 or <code class="literal">ON</code>:
        </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SET profiling = 1;</code></strong>
</pre><p>
          <code class="literal">SHOW PROFILES</code> displays a list of the most
          recent statements sent to the master. The size of the list is
          controlled by the <code class="literal">profiling_history_size</code>
          session variable, which has a default value of 15. The maximum
          value is 100. Setting the value to 0 has the practical effect
          of disabling profiling.
        </p><p>
          All statements are profiled except <code class="literal">SHOW
          PROFILES</code> and <code class="literal">SHOW PROFILE</code>, so you
          will find neither of those statements in the profile list.
          Malformed statements are profiled. For example, <code class="literal">SHOW
          PROFILING</code> is an illegal statement, and a syntax
          error occurs if you try to execute it, but it will show up in
          the profiling list.
        </p><p>
          <code class="literal">SHOW PROFILE</code> displays detailed information
          about a single statement. Without the <code class="literal">FOR QUERY
          <em class="replaceable"><code>n</code></em></code> clause, the output
          pertains to the most recently executed statement. If
          <code class="literal">FOR QUERY <em class="replaceable"><code>n</code></em></code> is
          included, <code class="literal">SHOW PROFILE</code> displays information
          for statement <em class="replaceable"><code>n</code></em>. The values of
          <em class="replaceable"><code>n</code></em> correspond to the
          <code class="literal">Query_ID</code> values displayed by <code class="literal">SHOW
          PROFILES</code>.
        </p><p>
          The <code class="literal">LIMIT <em class="replaceable"><code>n</code></em></code>
          clause may be given to limit the output to
          <em class="replaceable"><code>n</code></em> rows. If <code class="literal">LIMIT</code>
          is given, <code class="literal">OFFSET
          <em class="replaceable"><code>n</code></em></code> may be added to begin
          the output <em class="replaceable"><code>n</code></em> rows into the full set
          of rows.
        </p><p>
          By default, <code class="literal">SHOW PROFILE</code> displays
          <code class="literal">Status</code> and <code class="literal">Duration</code>
          columns. Optional <em class="replaceable"><code>type</code></em> values may
          be specified to display specific additional types of
          information:
        </p><div class="itemizedlist"><ul type="disc"><li><p>
              <code class="literal">ALL</code> displays all information
            </p></li><li><p>
              <code class="literal">BLOCK IO</code> displays counts for block
              input and output operations
            </p></li><li><p>
              <code class="literal">CONTEXT SWITCHES</code> displays counts for
              voluntary and involuntary context switches
            </p></li><li><p>
              <code class="literal">CPU</code> displays user and system CPU usage
              times
            </p></li><li><p>
              <code class="literal">IPC</code> displays counts for messages sent
              and received
            </p></li><li><p>
              <code class="literal">MEMORY</code> is not currently implemented
            </p></li><li><p>
              <code class="literal">PAGE FAULTS</code> displays counts for major
              and minor page faults
            </p></li><li><p>
              <code class="literal">SOURCE</code> displays the names of functions
              from the source code, together with the name and line
              number of the file in which the function occurs
            </p></li><li><p>
              <code class="literal">SWAPS</code> displays swap counts
            </p></li></ul></div><p>
          Profiling is enabled per session. When a session ends, its
          profiling information is lost.
        </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SELECT @@profiling;</code></strong>
+-------------+
| @@profiling |
+-------------+
|           0 |
+-------------+
1 row in set (0.00 sec)

mysql&gt; <strong class="userinput"><code>SET profiling = 1;</code></strong>
Query OK, 0 rows affected (0.00 sec)

mysql&gt; <strong class="userinput"><code>DROP TABLE IF EXISTS t1;</code></strong>
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql&gt; <strong class="userinput"><code>CREATE TABLE T1 (id INT);</code></strong>
Query OK, 0 rows affected (0.01 sec)

mysql&gt; <strong class="userinput"><code>SHOW PROFILES;</code></strong>
+----------+----------+--------------------------+
| Query_ID | Duration | Query                    |
+----------+----------+--------------------------+
|        0 | 0.000088 | SET PROFILING = 1        |
|        1 | 0.000136 | DROP TABLE IF EXISTS t1  |
|        2 | 0.011947 | CREATE TABLE t1 (id INT) |
+----------+----------+--------------------------+
3 rows in set (0.00 sec)

mysql&gt; <strong class="userinput"><code>SHOW PROFILE;</code></strong>
+----------------------+----------+
| Status               | Duration |
+----------------------+----------+
| checking permissions | 0.000040 |
| creating table       | 0.000056 |
| After create         | 0.011363 |
| query end            | 0.000375 |
| freeing items        | 0.000089 |
| logging slow query   | 0.000019 |
| cleaning up          | 0.000005 |
+----------------------+----------+
7 rows in set (0.00 sec)

mysql&gt; <strong class="userinput"><code>SHOW PROFILE FOR QUERY 1;</code></strong>
+--------------------+----------+
| Status             | Duration |
+--------------------+----------+
| query end          | 0.000107 |
| freeing items      | 0.000008 |
| logging slow query | 0.000015 |
| cleaning up        | 0.000006 |
+--------------------+----------+
4 rows in set (0.00 sec)

mysql&gt; <strong class="userinput"><code>SHOW PROFILE CPU FOR QUERY 2;</code></strong>
+----------------------+----------+----------+------------+
| Status               | Duration | CPU_user | CPU_system |
+----------------------+----------+----------+------------+
| checking permissions | 0.000040 | 0.000038 |   0.000002 |
| creating table       | 0.000056 | 0.000028 |   0.000028 |
| After create         | 0.011363 | 0.000217 |   0.001571 |
| query end            | 0.000375 | 0.000013 |   0.000028 |
| freeing items        | 0.000089 | 0.000010 |   0.000014 |
| logging slow query   | 0.000019 | 0.000009 |   0.000010 |
| cleaning up          | 0.000005 | 0.000003 |   0.000002 |
+----------------------+----------+----------+------------+
7 rows in set (0.00 sec)
</pre><p>
          Profiling is only partially functional on some architectures.
          For values that depend on the <code class="literal">getrusage()</code>
          system call, <code class="literal">NULL</code> is returned on systems
          that do not support the call.
        </p><p>
          <code class="literal">SHOW PROFILES</code> and <code class="literal">SHOW
          PROFILE</code> were added in MySQL 5.0.37.
        </p><p>
          You can also get profiling information from the
          <code class="literal">PROFILING</code> table in
          <code class="literal">INFORMATION_SCHEMA</code>. See
          <a href="http://dev.mysql.com/doc/refman/5.0/en/profiling-table.html" target="_top">The <code class="literal">INFORMATION_SCHEMA PROFILING</code> Table</a>. For example, the following
          queries produce the same result:
        </p><pre class="programlisting">SHOW PROFILE FOR QUERY 2;
          
SELECT STATE, FORMAT(DURATION, 6) AS DURATION
FROM INFORMATION_SCHEMA.PROFILING 
WHERE QUERY_ID = 2 ORDER BY SEQ; 
</pre></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="show-status"></a><code class="literal">SHOW STATUS</code> Syntax</h4></div></div></div><a id="id2898113" class="indexterm"></a><a id="id2898120" class="indexterm"></a><pre class="programlisting">SHOW [GLOBAL | SESSION] STATUS [LIKE '<em class="replaceable"><code>pattern</code></em>']
</pre><a id="id2898155" class="indexterm"></a><p>
          <code class="literal">SHOW STATUS</code> provides server status
          information. This information also can be obtained using the
          <span><strong class="command">mysqladmin extended-status</strong></span> command.
        </p><p>
          Partial output is shown here. The list of names and values may
          be different for your server. The meaning of each variable is
          given in <a href="http://dev.mysql.com/doc/refman/5.0/en/server-status-variables.html" target="_top">Status Variables</a>.
        </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SHOW STATUS;</code></strong>
+--------------------------+------------+
| Variable_name            | Value      |
+--------------------------+------------+
| Aborted_clients          | 0          |
| Aborted_connects         | 0          |
| Bytes_received           | 155372598  |
| Bytes_sent               | 1176560426 |
| Connections              | 30023      |
| Created_tmp_disk_tables  | 0          |
| Created_tmp_tables       | 8340       |
| Created_tmp_files        | 60         |
...
| Open_tables              | 1          |
| Open_files               | 2          |
| Open_streams             | 0          |
| Opened_tables            | 44600      |
| Questions                | 2026873    |
...
| Table_locks_immediate    | 1920382    |
| Table_locks_waited       | 0          |
| Threads_cached           | 0          |
| Threads_created          | 30022      |
| Threads_connected        | 1          |
| Threads_running          | 1          |
| Uptime                   | 80380      |
+--------------------------+------------+
</pre><p>
          With a <code class="literal">LIKE</code> clause, the statement displays
          only rows for those variables with names that match the
          pattern:
        </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SHOW STATUS LIKE 'Key%';</code></strong>
+--------------------+----------+
| Variable_name      | Value    |
+--------------------+----------+
| Key_blocks_used    | 14955    |
| Key_read_requests  | 96854827 |
| Key_reads          | 162040   |
| Key_write_requests | 7589728  |
| Key_writes         | 3813196  |
+--------------------+----------+
</pre><p>
          The <code class="literal">GLOBAL</code> and <code class="literal">SESSION</code>
          options are new in MySQL 5.0.2. With the
          <code class="literal">GLOBAL</code> modifier, <code class="literal">SHOW
          STATUS</code> displays the status values for all
          connections to MySQL. With <code class="literal">SESSION</code>, it
          displays the status values for the current connection. If no
          modifier is present, the default is
          <code class="literal">SESSION</code>. <code class="literal">LOCAL</code> is a
          synonym for <code class="literal">SESSION</code>.
        </p><p>
          Some status variables have only a global value. For these, you
          get the same value for both <code class="literal">GLOBAL</code> and
          <code class="literal">SESSION</code>.
        </p><p>
          <span class="bold"><strong>Note</strong></span>: Before MySQL 5.0.2,
          <code class="literal">SHOW STATUS</code> returned global status values.
          Because the default as of 5.0.2 is to return session values,
          this is incompatible with previous versions. To issue a
          <code class="literal">SHOW STATUS</code> statement that will retrieve
          global status values for all versions of MySQL, write it like
          this:
        </p><pre class="programlisting">SHOW /*!50002 GLOBAL */ STATUS;
</pre></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="show-table-status"></a><code class="literal">SHOW TABLE STATUS</code> Syntax</h4></div></div></div><a id="id2898341" class="indexterm"></a><a id="id2898352" class="indexterm"></a><a id="id2898362" class="indexterm"></a><pre class="programlisting">SHOW TABLE STATUS [FROM <em class="replaceable"><code>db_name</code></em>] [LIKE '<em class="replaceable"><code>pattern</code></em>']
</pre><p>
          <code class="literal">SHOW TABLE STATUS</code> works likes <code class="literal">SHOW
          TABLES</code>, but provides a lot of information about each
          table. You can also get this list using the <span><strong class="command">mysqlshow
          --status <em class="replaceable"><code>db_name</code></em></strong></span> command.
        </p><p>
          As of MySQL 5.0.1, this statement also displays information
          about views.
        </p><p>
          <code class="literal">SHOW TABLE STATUS</code> returns the following
          fields:
        </p><div class="itemizedlist"><ul type="disc"><li><p>
              <code class="literal">Name</code>
            </p><p>
              The name of the table.
            </p></li><li><p>
              <code class="literal">Engine</code>
            </p><p>
              The storage engine for the table. See
              <a href="http://dev.mysql.com/doc/refman/5.0/en/storage-engines.html" target="_top">Storage Engines and Table Types</a>.
            </p></li><li><p>
              <code class="literal">Version</code>
            </p><p>
              The version number of the table's
              <code class="filename">.frm</code> file.
            </p></li><li><p>
              <code class="literal">Row_format</code>
            </p><p>
              The row storage format (<code class="literal">Fixed</code>,
              <code class="literal">Dynamic</code>, <code class="literal">Compressed</code>,
              <code class="literal">Redundant</code>, <code class="literal">Compact</code>).
              Starting with MySQL/InnoDB 5.0.3, the format of
              <code class="literal">InnoDB</code> tables is reported as
              <code class="literal">Redundant</code> or
              <code class="literal">Compact</code>. Prior to 5.0.3,
              <code class="literal">InnoDB</code> tables are always in the
              <code class="literal">Redundant</code> format.
            </p></li><li><p>
              <code class="literal">Rows</code>
            </p><p>
              The number of rows. Some storage engines, such as
              <code class="literal">MyISAM</code>, store the exact count. For
              other storage engines, such as <code class="literal">InnoDB</code>,
              this value is an approximation, and may vary from the
              actual value by as much as 40 to 50%. In such cases, use
              <code class="literal">SELECT COUNT(*)</code> to obtain an accurate
              count.
            </p><p>
              The <code class="literal">Rows</code> value is
              <code class="literal">NULL</code> for tables in the
              <code class="literal">INFORMATION_SCHEMA</code> database.
            </p></li><li><p>
              <code class="literal">Avg_row_length</code>
            </p><p>
              The average row length.
            </p></li><li><p>
              <code class="literal">Data_length</code>
            </p><p>
              The length of the data file.
            </p></li><li><p>
              <code class="literal">Max_data_length</code>
            </p><p>
              The maximum length of the data file. This is the total
              number of bytes of data that can be stored in the table,
              given the data pointer size used.
            </p></li><li><p>
              <code class="literal">Index_length</code>
            </p><p>
              The length of the index file.
            </p></li><li><p>
              <code class="literal">Data_free</code>
            </p><p>
              The number of allocated but unused bytes.
            </p></li><li><p>
              <code class="literal">Auto_increment</code>
            </p><p>
              The next <code class="literal">AUTO_INCREMENT</code> value.
            </p></li><li><p>
              <code class="literal">Create_time</code>
            </p><p>
              When the table was created.
            </p></li><li><p>
              <code class="literal">Update_time</code>
            </p><p>
              When the data file was last updated. For some storage
              engines, this value is <code class="literal">NULL</code>. For
              example, <code class="literal">InnoDB</code> stores multiple tables
              in its tablespace and the data file timestamp does not
              apply.
            </p></li><li><p>
              <code class="literal">Check_time</code>
            </p><p>
              When the table was last checked. Not all storage engines
              update this time, in which case the value is always
              <code class="literal">NULL</code>.
            </p></li><li><p>
              <code class="literal">Collation</code>
            </p><p>
              The table's character set and collation.
            </p></li><li><p>
              <code class="literal">Checksum</code>
            </p><p>
              The live checksum value (if any).
            </p></li><li><p>
              <code class="literal">Create_options</code>
            </p><p>
              Extra options used with <code class="literal">CREATE TABLE</code>.
            </p></li><li><p>
              <code class="literal">Comment</code>
            </p><p>
              The comment used when creating the table (or information
              as to why MySQL could not access the table information).
            </p></li></ul></div><p>
          In the table comment, <code class="literal">InnoDB</code> tables report
          the free space of the tablespace to which the table belongs.
          For a table located in the shared tablespace, this is the free
          space of the shared tablespace. If you are using multiple
          tablespaces and the table has its own tablespace, the free
          space is for only that table.
        </p><p>
          For <code class="literal">MEMORY</code> tables, the
          <code class="literal">Data_length</code>,
          <code class="literal">Max_data_length</code>, and
          <code class="literal">Index_length</code> values approximate the actual
          amount of allocated memory. The allocation algorithm reserves
          memory in large amounts to reduce the number of allocation
          operations.
        </p><p>
          Beginning with MySQL 5.0.3, for <code class="literal">NDB Cluster</code>
          tables, the output of this statement shows appropriate values
          for the <code class="literal">Avg_row_length</code> and
          <code class="literal">Data_length</code> columns, with the exception
          that <code class="literal">BLOB</code> columns are not taken into
          account. In addition, the number of replicas is now shown in
          the <code class="literal">Comment</code> column (as
          <code class="literal">number_of_replicas</code>).
        </p><p>
          For views, all the fields displayed by <code class="literal">SHOW TABLE
          STATUS</code> are <code class="literal">NULL</code> except that
          <code class="literal">Name</code> indicates the view name and
          <code class="literal">Comment</code> says <code class="literal">view</code>.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="show-tables"></a><code class="literal">SHOW TABLES</code> Syntax</h4></div></div></div><a id="id2898921" class="indexterm"></a><a id="id2898935" class="indexterm"></a><pre class="programlisting">SHOW [FULL] TABLES [FROM <em class="replaceable"><code>db_name</code></em>] [LIKE '<em class="replaceable"><code>pattern</code></em>']
</pre><p>
          <code class="literal">SHOW TABLES</code> lists the
          non-<code class="literal">TEMPORARY</code> tables in a given database.
          You can also get this list using the <span><strong class="command">mysqlshow
          <em class="replaceable"><code>db_name</code></em></strong></span> command.
        </p><p>
          Before MySQL 5.0.1, the output from <code class="literal">SHOW
          TABLES</code> contains a single column of table names.
          Beginning with MySQL 5.0.1, this statement also lists any
          views in the database. As of MySQL 5.0.2, the
          <code class="literal">FULL</code> modifier is supported such that
          <code class="literal">SHOW FULL TABLES</code> displays a second output
          column. Values for the second column are <code class="literal">BASE
          TABLE</code> for a table and <code class="literal">VIEW</code> for a
          view.
        </p><p>
          <span class="bold"><strong>Note</strong></span>: If you have no
          privileges for a table, the table does not show up in the
          output from <code class="literal">SHOW TABLES</code> or
          <span><strong class="command">mysqlshow db_name</strong></span>.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="show-triggers"></a><code class="literal">SHOW TRIGGERS</code> Syntax</h4></div></div></div><a id="id2899057" class="indexterm"></a><a id="id2899064" class="indexterm"></a><a id="id2899071" class="indexterm"></a><pre class="programlisting">SHOW TRIGGERS [FROM <em class="replaceable"><code>db_name</code></em>] [LIKE <em class="replaceable"><code>expr</code></em>]
</pre><p>
          <code class="literal">SHOW TRIGGERS</code> lists the triggers currently
          defined on the MySQL server. This statement requires the
          <code class="literal">SUPER</code> privilege. It was implemented in
          MySQL 5.0.10.
        </p><p>
          For the trigger <code class="literal">ins_sum</code> as defined in
          <a href="http://dev.mysql.com/doc/refman/5.0/en/using-triggers.html" target="_top">Using Triggers</a>, the output of this statement
          is as shown here:
        </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SHOW TRIGGERS LIKE 'acc%'\G</code></strong>
*************************** 1. row ***************************
  Trigger: ins_sum
    Event: INSERT
    Table: account
Statement: SET @sum = @sum + NEW.amount
   Timing: BEFORE
  Created: NULL
 sql_mode:
  Definer: myname@localhost
</pre><p>
          <span class="bold"><strong>Note</strong></span>: When using a
          <code class="literal">LIKE</code> clause with <code class="literal">SHOW
          TRIGGERS</code>, the expression to be matched
          (<em class="replaceable"><code>expr</code></em>) is compared with the name of
          the table on which the trigger is declared, and not with the
          name of the trigger:
        </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SHOW TRIGGERS LIKE 'ins%';</code></strong>
Empty set (0.01 sec)
</pre><p>
          A brief explanation of the columns in the output of this
          statement is shown here:
        </p><div class="itemizedlist"><ul type="disc"><li><p>
              <code class="literal">Trigger</code>
            </p><p>
              The name of the trigger.
            </p></li><li><p>
              <code class="literal">Event</code>
            </p><p>
              The event that causes trigger activation: one of
              <code class="literal">'INSERT'</code>, <code class="literal">'UPDATE'</code>,
              or <code class="literal">'DELETE'</code>.
            </p></li><li><p>
              <code class="literal">Table</code>
            </p><p>
              The table for which the trigger is defined.
            </p></li><li><p>
              <code class="literal">Statement</code>
            </p><p>
              The statement to be executed when the trigger is
              activated. This is the same as the text shown in the
              <code class="literal">ACTION_STATEMENT</code> column of
              <code class="literal">INFORMATION_SCHEMA.TRIGGERS</code>.
            </p></li><li><p>
              <code class="literal">Timing</code>
            </p><p>
              One of the two values <code class="literal">'BEFORE'</code> or
              <code class="literal">'AFTER'</code>.
            </p></li><li><p>
              <code class="literal">Created</code>
            </p><p>
              Currently, the value of this column is always
              <code class="literal">NULL</code>.
            </p></li><li><p>
              <code class="literal">sql_mode</code>
            </p><p>
              The SQL mode in effect when the trigger executes. This
              column was added in MySQL 5.0.11.
            </p></li><li><p>
              <code class="literal">Definer</code>
            </p><p>
              The account that created the trigger. This column was
              added in MySQL 5.0.17.
            </p></li></ul></div><p>
          You must have the <code class="literal">SUPER</code> privilege to
          execute <code class="literal">SHOW TRIGGERS</code>.
        </p><p>
          See also <a href="http://dev.mysql.com/doc/refman/5.0/en/triggers-table.html" target="_top">The <code class="literal">INFORMATION_SCHEMA TRIGGERS</code> Table</a>.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="show-variables"></a><code class="literal">SHOW VARIABLES</code> Syntax</h4></div></div></div><a id="id2899382" class="indexterm"></a><a id="id2899389" class="indexterm"></a><a id="id2899396" class="indexterm"></a><a id="id2899406" class="indexterm"></a><pre class="programlisting">SHOW [GLOBAL | SESSION] VARIABLES [LIKE '<em class="replaceable"><code>pattern</code></em>']
</pre><a id="id2899441" class="indexterm"></a><p>
          <code class="literal">SHOW VARIABLES</code> shows the values of MySQL
          system variables. This information also can be obtained using
          the <span><strong class="command">mysqladmin variables</strong></span> command.
        </p><p>
          With the <code class="literal">GLOBAL</code> modifier, <code class="literal">SHOW
          VARIABLES</code> displays the values that are used for new
          connections to MySQL. With <code class="literal">SESSION</code>, it
          displays the values that are in effect for the current
          connection. If no modifier is present, the default is
          <code class="literal">SESSION</code>. <code class="literal">LOCAL</code> is a
          synonym for <code class="literal">SESSION</code>.
        </p><p>
          If the default system variable values are unsuitable, you can
          set them using command options when <span><strong class="command">mysqld</strong></span>
          starts, and most can be changed at runtime with the
          <code class="literal">SET</code> statement. See
          <a href="http://dev.mysql.com/doc/refman/5.0/en/using-system-variables.html" target="_top">Using System Variables</a>, and
          <a href="mysqlqb_statements.html#set-option" title="SET Syntax"><code class="literal">SET</code> Syntax</a>.
        </p><p>
          Partial output is shown here. The list of names and values may
          be different for your server.
          <a href="http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html" target="_top">System Variables</a>, describes the
          meaning of each variable, and
          <a href="http://dev.mysql.com/doc/refman/5.0/en/server-parameters.html" target="_top">Tuning Server Parameters</a>, provides information
          about tuning them.
        </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SHOW VARIABLES;</code></strong>
+---------------------------------+-------------------------------------+
| Variable_name                   | Value                               |
+---------------------------------+-------------------------------------+
| auto_increment_increment        | 1                                   |
| auto_increment_offset           | 1                                   |
| automatic_sp_privileges         | ON                                  |
| back_log                        | 50                                  |
| basedir                         | /                                   |
| bdb_cache_size                  | 8388600                             |
| bdb_home                        | /var/lib/mysql/                     |
| bdb_log_buffer_size             | 32768                               |
...
| max_connections                 | 100                                 |
| max_connect_errors              | 10                                  |
| max_delayed_threads             | 20                                  |
| max_error_count                 | 64                                  |
| max_heap_table_size             | 16777216                            |
| max_join_size                   | 4294967295                          |
| max_relay_log_size              | 0                                   |
| max_sort_length                 | 1024                                |
...
| time_zone                       | SYSTEM                              |
| timed_mutexes                   | OFF                                 |
| tmp_table_size                  | 33554432                            |
| tmpdir                          |                                     |
| transaction_alloc_block_size    | 8192                                |
| transaction_prealloc_size       | 4096                                |
| tx_isolation                    | REPEATABLE-READ                     |
| updatable_views_with_limit      | YES                                 |
| version                         | 5.0.19-Max                          |
| version_comment                 | MySQL Community Edition - Max (GPL) |
| version_compile_machine         | i686                                |
| version_compile_os              | pc-linux-gnu                        |
| wait_timeout                    | 28800                               |
+---------------------------------+-------------------------------------+
</pre><p>
          With a <code class="literal">LIKE</code> clause, the statement displays
          only rows for those variables with names that match the
          pattern. To obtain the row for a specific variable, use a
          <code class="literal">LIKE</code> clause as shown:
        </p><pre class="programlisting">SHOW VARIABLES LIKE 'max_join_size';
SHOW SESSION VARIABLES LIKE 'max_join_size';
</pre><p>
          To get a list of variables whose name match a pattern, use the
          ‘<code class="literal">%</code>’ wildcard character in a
          <code class="literal">LIKE</code> clause:
        </p><pre class="programlisting">SHOW VARIABLES LIKE '%size%';
SHOW GLOBAL VARIABLES LIKE '%size%';
</pre><p>
          Wildcard characters can be used in any position within the
          pattern to be matched. Strictly speaking, because
          ‘<code class="literal">_</code>’ is a wildcard that matches
          any single character, you should escape it as
          ‘<code class="literal">\_</code>’ to match it literally. In
          practice, this is rarely necessary.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="show-warnings"></a><code class="literal">SHOW WARNINGS</code> Syntax</h4></div></div></div><a id="id2899722" class="indexterm"></a><pre class="programlisting">SHOW WARNINGS [LIMIT [<em class="replaceable"><code>offset</code></em>,] <em class="replaceable"><code>row_count</code></em>]
SHOW COUNT(*) WARNINGS
</pre><p>
          <code class="literal">SHOW WARNINGS</code> shows the error, warning, and
          note messages that resulted from the last statement that
          generated messages, or nothing if the last statement that used
          a table generated no messages. A related statement,
          <code class="literal">SHOW ERRORS</code>, shows only the errors. See
          <a href="mysqlqb_statements.html#show-errors" title="SHOW ERRORS Syntax"><code class="literal">SHOW ERRORS</code> Syntax</a>.
        </p><p>
          The list of messages is reset for each new statement that uses
          a table.
        </p><p>
          The <code class="literal">SHOW COUNT(*) WARNINGS</code> statement
          displays the total number of errors, warnings, and notes. You
          can also retrieve this number from the
          <code class="literal">warning_count</code> variable:
        </p><pre class="programlisting">SHOW COUNT(*) WARNINGS;
SELECT @@warning_count;
</pre><p>
          The value of <code class="literal">warning_count</code> might be greater
          than the number of messages displayed by <code class="literal">SHOW
          WARNINGS</code> if the <code class="literal">max_error_count</code>
          system variable is set so low that not all messages are
          stored. An example shown later in this section demonstrates
          how this can happen.
        </p><p>
          The <code class="literal">LIMIT</code> clause has the same syntax as for
          the <code class="literal">SELECT</code> statement. See
          <a href="mysqlqb_statements.html#select" title="SELECT Syntax"><code class="literal">SELECT</code> Syntax</a>.
        </p><p>
          The MySQL server sends back the total number of errors,
          warnings, and notes resulting from the last statement. If you
          are using the C API, this value can be obtained by calling
          <code class="literal">mysql_warning_count()</code>. See
          <a href="http://dev.mysql.com/doc/refman/5.0/en/mysql-warning-count.html" target="_top"><code class="literal">mysql_warning_count()</code></a>.
        </p><p>
          Warnings are generated for statements such as <code class="literal">LOAD
          DATA INFILE</code> and DML statements such as
          <code class="literal">INSERT</code>, <code class="literal">UPDATE</code>,
          <code class="literal">CREATE TABLE</code>, and <code class="literal">ALTER
          TABLE</code>.
        </p><p>
          The following <code class="literal">DROP TABLE</code> statement results
          in a note:
        </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>DROP TABLE IF EXISTS no_such_table;</code></strong>
mysql&gt; <strong class="userinput"><code>SHOW WARNINGS;</code></strong>
+-------+------+-------------------------------+
| Level | Code | Message                       |
+-------+------+-------------------------------+
| Note  | 1051 | Unknown table 'no_such_table' |
+-------+------+-------------------------------+
</pre><p>
          Here is a simple example that shows a syntax warning for
          <code class="literal">CREATE TABLE</code> and conversion warnings for
          <code class="literal">INSERT</code>:
        </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>CREATE TABLE t1 (a TINYINT NOT NULL, b CHAR(4)) TYPE=MyISAM;</code></strong>
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql&gt; <strong class="userinput"><code>SHOW WARNINGS\G</code></strong>
*************************** 1. row ***************************
  Level: Warning
   Code: 1287
Message: 'TYPE=storage_engine' is deprecated, use
         'ENGINE=storage_engine' instead
1 row in set (0.00 sec)

mysql&gt; <strong class="userinput"><code>INSERT INTO t1 VALUES(10,'mysql'),(NULL,'test'),</code></strong>
    -&gt; <strong class="userinput"><code>(300,'Open Source');</code></strong>
Query OK, 3 rows affected, 4 warnings (0.01 sec)
Records: 3  Duplicates: 0  Warnings: 4

mysql&gt; <strong class="userinput"><code>SHOW WARNINGS\G</code></strong>
*************************** 1. row ***************************
  Level: Warning
   Code: 1265
Message: Data truncated for column 'b' at row 1
*************************** 2. row ***************************
  Level: Warning
   Code: 1263
Message: Data truncated, NULL supplied to NOT NULL column 'a' at row 2
*************************** 3. row ***************************
  Level: Warning
   Code: 1264
Message: Data truncated, out of range for column 'a' at row 3
*************************** 4. row ***************************
  Level: Warning
   Code: 1265
Message: Data truncated for column 'b' at row 3
4 rows in set (0.00 sec)
</pre><p>
          The maximum number of error, warning, and note messages to
          store is controlled by the <code class="literal">max_error_count</code>
          system variable. By default, its value is 64. To change the
          number of messages you want stored, change the value of
          <code class="literal">max_error_count</code>. In the following example,
          the <code class="literal">ALTER TABLE</code> statement produces three
          warning messages, but only one is stored because
          <code class="literal">max_error_count</code> has been set to 1:
        </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SHOW VARIABLES LIKE 'max_error_count';</code></strong>
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_error_count | 64    |
+-----------------+-------+
1 row in set (0.00 sec)

mysql&gt; <strong class="userinput"><code>SET max_error_count=1;</code></strong>
Query OK, 0 rows affected (0.00 sec)

mysql&gt; <strong class="userinput"><code>ALTER TABLE t1 MODIFY b CHAR;</code></strong>
Query OK, 3 rows affected, 3 warnings (0.00 sec)
Records: 3  Duplicates: 0  Warnings: 3

mysql&gt; <strong class="userinput"><code>SELECT @@warning_count;</code></strong>
+-----------------+
| @@warning_count |
+-----------------+
|               3 |
+-----------------+
1 row in set (0.01 sec)

mysql&gt; <strong class="userinput"><code>SHOW WARNINGS;</code></strong>
+---------+------+----------------------------------------+
| Level   | Code | Message                                |
+---------+------+----------------------------------------+
| Warning | 1263 | Data truncated for column 'b' at row 1 |
+---------+------+----------------------------------------+
1 row in set (0.00 sec)
</pre><p>
          To disable warnings, set <code class="literal">max_error_count</code> to
          0. In this case, <code class="literal">warning_count</code> still
          indicates how many warnings have occurred, but none of the
          messages are stored.
        </p><p>
          As of MySQL 5.0.3, you can set the
          <code class="literal">SQL_NOTES</code> session variable to 0 to cause
          <code class="literal">Note</code>-level warnings not to be recorded.
        </p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="other-administrative-sql"></a>Other Administrative Statements</h3></div></div></div><div class="toc"><dl><dt><span class="section"><a href="mysqlqb_statements.html#cache-index"><code class="literal">CACHE INDEX</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#flush"><code class="literal">FLUSH</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#kill"><code class="literal">KILL</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#load-index"><code class="literal">LOAD INDEX INTO CACHE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#reset"><code class="literal">RESET</code> Syntax</a></span></dt></dl></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="cache-index"></a><code class="literal">CACHE INDEX</code> Syntax</h4></div></div></div><a id="id2900100" class="indexterm"></a><a id="id2900106" class="indexterm"></a><a id="id2900117" class="indexterm"></a><pre class="programlisting">CACHE INDEX
  <em class="replaceable"><code>tbl_index_list</code></em> [, <em class="replaceable"><code>tbl_index_list</code></em>] ...
  IN <em class="replaceable"><code>key_cache_name</code></em>

<em class="replaceable"><code>tbl_index_list</code></em>:
  <em class="replaceable"><code>tbl_name</code></em> [[INDEX|KEY] (<em class="replaceable"><code>index_name</code></em>[, <em class="replaceable"><code>index_name</code></em>] ...)]
</pre><p>
          The <code class="literal">CACHE INDEX</code> statement assigns table
          indexes to a specific key cache. It is used only for
          <code class="literal">MyISAM</code> tables.
        </p><p>
          The following statement assigns indexes from the tables
          <code class="literal">t1</code>, <code class="literal">t2</code>, and
          <code class="literal">t3</code> to the key cache named
          <code class="literal">hot_cache</code>:
        </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>CACHE INDEX t1, t2, t3 IN hot_cache;</code></strong>
+---------+--------------------+----------+----------+
| Table   | Op                 | Msg_type | Msg_text |
+---------+--------------------+----------+----------+
| test.t1 | assign_to_keycache | status   | OK       |
| test.t2 | assign_to_keycache | status   | OK       |
| test.t3 | assign_to_keycache | status   | OK       |
+---------+--------------------+----------+----------+
</pre><p>
          The syntax of <code class="literal">CACHE INDEX</code> enables you to
          specify that only particular indexes from a table should be
          assigned to the cache. The current implementation assigns all
          the table's indexes to the cache, so there is no reason to
          specify anything other than the table name.
        </p><p>
          The key cache referred to in a <code class="literal">CACHE INDEX</code>
          statement can be created by setting its size with a parameter
          setting statement or in the server parameter settings. For
          example:
        </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SET GLOBAL keycache1.key_buffer_size=128*1024;</code></strong>
</pre><p>
          Key cache parameters can be accessed as members of a
          structured system variable. See
          <a href="http://dev.mysql.com/doc/refman/5.0/en/structured-system-variables.html" target="_top">Structured System Variables</a>.
        </p><p>
          A key cache must exist before you can assign indexes to it:
        </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>CACHE INDEX t1 IN non_existent_cache;</code></strong>
ERROR 1284 (HY000): Unknown key cache 'non_existent_cache'
</pre><p>
          By default, table indexes are assigned to the main (default)
          key cache created at the server startup. When a key cache is
          destroyed, all indexes assigned to it become assigned to the
          default key cache again.
        </p><p>
          Index assignment affects the server globally: If one client
          assigns an index to a given cache, this cache is used for all
          queries involving the index, no matter which client issues the
          queries.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="flush"></a><code class="literal">FLUSH</code> Syntax</h4></div></div></div><a id="id2900312" class="indexterm"></a><a id="id2900319" class="indexterm"></a><a id="id2900326" class="indexterm"></a><a id="id2900337" class="indexterm"></a><pre class="programlisting">FLUSH [LOCAL | NO_WRITE_TO_BINLOG]
    <em class="replaceable"><code>flush_option</code></em> [, <em class="replaceable"><code>flush_option</code></em>] ...
</pre><p>
          The <code class="literal">FLUSH</code> statement clears or reloads
          various internal caches used by MySQL. To execute
          <code class="literal">FLUSH</code>, you must have the
          <code class="literal">RELOAD</code> privilege.
        </p><p>
          The <code class="literal">RESET</code> statement is similar to
          <code class="literal">FLUSH</code>. See <a href="mysqlqb_statements.html#reset" title="RESET Syntax"><code class="literal">RESET</code> Syntax</a>.
        </p><p>
          <em class="replaceable"><code>flush_option</code></em> can be any of the
          following:
        </p><div class="itemizedlist"><ul type="disc"><li><p>
              <code class="literal">HOSTS</code>
            </p><p>
              Empties the host cache tables. You should flush the host
              tables if some of your hosts change IP number or if you
              get the error message <code class="literal">Host
              '<em class="replaceable"><code>host_name</code></em>' is
              blocked</code>. When more than
              <code class="literal">max_connect_errors</code> errors occur
              successively for a given host while connecting to the
              MySQL server, MySQL assumes that something is wrong and
              blocks the host from further connection requests. Flushing
              the host tables allows the host to attempt to connect
              again. See <a href="http://dev.mysql.com/doc/refman/5.0/en/blocked-host.html" target="_top"><code class="literal">Host '<em class="replaceable"><code>host_name</code></em>' is  blocked</code></a>. You can start
              <span><strong class="command">mysqld</strong></span> with
              <code class="option">--max_connect_errors=999999999</code> to avoid
              this error message.
            </p></li><li><p>
              <code class="literal">DES_KEY_FILE</code>
            </p><p>
              Reloads the DES keys from the file that was specified with
              the <code class="option">--des-key-file</code> option at server
              startup time.
            </p></li><li><p>
              <code class="literal">LOGS</code>
            </p><p>
              Closes and reopens all log files. If binary logging is
              enabled, the sequence number of the binary log file is
              incremented by one relative to the previous file. On Unix,
              this is the same thing as sending a
              <code class="literal">SIGHUP</code> signal to the
              <span><strong class="command">mysqld</strong></span> server (except on some Mac OS X
              10.3 versions where <span><strong class="command">mysqld</strong></span> ignores
              <code class="literal">SIGHUP</code> and <code class="literal">SIGQUIT</code>).
            </p><p>
              If the server was started with the
              <code class="option">--log-error</code> option, <code class="literal">FLUSH
              LOGS</code> causes it to rename the current error log
              file with a suffix of <code class="literal">-old</code> and create a
              new empty log file. No renaming occurs if the
              <code class="option">--log-error</code> option was not given.
            </p></li><li><p>
              <code class="literal">MASTER</code>
              (<span class="emphasis"><em>DEPRECATED</em></span>). Deletes all binary
              logs, resets the binary log index file and creates a new
              binary log. <code class="literal">FLUSH MASTER</code> is deprecated
              in favor of <code class="literal">RESET MASTER</code>, and is
              supported for backwards compatibility only. See
              <a href="mysqlqb_statements.html#reset-master" title="RESET MASTER Syntax"><code class="literal">RESET MASTER</code> Syntax</a>.
            </p></li><li><p>
              <code class="literal">PRIVILEGES</code>
            </p><p>
              Reloads the privileges from the grant tables in the
              <code class="literal">mysql</code> database.
            </p></li><li><p>
              <code class="literal">QUERY CACHE</code>
            </p><p>
              Defragment the query cache to better utilize its memory.
              <code class="literal">FLUSH QUERY CACHE</code> does not remove any
              queries from the cache, unlike <code class="literal">RESET QUERY
              CACHE</code>.
            </p></li><li><p>
              <code class="literal">SLAVE</code>
              (<span class="emphasis"><em>DEPRECATED</em></span>). Resets all replication
              slave parameters, including relay log files and
              replication position in the master's binary logs.
              <code class="literal">FLUSH SLAVE</code> is deprecated in favour of
              <code class="literal">RESET SLAVE</code>, and is supported for
              backwards compatibility only. See
              <a href="mysqlqb_statements.html#reset-slave" title="RESET SLAVE Syntax"><code class="literal">RESET SLAVE</code> Syntax</a>.
            </p></li><li><p>
              <code class="literal">STATUS</code>
            </p><p>
              This option adds the current thread's session status
              variable values to the global values and resets the
              session values to zero. It also resets the counters for
              key caches (default and named) to zero and sets
              <code class="literal">Max_used_conections</code> to the current
              number of open connections. This is something you should
              use only when debugging a query. See
              <a href="http://dev.mysql.com/doc/refman/5.1/en/bug-reports.html" target="_top">How to Report Bugs or Problems</a>.
            </p></li><li><p>
              <code class="literal">{TABLE | TABLES}
              [<em class="replaceable"><code>tbl_name</code></em> [,
              <em class="replaceable"><code>tbl_name</code></em>] ...]</code>
            </p><p>
              When no tables are named, closes all open tables and
              forces all tables in use to be closed. This also flushes
              the query cache. With one or more table names, flushes
              only the given tables. <code class="literal">FLUSH TABLES</code>
              also removes all query results from the query cache, like
              the <code class="literal">RESET QUERY CACHE</code> statement.
            </p></li><li><p>
              <code class="literal">TABLES WITH READ LOCK</code>
            </p><p>
              Closes all open tables and locks all tables for all
              databases with a read lock until you explicitly release
              the lock by executing <code class="literal">UNLOCK TABLES</code>.
              This is very convenient way to get backups if you have a
              filesystem such as Veritas that can take snapshots in
              time.
            </p><p>
              <code class="literal">FLUSH TABLES WITH READ LOCK</code> acquires a
              global read lock and not table locks, so it is not subject
              to the same behavior as <code class="literal">LOCK TABLES</code> and
              <code class="literal">UNLOCK TABLES</code> with respect to table
              locking and implicit commits:
            </p><div class="itemizedlist"><ul type="circle"><li><p>
                  <code class="literal">UNLOCK TABLES</code> commits a transaction
                  only if any tables currently have been locked with
                  <code class="literal">LOCK TABLES</code>. This does not occur
                  for <code class="literal">UNLOCK TABLES</code> following
                  <code class="literal">FLUSH TABLES WITH READ LOCK</code> because
                  the latter statement does not acquire table-level
                  locks.
                </p></li><li><p>
                  Beginning a transaction causes table locks acquired
                  with <code class="literal">LOCK TABLES</code> to be released, as
                  though you had executed <code class="literal">UNLOCK
                  TABLES</code>. Beginning a transaction does not
                  release a global read lock acquired with
                  <code class="literal">FLUSH TABLES WITH READ LOCK</code>.
                </p></li></ul></div></li><li><p>
              <code class="literal">USER_RESOURCES</code>
            </p><p>
              Resets all per-hour user resources to zero. This enables
              clients that have reached their hourly connection, query,
              or update limits to resume activity immediately.
              <code class="literal">FLUSH USER_RESOURCES</code> does not apply to
              the limit on maximum simultaneous connections. See
              <a href="mysqlqb_statements.html#grant" title="GRANT Syntax"><code class="literal">GRANT</code> Syntax</a>.
            </p></li></ul></div><p>
          <code class="literal">FLUSH</code> statements are written to the binary
          log unless the optional <code class="literal">NO_WRITE_TO_BINLOG</code>
          keyword (or its alias <code class="literal">LOCAL</code>) is used. This
          is done so that <code class="literal">FLUSH</code> statements used on a
          MySQL server acting as a replication master will be replicated
          by default to the replication slave.
        </p><p>
          <span class="bold"><strong>Note</strong></span>: <code class="literal">FLUSH
          LOGS</code>, <code class="literal">FLUSH MASTER</code>,
          <code class="literal">FLUSH SLAVE</code>, and <code class="literal">FLUSH TABLES WITH
          READ LOCK</code> are not logged in any case because they
          would cause problems if replicated to a slave.
        </p><p>
          You can also access some of these statements with the
          <span><strong class="command">mysqladmin</strong></span> utility, using the
          <code class="literal">flush-hosts</code>, <code class="literal">flush-logs</code>,
          <code class="literal">flush-privileges</code>,
          <code class="literal">flush-status</code>, or
          <code class="literal">flush-tables</code> commands.
        </p><p>
          Using <code class="literal">FLUSH</code> statements within stored
          functions or triggers is not supported in MySQL
          5.0. However, you may use
          <code class="literal">FLUSH</code> in stored procedures, so long as
          these are not called from stored functions or triggers. See
          <a href="http://dev.mysql.com/doc/refman/5.0/en/routine-restrictions.html" target="_top">Restrictions on Stored Routines and Triggers</a>.
        </p><p>
          See also <a href="mysqlqb_statements.html#reset" title="RESET Syntax"><code class="literal">RESET</code> Syntax</a>, for information about how
          the <code class="literal">RESET</code> statement is used with
          replication.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="kill"></a><code class="literal">KILL</code> Syntax</h4></div></div></div><a id="id2900986" class="indexterm"></a><a id="id2900993" class="indexterm"></a><pre class="programlisting">KILL [CONNECTION | QUERY] <em class="replaceable"><code>thread_id</code></em>
</pre><p>
          Each connection to <span><strong class="command">mysqld</strong></span> runs in a
          separate thread. You can see which threads are running with
          the <code class="literal">SHOW PROCESSLIST</code> statement and kill a
          thread with the <code class="literal">KILL
          <em class="replaceable"><code>thread_id</code></em></code> statement.
        </p><p>
          In MySQL 5.0.0, <code class="literal">KILL</code> allows the optional
          <code class="literal">CONNECTION</code> or <code class="literal">QUERY</code>
          modifier:
        </p><div class="itemizedlist"><ul type="disc"><li><p>
              <code class="literal">KILL CONNECTION</code> is the same as
              <code class="literal">KILL</code> with no modifier: It terminates
              the connection associated with the given
              <em class="replaceable"><code>thread_id</code></em>.
            </p></li><li><p>
              <code class="literal">KILL QUERY</code> terminates the statement
              that the connection is currently executing, but leaves the
              connection itself intact.
            </p></li></ul></div><p>
          If you have the <code class="literal">PROCESS</code> privilege, you can
          see all threads. If you have the <code class="literal">SUPER</code>
          privilege, you can kill all threads and statements. Otherwise,
          you can see and kill only your own threads and statements.
        </p><p>
          You can also use the <span><strong class="command">mysqladmin processlist</strong></span>
          and <span><strong class="command">mysqladmin kill</strong></span> commands to examine and
          kill threads.
        </p><p>
          <span class="bold"><strong>Note</strong></span>: You cannot use
          <code class="literal">KILL</code> with the Embedded MySQL Server
          library, because the embedded server merely runs inside the
          threads of the host application. It does not create any
          connection threads of its own.
        </p><p>
          When you use <code class="literal">KILL</code>, a thread-specific kill
          flag is set for the thread. In most cases, it might take some
          time for the thread to die, because the kill flag is checked
          only at specific intervals:
        </p><div class="itemizedlist"><ul type="disc"><li><p>
              In <code class="literal">SELECT</code>, <code class="literal">ORDER BY</code>
              and <code class="literal">GROUP BY</code> loops, the flag is checked
              after reading a block of rows. If the kill flag is set,
              the statement is aborted.
            </p></li><li><p>
              During <code class="literal">ALTER TABLE</code>, the kill flag is
              checked before each block of rows are read from the
              original table. If the kill flag was set, the statement is
              aborted and the temporary table is deleted.
            </p></li><li><p>
              During <code class="literal">UPDATE</code> or
              <code class="literal">DELETE</code> operations, the kill flag is
              checked after each block read and after each updated or
              deleted row. If the kill flag is set, the statement is
              aborted. Note that if you are not using transactions, the
              changes are not rolled back.
            </p></li><li><p>
              <code class="literal">GET_LOCK()</code> aborts and returns
              <code class="literal">NULL</code>.
            </p></li><li><p>
              An <code class="literal">INSERT DELAYED</code> thread quickly
              flushes (inserts) all rows it has in memory and then
              terminates.
            </p></li><li><p>
              If the thread is in the table lock handler (state:
              <code class="literal">Locked</code>), the table lock is quickly
              aborted.
            </p></li><li><p>
              If the thread is waiting for free disk space in a write
              call, the write is aborted with a “<span class="quote">disk full</span>”
              error message.
            </p></li><li><p>
              <span class="bold"><strong>Warning</strong></span>: Killing a
              <code class="literal">REPAIR TABLE</code> or <code class="literal">OPTIMIZE
              TABLE</code> operation on a <code class="literal">MyISAM</code>
              table results in a table that is corrupted and unusable.
              Any reads or writes to such a table fail until you
              optimize or repair it again (without interruption).
            </p></li></ul></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="load-index"></a><code class="literal">LOAD INDEX INTO CACHE</code> Syntax</h4></div></div></div><pre class="programlisting">LOAD INDEX INTO CACHE
  <em class="replaceable"><code>tbl_index_list</code></em> [, <em class="replaceable"><code>tbl_index_list</code></em>] ...

<em class="replaceable"><code>tbl_index_list</code></em>:
  <em class="replaceable"><code>tbl_name</code></em>
    [[INDEX|KEY] (<em class="replaceable"><code>index_name</code></em>[, <em class="replaceable"><code>index_name</code></em>] ...)]
    [IGNORE LEAVES]
</pre><p>
          The <code class="literal">LOAD INDEX INTO CACHE</code> statement
          preloads a table index into the key cache to which it has been
          assigned by an explicit <code class="literal">CACHE INDEX</code>
          statement, or into the default key cache otherwise.
          <code class="literal">LOAD INDEX INTO CACHE</code> is used only for
          <code class="literal">MyISAM</code> tables.
        </p><p>
          The <code class="literal">IGNORE LEAVES</code> modifier causes only
          blocks for the non-leaf nodes of the index to be preloaded.
        </p><p>
          The following statement preloads nodes (index blocks) of
          indexes for the tables <code class="literal">t1</code> and
          <code class="literal">t2</code>:
        </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>LOAD INDEX INTO CACHE t1, t2 IGNORE LEAVES;</code></strong>
+---------+--------------+----------+----------+
| Table   | Op           | Msg_type | Msg_text |
+---------+--------------+----------+----------+
| test.t1 | preload_keys | status   | OK       |
| test.t2 | preload_keys | status   | OK       |
+---------+--------------+----------+----------+
</pre><p>
          This statement preloads all index blocks from
          <code class="literal">t1</code>. It preloads only blocks for the
          non-leaf nodes from <code class="literal">t2</code>.
        </p><p>
          The syntax of <code class="literal">LOAD INDEX INTO CACHE</code> enables
          you to specify that only particular indexes from a table
          should be preloaded. The current implementation preloads all
          the table's indexes into the cache, so there is no reason to
          specify anything other than the table name.
        </p><p>
          <code class="literal">LOAD INDEX INTO CACHE</code> fails unless all
          indexes in a table have the same block size. You can determine
          index block sizes for a table by using <span><strong class="command">myisamchk
          -dv</strong></span> and checking the <code class="literal">Blocksize</code>
          column.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="reset"></a><code class="literal">RESET</code> Syntax</h4></div></div></div><pre class="programlisting">RESET <em class="replaceable"><code>reset_option</code></em> [, <em class="replaceable"><code>reset_option</code></em>] ...
</pre><p>
          The <code class="literal">RESET</code> statement is used to clear the
          state of various server operations. You must have the
          <code class="literal">RELOAD</code> privilege to execute
          <code class="literal">RESET</code>.
        </p><p>
          <code class="literal">RESET</code> acts as a stronger version of the
          <code class="literal">FLUSH</code> statement. See
          <a href="mysqlqb_statements.html#flush" title="FLUSH Syntax"><code class="literal">FLUSH</code> Syntax</a>.
        </p><p>
          <em class="replaceable"><code>reset_option</code></em> can be any of the
          following:
        </p><div class="itemizedlist"><ul type="disc"><li><p>
              <code class="literal">MASTER</code>
            </p><p>
              Deletes all binary logs listed in the index file, resets
              the binary log index file to be empty, and creates a new
              binary log file. (Known as <code class="literal">FLUSH MASTER</code>
              in versions of MySQL before 3.23.26.) See
              <a href="mysqlqb_statements.html#replication-master-sql" title="SQL Statements for Controlling Master Servers">SQL Statements for Controlling Master Servers</a>.
            </p></li><li><p>
              <code class="literal">QUERY CACHE</code>
            </p><p>
              Removes all query results from the query cache.
            </p></li><li><p>
              <code class="literal">SLAVE</code>
            </p><p>
              Makes the slave forget its replication position in the
              master binary logs. Also resets the relay log by deleting
              any existing relay log files and beginning a new one.
              (Known as <code class="literal">FLUSH SLAVE</code> in versions of
              MySQL before 3.23.26.) See
              <a href="mysqlqb_statements.html#replication-slave-sql" title="SQL Statements for Controlling Slave Servers">SQL Statements for Controlling Slave Servers</a>.
            </p></li></ul></div></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="replication-sql"></a>Replication Statements</h2></div></div></div><div class="toc"><dl><dt><span class="section"><a href="mysqlqb_statements.html#replication-master-sql">SQL Statements for Controlling Master Servers</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#replication-slave-sql">SQL Statements for Controlling Slave Servers</a></span></dt></dl></div><p>
      This section describes SQL statements related to replication. One
      group of statements is used for controlling master servers. The
      other is used for controlling slave servers.
    </p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="replication-master-sql"></a>SQL Statements for Controlling Master Servers</h3></div></div></div><div class="toc"><dl><dt><span class="section"><a href="mysqlqb_statements.html#purge-master-logs"><code class="literal">PURGE MASTER LOGS</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#reset-master"><code class="literal">RESET MASTER</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#set-sql-log-bin"><code class="literal">SET SQL_LOG_BIN</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#show-binlog-events"><code class="literal">SHOW BINLOG EVENTS</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#show-binary-logs"><code class="literal">SHOW BINARY LOGS</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#show-master-status"><code class="literal">SHOW MASTER STATUS</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#show-slave-hosts"><code class="literal">SHOW SLAVE HOSTS</code> Syntax</a></span></dt></dl></div><a id="id2901637" class="indexterm"></a><a id="id2901647" class="indexterm"></a><a id="id2901658" class="indexterm"></a><p>
        Replication can be controlled through the SQL interface. This
        section discusses statements for managing master replication
        servers. <a href="mysqlqb_statements.html#replication-slave-sql" title="SQL Statements for Controlling Slave Servers">SQL Statements for Controlling Slave Servers</a>, discusses
        statements for managing slave servers.
      </p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="purge-master-logs"></a><code class="literal">PURGE MASTER LOGS</code> Syntax</h4></div></div></div><a id="id2901690" class="indexterm"></a><pre class="programlisting">PURGE {MASTER | BINARY} LOGS TO '<em class="replaceable"><code>log_name</code></em>'
PURGE {MASTER | BINARY} LOGS BEFORE '<em class="replaceable"><code>date</code></em>'
</pre><p>
          Deletes all the binary logs listed in the log index prior to
          the specified log or date. The logs also are removed from the
          list recorded in the log index file, so that the given log
          becomes the first.
        </p><p>
          Example:
        </p><pre class="programlisting">PURGE MASTER LOGS TO 'mysql-bin.010';
PURGE MASTER LOGS BEFORE '2003-04-02 22:46:26';
</pre><p>
          The <code class="literal">BEFORE</code> variant's
          <em class="replaceable"><code>date</code></em> argument can be in
          <code class="literal">'YYYY-MM-DD hh:mm:ss'</code> format.
          <code class="literal">MASTER</code> and <code class="literal">BINARY</code> are
          synonyms.
        </p><p>
          This statement is safe to run while slaves are replicating.
          You do not need to stop them. If you have an active slave that
          currently is reading one of the logs you are trying to delete,
          this statement does nothing and fails with an error. However,
          if a slave is dormant and you happen to purge one of the logs
          it has yet to read, the slave will be unable to replicate
          after it comes up.
        </p><p>
          To safely purge logs, follow this procedure:
        </p><div class="orderedlist"><ol type="1"><li><p>
              On each slave server, use <code class="literal">SHOW SLAVE
              STATUS</code> to check which log it is reading.
            </p></li><li><p>
              Obtain a listing of the binary logs on the master server
              with <code class="literal">SHOW BINARY LOGS</code>.
            </p></li><li><p>
              Determine the earliest log among all the slaves. This is
              the target log. If all the slaves are up to date, this is
              the last log on the list.
            </p></li><li><p>
              Make a backup of all the logs you are about to delete.
              (This step is optional, but always advisable.)
            </p></li><li><p>
              Purge all logs up to but not including the target log.
            </p></li></ol></div><p>
          You can also set the <code class="literal">expire_logs_days</code>
          system variable to expire binary log files automatically after
          a given number of days (see
          <a href="http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html" target="_top">System Variables</a>). If you are using
          replication, you should set the variable no lower than the
          maximum number of days your slaves might lag behind the
          master.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="reset-master"></a><code class="literal">RESET MASTER</code> Syntax</h4></div></div></div><a id="id2901880" class="indexterm"></a><pre class="programlisting">RESET MASTER
</pre><p>
          Deletes all binary logs listed in the index file, resets the
          binary log index file to be empty, and creates a new binary
          log file.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="set-sql-log-bin"></a><code class="literal">SET SQL_LOG_BIN</code> Syntax</h4></div></div></div><a id="id2901935" class="indexterm"></a><pre class="programlisting">SET SQL_LOG_BIN = {0|1}
</pre><p>
          Disables or enables binary logging for the current connection
          (<code class="literal">SQL_LOG_BIN</code> is a session variable) if the
          client has the <code class="literal">SUPER</code> privilege. The
          statement is refused with an error if the client does not have
          that privilege.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="show-binlog-events"></a><code class="literal">SHOW BINLOG EVENTS</code> Syntax</h4></div></div></div><a id="id2901999" class="indexterm"></a><pre class="programlisting">SHOW BINLOG EVENTS
   [IN '<em class="replaceable"><code>log_name</code></em>'] [FROM <em class="replaceable"><code>pos</code></em>] [LIMIT [<em class="replaceable"><code>offset</code></em>,] <em class="replaceable"><code>row_count</code></em>]
</pre><p>
          Shows the events in the binary log. If you do not specify
          <code class="literal">'<em class="replaceable"><code>log_name</code></em>'</code>, the
          first binary log is displayed.
        </p><p>
          The <code class="literal">LIMIT</code> clause has the same syntax as for
          the <code class="literal">SELECT</code> statement. See
          <a href="mysqlqb_statements.html#select" title="SELECT Syntax"><code class="literal">SELECT</code> Syntax</a>.
        </p><p>
          <span class="bold"><strong>Note</strong></span>: Issuing a <code class="literal">SHOW
          BINLOG EVENTS</code> with no <code class="literal">LIMIT</code>
          clause could start a very time- and resource-consuming process
          because the server returns to the client the complete contents
          of the binary log (which includes all statements executed by
          the server that modify data). As an alternative to
          <code class="literal">SHOW BINLOG EVENTS</code>, use the
          <span><strong class="command">mysqlbinlog</strong></span> utility to save the binary log
          to a text file for later examination and analysis. See
          <a href="http://dev.mysql.com/doc/refman/5.0/en/mysqlbinlog.html" target="_top">mysqlbinlog</a>.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="show-binary-logs"></a><code class="literal">SHOW BINARY LOGS</code> Syntax</h4></div></div></div><a id="id2902130" class="indexterm"></a><a id="id2902137" class="indexterm"></a><pre class="programlisting">SHOW BINARY LOGS
SHOW MASTER LOGS
</pre><p>
          Lists the binary log files on the server. This statement is
          used as part of the procedure described in
          <a href="mysqlqb_statements.html#purge-master-logs" title="PURGE MASTER LOGS Syntax"><code class="literal">PURGE MASTER LOGS</code> Syntax</a>, that shows how to
          determine which logs can be purged.
        </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SHOW BINARY LOGS;</code></strong>
+---------------+-----------+
| Log_name      | File_size |
+---------------+-----------+
| binlog.000015 |    724935 |
| binlog.000016 |    733481 |
+---------------+-----------+
</pre><p>
          <code class="literal">SHOW MASTER LOGS</code> is equivalent to
          <code class="literal">SHOW BINARY LOGS</code>. The
          <code class="literal">File_size</code> column is displayed as of MySQL
          5.0.7.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="show-master-status"></a><code class="literal">SHOW MASTER STATUS</code> Syntax</h4></div></div></div><a id="id2902230" class="indexterm"></a><pre class="programlisting">SHOW MASTER STATUS
</pre><p>
          Provides status information about the binary log files of the
          master. Example:
        </p><pre class="programlisting">mysql &gt; <strong class="userinput"><code>SHOW MASTER STATUS;</code></strong>
+---------------+----------+--------------+------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+---------------+----------+--------------+------------------+
| mysql-bin.003 | 73       | test         | manual,mysql     |
+---------------+----------+--------------+------------------+
</pre></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="show-slave-hosts"></a><code class="literal">SHOW SLAVE HOSTS</code> Syntax</h4></div></div></div><a id="id2902297" class="indexterm"></a><pre class="programlisting">          SHOW SLAVE HOSTS
        </pre><p>
          Displays a list of replication slaves currently registered
          with the master. Only slaves started with the
          <code class="option">--report-host=<em class="replaceable"><code>slave_name</code></em></code>
          option are visible in this list.
        </p><p>
          The list is displayed on any server (not just the master
          server). The output looks like this:

</p><pre class="programlisting">            mysql&gt; <strong class="userinput"><code>SHOW SLAVE HOSTS</code></strong>;
            +------------+-----------+------+-----------+
            | Server_id  | Host      | Port | Master_id |
            +------------+-----------+------+-----------+
            |  192168010 | iconnect2 | 3306 | 192168011 |
            | 1921680101 | athena    | 3306 | 192168011 |
            +------------+-----------+------+-----------+
          </pre><p>

          </p><div class="itemizedlist"><ul type="disc"><li><p>
                <code class="literal">Server_id</code>: The unique server ID of
                the slave server, as configured in the server's option
                file, or on the command line with
                <code class="option">--server-id=<em class="replaceable"><code>value</code></em>
                </code>.
              </p></li><li><p>
                <code class="literal">Host</code>: The host name of the slave
                server, as configured in the server's option file, or on
                the command line with
                <code class="option">--report-host=<em class="replaceable"><code>value</code></em></code>.
                Note that this can differ from the machine name as
                configured in the operating system.
              </p></li><li><p>
                <code class="literal">Port</code>: The port the slave server is
                listening on.
              </p></li><li><p>
                <code class="literal">Master_id</code>: The unique server ID of
                the master server that the slave server is replicating
                from.
              </p></li></ul></div><p>

          Some MySQL versions report another variable,
          <code class="literal">Rpl_recovery_rank</code>. This variable was never
          used, and was eventually removed.
        </p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="replication-slave-sql"></a>SQL Statements for Controlling Slave Servers</h3></div></div></div><div class="toc"><dl><dt><span class="section"><a href="mysqlqb_statements.html#change-master-to"><code class="literal">CHANGE MASTER TO</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#load-data-from-master"><code class="literal">LOAD DATA FROM MASTER</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#load-table-from-master"><code class="literal">LOAD TABLE <em class="replaceable"><code>tbl_name</code></em> FROM
          MASTER</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#master-pos-wait"><code class="literal">MASTER_POS_WAIT()</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#reset-slave"><code class="literal">RESET SLAVE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#set-global-sql-slave-skip-counter"><code class="literal">SET GLOBAL SQL_SLAVE_SKIP_COUNTER</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#show-slave-status"><code class="literal">SHOW SLAVE STATUS</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#start-slave"><code class="literal">START SLAVE</code> Syntax</a></span></dt><dt><span class="section"><a href="mysqlqb_statements.html#stop-slave"><code class="literal">STOP SLAVE</code> Syntax</a></span></dt></dl></div><a id="id2902451" class="indexterm"></a><a id="id2902462" class="indexterm"></a><a id="id2902472" class="indexterm"></a><p>
        Replication can be controlled through the SQL interface. This
        section discusses statements for managing slave replication
        servers. <a href="mysqlqb_statements.html#replication-master-sql" title="SQL Statements for Controlling Master Servers">SQL Statements for Controlling Master Servers</a>, discusses
        statements for managing master servers.
      </p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="change-master-to"></a><code class="literal">CHANGE MASTER TO</code> Syntax</h4></div></div></div><a id="id2902504" class="indexterm"></a><pre class="programlisting">CHANGE MASTER TO <em class="replaceable"><code>master_def</code></em> [, <em class="replaceable"><code>master_def</code></em>] ...

<em class="replaceable"><code>master_def</code></em>:
    MASTER_HOST = '<em class="replaceable"><code>host_name</code></em>'
  | MASTER_USER = '<em class="replaceable"><code>user_name</code></em>'
  | MASTER_PASSWORD = '<em class="replaceable"><code>password</code></em>'
  | MASTER_PORT = <em class="replaceable"><code>port_num</code></em>
  | MASTER_CONNECT_RETRY = <em class="replaceable"><code>count</code></em>
  | MASTER_LOG_FILE = '<em class="replaceable"><code>master_log_name</code></em>'
  | MASTER_LOG_POS = <em class="replaceable"><code>master_log_pos</code></em>
  | RELAY_LOG_FILE = '<em class="replaceable"><code>relay_log_name</code></em>'
  | RELAY_LOG_POS = <em class="replaceable"><code>relay_log_pos</code></em>
  | MASTER_SSL = {0|1}
  | MASTER_SSL_CA = '<em class="replaceable"><code>ca_file_name</code></em>'
  | MASTER_SSL_CAPATH = '<em class="replaceable"><code>ca_directory_name</code></em>'
  | MASTER_SSL_CERT = '<em class="replaceable"><code>cert_file_name</code></em>'
  | MASTER_SSL_KEY = '<em class="replaceable"><code>key_file_name</code></em>'
  | MASTER_SSL_CIPHER = '<em class="replaceable"><code>cipher_list</code></em>'
</pre><p>
          <code class="literal">CHANGE MASTER TO</code> changes the parameters
          that the slave server uses for connecting to and communicating
          with the master server. It also updates the contents of the
          <code class="filename">master.info</code> and
          <code class="filename">relay-log.info</code> files.
        </p><p>
          <code class="literal">MASTER_USER</code>,
          <code class="literal">MASTER_PASSWORD</code>,
          <code class="literal">MASTER_SSL</code>,
          <code class="literal">MASTER_SSL_CA</code>,
          <code class="literal">MASTER_SSL_CAPATH</code>,
          <code class="literal">MASTER_SSL_CERT</code>,
          <code class="literal">MASTER_SSL_KEY</code>, and
          <code class="literal">MASTER_SSL_CIPHER</code> provide information to
          the slave about how to connect to its master.
        </p><p>
          The SSL options (<code class="literal">MASTER_SSL</code>,
          <code class="literal">MASTER_SSL_CA</code>,
          <code class="literal">MASTER_SSL_CAPATH</code>,
          <code class="literal">MASTER_SSL_CERT</code>,
          <code class="literal">MASTER_SSL_KEY</code>, and
          <code class="literal">MASTER_SSL_CIPHER</code>) can be changed even on
          slaves that are compiled without SSL support. They are saved
          to the <code class="filename">master.info</code> file, but are ignored
          unless you use a server that has SSL support enabled.
        </p><p>
          If you don't specify a given parameter, it keeps its old
          value, except as indicated in the following discussion. For
          example, if the password to connect to your MySQL master has
          changed, you just need to issue these statements to tell the
          slave about the new password:
        </p><pre class="programlisting">STOP SLAVE; -- if replication was running
CHANGE MASTER TO MASTER_PASSWORD='new3cret';
START SLAVE; -- if you want to restart replication
</pre><p>
          There is no need to specify the parameters that do not change
          (host, port, user, and so forth).
        </p><p>
          <code class="literal">MASTER_HOST</code> and
          <code class="literal">MASTER_PORT</code> are the hostname (or IP
          address) of the master host and its TCP/IP port. Note that if
          <code class="literal">MASTER_HOST</code> is equal to
          <code class="literal">localhost</code>, then, like in other parts of
          MySQL, the port number might be ignored (if Unix socket files
          can be used, for example).
        </p><p>
          If you specify <code class="literal">MASTER_HOST</code> or
          <code class="literal">MASTER_PORT</code>, the slave assumes that the
          master server is different from before (even if you specify a
          host or port value that is the same as the current value.) In
          this case, the old values for the master binary log name and
          position are considered no longer applicable, so if you do not
          specify <code class="literal">MASTER_LOG_FILE</code> and
          <code class="literal">MASTER_LOG_POS</code> in the statement,
          <code class="literal">MASTER_LOG_FILE=''</code> and
          <code class="literal">MASTER_LOG_POS=4</code> are silently appended to
          it.
        </p><p>
          <code class="literal">MASTER_LOG_FILE</code> and
          <code class="literal">MASTER_LOG_POS</code> are the coordinates at which
          the slave I/O thread should begin reading from the master the
          next time the thread starts. If you specify either of them,
          you cannot specify <code class="literal">RELAY_LOG_FILE</code> or
          <code class="literal">RELAY_LOG_POS</code>. If neither of
          <code class="literal">MASTER_LOG_FILE</code> or
          <code class="literal">MASTER_LOG_POS</code> are specified, the slave
          uses the last coordinates of the <span class="emphasis"><em>slave SQL
          thread</em></span> before <code class="literal">CHANGE MASTER</code> was
          issued. This ensures that there is no discontinuity in
          replication, even if the slave SQL thread was late compared to
          the slave I/O thread, when you merely want to change, say, the
          password to use.
        </p><p>
          <code class="literal">CHANGE MASTER</code> <span class="emphasis"><em>deletes all relay
          log files</em></span> and starts a new one, unless you specify
          <code class="literal">RELAY_LOG_FILE</code> or
          <code class="literal">RELAY_LOG_POS</code>. In that case, relay logs are
          kept; the <code class="literal">relay_log_purge</code> global variable
          is set silently to 0.
        </p><p>
          <code class="literal">CHANGE MASTER</code> is useful for setting up a
          slave when you have the snapshot of the master and have
          recorded the log and the offset corresponding to it. After
          loading the snapshot into the slave, you can run
          <code class="literal">CHANGE MASTER TO
          MASTER_LOG_FILE='<em class="replaceable"><code>log_name_on_master</code></em>',
          MASTER_LOG_POS=<em class="replaceable"><code>log_offset_on_master</code></em></code>
          on the slave.
        </p><p>
          The following example changes the master and master's binary
          log coordinates. This is used when you want to set up the
          slave to replicate the master:
        </p><pre class="programlisting">CHANGE MASTER TO
  MASTER_HOST='master2.mycompany.com',
  MASTER_USER='replication',
  MASTER_PASSWORD='bigs3cret',
  MASTER_PORT=3306,
  MASTER_LOG_FILE='master2-bin.001',
  MASTER_LOG_POS=4,
  MASTER_CONNECT_RETRY=10;
</pre><p>
          The next example shows an operation that is less frequently
          employed. It is used when the slave has relay logs that you
          want it to execute again for some reason. To do this, the
          master need not be reachable. You need only use
          <code class="literal">CHANGE MASTER TO</code> and start the SQL thread
          (<code class="literal">START SLAVE SQL_THREAD</code>):
        </p><pre class="programlisting">CHANGE MASTER TO
  RELAY_LOG_FILE='slave-relay-bin.006',
  RELAY_LOG_POS=4025;
</pre><p>
          You can even use the second operation in a non-replication
          setup with a standalone, non-slave server for recovery
          following a crash. Suppose that your server has crashed and
          you have restored a backup. You want to replay the server's
          own binary logs (not relay logs, but regular binary logs),
          named (for example) <code class="filename">myhost-bin.*</code>. First,
          make a backup copy of these binary logs in some safe place, in
          case you don't exactly follow the procedure below and
          accidentally have the server purge the binary logs. Use
          <code class="literal">SET GLOBAL relay_log_purge=0</code> for additional
          safety. Then start the server without the
          <code class="option">--log-bin</code> option, Instead, use the
          <code class="option">--replicate-same-server-id</code>,
          <code class="option">--relay-log=myhost-bin</code> (to make the server
          believe that these regular binary logs are relay logs) and
          <code class="option">--skip-slave-start</code> options. After the server
          starts, issue these statements:
        </p><pre class="programlisting">CHANGE MASTER TO
  RELAY_LOG_FILE='myhost-bin.153',
  RELAY_LOG_POS=410,
  MASTER_HOST='some_dummy_string';
START SLAVE SQL_THREAD;
</pre><p>
          The server reads and executes its own binary logs, thus
          achieving crash recovery. Once the recovery is finished, run
          <code class="literal">STOP SLAVE</code>, shut down the server, delete
          the <code class="filename">master.info</code> and
          <code class="filename">relay-log.info</code> files, and restart the
          server with its original options.
        </p><p>
          Specifying the <code class="literal">MASTER_HOST</code> option (even
          with a dummy value) is required to make the server think it is
          a slave.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="load-data-from-master"></a><code class="literal">LOAD DATA FROM MASTER</code> Syntax</h4></div></div></div><a id="id2902991" class="indexterm"></a><pre class="programlisting">LOAD DATA FROM MASTER
</pre><p class="deprecated"><span class="bold"><strong>This feature is deprecated. We recommend not using it anymore. It is subject to removal in a future version of MySQL.</strong></span></p><p>
          Since the current implementation of <code class="literal">LOAD DATA FROM
          MASTER</code> and <code class="literal">LOAD TABLE FROM MASTER</code>
          is very limited, these statements are deprecated in versions
          4.1 of MySQL and above. We will introduce a more advanced
          technique (called “<span class="quote">online backup</span>”) in a future
          version. That technique will have the additional advantage of
          working with more storage engines.
        </p><p>
          For MySQL 5.1 and earlier, the recommended alternative
          solution to using <code class="literal">LOAD DATA FROM MASTER</code> or
          <code class="literal">LOAD TABLE FROM MASTER</code> is using
          <span><strong class="command">mysqldump</strong></span> or
          <span><strong class="command">mysqlhotcopy</strong></span>. The latter requires Perl and
          two Perl modules (<code class="literal">DBI</code> and
          <code class="literal">DBD:mysql</code>) and works for
          <code class="literal">MyISAM</code> and <code class="literal">ARCHIVE</code>
          tables only. With <span><strong class="command">mysqldump</strong></span>, you can create
          SQL dumps on the master and pipe (or copy) these to a
          <span><strong class="command">mysql</strong></span> client on the slave. This has the
          advantage of working for all storage engines, but can be quite
          slow, since it works using <code class="literal">SELECT</code>.
        </p><p>
          This statement takes a snapshot of the master and copies it to
          the slave. It updates the values of
          <code class="literal">MASTER_LOG_FILE</code> and
          <code class="literal">MASTER_LOG_POS</code> so that the slave starts
          replicating from the correct position. Any table and database
          exclusion rules specified with the
          <code class="option">--replicate-*-do-*</code> and
          <code class="option">--replicate-*-ignore-*</code> options are honored.
          <code class="option">--replicate-rewrite-db</code> is
          <span class="emphasis"><em>not</em></span> taken into account because a user
          could use this option to set up a non-unique mapping such as
          <code class="option">--replicate-rewrite-db="db1-&gt;db3"</code> and
          <code class="option">--replicate-rewrite-db="db2-&gt;db3"</code>, which
          would confuse the slave when loading tables from the master.
        </p><p>
          Use of this statement is subject to the following conditions:
        </p><div class="itemizedlist"><ul type="disc"><li><p>
              It works only for <code class="literal">MyISAM</code> tables.
              Attempting to load a non-<code class="literal">MyISAM</code> table
              results in the following error:
            </p><pre class="programlisting">ERROR 1189 (08S01): Net error reading from master
</pre></li><li><p>
              It acquires a global read lock on the master while taking
              the snapshot, which prevents updates on the master during
              the load operation.
            </p></li></ul></div><p>
          If you are loading large tables, you might have to increase
          the values of <code class="literal">net_read_timeout</code> and
          <code class="literal">net_write_timeout</code> on both the master and
          slave servers. See <a href="http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html" target="_top">System Variables</a>.
        </p><p>
          Note that <code class="literal">LOAD DATA FROM MASTER</code> does
          <span class="emphasis"><em>not</em></span> copy any tables from the
          <code class="literal">mysql</code> database. This makes it easy to have
          different users and privileges on the master and the slave.
        </p><p>
          To use <code class="literal">LOAD DATA FROM MASTER</code>, the
          replication account that is used to connect to the master must
          have the <code class="literal">RELOAD</code> and
          <code class="literal">SUPER</code> privileges on the master and the
          <code class="literal">SELECT</code> privilege for all master tables you
          want to load. All master tables for which the user does not
          have the <code class="literal">SELECT</code> privilege are ignored by
          <code class="literal">LOAD DATA FROM MASTER</code>. This is because the
          master hides them from the user: <code class="literal">LOAD DATA FROM
          MASTER</code> calls <code class="literal">SHOW DATABASES</code> to
          know the master databases to load, but <code class="literal">SHOW
          DATABASES</code> returns only databases for which the user
          has some privilege. See <a href="mysqlqb_statements.html#show-databases" title="SHOW DATABASES Syntax"><code class="literal">SHOW DATABASES</code> Syntax</a>. On
          the slave side, the user that issues <code class="literal">LOAD DATA FROM
          MASTER</code> must have privileges for dropping and
          creating the databases and tables that are copied.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="load-table-from-master"></a><code class="literal">LOAD TABLE <em class="replaceable"><code>tbl_name</code></em> FROM
          MASTER</code> Syntax</h4></div></div></div><a id="id2903313" class="indexterm"></a><pre class="programlisting">LOAD TABLE <em class="replaceable"><code>tbl_name</code></em> FROM MASTER
</pre><p class="deprecated"><span class="bold"><strong>This feature is deprecated. We recommend not using it anymore. It is subject to removal in a future version of MySQL.</strong></span></p><p>
          Since the current implementation of <code class="literal">LOAD DATA FROM
          MASTER</code> and <code class="literal">LOAD TABLE FROM MASTER</code>
          is very limited, these statements are deprecated in versions
          4.1 of MySQL and above. We will introduce a more advanced
          technique (called “<span class="quote">online backup</span>”) in a future
          version. That technique will have the additional advantage of
          working with more storage engines.
        </p><p>
          For MySQL 5.1 and earlier, the recommended alternative
          solution to using <code class="literal">LOAD DATA FROM MASTER</code> or
          <code class="literal">LOAD TABLE FROM MASTER</code> is using
          <span><strong class="command">mysqldump</strong></span> or
          <span><strong class="command">mysqlhotcopy</strong></span>. The latter requires Perl and
          two Perl modules (<code class="literal">DBI</code> and
          <code class="literal">DBD:mysql</code>) and works for
          <code class="literal">MyISAM</code> and <code class="literal">ARCHIVE</code>
          tables only. With <span><strong class="command">mysqldump</strong></span>, you can create
          SQL dumps on the master and pipe (or copy) these to a
          <span><strong class="command">mysql</strong></span> client on the slave. This has the
          advantage of working for all storage engines, but can be quite
          slow, since it works using <code class="literal">SELECT</code>.
        </p><p>
          Transfers a copy of the table from the master to the slave.
          This statement is implemented mainly debugging <code class="literal">LOAD
          DATA FROM MASTER</code> operations. To use <code class="literal">LOAD
          TABLE</code>, the account used for connecting to the master
          server must have the <code class="literal">RELOAD</code> and
          <code class="literal">SUPER</code> privileges on the master and the
          <code class="literal">SELECT</code> privilege for the master table to
          load. On the slave side, the user that issues <code class="literal">LOAD
          TABLE FROM MASTER</code> must have privileges for dropping
          and creating the table.
        </p><p>
          The conditions for <code class="literal">LOAD DATA FROM MASTER</code>
          apply here as well. For example, <code class="literal">LOAD TABLE FROM
          MASTER</code> works only for <code class="literal">MyISAM</code>
          tables. The timeout notes for <code class="literal">LOAD DATA FROM
          MASTER</code> apply as well.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="master-pos-wait"></a><code class="literal">MASTER_POS_WAIT()</code> Syntax</h4></div></div></div><a id="id2903505" class="indexterm"></a><pre class="programlisting">SELECT MASTER_POS_WAIT('<em class="replaceable"><code>master_log_file</code></em>', <em class="replaceable"><code>master_log_pos</code></em>)
</pre><p>
          This is actually a function, not a statement. It is used to
          ensure that the slave has read and executed events up to a
          given position in the master's binary log. See
          <a href="mysqlqb_functions.html#miscellaneous-functions" title="Miscellaneous Functions">Miscellaneous Functions</a>, for a full
          description.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="reset-slave"></a><code class="literal">RESET SLAVE</code> Syntax</h4></div></div></div><a id="id2903547" class="indexterm"></a><pre class="programlisting">RESET SLAVE
</pre><p>
          <code class="literal">RESET SLAVE</code> makes the slave forget its
          replication position in the master's binary logs. This
          statement is meant to be used for a clean start: It deletes
          the <code class="filename">master.info</code> and
          <code class="filename">relay-log.info</code> files, all the relay logs,
          and starts a new relay log.
        </p><p>
          <span class="bold"><strong>Note</strong></span>: All relay logs are
          deleted, even if they have not been completely executed by the
          slave SQL thread. (This is a condition likely to exist on a
          replication slave if you have issued a <code class="literal">STOP
          SLAVE</code> statement or if the slave is highly loaded.)
        </p><p>
          Connection information stored in the
          <code class="filename">master.info</code> file is immediately reset
          using any values specified in the corresponding startup
          options. This information includes values such as master host,
          master port, master user, and master password. If the slave
          SQL thread was in the middle of replicating temporary tables
          when it was stopped, and <code class="literal">RESET SLAVE</code> is
          issued, these replicated temporary tables are deleted on the
          slave.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="set-global-sql-slave-skip-counter"></a><code class="literal">SET GLOBAL SQL_SLAVE_SKIP_COUNTER</code> Syntax</h4></div></div></div><a id="id2903651" class="indexterm"></a><pre class="programlisting">SET GLOBAL SQL_SLAVE_SKIP_COUNTER = <em class="replaceable"><code>N</code></em>
</pre><p>
          This statement skips the next <em class="replaceable"><code>N</code></em>
          events from the master. This is useful for recovering from
          replication stops caused by a statement.
        </p><p>
          This statement is valid only when the slave thread is not
          running. Otherwise, it produces an error.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="show-slave-status"></a><code class="literal">SHOW SLAVE STATUS</code> Syntax</h4></div></div></div><a id="id2903720" class="indexterm"></a><pre class="programlisting">SHOW SLAVE STATUS
</pre><p>
          This statement provides status information on essential
          parameters of the slave threads. If you issue this statement
          using the <span><strong class="command">mysql</strong></span> client, you can use a
          <code class="literal">\G</code> statement terminator rather than a
          semicolon to obtain a more readable vertical layout:
        </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SHOW SLAVE STATUS\G</code></strong>
*************************** 1. row ***************************
       Slave_IO_State: Waiting for master to send event
          Master_Host: localhost
          Master_User: root
          Master_Port: 3306
        Connect_Retry: 3
      Master_Log_File: gbichot-bin.005
  Read_Master_Log_Pos: 79
       Relay_Log_File: gbichot-relay-bin.005
        Relay_Log_Pos: 548
Relay_Master_Log_File: gbichot-bin.005
     Slave_IO_Running: Yes
    Slave_SQL_Running: Yes
      Replicate_Do_DB:
  Replicate_Ignore_DB:
           Last_Errno: 0
           Last_Error:
         Skip_Counter: 0
  Exec_Master_Log_Pos: 79
      Relay_Log_Space: 552
      Until_Condition: None
       Until_Log_File:
        Until_Log_Pos: 0
   Master_SSL_Allowed: No
   Master_SSL_CA_File:
   Master_SSL_CA_Path:
      Master_SSL_Cert:
    Master_SSL_Cipher:
       Master_SSL_Key:
Seconds_Behind_Master: 8
</pre><p>
          <code class="literal">SHOW SLAVE STATUS</code> returns the following
          fields:
        </p><div class="itemizedlist"><ul type="disc"><li><p>
              <code class="literal">Slave_IO_State</code>
            </p><p>
              A copy of the <code class="literal">State</code> field of the output
              of <code class="literal">SHOW PROCESSLIST</code> for the slave I/O
              thread. This tells you what the thread is doing: trying to
              connect to the master, waiting for events from the master,
              reconnecting to the master, and so on. Possible states are
              listed in
              <a href="http://dev.mysql.com/doc/refman/5.0/en/replication-implementation-details.html" target="_top">Replication Implementation Details</a>. It
              is necessary to check this field for older versions of
              MySQL (prior to 5.0.12) because in these versions the
              thread could be running while unsuccessfully trying to
              connect to the master; only this field makes you aware of
              the connection problem. The state of the SQL thread is not
              copied because it is simpler. If it is running, there is
              no problem; if it is not, you can find the error in the
              <code class="literal">Last_Error</code> field (described below).
            </p></li><li><p>
              <code class="literal">Master_Host</code>
            </p><p>
              The current master host.
            </p></li><li><p>
              <code class="literal">Master_User</code>
            </p><p>
              The current user used to connect to the master.
            </p></li><li><p>
              <code class="literal">Master_Port</code>
            </p><p>
              The current master port.
            </p></li><li><p>
              <code class="literal">Connect_Retry</code>
            </p><p>
              The current value of the
              <code class="option">--master-connect-retry</code> option.
            </p></li><li><p>
              <code class="literal">Master_Log_File</code>
            </p><p>
              The name of the master binary log file from which the I/O
              thread is currently reading.
            </p></li><li><p>
              <code class="literal">Read_Master_Log_Pos</code>
            </p><p>
              The position up to which the I/O thread has read in the
              current master binary log.
            </p></li><li><p>
              <code class="literal">Relay_Log_File</code>
            </p><p>
              The name of the relay log file from which the SQL thread
              is currently reading and executing.
            </p></li><li><p>
              <code class="literal">Relay_Log_Pos</code>
            </p><p>
              The position up to which the SQL thread has read and
              executed in the current relay log.
            </p></li><li><p>
              <code class="literal">Relay_Master_Log_File</code>
            </p><p>
              The name of the master binary log file containing the most
              recent event executed by the SQL thread.
            </p></li><li><p>
              <code class="literal">Slave_IO_Running</code>
            </p><p>
              Whether the I/O thread is started and has connected
              successfully to the master. For older versions of MySQL
              (prior to 4.1.14 and 5.0.12)
              <code class="literal">Slave_IO_Running</code> is
              <code class="literal">YES</code> if the I/O thread is started, even
              if the slave hasn't connected to the master yet.
            </p></li><li><p>
              <code class="literal">Slave_SQL_Running</code>
            </p><p>
              Whether the SQL thread is started.
            </p></li><li><p>
              <code class="literal">Replicate_Do_DB</code>,
              <code class="literal">Replicate_Ignore_DB</code>
            </p><p>
              The lists of databases that were specified with the
              <code class="option">--replicate-do-db</code> and
              <code class="option">--replicate-ignore-db</code> options, if any.
            </p></li><li><p>
              <code class="literal">Replicate_Do_Table</code>,
              <code class="literal">Replicate_Ignore_Table</code>,
              <code class="literal">Replicate_Wild_Do_Table</code>,
              <code class="literal">Replicate_Wild_Ignore_Table</code>
            </p><p>
              The lists of tables that were specified with the
              <code class="option">--replicate-do-table</code>,
              <code class="option">--replicate-ignore-table</code>,
              <code class="option">--replicate-wild-do-table</code>, and
              <code class="option">--replicate-wild-ignore_table</code> options, if
              any.
            </p></li><li><p>
              <code class="literal">Last_Errno</code>,
              <code class="literal">Last_Error</code>
            </p><p>
              The error number and error message returned by the most
              recently executed query. An error number of 0 and message
              of the empty string mean “<span class="quote">no error.</span>” If the
              <code class="literal">Last_Error</code> value is not empty, it also
              appears as a message in the slave's error log. For
              example:
            </p><pre class="programlisting">Last_Errno: 1051
Last_Error: error 'Unknown table 'z'' on query 'drop table z'
</pre><p>
              The message indicates that the table <code class="literal">z</code>
              existed on the master and was dropped there, but it did
              not exist on the slave, so <code class="literal">DROP TABLE</code>
              failed on the slave. (This might occur, for example, if
              you forget to copy the table to the slave when setting up
              replication.)
            </p></li><li><p>
              <code class="literal">Skip_Counter</code>
            </p><p>
              The most recently used value for
              <code class="literal">SQL_SLAVE_SKIP_COUNTER</code>.
            </p></li><li><p>
              <code class="literal">Exec_Master_Log_Pos</code>
            </p><p>
              The position of the last event executed by the SQL thread
              from the master's binary log
              (<code class="literal">Relay_Master_Log_File</code>).
              (<code class="literal">Relay_Master_Log_File</code>,
              <code class="literal">Exec_Master_Log_Pos</code>) in the master's
              binary log corresponds to
              (<code class="literal">Relay_Log_File</code>,
              <code class="literal">Relay_Log_Pos</code>) in the relay log.
            </p></li><li><p>
              <code class="literal">Relay_Log_Space</code>
            </p><p>
              The total combined size of all existing relay logs.
            </p></li><li><p>
              <code class="literal">Until_Condition</code>,
              <code class="literal">Until_Log_File</code>,
              <code class="literal">Until_Log_Pos</code>
            </p><p>
              The values specified in the <code class="literal">UNTIL</code>
              clause of the <code class="literal">START SLAVE</code> statement.
            </p><p>
              <code class="literal">Until_Condition</code> has these values:
            </p><div class="itemizedlist"><ul type="circle"><li><p>
                  <code class="literal">None</code> if no <code class="literal">UNTIL</code>
                  clause was specified
                </p></li><li><p>
                  <code class="literal">Master</code> if the slave is reading
                  until a given position in the master's binary logs
                </p></li><li><p>
                  <code class="literal">Relay</code> if the slave is reading until
                  a given position in its relay logs
                </p></li></ul></div><p>
              <code class="literal">Until_Log_File</code> and
              <code class="literal">Until_Log_Pos</code> indicate the log filename
              and position values that define the point at which the SQL
              thread stops executing.
            </p></li><li><p>
              <code class="literal">Master_SSL_Allowed</code>,
              <code class="literal">Master_SSL_CA_File</code>,
              <code class="literal">Master_SSL_CA_Path</code>,
              <code class="literal">Master_SSL_Cert</code>,
              <code class="literal">Master_SSL_Cipher</code>,
              <code class="literal">Master_SSL_Key</code>
            </p><p>
              These fields show the SSL parameters used by the slave to
              connect to the master, if any.
            </p><p>
              <code class="literal">Master_SSL_Allowed</code> has these values:
            </p><div class="itemizedlist"><ul type="circle"><li><p>
                  <code class="literal">Yes</code> if an SSL connection to the
                  master is permitted
                </p></li><li><p>
                  <code class="literal">No</code> if an SSL connection to the
                  master is not permitted
                </p></li><li><p>
                  <code class="literal">Ignored</code> if an SSL connection is
                  permitted but the slave server does not have SSL
                  support enabled
                </p></li></ul></div><p>
              The values of the other SSL-related fields correspond to
              the values of the <code class="literal">MASTER_SSL_CA</code>,
              <code class="literal">MASTER_SSL_CAPATH</code>,
              <code class="literal">MASTER_SSL_CERT</code>,
              <code class="literal">MASTER_SSL_CIPHER</code>, and
              <code class="literal">MASTER_SSL_KEY</code> options to the
              <code class="literal">CHANGE MASTER</code> statement. See
              <a href="mysqlqb_statements.html#change-master-to" title="CHANGE MASTER TO Syntax"><code class="literal">CHANGE MASTER TO</code> Syntax</a>.
            </p></li><li><p>
              <code class="literal">Seconds_Behind_Master</code>
            </p><p>
              This field is an indication of how “<span class="quote">late</span>” the
              slave is:
            </p><div class="itemizedlist"><ul type="circle"><li><p>
                  When the slave SQL thread is actively running
                  (processing updates), this field is the number of
                  seconds that have elapsed since the timestamp of the
                  most recent event on the master executed by that
                  thread.
                </p></li><li><p>
                  When the SQL thread has caught up to the slave I/O
                  thread and goes idle waiting for more events from the
                  I/O thread, this field is zero.
                </p></li></ul></div><p>
              In essence, this field measures the time difference in
              seconds between the slave SQL thread and the slave I/O
              thread.
            </p><p>
              If the network connection between master and slave is
              fast, the slave I/O thread is very close to the master, so
              this field is a good approximation of how late the slave
              SQL thread is compared to the master. If the network is
              slow, this is <span class="emphasis"><em>not</em></span> a good
              approximation; the slave SQL thread may quite often be
              caught up with the slow-reading slave I/O thread, so
              <code class="literal">Seconds_Behind_Master</code> often shows a
              value of 0, even if the I/O thread is late compared to the
              master. In other words, <span class="emphasis"><em>this column is useful
              only for fast networks</em></span>.
            </p><p>
              This time difference computation works even though the
              master and slave do not have identical clocks (the clock
              difference is computed when the slave I/O thread starts,
              and assumed to remain constant from then on).
              <code class="literal">Seconds_Behind_Master</code> is
              <code class="literal">NULL</code> (which means
              “<span class="quote">unknown</span>”) if the slave SQL thread is not
              running, or if the slave I/O thread is not running or not
              connected to master. For example if the slave I/O thread
              is sleeping for the number of seconds given by the
              <code class="option">--master-connect-retry</code> option before
              reconnecting, <code class="literal">NULL</code> is shown, as the
              slave cannot know what the master is doing, and so cannot
              say reliably how late it is.
            </p><p>
              This field has one limitation. The timestamp is preserved
              through replication, which means that, if a master M1 is
              itself a slave of M0, any event from M1's binlog which
              originates in replicating an event from M0's binlog has
              the timestamp of that event. This enables MySQL to
              replicate <code class="literal">TIMESTAMP</code> successfully.
              However, the drawback for
              <code class="literal">Seconds_Behind_Master</code> is that if M1
              also receives direct updates from clients, the value
              randomly deviates, because sometimes the last M1's event
              is from M0 and sometimes it is the most recent timestamp
              from a direct update.
            </p></li></ul></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="start-slave"></a><code class="literal">START SLAVE</code> Syntax</h4></div></div></div><a id="id2904588" class="indexterm"></a><pre class="programlisting">START SLAVE [<em class="replaceable"><code>thread_type</code></em> [, <em class="replaceable"><code>thread_type</code></em>] ... ]
START SLAVE [SQL_THREAD] UNTIL
    MASTER_LOG_FILE = '<em class="replaceable"><code>log_name</code></em>', MASTER_LOG_POS = <em class="replaceable"><code>log_pos</code></em>
START SLAVE [SQL_THREAD] UNTIL
    RELAY_LOG_FILE = '<em class="replaceable"><code>log_name</code></em>', RELAY_LOG_POS = <em class="replaceable"><code>log_pos</code></em>

<em class="replaceable"><code>thread_type</code></em>: IO_THREAD | SQL_THREAD
</pre><p>
          <code class="literal">START SLAVE</code> with no
          <em class="replaceable"><code>thread_type</code></em> options starts both of
          the slave threads. The I/O thread reads queries from the
          master server and stores them in the relay log. The SQL thread
          reads the relay log and executes the queries. <code class="literal">START
          SLAVE</code> requires the <code class="literal">SUPER</code>
          privilege.
        </p><p>
          If <code class="literal">START SLAVE</code> succeeds in starting the
          slave threads, it returns without any error. However, even in
          that case, it might be that the slave threads start and then
          later stop (for example, because they do not manage to connect
          to the master or read its binary logs, or some other problem).
          <code class="literal">START SLAVE</code> does not warn you about this.
          You must check the slave's error log for error messages
          generated by the slave threads, or check that they are running
          satisfactorily with <code class="literal">SHOW SLAVE STATUS</code>.
        </p><p>
          You can add <code class="literal">IO_THREAD</code> and
          <code class="literal">SQL_THREAD</code> options to the statement to name
          which of the threads to start.
        </p><p>
          An <code class="literal">UNTIL</code> clause may be added to specify
          that the slave should start and run until the SQL thread
          reaches a given point in the master binary logs or in the
          slave relay logs. When the SQL thread reaches that point, it
          stops. If the <code class="literal">SQL_THREAD</code> option is
          specified in the statement, it starts only the SQL thread.
          Otherwise, it starts both slave threads. If the SQL thread is
          running, the <code class="literal">UNTIL</code> clause is ignored and a
          warning is issued.
        </p><p>
          For an <code class="literal">UNTIL</code> clause, you must specify both
          a log filename and position. Do not mix master and relay log
          options.
        </p><p>
          Any <code class="literal">UNTIL</code> condition is reset by a
          subsequent <code class="literal">STOP SLAVE</code> statement, a
          <code class="literal">START SLAVE</code> statement that includes no
          <code class="literal">UNTIL</code> clause, or a server restart.
        </p><p>
          The <code class="literal">UNTIL</code> clause can be useful for
          debugging replication, or to cause replication to proceed
          until just before the point where you want to avoid having the
          slave replicate a statement. For example, if an unwise
          <code class="literal">DROP TABLE</code> statement was executed on the
          master, you can use <code class="literal">UNTIL</code> to tell the slave
          to execute up to that point but no farther. To find what the
          event is, use <span><strong class="command">mysqlbinlog</strong></span> with the master
          logs or slave relay logs, or by using a <code class="literal">SHOW BINLOG
          EVENTS</code> statement.
        </p><p>
          If you are using <code class="literal">UNTIL</code> to have the slave
          process replicated queries in sections, it is recommended that
          you start the slave with the
          <code class="option">--skip-slave-start</code> option to prevent the SQL
          thread from running when the slave server starts. It is
          probably best to use this option in an option file rather than
          on the command line, so that an unexpected server restart does
          not cause it to be forgotten.
        </p><p>
          The <code class="literal">SHOW SLAVE STATUS</code> statement includes
          output fields that display the current values of the
          <code class="literal">UNTIL</code> condition.
        </p><p>
          In old versions of MySQL (before 4.0.5), this statement was
          called <code class="literal">SLAVE START</code>. This usage is still
          accepted in MySQL 5.0 for backward compatibility,
          but is deprecated.
        </p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="stop-slave"></a><code class="literal">STOP SLAVE</code> Syntax</h4></div></div></div><a id="id2904849" class="indexterm"></a><pre class="programlisting">STOP SLAVE [<em class="replaceable"><code>thread_type</code></em> [, <em class="replaceable"><code>thread_type</code></em>] ... ]

<em class="replaceable"><code>thread_type</code></em>: IO_THREAD | SQL_THREAD
</pre><p>
          Stops the slave threads. <code class="literal">STOP SLAVE</code>
          requires the <code class="literal">SUPER</code> privilege.
        </p><p>
          Like <code class="literal">START SLAVE</code>, this statement may be
          used with the <code class="literal">IO_THREAD</code> and
          <code class="literal">SQL_THREAD</code> options to name the thread or
          threads to be stopped.
        </p><p>
          In old versions of MySQL (before 4.0.5), this statement was
          called <code class="literal">SLAVE STOP</code>. This usage is still
          accepted in MySQL 5.0 for backward compatibility,
          but is deprecated.
        </p></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="sqlps"></a>SQL Syntax for Prepared Statements</h2></div></div></div><a id="id2904970" class="indexterm"></a><a id="id2904977" class="indexterm"></a><a id="id2904983" class="indexterm"></a><p>
      MySQL 5.0 provides support for server-side prepared
      statements. This support takes advantage of the efficient
      client/server binary protocol implemented in MySQL 4.1, provided
      that you use an appropriate client programming interface.
      Candidate interfaces include the MySQL C API client library (for C
      programs), MySQL Connector/J (for Java programs), and MySQL
      Connector/NET. For example, the C API provides a set of function
      calls that make up its prepared statement API. See
      <a href="http://dev.mysql.com/doc/refman/5.0/en/c-api-prepared-statements.html" target="_top">C API Prepared Statements</a>. Other language
      interfaces can provide support for prepared statements that use
      the binary protocol by linking in the C client library, one
      example being the
      <a href="http://php.net/mysqli" target="_top"><code class="literal">mysqli</code>
      extension</a>, available in PHP 5.0 and later.
    </p><p>
      An alternative SQL interface to prepared statements is available.
      This interface is not as efficient as using the binary protocol
      through a prepared statement API, but requires no programming
      because it is available directly at the SQL level:
    </p><div class="itemizedlist"><ul type="disc"><li><p>
          You can use it when no programming interface is available to
          you.
        </p></li><li><p>
          You can use it from any program that allows you to send SQL
          statements to the server to be executed, such as the
          <span><strong class="command">mysql</strong></span> client program.
        </p></li><li><p>
          You can use it even if the client is using an old version of
          the client library. The only requirement is that you be able
          to connect to a server that is recent enough to support SQL
          syntax for prepared statements.
        </p></li></ul></div><p>
      SQL syntax for prepared statements is intended to be used for
      situations such as these:
    </p><div class="itemizedlist"><ul type="disc"><li><p>
          You want to test how prepared statements work in your
          application before coding it.
        </p></li><li><p>
          An application has problems executing prepared statements and
          you want to determine interactively what the problem is.
        </p></li><li><p>
          You want to create a test case that describes a problem you
          are having with prepared statements, so that you can file a
          bug report.
        </p></li><li><p>
          You need to use prepared statements but do not have access to
          a programming API that supports them.
        </p></li></ul></div><p>
      SQL syntax for prepared statements is based on three SQL
      statements:
    </p><div class="itemizedlist"><ul type="disc"><li><p>
          <a id="id2905147" class="indexterm"></a>

          <code class="literal">PREPARE <em class="replaceable"><code>stmt_name</code></em> FROM
          <em class="replaceable"><code>preparable_stmt</code></em></code>
        </p><p>
          The <code class="literal">PREPARE</code> statement prepares a statement
          and assigns it a name, <em class="replaceable"><code>stmt_name</code></em>,
          by which to refer to the statement later. Statement names are
          not case sensitive. <em class="replaceable"><code>preparable_stmt</code></em>
          is either a string literal or a user variable that contains
          the text of the statement. The text must represent a single
          SQL statement, not multiple statements. Within the statement,
          ‘<code class="literal">?</code>’ characters can be used as
          parameter markers to indicate where data values are to be
          bound to the query later when you execute it. The
          ‘<code class="literal">?</code>’ characters should not be
          enclosed within quotes, even if you intend to bind them to
          string values. Parameter markers can be used only where data
          values should appear, not for SQL keywords, identifiers, and
          so forth.
        </p><p>
          If a prepared statement with the given name already exists, it
          is deallocated implicitly before the new statement is
          prepared. This means that if the new statement contains an
          error and cannot be prepared, an error is returned and no
          statement with the given name exists.
        </p><p>
          The scope of a prepared statement is the client session within
          which it is created. Other clients cannot see it.
        </p></li><li><p>
          <a id="id2905262" class="indexterm"></a>

          <code class="literal">EXECUTE <em class="replaceable"><code>stmt_name</code></em> [USING
          @<em class="replaceable"><code>var_name</code></em> [,
          @<em class="replaceable"><code>var_name</code></em>] ...]</code>
        </p><p>
          After preparing a statement, you execute it with an
          <code class="literal">EXECUTE</code> statement that refers to the
          prepared statement name. If the prepared statement contains
          any parameter markers, you must supply a
          <code class="literal">USING</code> clause that lists user variables
          containing the values to be bound to the parameters. Parameter
          values can be supplied only by user variables, and the
          <code class="literal">USING</code> clause must name exactly as many
          variables as the number of parameter markers in the statement.
        </p><p>
          You can execute a given prepared statement multiple times,
          passing different variables to it or setting the variables to
          different values before each execution.
        </p></li><li><p>
          <a id="id2905353" class="indexterm"></a>

          <a id="id2905361" class="indexterm"></a>

          <code class="literal">{DEALLOCATE | DROP} PREPARE
          <em class="replaceable"><code>stmt_name</code></em></code>
        </p><p>
          To deallocate a prepared statement, use the
          <code class="literal">DEALLOCATE PREPARE</code> statement. Attempting to
          execute a prepared statement after deallocating it results in
          an error.
        </p><p>
          If you terminate a client session without deallocating a
          previously prepared statement, the server deallocates it
          automatically.
        </p></li></ul></div><p>
      The following SQL statements can be used in prepared statements:
      <code class="literal">CREATE TABLE</code>, <code class="literal">DELETE</code>,
      <code class="literal">DO</code>, <code class="literal">INSERT</code>,
      <code class="literal">REPLACE</code>, <code class="literal">SELECT</code>,
      <code class="literal">SET</code>, <code class="literal">UPDATE</code>, and most
      <code class="literal">SHOW</code> statements. supported. <code class="literal">ANALYZE
      TABLE</code>, <code class="literal">OPTIMIZE TABLE</code>, and
      <code class="literal">REPAIR TABLE</code> are supported as of MySQL 5.0.23.
      Other statements are not yet supported.
    </p><p>
      The following examples show two equivalent ways of preparing a
      statement that computes the hypotenuse of a triangle given the
      lengths of the two sides.
    </p><p>
      The first example shows how to create a prepared statement by
      using a string literal to supply the text of the statement:
    </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>PREPARE stmt1 FROM 'SELECT SQRT(POW(?,2) + POW(?,2)) AS hypotenuse';</code></strong>
mysql&gt; <strong class="userinput"><code>SET @a = 3;</code></strong>
mysql&gt; <strong class="userinput"><code>SET @b = 4;</code></strong>
mysql&gt; <strong class="userinput"><code>EXECUTE stmt1 USING @a, @b;</code></strong>
+------------+
| hypotenuse |
+------------+
|          5 |
+------------+
mysql&gt; <strong class="userinput"><code>DEALLOCATE PREPARE stmt1;</code></strong>
</pre><p>
      The second example is similar, but supplies the text of the
      statement as a user variable:
    </p><pre class="programlisting">mysql&gt; <strong class="userinput"><code>SET @s = 'SELECT SQRT(POW(?,2) + POW(?,2)) AS hypotenuse';</code></strong>
mysql&gt; <strong class="userinput"><code>PREPARE stmt2 FROM @s;</code></strong>
mysql&gt; <strong class="userinput"><code>SET @a = 6;</code></strong>
mysql&gt; <strong class="userinput"><code>SET @b = 8;</code></strong>
mysql&gt; <strong class="userinput"><code>EXECUTE stmt2 USING @a, @b;</code></strong>
+------------+
| hypotenuse |
+------------+
|         10 |
+------------+
mysql&gt; <strong class="userinput"><code>DEALLOCATE PREPARE stmt2;</code></strong>
</pre><p>
      As of MySQL 5.0.7, placeholders can be used for the arguments of
      the <code class="literal">LIMIT</code> clause when using prepared
      statements. See <a href="mysqlqb_statements.html#select" title="SELECT Syntax"><code class="literal">SELECT</code> Syntax</a>.
    </p><p>
      SQL syntax for prepared statements cannot be used in nested
      fashion. That is, a statement passed to <code class="literal">PREPARE</code>
      cannot itself be a <code class="literal">PREPARE</code>,
      <code class="literal">EXECUTE</code>, or <code class="literal">DEALLOCATE
      PREPARE</code> statement.
    </p><p>
      SQL syntax for prepared statements is distinct from using prepared
      statement API calls. For example, you cannot use the
      <code class="literal">mysql_stmt_prepare()</code> C API function to prepare
      a <code class="literal">PREPARE</code>, <code class="literal">EXECUTE</code>, or
      <code class="literal">DEALLOCATE PREPARE</code> statement.
    </p><p>
      SQL syntax for prepared statements cannot be used within stored
      routines (procedures or functions), or triggers. This restriction
      is lifted as of MySQL 5.0.13 for stored procedures, but not for
      stored functions or triggers.
    </p><p>
      SQL syntax for prepared statements does not support
      multi-statements (that is, multiple statements within a single
      string separated by ‘<code class="literal">;</code>’
      characters).
    </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="mysqlqb_functions.html">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> </td></tr><tr><td width="40%" align="left" valign="top">Functions and Operators </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> </td></tr></table></div></body></html>