Below is the list of changes that have just been committed into a local
mysqldoc repository of jon. When jon does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://www.mysql.com/doc/I/n/Installing_source_tree.html
ChangeSet
1.2936 05/07/05 20:09:30 jon@stripped +1 -0
sql-syntax.xml:
Moved data-definition node
before data-manipulation.
(Was marked as TODO.)
refman-4.1/sql-syntax.xml
1.6 05/07/05 20:09:28 jon@stripped +3063 -3062
Moved data-definition node
before data-manipulation.
(Was marked as TODO.)
# This is a BitKeeper patch. What follows are the unified diffs for the
# set of deltas contained in the patch. The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User: jon
# Host: gigan.
# Root: /home/jon/bk/mysqldoc
--- 1.5/refman-4.1/sql-syntax.xml 2005-06-29 20:05:30 +10:00
+++ 1.6/refman-4.1/sql-syntax.xml 2005-07-05 20:09:28 +10:00
@@ -11,15 +11,3072 @@
<title id='title-sql-syntax'>&title-sql-syntax;</title>
-<!-- TODO: move DDL before DML; you have to create something before you -->
-
-<!-- can manipulate it... -->
-
<para>
This chapter describes the syntax for the SQL statements supported in
MySQL.
</para>
+
+
+ <section id="data-definition">
+
+ <title id='title-data-definition'>&title-data-definition;</title>
+
+ <!-- help_category Data Definition -->
+
+ <section id="alter-database">
+
+ <title id='title-alter-database'>&title-alter-database;</title>
+
+ <indexterm type="function">
+ <primary>ALTER DATABASE</primary>
+ </indexterm>
+
+ <indexterm type="function">
+ <primary>ALTER SCHEMA</primary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>altering</primary>
+ <secondary>database</secondary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>database</primary>
+ <secondary>altering</secondary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>altering</primary>
+ <secondary>schema</secondary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>schema</primary>
+ <secondary>altering</secondary>
+ </indexterm>
+
+ <!-- example_for_help_topic ALTER DATABASE -->
+
+ <programlisting>
+ ALTER {DATABASE | SCHEMA} [<replaceable>db_name</replaceable>]
+ <replaceable>alter_specification</replaceable> [, <replaceable>alter_specification</replaceable>] ...
+
+ <replaceable>alter_specification</replaceable>:
+ [DEFAULT] CHARACTER SET <replaceable>charset_name</replaceable>
+ | [DEFAULT] COLLATE <replaceable>collation_name</replaceable>
+ </programlisting>
+
+ <!-- description_for_help_topic ALTER DATABASE CHARACTER SET SCHEMA -->
+
+ <para>
+ <literal>ALTER DATABASE</literal> allows you to change the overall
+ characteristics of a database. These characteristics are stored in
+ the <filename>db.opt</filename> file in the database directory. To
+ use <literal>ALTER DATABASE</literal>, you need the
+ <literal>ALTER</literal> privilege on the database.
+
+ <!-- end_description_for_help_topic -->
+ </para>
+
+ <para>
+ The <literal>CHARACTER SET</literal> clause changes the default
+ database character set. The <literal>COLLATE</literal> clause
+ changes the default database collation. Character set and collation
+ names are discussed in <xref linkend="charset"/>.
+ </para>
+
+ <!-- It's really 4.1.0, but with a different syntax than in 4.1.1. -->
+
+ <!-- (COLLATE is not supported.) -->
+
+ <para>
+ <literal>ALTER DATABASE</literal> was added in MySQL 4.1.1.
+ Beginning with MySQL 4.1.8, the database name can be omitted. The
+ statement applies to the default database in this case.
+ <literal>ALTER SCHEMA</literal> can be used as of MySQL 5.0.2.
+ </para>
+
+ </section>
+
+ <section id="alter-table">
+
+ <title id='title-alter-table'>&title-alter-table;</title>
+
+ <indexterm type="function">
+ <primary>ALTER TABLE</primary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>changing</primary>
+ <secondary>table</secondary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>table</primary>
+ <secondary>changing</secondary>
+ </indexterm>
+
+ <!-- example_for_help_topic ALTER TABLE -->
+
+ <programlisting>
+ ALTER [IGNORE] TABLE <replaceable>tbl_name</replaceable>
+ <replaceable>alter_specification</replaceable> [, <replaceable>alter_specification</replaceable>] ...
+
+ <replaceable>alter_specification</replaceable>:
+ ADD [COLUMN] <replaceable>column_definition</replaceable> [FIRST | AFTER <replaceable>col_name</replaceable> ]
+ | ADD [COLUMN] (<replaceable>column_definition</replaceable>,...)
+ | ADD INDEX [<replaceable>index_name</replaceable>] [<replaceable>index_type</replaceable>] (<replaceable>index_col_name</replaceable>,...)
+ | ADD [CONSTRAINT [<replaceable>symbol</replaceable>]]
+ PRIMARY KEY [<replaceable>index_type</replaceable>] (<replaceable>index_col_name</replaceable>,...)
+ | ADD [CONSTRAINT [<replaceable>symbol</replaceable>]]
+ UNIQUE [<replaceable>index_name</replaceable>] [<replaceable>index_type</replaceable>] (<replaceable>index_col_name</replaceable>,...)
+ | ADD [FULLTEXT|SPATIAL] [<replaceable>index_name</replaceable>] (<replaceable>index_col_name</replaceable>,...)
+ | ADD [CONSTRAINT [<replaceable>symbol</replaceable>]]
+ FOREIGN KEY [<replaceable>index_name</replaceable>] (<replaceable>index_col_name</replaceable>,...)
+ [<replaceable>reference_definition</replaceable>]
+ | ALTER [COLUMN] <replaceable>col_name</replaceable> {SET DEFAULT <replaceable>literal</replaceable> | DROP DEFAULT}
+ | CHANGE [COLUMN] <replaceable>old_col_name</replaceable> <replaceable>column_definition</replaceable>
+ [FIRST|AFTER <replaceable>col_name</replaceable>]
+ | MODIFY [COLUMN] <replaceable>column_definition</replaceable> [FIRST | AFTER <replaceable>col_name</replaceable>]
+ | DROP [COLUMN] <replaceable>col_name</replaceable>
+ | DROP PRIMARY KEY
+ | DROP INDEX <replaceable>index_name</replaceable>
+ | DROP FOREIGN KEY <replaceable>fk_symbol</replaceable>
+ | DISABLE KEYS
+ | ENABLE KEYS
+ | RENAME [TO] <replaceable>new_tbl_name</replaceable>
+ | ORDER BY <replaceable>col_name</replaceable>
+ | CONVERT TO CHARACTER SET <replaceable>charset_name</replaceable> [COLLATE <replaceable>collation_name</replaceable>]
+ | [DEFAULT] CHARACTER SET <replaceable>charset_name</replaceable> [COLLATE <replaceable>collation_name</replaceable>]
+ | DISCARD TABLESPACE
+ | IMPORT TABLESPACE
+ | <replaceable>table_options</replaceable>
+ </programlisting>
+
+ <!-- description_for_help_topic ALTER TABLE ADD ALTER AFTER AVG_ROW_LENGTH BY COLUMN FIRST INDEX PRIMARY KEY KEYS UNIQUE FULLTEXT SPATIAL CONSTRAINT DROP DISABLE ENABLE RENAME ORDER MODIFY CHANGE DEFAULT SET FOREIGN IGNORE ENGINE TYPE -->
+
+ <para>
+ <literal>ALTER TABLE</literal> allows 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.
+
+ <!-- end_description_for_help_topic -->
+ </para>
+
+ <para>
+ The syntax for many of the allowable alterations is similar to
+ clauses of the <literal>CREATE TABLE</literal> statement. This
+ includes <replaceable>table_options</replaceable> modifications, for
+ options such as <literal>ENGINE</literal>,
+ <literal>AUTO_INCREMENT</literal>, and
+ <literal>AVG_ROW_LENGTH</literal>. See
+ <xref linkend="create-table"/>.
+ </para>
+
+ <para>
+ Some operations may result in warnings if attempted on a table for
+ which the storage engine does not support the operation. In MySQL
+ 4.1 and up, these warnings can be displayed with <literal>SHOW
+ WARNINGS</literal>. See <xref linkend="show-warnings"/>.
+ </para>
+
+ <para>
+ If you use <literal>ALTER TABLE</literal> to change a column
+ specification but <literal>DESCRIBE
+ <replaceable>tbl_name</replaceable></literal> indicates that your
+ column was not changed, it is possible that MySQL ignored your
+ modification for one of the reasons described in
+ <xref linkend="silent-column-changes"/>. For example, if you try to
+ change a <literal>VARCHAR</literal> column to
+ <literal>CHAR</literal>, MySQL still uses <literal>VARCHAR</literal>
+ if the table contains other variable-length columns.
+ </para>
+
+ <para>
+ <literal>ALTER TABLE</literal> works by making a temporary copy of
+ the original table. The alteration is performed on the copy, then
+ the original table is deleted and the new one is renamed. While
+ <literal>ALTER TABLE</literal> is executing, the original table is
+ readable by other clients. Updates and writes to the table are
+ stalled until the new table is ready, then are automatically
+ redirected to the new table without any failed updates.
+ </para>
+
+ <para>
+ Note that if you use any other option to <literal>ALTER
+ TABLE</literal> than <literal>RENAME</literal>, 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). We plan to
+ fix this in the future, but because <literal>ALTER TABLE</literal>
+ is not a statement that is normally used frequently, this isn't high
+ on our TODO list. For <literal>MyISAM</literal> tables, you can
+ speed up the index re-creation operation (which is the slowest part
+ of the alteration process) by setting the
+ <literal>myisam_sort_buffer_size</literal> system variable to a high
+ value.
+ </para>
+
+ <itemizedlist>
+
+ <listitem><para>
+ To use <literal>ALTER TABLE</literal>, you need
+ <literal>ALTER</literal>, <literal>INSERT</literal>, and
+ <literal>CREATE</literal> privileges for the table.
+ </para></listitem>
+
+ <listitem><para>
+ <literal>IGNORE</literal> is a MySQL extension to standard SQL. It
+ controls how <literal>ALTER TABLE</literal> works if there are
+ duplicates on unique keys in the new table or if warnings occur
+ when <literal>STRICT</literal> mode is enabled. If
+ <literal>IGNORE</literal> isn't specified, the copy is aborted and
+ rolled back if duplicate-key errors occur. If
+ <literal>IGNORE</literal> is specified, then for rows with
+ duplicates on a unique key, only the first row is used. The others
+ conflicting rows are deleted. Wrong values are truncated to the
+ closest matching acceptable value.
+ </para></listitem>
+
+ <listitem><para>
+ You can issue multiple <literal>ADD</literal>,
+ <literal>ALTER</literal>, <literal>DROP</literal>, and
+ <literal>CHANGE</literal> clauses in a single <literal>ALTER
+ TABLE</literal> statement. This is a MySQL extension to standard
+ SQL, which allows only one of each clause per <literal>ALTER
+ TABLE</literal> statement. For example, to drop multiple columns in
+ a single statement:
+ </para>
+
+ <programlisting>
+ mysql> ALTER TABLE t2 DROP COLUMN c, DROP COLUMN d;
+ </programlisting></listitem>
+
+ <listitem><para>
+ <literal>CHANGE <replaceable>col_name</replaceable></literal>,
+ <literal>DROP <replaceable>col_name</replaceable></literal>, and
+ <literal>DROP INDEX</literal> are MySQL extensions to standard SQL.
+ </para></listitem>
+
+ <listitem><para>
+ <literal>MODIFY</literal> is an Oracle extension to <literal>ALTER
+ TABLE</literal>.
+ </para></listitem>
+
+ <listitem><para>
+ The word <literal>COLUMN</literal> is purely optional and can be
+ omitted.
+ </para></listitem>
+
+ <listitem><para>
+ If you use <literal>ALTER TABLE <replaceable>tbl_name</replaceable>
+ RENAME TO <replaceable>new_tbl_name</replaceable></literal> without
+ any other options, MySQL simply renames any files that correspond
+ to the table <replaceable>tbl_name</replaceable>. There is no need
+ to create a temporary table. (You can also use the <literal>RENAME
+ TABLE</literal> statement to rename tables. See
+ <xref linkend="rename-table"/>.)
+ </para></listitem>
+
+ <listitem><para>
+ <replaceable>column_definition</replaceable> clauses use the same
+ syntax for <literal>ADD</literal> and <literal>CHANGE</literal> as
+ for <literal>CREATE TABLE</literal>. Note that this syntax includes
+ the column name, not just the column type. See
+ <xref linkend="create-table"/>.
+ </para></listitem>
+
+ <listitem><para>
+ You can rename a column using a <literal>CHANGE
+ <replaceable>old_col_name</replaceable>
+ <replaceable>column_definition</replaceable></literal> clause. To
+ do so, specify the old and new column names and the type that the
+ column currently has. For example, to rename an
+ <literal>INTEGER</literal> column from <literal>a</literal> to
+ <literal>b</literal>, you can do this:
+ </para>
+
+ <programlisting>
+ mysql> ALTER TABLE t1 CHANGE a b INTEGER;
+ </programlisting>
+
+ <para>
+ If you want to change a column's type but not the name,
+ <literal>CHANGE</literal> syntax still requires an old and new
+ column name, even if they are the same. For example:
+ </para>
+
+ <programlisting>
+ mysql> ALTER TABLE t1 CHANGE b b BIGINT NOT NULL;
+ </programlisting>
+
+ <para>
+ However, as of MySQL 3.22.16a, you can also use
+ <literal>MODIFY</literal> to change a column's type without
+ renaming it:
+ </para>
+
+ <programlisting>
+ mysql> ALTER TABLE t1 MODIFY b BIGINT NOT NULL;
+ </programlisting></listitem>
+
+ <listitem><para>
+ If you use <literal>CHANGE</literal> or <literal>MODIFY</literal>
+ 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.
+ </para></listitem>
+
+ <listitem><para>
+ When you change a column type using <literal>CHANGE</literal> or
+ <literal>MODIFY</literal>, MySQL tries to convert existing column
+ values to the new type as well as possible.
+ </para></listitem>
+
+ <listitem><para>
+ In MySQL 3.22 or later, you can use <literal>FIRST</literal> or
+ <literal>AFTER <replaceable>col_name</replaceable></literal> to add
+ a column at a specific position within a table row. The default is
+ to add the column last. From MySQL 4.0.1 on, you can also use
+ <literal>FIRST</literal> and <literal>AFTER</literal> in
+ <literal>CHANGE</literal> or <literal>MODIFY</literal> operations.
+ </para>
+
+ <indexterm type="function">
+ <primary>ALTER COLUMN</primary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>changing</primary>
+ <secondary>column</secondary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>column</primary>
+ <secondary>changing</secondary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>changing</primary>
+ <secondary>field</secondary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>field</primary>
+ <secondary>changing</secondary>
+ </indexterm></listitem>
+
+ <listitem><para>
+ <literal>ALTER COLUMN</literal> specifies a new default value for a
+ column or removes the old default value. If the old default is
+ removed and the column can be <literal>NULL</literal>, the new
+ default is <literal>NULL</literal>. If the column cannot be
+ <literal>NULL</literal>, MySQL assigns a default value, as
+ described in <xref linkend="create-table"/>.
+ </para>
+
+ <indexterm type="function">
+ <primary>DROP INDEX</primary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>deleting</primary>
+ <secondary>index</secondary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>index</primary>
+ <secondary>deleting</secondary>
+ </indexterm></listitem>
+
+ <listitem><para>
+ <literal>DROP INDEX</literal> removes an index. This is a MySQL
+ extension to standard SQL. See <xref linkend="drop-index"/>.
+ </para></listitem>
+
+ <listitem><para>
+ 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.
+ </para></listitem>
+
+ <listitem><para>
+ If a table contains only one column, the column cannot be dropped.
+ If what you intend is to remove the table, use <literal>DROP
+ TABLE</literal> instead.
+ </para></listitem>
+
+ <listitem><indexterm type="function">
+ <primary>DROP PRIMARY KEY</primary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>deleting</primary>
+ <secondary>primary key</secondary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>primary key</primary>
+ <secondary>deleting</secondary>
+ </indexterm>
+
+ <para>
+ <literal>DROP PRIMARY KEY</literal> drops the primary index. (Prior
+ to MySQL 4.1.2, if no primary index exists, <literal>DROP PRIMARY
+ KEY</literal> drops the first <literal>UNIQUE</literal> index in
+ the table. MySQL marks the first <literal>UNIQUE</literal> key as
+ the <literal>PRIMARY KEY</literal> if no <literal>PRIMARY
+ KEY</literal> was specified explicitly.)
+ </para>
+
+ <indexterm type="function">
+ <primary>UNIQUE</primary>
+ </indexterm>
+
+ <indexterm type="function">
+ <primary>PRIMARY KEY</primary>
+ </indexterm>
+
+ <para>
+ If you add a <literal>UNIQUE INDEX</literal> or <literal>PRIMARY
+ KEY</literal> to a table, it is stored before any non-unique index
+ so that MySQL can detect duplicate keys as early as possible.
+ </para>
+
+ <indexterm type="function">
+ <primary>ORDER BY</primary>
+ </indexterm></listitem>
+
+ <listitem><para>
+ <literal>ORDER BY</literal> allows 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 mainly
+ useful when you know that you are mostly going to query the rows in
+ a certain order; by using this option after big 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.
+ </para>
+
+ <indexterm type="function">
+ <primary>ALTER TABLE</primary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>changing</primary>
+ <secondary>table</secondary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>table</primary>
+ <secondary>changing</secondary>
+ </indexterm></listitem>
+
+ <listitem><para>
+ If you use <literal>ALTER TABLE</literal> on a
+ <literal>MyISAM</literal> table, all non-unique indexes are created
+ in a separate batch (as for <literal>REPAIR TABLE</literal>). This
+ should make <literal>ALTER TABLE</literal> much faster when you
+ have many indexes.
+ </para>
+
+ <para>
+ As of MySQL 4.0, this feature can be activated explicitly.
+ <literal>ALTER TABLE ... DISABLE KEYS</literal> tells MySQL to stop
+ updating non-unique indexes for a <literal>MyISAM</literal> table.
+ <literal>ALTER TABLE ... ENABLE KEYS</literal> 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 <literal>ALTER TABLE ... DISABLE
+ KEYS</literal> requires the <literal>INDEX</literal> privilege in
+ addition to the privileges mentioned earlier.
+ </para></listitem>
+
+ <listitem><indexterm type="concept">
+ <primary>foreign keys</primary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>references</primary>
+ </indexterm>
+
+ <para>
+ The <literal>FOREIGN KEY</literal> and
+ <literal>REFERENCES</literal> clauses are supported by the
+ <literal>InnoDB</literal> storage engine, which implements
+ <literal>ADD [CONSTRAINT [<replaceable>symbol</replaceable>]]
+ FOREIGN KEY (...) REFERENCES ... (...)</literal>. See
+ <xref linkend="innodb-foreign-key-constraints"/>. For other storage
+ engines, the clauses are parsed but ignored. The
+ <literal>CHECK</literal> clause is parsed but ignored by all
+ storage engines. See <xref linkend="create-table"/>. 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
+ <xref linkend="differences-from-ansi"/>.
+ </para></listitem>
+
+ <listitem><indexterm type="function">
+ <primary>DROP FOREIGN KEY</primary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>deleting</primary>
+ <secondary>foreign key</secondary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>foreign key</primary>
+ <secondary>deleting</secondary>
+ </indexterm>
+
+ <para>
+ Starting from MySQL 4.0.13, <literal>InnoDB</literal> supports the
+ use of <literal>ALTER TABLE</literal> to drop foreign keys:
+ </para>
+
+ <programlisting>
+ ALTER TABLE <replaceable>yourtablename</replaceable> DROP FOREIGN KEY <replaceable>fk_symbol</replaceable>;
+ </programlisting>
+
+ <para>
+ For more information, see
+ <xref linkend="innodb-foreign-key-constraints"/>.
+ </para></listitem>
+
+ <listitem><para>
+ <literal>ALTER TABLE</literal> ignores the <literal>DATA
+ DIRECTORY</literal> and <literal>INDEX DIRECTORY</literal> table
+ options.
+ </para></listitem>
+
+ <listitem><indexterm type="function">
+ <primary>CONVERT TO</primary>
+ </indexterm>
+
+ <para>
+ From MySQL 4.1.2 on, if you want to change the table default
+ character set and all character columns (<literal>CHAR</literal>,
+ <literal>VARCHAR</literal>, <literal>TEXT</literal>) to a new
+ character set, use a statement like this:
+ </para>
+
+ <programlisting>
+ ALTER TABLE <replaceable>tbl_name</replaceable> CONVERT TO CHARACTER SET <replaceable>charset_name</replaceable>;
+ </programlisting>
+
+ <para>
+ This is useful, for example, after upgrading from MySQL 4.0.x to
+ 4.1.x. See <xref linkend="charset-upgrading"/>.
+ </para>
+
+ <para>
+ <emphasis role="bold">Warning:</emphasis> The preceding operation
+ converts column values between the character sets. This is
+ <emphasis>not</emphasis> what you want if you have a column in one
+ character set (like <literal>latin1</literal>) but the stored
+ values actually use some other, incompatible character set (like
+ <literal>utf8</literal>). In this case, you have to do the
+ following for each such column:
+ </para>
+
+ <programlisting>
+ ALTER TABLE t1 CHANGE c1 c1 BLOB;
+ ALTER TABLE t1 CHANGE c1 c1 TEXT CHARACTER SET utf8;
+ </programlisting>
+
+ <para>
+ The reason this works is that there is no conversion when you
+ convert to or from <literal>BLOB</literal> columns.
+ </para>
+
+ <para>
+ If you specify <literal>CONVERT TO CHARACTER SET binary</literal>,
+ the <literal>CHAR</literal>, <literal>VARCHAR</literal>, and
+ <literal>TEXT</literal> columns are converted to their
+ corresponding binary string types (<literal>BINARY</literal>,
+ <literal>VARBINARY</literal>, <literal>BLOB</literal>). This means
+ that the columns no longer will have a character set and a
+ subsequent <literal>CONVERT TO</literal> operation will not apply
+ to them.
+ </para>
+
+ <para>
+ To change only the <emphasis>default</emphasis> character set for a
+ table, use this statement:
+ </para>
+
+ <programlisting>
+ ALTER TABLE <replaceable>tbl_name</replaceable> DEFAULT CHARACTER SET <replaceable>charset_name</replaceable>;
+ </programlisting>
+
+ <para>
+ The word <literal>DEFAULT</literal> is optional. The default
+ character set is the character set that is used if you don't
+ specify the character set for a new column you add to a table (for
+ example, with <literal>ALTER TABLE ... ADD column</literal>).
+ </para>
+
+ <para>
+ <emphasis role="bold">Warning:</emphasis> From MySQL 4.1.2 and up,
+ <literal>ALTER TABLE ... DEFAULT CHARACTER SET</literal> and
+ <literal>ALTER TABLE ... CHARACTER SET</literal> are equivalent and
+ change only the default table character set. In MySQL 4.1 releases
+ before 4.1.2, <literal>ALTER TABLE ... DEFAULT CHARACTER
+ SET</literal> changes the default character set, but <literal>ALTER
+ TABLE ... CHARACTER SET</literal> (without
+ <literal>DEFAULT</literal>) changes the default character set
+ <emphasis>and also</emphasis> converts all columns to the new
+ character set.
+ </para></listitem>
+
+ <listitem><indexterm type="function">
+ <primary>DISCARD TABLESPACE</primary>
+ </indexterm>
+
+ <indexterm type="function">
+ <primary>IMPORT TABLESPACE</primary>
+ </indexterm>
+
+ <para>
+ For an <literal>InnoDB</literal> table that is created with its own
+ tablespace in an <filename>.ibd</filename> file, that file can be
+ discarded and imported. To discard the <filename>.ibd</filename>
+ file, use this statement:
+ </para>
+
+ <programlisting>
+ ALTER TABLE <replaceable>tbl_name</replaceable> DISCARD TABLESPACE;
+ </programlisting>
+
+ <para>
+ This deletes the current <filename>.ibd</filename> 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.
+ </para>
+
+ <para>
+ To import the backup <filename>.ibd</filename> file back into the
+ table, copy it into the database directory, then issue this
+ statement:
+ </para>
+
+ <programlisting>
+ ALTER TABLE <replaceable>tbl_name</replaceable> IMPORT TABLESPACE;
+ </programlisting>
+
+ <para>
+ See <xref linkend="multiple-tablespaces"/>.
+ </para></listitem>
+
+ <listitem><indexterm type="function">
+ <primary>mysql_info()</primary>
+ </indexterm>
+
+ <para>
+ With the <literal>mysql_info()</literal> C API function, you can
+ find out how many records were copied, and (when
+ <literal>IGNORE</literal> is used) how many records were deleted
+ due to duplication of unique key values. See
+ <xref linkend="mysql-info"/>.
+ </para></listitem>
+
+ </itemizedlist>
+
+ <para>
+ Here are some examples that show uses of <literal>ALTER
+ TABLE</literal>. Begin with a table <literal>t1</literal> that is
+ created as shown here:
+ </para>
+
+ <programlisting>
+ mysql> CREATE TABLE t1 (a INTEGER,b CHAR(10));
+ </programlisting>
+
+ <para>
+ To rename the table from <literal>t1</literal> to
+ <literal>t2</literal>:
+ </para>
+
+ <programlisting>
+ mysql> ALTER TABLE t1 RENAME t2;
+ </programlisting>
+
+ <para>
+ To change column <literal>a</literal> from
+ <literal>INTEGER</literal> to <literal>TINYINT NOT NULL</literal>
+ (leaving the name the same), and to change column
+ <literal>b</literal> from <literal>CHAR(10)</literal> to
+ <literal>CHAR(20)</literal> as well as renaming it from
+ <literal>b</literal> to <literal>c</literal>:
+ </para>
+
+ <programlisting>
+ mysql> ALTER TABLE t2 MODIFY a TINYINT NOT NULL, CHANGE b c CHAR(20);
+ </programlisting>
+
+ <para>
+ To add a new <literal>TIMESTAMP</literal> column named
+ <literal>d</literal>:
+ </para>
+
+ <programlisting>
+ mysql> ALTER TABLE t2 ADD d TIMESTAMP;
+ </programlisting>
+
+ <para>
+ To add indexes on column <literal>d</literal> and on column
+ <literal>a</literal>:
+ </para>
+
+ <programlisting>
+ mysql> ALTER TABLE t2 ADD INDEX (d), ADD INDEX (a);
+ </programlisting>
+
+ <para>
+ To remove column <literal>c</literal>:
+ </para>
+
+ <programlisting>
+ mysql> ALTER TABLE t2 DROP COLUMN c;
+ </programlisting>
+
+ <para>
+ To add a new <literal>AUTO_INCREMENT</literal> integer column named
+ <literal>c</literal>:
+ </para>
+
+ <programlisting>
+ mysql> ALTER TABLE t2 ADD c INT UNSIGNED NOT NULL AUTO_INCREMENT,
+ -> ADD PRIMARY KEY (c);
+ </programlisting>
+
+ <para>
+ Note that we indexed <literal>c</literal> (as a <literal>PRIMARY
+ KEY</literal>), because <literal>AUTO_INCREMENT</literal> columns
+ must be indexed, and also that we declare <literal>c</literal> as
+ <literal>NOT NULL</literal>, because primary key columns cannot be
+ <literal>NULL</literal>.
+ </para>
+
+ <para>
+ When you add an <literal>AUTO_INCREMENT</literal> column, column
+ values are filled in with sequence numbers for you automatically.
+ For <literal>MyISAM</literal> tables, you can set the first sequence
+ number by executing <literal>SET
+ INSERT_ID=<replaceable>value</replaceable></literal> before
+ <literal>ALTER TABLE</literal> or by using the
+ <literal>AUTO_INCREMENT=<replaceable>value</replaceable></literal>
+ table option. See <xref linkend="set-option"/>.
+ </para>
+
+ <para>
+ From MySQL 5.0.3, you can use the <literal>ALTER TABLE ...
+ AUTO_INCREMENT=<replaceable>value</replaceable></literal> table
+ option for <literal>InnoDB</literal> tables to set the sequence
+ number for new rows if the value is greater than the maximum value
+ in the <literal>AUTO_INCREMENT</literal> column. If the value is
+ less than the maximum column value, no error message is given and
+ the current sequence value is not changed.
+ </para>
+
+ <para>
+ With <literal>MyISAM</literal> tables, if you don't change the
+ <literal>AUTO_INCREMENT</literal> column, the sequence number is not
+ affected. If you drop an <literal>AUTO_INCREMENT</literal> column
+ and then add another <literal>AUTO_INCREMENT</literal> column, the
+ numbers are resequenced beginning with 1.
+ </para>
+
+ <para>
+ See <xref linkend="alter-table-problems"/>.
+ </para>
+
+ </section>
+
+ <section id="create-database">
+
+ <title id='title-create-database'>&title-create-database;</title>
+
+ <indexterm type="function">
+ <primary>CREATE DATABASE</primary>
+ </indexterm>
+
+ <indexterm type="function">
+ <primary>CREATE SCHEMA</primary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>creating</primary>
+ <secondary>database</secondary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>database</primary>
+ <secondary>creating</secondary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>creating</primary>
+ <secondary>schema</secondary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>schema</primary>
+ <secondary>creating</secondary>
+ </indexterm>
+
+ <!-- example_for_help_topic CREATE DATABASE -->
+
+ <programlisting>
+ CREATE {DATABASE | SCHEMA} [IF NOT EXISTS] <replaceable>db_name</replaceable>
+ [<replaceable>create_specification</replaceable> [, <replaceable>create_specification</replaceable>] ...]
+
+ <replaceable>create_specification</replaceable>:
+ [DEFAULT] CHARACTER SET <replaceable>charset_name</replaceable>
+ | [DEFAULT] COLLATE <replaceable>collation_name</replaceable>
+ </programlisting>
+
+ <!-- description_for_help_topic CREATE DATABASE CREATE DATABASE SCHEMA IF EXISTS NOT -->
+
+ <para>
+ <literal>CREATE DATABASE</literal> creates a database with the given
+ name. To use <literal>CREATE DATABASE</literal>, you need the
+ <literal>CREATE</literal> privilege on the database.
+
+ <!-- end_description_for_help_topic -->
+ </para>
+
+ <para>
+ Rules for allowable database names are given in
+ <xref linkend="legal-names"/>. An error occurs if the database
+ exists and you didn't specify <literal>IF NOT EXISTS</literal>.
+ </para>
+
+ <para>
+ As of MySQL 4.1.1, <literal>create_specification</literal> options
+ can be given to specify database characteristics. Database
+ characteristics are stored in the <filename>db.opt</filename> file
+ in the database directory. The <literal>CHARACTER SET</literal>
+ clause specifies the default database character set. The
+ <literal>COLLATE</literal> clause specifies the default database
+ collation. Character set and collation names are discussed in
+ <xref linkend="charset"/>.
+ </para>
+
+ <para>
+ Databases in MySQL are implemented as directories containing files
+ that correspond to tables in the database. Because there are no
+ tables in a database when it is initially created, the
+ <literal>CREATE DATABASE</literal> statement only creates a
+ directory under the MySQL data directory (and the
+ <filename>db.opt</filename> file, for MySQL 4.1.1 and up).
+ </para>
+
+ <para>
+ If you manually create a directory under the data directory (for
+ example, with <command>mkdir</command>), the server considers it a
+ database directory and it shows up in the output of <literal>SHOW
+ DATABASES</literal>.
+ </para>
+
+ <para>
+ <literal>CREATE SCHEMA</literal> can be used as of MySQL 5.0.2.
+ </para>
+
+ <indexterm type="concept">
+ <primary><command>mysqladmin</command></primary>
+ </indexterm>
+
+ <para>
+ You can also use the <command>mysqladmin</command> program to create
+ databases. See <xref linkend="mysqladmin"/>.
+ </para>
+
+ </section>
+
+ <section id="create-index">
+
+ <title id='title-create-index'>&title-create-index;</title>
+
+ <indexterm type="function">
+ <primary>CREATE INDEX</primary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>indexes</primary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>indexes</primary>
+ <secondary>multiple-part</secondary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>multiple-part index</primary>
+ </indexterm>
+
+ <!-- example_for_help_topic CREATE INDEX -->
+
+ <programlisting>
+ CREATE [UNIQUE|FULLTEXT|SPATIAL] INDEX <replaceable>index_name</replaceable>
+ [USING <replaceable>index_type</replaceable>]
+ ON <replaceable>tbl_name</replaceable> (<replaceable>index_col_name</replaceable>,...)
+
+ <replaceable>index_col_name</replaceable>:
+ <replaceable>col_name</replaceable> [(<replaceable>length</replaceable>)] [ASC | DESC]
+ </programlisting>
+
+ <!-- description_for_help_topic CREATE INDEX BTREE RTREE INDEX CREATE FULLTEXT SPATIAL -->
+
+ <para>
+ In MySQL 3.22 or later, <literal>CREATE INDEX</literal> is mapped to
+ an <literal>ALTER TABLE</literal> statement to create indexes. See
+ <xref linkend="alter-table"/>. The <literal>CREATE INDEX</literal>
+ statement doesn't do anything prior to MySQL 3.22.
+
+ <!-- end_description_for_help_topic -->
+ </para>
+
+ <para>
+ Normally, you create all indexes on a table at the time the table
+ itself is created with <literal>CREATE TABLE</literal>. See
+ <xref linkend="create-table"/>. <literal>CREATE INDEX</literal>
+ allows you to add indexes to existing tables.
+ </para>
+
+ <para>
+ A column list of the form <literal>(col1,col2,...)</literal> creates
+ a multiple-column index. Index values are formed by concatenating
+ the values of the given columns.
+ </para>
+
+ <para>
+ For <literal>CHAR</literal> and <literal>VARCHAR</literal> columns,
+ indexes can be created that use only part of a column, using
+ <literal><replaceable>col_name</replaceable>(<replaceable>length</replaceable>)</literal>
+ syntax to index a prefix consisting of the first
+ <replaceable>length</replaceable> characters of each column value.
+ <literal>BLOB</literal> and <literal>TEXT</literal> columns also can
+ be indexed, but a prefix length <emphasis>must</emphasis> be given.
+ </para>
+
+ <para>
+ The statement shown here creates an index using the first 10
+ characters of the <literal>name</literal> column:
+ </para>
+
+ <programlisting>
+ CREATE INDEX part_of_name ON customer (name(10));
+ </programlisting>
+
+ <para>
+ Because most names usually differ in the first 10 characters, this
+ index should not be much slower than an index created from the
+ entire <literal>name</literal> column. Also, using partial columns
+ for indexes can make the index file much smaller, which could save a
+ lot of disk space and might also speed up <literal>INSERT</literal>
+ operations!
+ </para>
+
+ <para>
+ Prefixes can be up to 255 bytes long (or 1000 bytes for
+ <literal>MyISAM</literal> and <literal>InnoDB</literal> tables as of
+ MySQL 4.1.2). Note that prefix limits are measured in bytes, whereas
+ the prefix length in <literal>CREATE INDEX</literal> statements is
+ interpreted as number of characters. Take this into account when
+ specifying a prefix length for a column that uses a multi-byte
+ character set.
+ </para>
+
+ <para>
+ You can add an index on a column that can have
+ <literal>NULL</literal> values only if you are using MySQL 3.23.2 or
+ newer and are using the <literal>MyISAM</literal>,
+ <literal>InnoDB</literal>, or <literal>BDB</literal> table type. You
+ can only add an index on a <literal>BLOB</literal> or
+ <literal>TEXT</literal> column if you are using MySQL 3.23.2 or
+ newer and are using the <literal>MyISAM</literal> or
+ <literal>BDB</literal> table type, or MySQL 4.0.14 or newer and the
+ <literal>InnoDB</literal> table type.
+ </para>
+
+ <para>
+ An <replaceable>index_col_name</replaceable> specification can end
+ with <literal>ASC</literal> or <literal>DESC</literal>. 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.
+ </para>
+
+ <para>
+ From MySQL 4.1.0 on, some storage engines allow you to specify an
+ index type when creating an index. The syntax for the
+ <replaceable>index_type</replaceable> specifier is <literal>USING
+ type_name</literal>. The allowable <literal>type_name</literal>
+ 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 <replaceable>index_type</replaceable>
+ specifier is given.
+ </para>
+
+ <informaltable>
+ <tgroup cols="2">
+ <colspec colwidth="20*"/>
+ <colspec colwidth="50*"/>
+ <tbody>
+ <row>
+ <entry>
+ <emphasis role="bold">Storage Engine</emphasis>
+ </entry>
+ <entry>
+ <emphasis role="bold">Allowable Index Types</emphasis>
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <literal>MyISAM</literal>
+ </entry>
+ <entry>
+ <literal>BTREE</literal>
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <literal>InnoDB</literal>
+ </entry>
+ <entry>
+ <literal>BTREE</literal>
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <literal>MEMORY/HEAP</literal>
+ </entry>
+ <entry>
+ <literal>HASH</literal>, <literal>BTREE</literal>
+ </entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </informaltable>
+
+ <para>
+ Example:
+ </para>
+
+ <programlisting>
+ CREATE TABLE lookup (id INT) ENGINE = MEMORY;
+ CREATE INDEX id_index USING BTREE ON lookup (id);
+ </programlisting>
+
+ <para>
+ <literal>TYPE type_name</literal> can be used as a synonym for
+ <literal>USING type_name</literal> to specify an index type.
+ However, <literal>USING</literal> is the preferred form. Also, the
+ index name that precedes the index type in the index specification
+ syntax is not optional with <literal>TYPE</literal>. This is
+ because, unlike <literal>USING</literal>, <literal>TYPE</literal> is
+ not a reserved word and thus is interpreted as an index name.
+ </para>
+
+ <para>
+ If you specify an index type that is not legal for a storage engine,
+ but there is another index type available that the engine can use
+ without affecting query results, the engine uses the available type.
+ </para>
+
+ <para>
+ For more information about how MySQL uses indexes, see
+ <xref linkend="mysql-indexes"/>.
+ </para>
+
+ <para>
+ <literal>FULLTEXT</literal> indexes can index only
+ <literal>CHAR</literal>, <literal>VARCHAR</literal>, and
+ <literal>TEXT</literal> columns, and only in
+ <literal>MyISAM</literal> tables. <literal>FULLTEXT</literal>
+ indexes are available in MySQL 3.23.23 or later.
+ <xref linkend="fulltext-search"/>.
+ </para>
+
+ <para>
+ <literal>SPATIAL</literal> indexes can index only spatial columns,
+ and only in <literal>MyISAM</literal> tables.
+ <literal>SPATIAL</literal> indexes are available in MySQL 4.1 or
+ later. Spatial column types are described in
+ <xref linkend="spatial-extensions-in-mysql"/>.
+ </para>
+
+ </section>
+
+ <section id="create-table">
+
+ <title id='title-create-table'>&title-create-table;</title>
+
+ <indexterm type="function">
+ <primary>CREATE TABLE</primary>
+ </indexterm>
+
+ <!-- example_for_help_topic CREATE TABLE -->
+
+ <programlisting>
+ CREATE [TEMPORARY] TABLE [IF NOT EXISTS] <replaceable>tbl_name</replaceable>
+ [(<replaceable>create_definition</replaceable>,...)]
+ [<replaceable>table_options</replaceable>] [<replaceable>select_statement</replaceable>]
+ </programlisting>
+
+ <para>
+ Or:
+ </para>
+
+ <programlisting>
+ CREATE [TEMPORARY] TABLE [IF NOT EXISTS] <replaceable>tbl_name</replaceable>
+ [(] LIKE <replaceable>old_tbl_name</replaceable> [)];
+
+ <replaceable>create_definition</replaceable>:
+ <replaceable>column_definition</replaceable>
+ | [CONSTRAINT [<replaceable>symbol</replaceable>]] PRIMARY KEY [<replaceable>index_type</replaceable>] (<replaceable>index_col_name</replaceable>,...)
+ | KEY [<replaceable>index_name</replaceable>] [<replaceable>index_type</replaceable>] (<replaceable>index_col_name</replaceable>,...)
+ | INDEX [<replaceable>index_name</replaceable>] [<replaceable>index_type</replaceable>] (<replaceable>index_col_name</replaceable>,...)
+ | [CONSTRAINT [<replaceable>symbol</replaceable>]] UNIQUE [INDEX]
+ [<replaceable>index_name</replaceable>] [<replaceable>index_type</replaceable>] (<replaceable>index_col_name</replaceable>,...)
+ | [FULLTEXT|SPATIAL] [INDEX] [<replaceable>index_name</replaceable>] (<replaceable>index_col_name</replaceable>,...)
+ | [CONSTRAINT [<replaceable>symbol</replaceable>]] FOREIGN KEY
+ [<replaceable>index_name</replaceable>] (<replaceable>index_col_name</replaceable>,...) [<replaceable>reference_definition</replaceable>]
+ | CHECK (<replaceable>expr</replaceable>)
+
+ <replaceable>column_definition</replaceable>:
+ <replaceable>col_name</replaceable> <replaceable>type</replaceable> [NOT NULL | NULL] [DEFAULT <replaceable>default_value</replaceable>]
+ [AUTO_INCREMENT] [UNIQUE [KEY] | [PRIMARY] KEY]
+ [COMMENT '<replaceable>string</replaceable>'] [<replaceable>reference_definition</replaceable>]
+
+ <replaceable>type</replaceable>:
+ TINYINT[(<replaceable>length</replaceable>)] [UNSIGNED] [ZEROFILL]
+ | SMALLINT[(<replaceable>length</replaceable>)] [UNSIGNED] [ZEROFILL]
+ | MEDIUMINT[(<replaceable>length</replaceable>)] [UNSIGNED] [ZEROFILL]
+ | INT[(<replaceable>length</replaceable>)] [UNSIGNED] [ZEROFILL]
+ | INTEGER[(<replaceable>length</replaceable>)] [UNSIGNED] [ZEROFILL]
+ | BIGINT[(<replaceable>length</replaceable>)] [UNSIGNED] [ZEROFILL]
+ | REAL[(<replaceable>length</replaceable>,<replaceable>decimals</replaceable>)] [UNSIGNED] [ZEROFILL]
+ | DOUBLE[(<replaceable>length</replaceable>,<replaceable>decimals</replaceable>)] [UNSIGNED] [ZEROFILL]
+ | FLOAT[(<replaceable>length</replaceable>,<replaceable>decimals</replaceable>)] [UNSIGNED] [ZEROFILL]
+ | DECIMAL(<replaceable>length</replaceable>,<replaceable>decimals</replaceable>) [UNSIGNED] [ZEROFILL]
+ | NUMERIC(<replaceable>length</replaceable>,<replaceable>decimals</replaceable>) [UNSIGNED] [ZEROFILL]
+ | DATE
+ | TIME
+ | TIMESTAMP
+ | DATETIME
+ | CHAR(<replaceable>length</replaceable>) [BINARY | ASCII | UNICODE]
+ | VARCHAR(<replaceable>length</replaceable>) [BINARY]
+ | TINYBLOB
+ | BLOB
+ | MEDIUMBLOB
+ | LONGBLOB
+ | TINYTEXT [BINARY]
+ | TEXT [BINARY]
+ | MEDIUMTEXT [BINARY]
+ | LONGTEXT [BINARY]
+ | ENUM(<replaceable>value1</replaceable>,<replaceable>value2</replaceable>,<replaceable>value3</replaceable>,...)
+ | SET(<replaceable>value1</replaceable>,<replaceable>value2</replaceable>,<replaceable>value3</replaceable>,...)
+ | <replaceable>spatial_type</replaceable>
+
+ <replaceable>index_col_name</replaceable>:
+ <replaceable>col_name</replaceable> [(<replaceable>length</replaceable>)] [ASC | DESC]
+
+ <replaceable>reference_definition</replaceable>:
+ REFERENCES <replaceable>tbl_name</replaceable> [(<replaceable>index_col_name</replaceable>,...)]
+ [MATCH FULL | MATCH PARTIAL | MATCH SIMPLE]
+ [ON DELETE <replaceable>reference_option</replaceable>]
+ [ON UPDATE <replaceable>reference_option</replaceable>]
+
+ <replaceable>reference_option</replaceable>:
+ RESTRICT | CASCADE | SET NULL | NO ACTION
+
+ <replaceable>table_options</replaceable>: <replaceable>table_option</replaceable> [<replaceable>table_option</replaceable>] ...
+
+ <replaceable>table_option</replaceable>:
+ {ENGINE|TYPE} = <replaceable>engine_name</replaceable>
+ | AUTO_INCREMENT = <replaceable>value</replaceable>
+ | AVG_ROW_LENGTH = <replaceable>value</replaceable>
+ | [DEFAULT] CHARACTER SET <replaceable>charset_name</replaceable> [COLLATE <replaceable>collation_name</replaceable>]
+ | CHECKSUM = {0 | 1}
+ | COMMENT = '<replaceable>string</replaceable>'
+ | MAX_ROWS = <replaceable>value</replaceable>
+ | MIN_ROWS = <replaceable>value</replaceable>
+ | PACK_KEYS = {0 | 1 | DEFAULT}
+ | PASSWORD = '<replaceable>string</replaceable>'
+ | DELAY_KEY_WRITE = {0 | 1}
+ | ROW_FORMAT = {DEFAULT|DYNAMIC|FIXED|COMPRESSED|REDUNDANT|COMPACT}
+ | RAID_TYPE = { 1 | STRIPED | RAID0 }
+ RAID_CHUNKS = <replaceable>value</replaceable>
+ RAID_CHUNKSIZE = <replaceable>value</replaceable>
+ | UNION = (<replaceable>tbl_name</replaceable>[,<replaceable>tbl_name</replaceable>]...)
+ | INSERT_METHOD = { NO | FIRST | LAST }
+ | DATA DIRECTORY = '<replaceable>absolute path to directory</replaceable>'
+ | INDEX DIRECTORY = '<replaceable>absolute path to directory</replaceable>'
+
+ <replaceable>select_statement:</replaceable>
+ [IGNORE | REPLACE] [AS] SELECT ... (<replaceable>Some legal select statement</replaceable>)
+ </programlisting>
+
+ <!-- description_for_help_topic CREATE TABLE ENGINE TYPE KEY CREATE DATA ACTION ARCHIVE AVG_ROW_LENGTH BERKELEYDB BDB BY CASCADE CHECK CHECKSUM COMMENT COMPACT CONSTRAINT COMPRESSED CSV FEDERATED FIXED DYNAMIC DEFAULT DELAY_KEY_WRITE DELETE DIRECTORY INDEX FIRST FOREIGN RAID_TYPE RAID_CHUNKS RAID_CHUNKSIZE ROW_FORMAT FULL FULLTEXT HEAP INNOBASE INNODB ISAM INSERT_METHOD MAX_ROWS MIN_ROWS PACK_KEYS PARTIAL RAID0 STRIPED MERGE MRG_MYISAM MYISAM NDB NDBCLUSTER NO REDUNDANT REFERENCES SERIAL -->
+
+ <para>
+ <literal>CREATE TABLE</literal> creates a table with the given name.
+ You must have the <literal>CREATE</literal> privilege for the table.
+ </para>
+
+ <para>
+ Rules for allowable table names are given in
+ <xref linkend="legal-names"/>. By default, the table is created in
+ the current database. An error occurs if the table exists, if there
+ is no current database, or if the database does not exist.
+
+ <!-- end_description_for_help_topic -->
+ </para>
+
+ <para>
+ In MySQL 3.22 or later, the table name can be specified as
+ <replaceable>db_name.tbl_name</replaceable> to create the table in a
+ specific database. This works whether or not there is a current
+ database. If you use quoted identifiers, quote the database and
+ table names separately. For example,
+ <literal>`mydb`.`mytbl`</literal> is legal, but
+ <literal>`mydb.mytbl`</literal> is not.
+ </para>
+
+ <para>
+ From MySQL 3.23 on, you can use the <literal>TEMPORARY</literal>
+ keyword when creating a table. A <literal>TEMPORARY</literal> 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-<literal>TEMPORARY</literal> table of the same name. (The
+ existing table is hidden until the temporary table is dropped.) From
+ MySQL 4.0.2 on, you must have the <literal>CREATE TEMPORARY
+ TABLES</literal> privilege to be able to create temporary tables.
+ </para>
+
+ <para>
+ In MySQL 3.23 or later, you can use the keywords <literal>IF NOT
+ EXISTS</literal> so that an error does not occur if the table
+ exists. Note that there is no verification that the existing table
+ has a structure identical to that indicated by the <literal>CREATE
+ TABLE</literal> statement. Also, if you use <literal>IF NOT
+ EXISTS</literal> in a <literal>CREATE TABLE ... SELECT</literal>
+ statement, any records selected by the <literal>SELECT</literal>
+ part are inserted regardless of whether the table already exists.
+ </para>
+
+ <para>
+ MySQL represents each table by an <filename>.frm</filename> table
+ format (definition) file in the database directory. The storage
+ engine for the table might create other files as well. In the case
+ of <literal>MyISAM</literal> tables, the storage engine creates data
+ and index files. Thus, for each <literal>MyISAM</literal> table
+ <replaceable>tbl_name</replaceable>, there are three disk files:
+ </para>
+
+ <informaltable>
+ <tgroup cols="2">
+ <colspec colwidth="30*"/>
+ <colspec colwidth="70*"/>
+ <tbody>
+ <row>
+ <entry>
+ <emphasis role="bold">File</emphasis>
+ </entry>
+ <entry>
+ <emphasis role="bold">Purpose</emphasis>
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <literal><replaceable>tbl_name</replaceable>.frm</literal>
+ </entry>
+ <entry>
+ Table format (definition) file
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <literal><replaceable>tbl_name</replaceable>.MYD</literal>
+ </entry>
+ <entry>
+ Data file
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <literal><replaceable>tbl_name</replaceable>.MYI</literal>
+ </entry>
+ <entry>
+ Index file
+ </entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </informaltable>
+
+ <para>
+ The files created by each storage engine to represent tables are
+ described in <xref linkend="storage-engines"/>.
+ </para>
+
+ <para>
+ For general information on the properties of the various column
+ types, see <xref linkend="column-types"/>. For information about
+ spatial column types, see
+ <xref linkend="spatial-extensions-in-mysql"/>.
+ </para>
+
+ <itemizedlist>
+
+ <listitem><para>
+ If neither <literal>NULL</literal> nor <literal>NOT NULL</literal>
+ is specified, the column is treated as though
+ <literal>NULL</literal> had been specified.
+ </para></listitem>
+
+ <listitem><para>
+ An integer column can have the additional attribute
+ <literal>AUTO_INCREMENT</literal>. When you insert a value of
+ <literal>NULL</literal> (recommended) or <literal>0</literal> into
+ an indexed <literal>AUTO_INCREMENT</literal> column, the column is
+ set to the next sequence value. Typically this is
+ <literal><replaceable>value</replaceable>+1</literal>, where
+ <replaceable>value</replaceable> is the largest value for the
+ column currently in the table. <literal>AUTO_INCREMENT</literal>
+ sequences begin with <literal>1</literal>. Such a column must be
+ defined as one of the integer types as described in
+ <xref linkend="numeric-type-overview"/>. (The value 1.0 is
+ <emphasis role="bold">not</emphasis> an integer.) See
+ <xref linkend="mysql-insert-id"/>.
+ </para>
+
+ <para>
+ As of MySQL 4.1.1, specifying the
+ <literal>NO_AUTO_VALUE_ON_ZERO</literal> flag for the
+ <literal>--sql-mode</literal> server option or the
+ <literal>sql_mode</literal> system variable allows you to store
+ <literal>0</literal> in <literal>AUTO_INCREMENT</literal> columns
+ as <literal>0</literal> without generating a new sequence value.
+ See <xref linkend="server-options"/>.
+ </para>
+
+ <para>
+ <emphasis role="bold">Note</emphasis>: There can be only one
+ <literal>AUTO_INCREMENT</literal> column per table, it must be
+ indexed, and it cannot have a <literal>DEFAULT</literal> value. As
+ of MySQL 3.23, an <literal>AUTO_INCREMENT</literal> 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
+ ``wrap'' over from positive to negative and also to ensure that you
+ don't accidentally get an <literal>AUTO_INCREMENT</literal> column
+ that contains <literal>0</literal>.
+ </para>
+
+ <para>
+ For <literal>MyISAM</literal> and <literal>BDB</literal> tables,
+ you can specify an <literal>AUTO_INCREMENT</literal> secondary
+ column in a multiple-column key. See
+ <xref linkend="example-auto-increment"/>.
+ </para>
+
+ <indexterm type="concept">
+ <primary>ODBC compatibility</primary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>compatibility</primary>
+ <secondary>with ODBC</secondary>
+ </indexterm>
+
+ <para>
+ To make MySQL compatible with some ODBC applications, you can find
+ the <literal>AUTO_INCREMENT</literal> value for the last inserted
+ row with the following query:
+ </para>
+
+ <programlisting>
+ SELECT * FROM <replaceable>tbl_name</replaceable> WHERE <replaceable>auto_col</replaceable> IS NULL
+ </programlisting></listitem>
+
+ <listitem><para>
+ As of MySQL 4.1, character column definitions can include a
+ <literal>CHARACTER SET</literal> attribute to specify the character
+ set and, optionally, a collation for the column. For details, see
+ <xref linkend="charset"/>. <literal>CHARSET</literal> is a synonym
+ for <literal>CHARACTER SET</literal>.
+ </para>
+
+ <programlisting>
+ CREATE TABLE t (c CHAR(20) CHARACTER SET utf8 COLLATE utf8_bin);
+ </programlisting>
+
+ <para>
+ Also as of 4.1, MySQL interprets length specifications in character
+ column definitions in characters. (Earlier versions interpret them
+ in bytes.)
+ </para></listitem>
+
+ <listitem><para>
+ <literal>NULL</literal> values are handled differently for
+ <literal>TIMESTAMP</literal> columns than for other column types.
+ Before MySQL 4.1.6, you cannot store a literal
+ <literal>NULL</literal> in a <literal>TIMESTAMP</literal> column;
+ setting the column to <literal>NULL</literal> sets it to the
+ current date and time. Because <literal>TIMESTAMP</literal> columns
+ behave this way, the <literal>NULL</literal> and <literal>NOT
+ NULL</literal> attributes do not apply in the normal way and are
+ ignored if you specify them. On the other hand, to make it easier
+ for MySQL clients to use <literal>TIMESTAMP</literal> columns, the
+ server reports that such columns can be assigned
+ <literal>NULL</literal> values (which is true), even though
+ <literal>TIMESTAMP</literal> never actually contains a
+ <literal>NULL</literal> value. You can see this when you use
+ <literal>DESCRIBE <replaceable>tbl_name</replaceable></literal> to
+ get a description of your table.
+ </para>
+
+ <para>
+ Note that setting a <literal>TIMESTAMP</literal> column to
+ <literal>0</literal> is not the same as setting it to
+ <literal>NULL</literal>, because <literal>0</literal> is a valid
+ <literal>TIMESTAMP</literal> value.
+ </para></listitem>
+
+ <listitem><indexterm type="concept">
+ <primary>default values</primary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>default values</primary>
+ <secondary>implicit</secondary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>implicit default values</primary>
+ </indexterm>
+
+ <indexterm type="function">
+ <primary>DEFAULT value clause</primary>
+ </indexterm>
+
+ <para>
+ The <literal>DEFAULT</literal> 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 <literal>NOW()</literal> or
+ <literal>CURRENT_DATE</literal>. The exception is that you can
+ specify <literal>CURRENT_TIMESTAMP</literal> as the default for a
+ <literal>TIMESTAMP</literal> column as of MySQL 4.1.2. See
+ <xref linkend="timestamp-4-1"/>.
+ </para>
+
+ <para>
+ Prior to MySQL 5.0.2, if a column definition includes no explicit
+ <literal>DEFAULT</literal> value, MySQL determines the default
+ value as follows:
+ </para>
+
+ <para>
+ If the column can take <literal>NULL</literal> as a value, the
+ column is defined with an explicit <literal>DEFAULT NULL</literal>
+ clause.
+ </para>
+
+ <para>
+ If the column cannot take <literal>NULL</literal> as the value,
+ MySQL defines the column with an explicit
+ <literal>DEFAULT</literal> clause, using the implicit default value
+ for the column data type. Implicit defaults are defined as follows:
+ </para>
+
+ <itemizedlist>
+
+ <listitem><para>
+ For numeric types other than those declared with the
+ <literal>AUTO_INCREMENT</literal> attribute, the default is
+ <literal>0</literal>. For an <literal>AUTO_INCREMENT</literal>
+ column, the default value is the next value in the sequence.
+ </para></listitem>
+
+ <listitem><para>
+ For date and time types other than <literal>TIMESTAMP</literal>,
+ the default is the appropriate ``zero'' value for the type. For
+ the first <literal>TIMESTAMP</literal> column in a table, the
+ default value is the current date and time. See
+ <xref linkend="date-and-time-types"/>.
+ </para></listitem>
+
+ <listitem><para>
+ For string types other than <literal>ENUM</literal>, the default
+ value is the empty string. For <literal>ENUM</literal>, the
+ default is the first enumeration value.
+ </para></listitem>
+
+ </itemizedlist>
+
+ <para>
+ <literal>BLOB</literal> and <literal>TEXT</literal> columns cannot
+ be assigned a default value.
+ </para>
+
+ <para>
+ As of MySQL 5.0.2, if a column definition includes no explicit
+ <literal>DEFAULT</literal> value, MySQL determines the default
+ value as follows:
+ </para>
+
+ <para>
+ If the column can take <literal>NULL</literal> as a value, the
+ column is defined with an explicit <literal>DEFAULT NULL</literal>
+ clause. This is the same as before 5.0.2.
+ </para>
+
+ <para>
+ If the column cannot take <literal>NULL</literal> as the value,
+ MySQL defines the column with no explicit
+ <literal>DEFAULT</literal> clause. For data entry, if an
+ <literal>INSERT</literal> or <literal>REPLACE</literal> statement
+ includes no value for the column, MySQL handles the column
+ according to the SQL mode in effect at the time:
+ </para>
+
+ <itemizedlist>
+
+ <listitem><para>
+ If strict mode is not enabled, MySQL sets the column to the
+ implicit default value for the column data type.
+ </para></listitem>
+
+ <listitem><para>
+ If strict mode is enabled, an error occurs for transactional
+ tables and the statement is rolled back. For non-transactional
+ tables, an error occurs, but if this happens for the the second or
+ subsequent row of a multiple-row statement, the preceding rows
+ will have been inserted.
+ </para></listitem>
+
+ </itemizedlist>
+
+ <para>
+ Suppose that a table <literal>t</literal> is defined as follows:
+ </para>
+
+ <programlisting>
+ CREATE TABLE t (i INT NOT NULL);
+ </programlisting>
+
+ <para>
+ In this case, <literal>i</literal> has no explicit default, so in
+ strict mode all of the following statements produce an error in
+ strict mode and no row is inserted. For non strict mode, only the
+ third statement produces an error; the implicit default is inserted
+ for the first two, but the third fails because
+ <literal>DEFAULT(i)</literal> cannot produce a value:
+ </para>
+
+ <programlisting>
+ INSERT INTO t VALUES();
+ INSERT INTO t VALUES(DEFAULT);
+ INSERT INTO t VALUES(DEFAULT(i));
+ </programlisting>
+
+ <para>
+ See <xref linkend="server-sql-mode"/>.
+ </para>
+
+ <para>
+ For a given table, you can use the <literal>SHOW CREATE
+ TABLE</literal> statement to see which columns have an explicit
+ <literal>DEFAULT</literal> clause.
+ </para></listitem>
+
+ <listitem><indexterm type="concept">
+ <primary>column comments</primary>
+ </indexterm>
+
+ <para>
+ A comment for a column can be specified with the
+ <literal>COMMENT</literal> option. The comment is displayed by the
+ <literal>SHOW CREATE TABLE</literal> and <literal>SHOW FULL
+ COLUMNS</literal> statements. This option is operational as of
+ MySQL 4.1. (It is allowed but ignored in earlier versions.)
+ </para></listitem>
+
+ <listitem><para>
+ From MySQL 4.1.0 on, the attribute <literal>SERIAL</literal> can be
+ used as an alias for <literal>BIGINT UNSIGNED NOT NULL
+ AUTO_INCREMENT UNIQUE</literal>.
+ </para></listitem>
+
+ <listitem><para>
+ <literal>KEY</literal> is normally a synonym for
+ <literal>INDEX</literal>. From MySQL 4.1, the key attribute
+ <literal>PRIMARY KEY</literal> can also be specified as just
+ <literal>KEY</literal> when given in a column definition. This was
+ implemented for compatibility with other database systems.
+ </para></listitem>
+
+ <listitem><para>
+ In MySQL, a <literal>UNIQUE</literal> index is one in which all
+ values in the index must be distinct. An error occurs if you try to
+ add a new row with a key that matches an existing row. The
+ exception to this is that if a column in the index is allowed to
+ contain <literal>NULL</literal> values, it can contain multiple
+ <literal>NULL</literal> values. This exception does not apply to
+ <literal>BDB</literal> tables, for which an indexed column allows
+ only a single <literal>NULL</literal>.
+ </para></listitem>
+
+ <listitem><indexterm type="type">
+ <primary>PRIMARY KEY</primary>
+ </indexterm>
+
+ <para>
+ A <literal>PRIMARY KEY</literal> is a unique <literal>KEY</literal>
+ where all key columns must be defined as <literal>NOT
+ NULL</literal>. If they are not explicitly declared as <literal>NOT
+ NULL</literal>, MySQL declares them so implicitly (and silently). A
+ table can have only one <literal>PRIMARY KEY</literal>. If you
+ don't have a <literal>PRIMARY KEY</literal> and an application asks
+ for the <literal>PRIMARY KEY</literal> in your tables, MySQL
+ returns the first <literal>UNIQUE</literal> index that has no
+ <literal>NULL</literal> columns as the <literal>PRIMARY
+ KEY</literal>.
+ </para></listitem>
+
+ <listitem><para>
+ In the created table, a <literal>PRIMARY KEY</literal> is placed
+ first, followed by all <literal>UNIQUE</literal> 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 <literal>UNIQUE</literal> keys.
+ </para></listitem>
+
+ <listitem><para>
+ A <literal>PRIMARY KEY</literal> can be a multiple-column index.
+ However, you cannot create a multiple-column index using the
+ <literal>PRIMARY KEY</literal> key attribute in a column
+ specification. Doing so only marks that single column as primary.
+ You must use a separate <literal>PRIMARY KEY(index_col_name,
+ ...)</literal> clause.
+ </para></listitem>
+
+ <listitem><para>
+ If a <literal>PRIMARY KEY</literal> or <literal>UNIQUE</literal>
+ index consists of only one column that has an integer type, you can
+ also refer to the column as <literal>_rowid</literal> in
+ <literal>SELECT</literal> statements (new in MySQL 3.23.11).
+ </para></listitem>
+
+ <listitem><para>
+ In MySQL, the name of a <literal>PRIMARY KEY</literal> is
+ <literal>PRIMARY</literal>. For other indexes, if you don't assign
+ a name, the index is assigned the same name as the first indexed
+ column, with an optional suffix (<literal>_2</literal>,
+ <literal>_3</literal>, <literal>...</literal>) to make it unique.
+ You can see index names for a table using <literal>SHOW INDEX FROM
+ <replaceable>tbl_name</replaceable></literal>. See
+ <xref linkend="show-index"/>.
+ </para></listitem>
+
+ <listitem><para>
+ From MySQL 4.1.0 on, some storage engines allow you to specify an
+ index type when creating an index. The syntax for the
+ <replaceable>index_type</replaceable> specifier is <literal>USING
+ type_name</literal>.
+ </para>
+
+ <para>
+ Example:
+ </para>
+
+ <programlisting>
+ CREATE TABLE lookup
+ (id INT, INDEX USING BTREE (id))
+ ENGINE = MEMORY;
+ </programlisting>
+
+ <para>
+ For details about <literal>USING</literal>, see
+ <xref linkend="create-index"/>.
+ </para>
+
+ <para>
+ For more information about how MySQL uses indexes, see
+ <xref linkend="mysql-indexes"/>.
+ </para></listitem>
+
+ <listitem><indexterm type="concept">
+ <primary><literal>NULL</literal> values</primary>
+ <secondary>and indexes</secondary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>indexes</primary>
+ <secondary>and <literal>NULL</literal> values</secondary>
+ </indexterm>
+
+ <para>
+ Only the <literal>MyISAM</literal>, <literal>InnoDB</literal>,
+ <literal>BDB</literal>, and (as of MySQL 4.0.2)
+ <literal>MEMORY</literal> storage engines support indexes on
+ columns that can have <literal>NULL</literal> values. In other
+ cases, you must declare indexed columns as <literal>NOT
+ NULL</literal> or an error results.
+ </para></listitem>
+
+ <listitem><para>
+ With
+ <literal><replaceable>col_name</replaceable>(<replaceable>length</replaceable>)</literal>
+ syntax in an index specification, you can create an index that uses
+ only the first <replaceable>length</replaceable> characters of a
+ <literal>CHAR</literal> or <literal>VARCHAR</literal> column.
+ Indexing only a prefix of column values like this can make the
+ index file much smaller. See <xref linkend="indexes"/>.
+ </para>
+
+ <indexterm type="concept">
+ <primary><literal>BLOB</literal> columns</primary>
+ <secondary>indexing</secondary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>indexes</primary>
+ <secondary>and <literal>BLOB</literal> columns</secondary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary><literal>TEXT</literal> columns</primary>
+ <secondary>indexing</secondary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>indexes</primary>
+ <secondary>and <literal>TEXT</literal> columns</secondary>
+ </indexterm>
+
+ <para>
+ The <literal>MyISAM</literal> and (as of MySQL 4.0.14)
+ <literal>InnoDB</literal> storage engines also support indexing on
+ <literal>BLOB</literal> and <literal>TEXT</literal> columns. When
+ indexing a <literal>BLOB</literal> or <literal>TEXT</literal>
+ column, you <emphasis>must</emphasis> specify a prefix length for
+ the index. For example:
+ </para>
+
+ <programlisting>
+ CREATE TABLE test (blob_col BLOB, INDEX(blob_col(10)));
+ </programlisting>
+
+ <para>
+ Prefixes can be up to 255 bytes long (or 1000 bytes for
+ <literal>MyISAM</literal> and <literal>InnoDB</literal> tables as
+ of MySQL 4.1.2). Note that prefix limits are measured in bytes,
+ whereas the prefix length in <literal>CREATE TABLE</literal>
+ statements is interpreted as number of characters. Take this into
+ account when specifying a prefix length for a column that uses a
+ multi-byte character set.
+ </para></listitem>
+
+ <listitem><para>
+ An <replaceable>index_col_name</replaceable> specification can end
+ with <literal>ASC</literal> or <literal>DESC</literal>. 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.
+ </para></listitem>
+
+ <listitem><para>
+ When you use <literal>ORDER BY</literal> or <literal>GROUP
+ BY</literal> with a <literal>TEXT</literal> or
+ <literal>BLOB</literal> column, the server sorts values using only
+ the initial number of bytes indicated by the
+ <literal>max_sort_length</literal> system variable. See
+ <xref linkend="blob"/>.
+ </para></listitem>
+
+ <listitem><para>
+ In MySQL 3.23.23 or later, you can create special
+ <literal>FULLTEXT</literal> indexes. They are used for full-text
+ search. Only the <literal>MyISAM</literal> table type supports
+ <literal>FULLTEXT</literal> indexes. They can be created only from
+ <literal>CHAR</literal>, <literal>VARCHAR</literal>, and
+ <literal>TEXT</literal> columns. Indexing always happens over the
+ entire column; partial indexing is not supported and any prefix
+ length is ignored if specified. See
+ <xref linkend="fulltext-search"/> for details of operation.
+ </para></listitem>
+
+ <listitem><para>
+ In MySQL 4.1 or later, you can create <literal>SPATIAL</literal>
+ indexes on spatial column types. Spatial types are supported only
+ for <literal>MyISAM</literal> tables and indexed columns must be
+ declared as <literal>NOT NULL</literal>. See
+ <xref linkend="spatial-extensions-in-mysql"/>.
+ </para></listitem>
+
+ <listitem><para>
+ In MySQL 3.23.44 or later, <literal>InnoDB</literal> tables support
+ checking of foreign key constraints. See <xref linkend="innodb"/>.
+ Note that the <literal>FOREIGN KEY</literal> syntax in
+ <literal>InnoDB</literal> is more restrictive than the syntax
+ presented for the <literal>CREATE TABLE</literal> statement at the
+ beginning of this section: The columns of the referenced table must
+ always be explicitly named. <literal>InnoDB</literal> supports both
+ <literal>ON DELETE</literal> and <literal>ON UPDATE</literal>
+ actions on foreign keys as of MySQL 3.23.50 and 4.0.8,
+ respectively. For the precise syntax, see
+ <xref linkend="innodb-foreign-key-constraints"/>.
+ </para>
+
+ <para>
+ For other storage engines, MySQL Server parses the <literal>FOREIGN
+ KEY</literal> and <literal>REFERENCES</literal> syntax in
+ <literal>CREATE TABLE</literal> statements, but without further
+ action being taken. The <literal>CHECK</literal> clause is parsed
+ but ignored by all storage engines. See
+ <xref linkend="ansi-diff-foreign-keys"/>.
+ </para></listitem>
+
+ <listitem><para>
+ For <literal>MyISAM</literal> and <literal>ISAM</literal> tables,
+ each <literal>NULL</literal> column takes one bit extra, rounded up
+ to the nearest byte. The maximum record length in bytes can be
+ calculated as follows:
+ </para>
+
+ <programlisting>
+ row length = 1
+ + (<replaceable>sum of column lengths</replaceable>)
+ + (<replaceable>number of NULL columns</replaceable> + <replaceable>delete_flag</replaceable> + 7)/8
+ + (<replaceable>number of variable-length columns</replaceable>)
+ </programlisting>
+
+ <para>
+ <replaceable>delete_flag</replaceable> is 1 for tables with static
+ record format. Static tables use a bit in the row record for a flag
+ that indicates whether the row has been deleted.
+ <replaceable>delete_flag</replaceable> is 0 for dynamic tables
+ because the flag is stored in the dynamic row header.
+ </para>
+
+ <para>
+ These calculations do not apply for <literal>InnoDB</literal>
+ tables, for which storage size is no different for
+ <literal>NULL</literal> columns than for <literal>NOT
+ NULL</literal> columns.
+ </para></listitem>
+
+ </itemizedlist>
+
+ <para>
+ The <replaceable>table_options</replaceable> part of the
+ <literal>CREATE TABLE</literal> syntax can be used in MySQL 3.23 and
+ above.
+ </para>
+
+ <para>
+ The <literal>ENGINE</literal> and <literal>TYPE</literal> options
+ specify the storage engine for the table. <literal>ENGINE</literal>
+ was added in MySQL 4.0.18 (for 4.0) and 4.1.2 (for 4.1). It is the
+ preferred option name as of those versions, and
+ <literal>TYPE</literal> has become deprecated.
+ <literal>TYPE</literal> is supported throughout the 4.x series, but
+ likely will be removed in MySQL 5.1.
+ </para>
+
+ <para>
+ The <literal>ENGINE</literal> and <literal>TYPE</literal> options
+ take the following values:
+ </para>
+
+ <informaltable>
+ <tgroup cols="2">
+ <colspec colwidth="25*"/>
+ <colspec colwidth="70*"/>
+ <tbody>
+ <row>
+ <entry>
+ <emphasis role="bold">Storage Engine</emphasis>
+ </entry>
+ <entry>
+ <emphasis role="bold">Description</emphasis>
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <literal>ARCHIVE</literal>
+ </entry>
+ <entry>
+ The archving storage engine. See
+ <xref linkend="archive-storage-engine"/>.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <literal>BDB</literal>
+ </entry>
+ <entry>
+ Transaction-safe tables with page locking. See
+ <xref linkend="bdb-storage-engine"/>.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <literal>BerkeleyDB</literal>
+ </entry>
+ <entry>
+ An alias for <literal>BDB</literal>.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <literal>CSV</literal>
+ </entry>
+ <entry>
+ Tables that store rows in comma-separated values format. See
+ <xref linkend="csv-storage-engine"/>.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <literal>EXAMPLE</literal>
+ </entry>
+ <entry>
+ An example engine. See
+ <xref linkend="example-storage-engine"/>.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <literal>FEDERATED</literal>
+ </entry>
+ <entry>
+ Storage engine that accesses remote tables. See
+ <xref linkend="federated-storage-engine"/>.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <literal>HEAP</literal>
+ </entry>
+ <entry>
+ The data for this table is stored only in memory. See
+ <xref linkend="memory-storage-engine"/>.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <literal>ISAM</literal>
+ </entry>
+ <entry>
+ The original MySQL storage engine. See
+ <xref linkend="isam-storage-engine"/>.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <literal>InnoDB</literal>
+ </entry>
+ <entry>
+ Transaction-safe tables with row locking and foreign keys.
+ See <xref linkend="innodb"/>.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <literal>MEMORY</literal>
+ </entry>
+ <entry>
+ An alias for <literal>HEAP</literal>. (Actually, as of MySQL
+ 4.1, <literal>MEMORY</literal> is the preferred term.)
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <literal>MERGE</literal>
+ </entry>
+ <entry>
+ A collection of <literal>MyISAM</literal> tables used as one
+ table. See <xref linkend="merge-storage-engine"/>.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <literal>MRG_MyISAM</literal>
+ </entry>
+ <entry>
+ An alias for <literal>MERGE</literal>.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <literal>MyISAM</literal>
+ </entry>
+ <entry>
+ The binary portable storage engine that is the improved
+ replacement for <literal>ISAM</literal>. See
+ <xref linkend="myisam-storage-engine"/>.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <literal>NDB</literal>
+ </entry>
+ <entry>
+ Alias for <literal>NDBCLUSTER</literal>.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <literal>NDBCLUSTER</literal>
+ </entry>
+ <entry>
+ Clustered, fault-tolerant, memory-based tables. See
+ <xref linkend="ndbcluster"/>.
+ </entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </informaltable>
+
+ <para>
+ See <xref linkend="storage-engines"/>.
+ </para>
+
+ <para>
+ If a storage engine is specified that is not available, MySQL uses
+ <literal>MyISAM</literal> instead. For example, if a table
+ definition includes the <literal>ENGINE=BDB</literal> option but the
+ MySQL server does not support <literal>BDB</literal> tables, the
+ table is created as a <literal>MyISAM</literal> 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 4.1.1, a warning
+ occurs if the storage engine specification is not honored.
+ </para>
+
+ <para>
+ The other table options are used to optimize the behavior of the
+ table. In most cases, you don't have to specify any of them. The
+ options work for all storage engines unless otherwise indicated:
+ </para>
+
+ <itemizedlist>
+
+ <listitem><para>
+ <literal>AUTO_INCREMENT</literal>
+ </para>
+
+ <para>
+ The initial <literal>AUTO_INCREMENT</literal> value for the table.
+ This works for <literal>MyISAM</literal> only, for
+ <literal>MEMORY</literal> as of MySQL 4.1, and for
+ <literal>InnoDB</literal> as of MySQL 5.0.3. To set the first
+ auto-increment value for engines that do not support the
+ <literal>AUTO_INCREMENT</literal> table option, insert a dummy row
+ with a value one less than the desired value after creating the
+ table, and then delete the dummy row.
+ </para>
+
+ <para>
+ For engines that support the <literal>AUTO_INCREMENT</literal>
+ table option in <literal>CREATE TABLE</literal> statements, you can
+ also use <literal>ALTER TABLE <replaceable>tbl_name</replaceable>
+ AUTO_INCREMENT = <replaceable>n</replaceable></literal> to reset
+ the <literal>AUTO_INCREMENT</literal> value.
+ </para></listitem>
+
+ <listitem><para>
+ <literal>AVG_ROW_LENGTH</literal>
+ </para>
+
+ <para>
+ An approximation of the average row length for your table. You need
+ to set this only for large tables with variable-size records.
+ </para>
+
+ <para>
+ When you create a <literal>MyISAM</literal> table, MySQL uses the
+ product of the <literal>MAX_ROWS</literal> and
+ <literal>AVG_ROW_LENGTH</literal> options to decide how big the
+ resulting table is. If you don't specify either option, the maximum
+ size for a table is 4GB (or 2GB if your operating system only
+ supports 2GB tables). The reason for this is just to keep down the
+ pointer sizes to make the index smaller and faster if you don't
+ really need big files. If you want all your tables to be able to
+ grow above the 4GB limit and are willing to have your smaller
+ tables slightly slower and larger than necessary, you may increase
+ the default pointer size by setting the
+ <literal>myisam_data_pointer_size</literal> system variable, which
+ was added in MySQL 4.1.2. See
+ <xref linkend="server-system-variables"/>.
+ </para></listitem>
+
+ <listitem><para>
+ <literal>[DEFAULT] CHARACTER SET</literal>
+ </para>
+
+ <para>
+ Specify a default character set for the table.
+ <literal>CHARSET</literal> is a synonym
+ </para>
+
+ <para>
+ for <literal>CHARACTER SET</literal>.
+ </para></listitem>
+
+ <listitem><para>
+ <literal>COLLATE</literal>
+ </para>
+
+ <para>
+ Specify a default collation for the table.
+ </para></listitem>
+
+ <listitem><para>
+ <literal>CHECKSUM</literal>
+ </para>
+
+ <para>
+ 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
+ <literal>CHECKSUM TABLE</literal> statement reports the checksum.
+ (<literal>MyISAM</literal> only.)
+ </para></listitem>
+
+ <listitem><para>
+ <literal>COMMENT</literal>
+ </para>
+
+ <para>
+ A comment for your table, up to 60 characters long.
+ </para></listitem>
+
+ <listitem><para>
+ <literal>MAX_ROWS</literal>
+ </para>
+
+ <para>
+ The maximum number of rows you plan to store in the table. This is
+ not a hard limit, but rather an indicator that the table must be
+ able to store at least this many rows.
+ </para></listitem>
+
+ <listitem><para>
+ <literal>MIN_ROWS</literal>
+ </para>
+
+ <para>
+ The minimum number of rows you plan to store in the table.
+ </para></listitem>
+
+ <listitem><para>
+ <literal>PACK_KEYS</literal>
+ </para>
+
+ <para>
+ 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
+ <literal>DEFAULT</literal> (MySQL 4.0) tells the storage engine to
+ only pack long <literal>CHAR</literal>/<literal>VARCHAR</literal>
+ columns. (<literal>MyISAM</literal> and <literal>ISAM</literal>
+ only.)
+ </para>
+
+ <para>
+ If you don't use <literal>PACK_KEYS</literal>, the default is to
+ only pack strings, not numbers. If you use
+ <literal>PACK_KEYS=1</literal>, numbers are packed as well.
+ </para>
+
+ <para>
+ When packing binary number keys, MySQL uses prefix compression:
+ </para>
+
+ <para>
+ <itemizedlist>
+
+ <listitem><para>
+ Every key needs one extra byte to indicate how many bytes of the
+ previous key are the same for the next key.
+ </para></listitem>
+
+ <listitem><para>
+ The pointer to the row is stored in high-byte-first order
+ directly after the key, to improve compression.
+ </para></listitem>
+
+ </itemizedlist>
+ </para>
+
+ <para>
+ This means that if you have many equal keys on two consecutive
+ rows, all following ``same'' keys usually only take two bytes
+ (including the pointer to the row). Compare this to the ordinary
+ case where the following keys takes <literal>storage_size_for_key +
+ pointer_size</literal> (where the pointer size is usually 4).
+ Conversely, you get a big 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 isn't a key
+ that can have <literal>NULL</literal> values. (In this case, the
+ packed key length is stored in the same byte that is used to mark
+ if a key is <literal>NULL</literal>.)
+ </para></listitem>
+
+ <listitem><para>
+ <literal>PASSWORD</literal>
+ </para>
+
+ <para>
+ Encrypt the <filename>.frm</filename> file with a password. This
+ option doesn't do anything in the standard MySQL version.
+ </para></listitem>
+
+ <listitem><para>
+ <literal>DELAY_KEY_WRITE</literal>
+ </para>
+
+ <para>
+ Set this to 1 if you want to delay key updates for the table until
+ the table is closed. (<literal>MyISAM</literal> only.)
+ </para></listitem>
+
+ <listitem><para>
+ <literal>ROW_FORMAT</literal>
+ </para>
+
+ <para>
+ Defines how the rows should be stored. Currently this option works
+ only with <literal>MyISAM</literal> tables. The option value can
+ <literal>FIXED</literal> or <literal>DYNAMIC</literal> for static
+ or variable-length row format. <command>myisampack</command> sets
+ the type to <literal>COMPRESSED</literal>. See
+ <xref linkend="myisam-table-formats"/>.
+ </para>
+
+ <para>
+ Starting with MySQL/InnoDB-5.0.3, InnoDB records are stored in a
+ more compact format (<literal>ROW_FORMAT=COMPACT</literal>) by
+ default. The old format can be requested by specifying
+ <literal>ROW_FORMAT=REDUNDANT</literal>.
+ </para></listitem>
+
+ <listitem><para>
+ <literal>RAID_TYPE</literal>
+
+ <indexterm type="concept">
+ <primary>RAID</primary>
+ <secondary>table type</secondary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>tables</primary>
+ <secondary>RAID</secondary>
+ </indexterm>
+ </para>
+
+ <para>
+ Note: This information applies only before MySQL 5.0.
+ <literal>RAID</literal> support has been removed as of MySQL 5.0.
+ </para>
+
+ <para>
+ The <literal>RAID_TYPE</literal> option can help you to exceed the
+ 2GB/4GB limit for the <literal>MyISAM</literal> data file (not the
+ index file) on operating systems that don't support big files. This
+ option is unnecessary and not recommended for filesystems that
+ support big files.
+ </para>
+
+ <para>
+ You can get more speed from the I/O bottleneck by putting
+ <literal>RAID</literal> directories on different physical disks.
+ The only allowed <literal>RAID_TYPE</literal> is
+ <literal>STRIPED</literal>. <literal>1</literal> and
+ <literal>RAID0</literal> are aliases for
+ <literal>STRIPED</literal>.
+ </para>
+
+ <para>
+ If you specify the <literal>RAID_TYPE</literal> option for a
+ <literal>MyISAM</literal> table, specify the
+ <literal>RAID_CHUNKS</literal> and
+ <literal>RAID_CHUNKSIZE</literal> options as well. The maximum
+ <literal>RAID_CHUNKS</literal> value is 255.
+ <literal>MyISAM</literal> creates <literal>RAID_CHUNKS</literal>
+ subdirectories named <filename>00</filename>,
+ <filename>01</filename>, <filename>02</filename>, ...
+ <filename>09</filename>, <filename>0a</filename>,
+ <filename>0b</filename>, ... in the database directory. In each of
+ these directories, <literal>MyISAM</literal> creates a file
+ <filename><replaceable>tbl_name</replaceable>.MYD</filename>. When
+ writing data to the data file, the <literal>RAID</literal> handler
+ maps the first <literal>RAID_CHUNKSIZE*1024</literal> bytes to the
+ first file, the next <literal>RAID_CHUNKSIZE*1024</literal> bytes
+ to the next file, and so on.
+ </para>
+
+ <para>
+ <literal>RAID_TYPE</literal> works on any operating system, as long
+ as you have built MySQL with the <literal>--with-raid</literal>
+ option to <command>configure</command>. To determine whether a
+ server supports <literal>RAID</literal> tables, use <literal>SHOW
+ VARIABLES LIKE 'have_raid'</literal> to see whether the variable
+ value is <literal>YES</literal>.
+ </para></listitem>
+
+ <listitem><para>
+ <literal>UNION</literal>
+ </para>
+
+ <para>
+ <literal>UNION</literal> is used when you want to use a collection
+ of identical tables as one. This works only with
+ <literal>MERGE</literal> tables. See
+ <xref linkend="merge-storage-engine"/>.
+ </para>
+
+ <para>
+ For the moment, you must have <literal>SELECT</literal>,
+ <literal>UPDATE</literal>, and <literal>DELETE</literal> privileges
+ for the tables you map to a <literal>MERGE</literal> table.
+ Originally, all used tables had to be in the same database as the
+ <literal>MERGE</literal> table itself. This restriction has been
+ lifted as of MySQL 4.1.1.
+ </para></listitem>
+
+ <listitem><para>
+ <literal>INSERT_METHOD</literal>
+ </para>
+
+ <para>
+ If you want to insert data in a <literal>MERGE</literal> table, you
+ have to specify with <literal>INSERT_METHOD</literal> into which
+ table the row should be inserted. <literal>INSERT_METHOD</literal>
+ is an option useful for <literal>MERGE</literal> tables only. Use a
+ value of <literal>FIRST</literal> or <literal>LAST</literal> to
+ have inserts go to the first or last table, or a value of
+ <literal>NO</literal> to prevent inserts. This option was
+ introduced in MySQL 4.0.0. See
+ <xref linkend="merge-storage-engine"/>.
+ </para></listitem>
+
+ <listitem><para>
+ <literal>DATA DIRECTORY</literal> , <literal>INDEX
+ DIRECTORY</literal>
+ </para>
+
+ <para>
+ By using <literal>DATA
+ DIRECTORY='<replaceable>directory</replaceable>'</literal> or
+ <literal>INDEX
+ DIRECTORY='<replaceable>directory</replaceable>'</literal> you can
+ specify where the <literal>MyISAM</literal> storage engine should
+ put a table's data file and index file. Note that the directory
+ should be a full path to the directory (not a relative path).
+ </para>
+
+ <para>
+ These options work only for <literal>MyISAM</literal> tables from
+ MySQL 4.0 on, when you are not using the
+ <literal>--skip-symbolic-links</literal> option. Your operating
+ system must also have a working, thread-safe
+ <literal>realpath()</literal> call. See
+ <xref linkend="symbolic-links-to-tables"/>.
+ </para></listitem>
+
+ </itemizedlist>
+
+ <indexterm type="concept">
+ <primary>copying tables</primary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>tables</primary>
+ <secondary>copying</secondary>
+ </indexterm>
+
+ <para>
+ As of MySQL 3.23, you can create one table from another by adding a
+ <literal>SELECT</literal> statement at the end of the
+ <literal>CREATE TABLE</literal> statement:
+ </para>
+
+ <programlisting>
+ CREATE TABLE <replaceable>new_tbl</replaceable> SELECT * FROM <replaceable>orig_tbl</replaceable>;
+ </programlisting>
+
+ <para>
+ MySQL creates new columns for all elements in the
+ <literal>SELECT</literal>. For example:
+ </para>
+
+ <programlisting>
+ mysql> CREATE TABLE test (a INT NOT NULL AUTO_INCREMENT,
+ -> PRIMARY KEY (a), KEY(b))
+ -> TYPE=MyISAM SELECT b,c FROM test2;
+ </programlisting>
+
+ <para>
+ This creates a <literal>MyISAM</literal> table with three columns,
+ <literal>a</literal>, <literal>b</literal>, and
+ <literal>c</literal>. Notice that the columns from the
+ <literal>SELECT</literal> statement are appended to the right side
+ of the table, not overlapped onto it. Take the following example:
+ </para>
+
+ <programlisting>
+ mysql> SELECT * FROM foo;
+ +---+
+ | n |
+ +---+
+ | 1 |
+ +---+
+
+ mysql> CREATE TABLE bar (m INT) SELECT n FROM foo;
+ Query OK, 1 row affected (0.02 sec)
+ Records: 1 Duplicates: 0 Warnings: 0
+
+ mysql> SELECT * FROM bar;
+ +------+---+
+ | m | n |
+ +------+---+
+ | NULL | 1 |
+ +------+---+
+ 1 row in set (0.00 sec)
+ </programlisting>
+
+ <para>
+ For each row in table <literal>foo</literal>, a row is inserted in
+ <literal>bar</literal> with the values from <literal>foo</literal>
+ and default values for the new columns.
+ </para>
+
+ <para>
+ If any errors occur while copying the data to the table, it is
+ automatically dropped and not created.
+ </para>
+
+ <para>
+ <literal>CREATE TABLE ... SELECT</literal> 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
+ <literal>SELECT</literal> statement:
+ </para>
+
+ <programlisting>
+ mysql> CREATE TABLE bar (UNIQUE (n)) SELECT n FROM foo;
+ </programlisting>
+
+ <para>
+ Some conversion of column types might occur. For example, the
+ <literal>AUTO_INCREMENT</literal> attribute is not preserved, and
+ <literal>VARCHAR</literal> columns can become
+ <literal>CHAR</literal> columns.
+ </para>
+
+ <para>
+ When creating a table with <literal>CREATE ... SELECT</literal>,
+ make sure to alias any function calls or expressions in the query.
+ If you do not, the <literal>CREATE</literal> statement might fail or
+ result in undesirable column names.
+ </para>
+
+ <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;
+ </programlisting>
+
+ <para>
+ As of MySQL 4.1, you can explicitly specify the type for a generated
+ column:
+ </para>
+
+ <programlisting>
+ CREATE TABLE foo (a TINYINT NOT NULL) SELECT b+1 AS a FROM bar;
+ </programlisting>
+
+ <para>
+ In MySQL 4.1, you can also use <literal>LIKE</literal> to create an
+ empty table based on the definition of another table, including any
+ column attributes and indexes the original table has:
+ </para>
+
+ <programlisting>
+ CREATE TABLE <replaceable>new_tbl</replaceable> LIKE <replaceable>orig_tbl</replaceable>;
+ </programlisting>
+
+ <para>
+ <literal>CREATE TABLE ... LIKE</literal> does not copy any
+ <literal>DATA DIRECTORY</literal> or <literal>INDEX
+ DIRECTORY</literal> table options that were specified for the
+ original table, or any foreign key definitions.
+ </para>
+
+ <para>
+ You can precede the <literal>SELECT</literal> by
+ <literal>IGNORE</literal> or <literal>REPLACE</literal> to indicate
+ how to handle records that duplicate unique key values. With
+ <literal>IGNORE</literal>, new records that duplicate an existing
+ record on a unique key value are discarded. With
+ <literal>REPLACE</literal>, new records replace records that have
+ the same unique key value. If neither <literal>IGNORE</literal> nor
+ <literal>REPLACE</literal> is specified, duplicate unique key values
+ result in an error.
+ </para>
+
+ <para>
+ To ensure that the update log/binary log can be used to re-create
+ the original tables, MySQL does not allow concurrent inserts during
+ <literal>CREATE TABLE ... SELECT</literal>.
+ </para>
+
+ <section id="silent-column-changes">
+
+ <title id='title-silent-column-changes'>&title-silent-column-changes;</title>
+
+ <indexterm type="concept">
+ <primary>silent column changes</primary>
+ </indexterm>
+
+ <para>
+ In some cases, MySQL silently changes column specifications from
+ those given in a <literal>CREATE TABLE</literal> or <literal>ALTER
+ TABLE</literal> statement. These might be changes to a data type,
+ to attributes associated with a data type, or to an index
+ specification.
+ </para>
+
+ <para>
+ Possible data type changes are given in the following list. These
+ occur prior to MySQL 5.0.3. (As of 5.0.3 an error occurs if a
+ column cannot be created using the specified data type.)
+ </para>
+
+ <itemizedlist>
+
+ <listitem><para>
+ <literal>VARCHAR</literal> columns with a length less than four
+ are changed to <literal>CHAR</literal>.
+ </para></listitem>
+
+ <listitem><para>
+ 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 (<literal>VARCHAR</literal>,
+ <literal>TEXT</literal>, or <literal>BLOB</literal>), all
+ <literal>CHAR</literal> columns longer than three characters are
+ changed to <literal>VARCHAR</literal> columns. This doesn't affect
+ how you use the columns in any way; in MySQL,
+ <literal>VARCHAR</literal> is just a different way to store
+ characters. MySQL performs this conversion because it saves space
+ and makes table operations faster. See
+ <xref linkend="storage-engines"/>.
+ </para></listitem>
+
+ <listitem><para>
+ From MySQL 4.1.0 to MySQL 5.0.2, a <literal>CHAR</literal> or
+ <literal>VARCHAR</literal> column with a length specification
+ greater than 255 is converted to the smallest
+ <literal>TEXT</literal> type that can hold values of the given
+ length. For example, <literal>VARCHAR(500)</literal> is converted
+ to <literal>TEXT</literal>, and <literal>VARCHAR(200000)</literal>
+ is converted to <literal>MEDIUMTEXT</literal>. Note that this
+ conversion results in a change in behavior with regard to
+ treatment of trailing spaces.
+ </para>
+
+ <para>
+ Similar conversions occur for <literal>BINARY</literal> and
+ <literal>VARBINARY</literal>, except that they are converted to a
+ <literal>BLOB</literal> type.
+ </para>
+
+ <para>
+ From MySQL 5.0.3 on, <literal>CHAR</literal> and
+ <literal>BINARY</literal> columns with a length specification
+ greater than 255 are not silently converted. Instead, an error
+ occurs. From MySQL 5.0.6 on, silent conversion of
+ <literal>VARCHAR</literal> and <literal>VARBINARY</literal>
+ columns with a length specification greater than 65,535 does not
+ occur if strict SQL mode is enabled. Instead, an error occurs.
+ </para></listitem>
+
+ <listitem><para>
+ For a specification of
+ <literal>DECIMAL(<replaceable>M</replaceable>,<replaceable>D</replaceable>)</literal>,
+ if <replaceable>M</replaceable> is not larger than
+ <replaceable>D</replaceable>, it is adjusted upward. For example,
+ <literal>DECIMAL(10,10)</literal> becomes
+ <literal>DECIMAL(11,10)</literal>.
+ </para></listitem>
+
+ </itemizedlist>
+
+ <para>
+ Other silent column specification changes include changes to
+ attribute or index specifications:
+ </para>
+
+ <itemizedlist>
+
+ <listitem><para>
+ <literal>TIMESTAMP</literal> display sizes are discarded from
+ MySQL 4.1 on, due to changes made to the
+ <literal>TIMESTAMP</literal> column type in that version. Before
+ MySQL 4.1, <literal>TIMESTAMP</literal> display sizes must be even
+ and in the range from 2 to 14. If you specify a display size of 0
+ or greater than 14, the size is coerced to 14. Odd-valued sizes in
+ the range from 1 to 13 are coerced to the next higher even number.
+ </para></listitem>
+
+ <listitem><para>
+ Before MySQL 4.1.6, you cannot store a literal
+ <literal>NULL</literal> in a <literal>TIMESTAMP</literal> column;
+ setting it to <literal>NULL</literal> sets it to the current date
+ and time. Because <literal>TIMESTAMP</literal> columns behave this
+ way, the <literal>NULL</literal> and <literal>NOT NULL</literal>
+ attributes do not apply in the normal way and are ignored if you
+ specify them. <literal>DESCRIBE
+ <replaceable>tbl_name</replaceable></literal> always reports that
+ a <literal>TIMESTAMP</literal> column can be assigned
+ <literal>NULL</literal> values.
+ </para></listitem>
+
+ <listitem><para>
+ Columns that are part of a <literal>PRIMARY KEY</literal> are made
+ <literal>NOT NULL</literal> even if not declared that way.
+ </para></listitem>
+
+ <listitem><para>
+ Starting from MySQL 3.23.51, trailing spaces are automatically
+ deleted from <literal>ENUM</literal> and <literal>SET</literal>
+ member values when the table is created.
+ </para></listitem>
+
+ <listitem><para>
+ MySQL maps certain column types used by other SQL database vendors
+ to MySQL types. See <xref linkend="other-vendor-column-types"/>.
+ </para></listitem>
+
+ <listitem><para>
+ If you include a <literal>USING</literal> clause to specify an
+ index type that is not legal for a storage engine, but there is
+ another index type available that the engine can use without
+ affecting query results, the engine uses the available type.
+ </para></listitem>
+
+ </itemizedlist>
+
+ <para>
+ To see whether MySQL used a column type other than the one you
+ specified, issue a <literal>DESCRIBE</literal> or <literal>SHOW
+ CREATE TABLE</literal> statement after creating or altering your
+ table.
+ </para>
+
+ <indexterm type="concept">
+ <primary><command>myisampack</command></primary>
+ </indexterm>
+
+ <para>
+ Certain other column type changes can occur if you compress a table
+ using <command>myisampack</command>. See
+ <xref linkend="compressed-format"/>.
+ </para>
+
+ </section>
+
+ </section>
+
+ <section id="drop-database">
+
+ <title id='title-drop-database'>&title-drop-database;</title>
+
+ <indexterm type="function">
+ <primary>DROP DATABASE</primary>
+ </indexterm>
+
+ <indexterm type="function">
+ <primary>DROP SCHEMA</primary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>deleting</primary>
+ <secondary>database</secondary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>database</primary>
+ <secondary>deleting</secondary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>deleting</primary>
+ <secondary>schema</secondary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>schema</primary>
+ <secondary>deleting</secondary>
+ </indexterm>
+
+ <!-- example_for_help_topic DROP DATABASE -->
+
+ <programlisting>
+ DROP {DATABASE | SCHEMA} [IF EXISTS] <replaceable>db_name</replaceable>
+ </programlisting>
+
+ <!-- description_for_help_topic DROP DATABASE DROP DATABASE SCHEMA EXISTS IF -->
+
+ <para>
+ <literal>DROP DATABASE</literal> drops all tables in the database
+ and deletes the database. Be <emphasis>very</emphasis> careful with
+ this statement! To use <literal>DROP DATABASE</literal>, you need
+ the <literal>DROP</literal> privilege on the database.
+ </para>
+
+ <para>
+ In MySQL 3.22 or later, you can use the keywords <literal>IF
+ EXISTS</literal> to prevent an error from occurring if the database
+ doesn't exist.
+ </para>
+
+ <para>
+ <literal>DROP SCHEMA</literal> can be used as of MySQL 5.0.2.
+
+ <!-- end_description_for_help_topic -->
+ </para>
+
+ <para>
+ If you use <literal>DROP DATABASE</literal> on a symbolically linked
+ database, both the link and the original database are deleted.
+ </para>
+
+ <para>
+ As of MySQL 4.1.2, <literal>DROP DATABASE</literal> returns the
+ number of tables that were removed. This corresponds to the number
+ of <filename>.frm</filename> files removed.
+ </para>
+
+ <para>
+ The <literal>DROP DATABASE</literal> statement removes from the
+ given database directory those files and directories that MySQL
+ itself may create during normal operation:
+ </para>
+
+ <itemizedlist>
+
+ <listitem><para>
+ All files with these extensions:
+ </para>
+
+ <informaltable>
+ <tgroup cols="4">
+ <colspec colwidth="10*"/>
+ <colspec colwidth="10*"/>
+ <colspec colwidth="10*"/>
+ <colspec colwidth="10*"/>
+ <tbody>
+ <row>
+ <entry>
+ <literal>.BAK</literal>
+ </entry>
+ <entry>
+ <literal>.DAT</literal>
+ </entry>
+ <entry>
+ <literal>.HSH</literal>
+ </entry>
+ <entry>
+ <literal>.ISD</literal>
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <literal>.ISM</literal>
+ </entry>
+ <entry>
+ <literal>.ISM</literal>
+ </entry>
+ <entry>
+ <literal>.MRG</literal>
+ </entry>
+ <entry>
+ <literal>.MYD</literal>
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <literal>.MYI</literal>
+ </entry>
+ <entry>
+ <literal>.db</literal>
+ </entry>
+ <entry>
+ <literal>.frm</literal>
+ </entry>
+ <entry></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </informaltable></listitem>
+
+ <listitem><para>
+ All subdirectories with names that consist of two hex digits
+ <literal>00</literal>-<literal>ff</literal>. These are
+ subdirectories used for <literal>RAID</literal> tables.
+ </para></listitem>
+
+ <listitem><para>
+ The <filename>db.opt</filename> file, if it exists.
+ </para></listitem>
+
+ </itemizedlist>
+
+ <para>
+ 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 <literal>DROP DATABASE</literal>
+ statement again.
+ </para>
+
+ <indexterm type="concept">
+ <primary><command>mysqladmin</command></primary>
+ </indexterm>
+
+ <para>
+ You can also drop databases with <command>mysqladmin</command>. See
+ <xref linkend="mysqladmin"/>.
+ </para>
+
+ </section>
+
+ <section id="drop-index">
+
+ <title id='title-drop-index'>&title-drop-index;</title>
+
+ <indexterm type="function">
+ <primary>DROP INDEX</primary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>deleting</primary>
+ <secondary>index</secondary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>index</primary>
+ <secondary>deleting</secondary>
+ </indexterm>
+
+ <!-- example_for_help_topic DROP INDEX -->
+
+ <programlisting>
+ DROP INDEX <replaceable>index_name</replaceable> ON <replaceable>tbl_name</replaceable>
+ </programlisting>
+
+ <!-- description_for_help_topic DROP INDEX DROP INDEX -->
+
+ <para>
+ <literal>DROP INDEX</literal> drops the index named
+ <replaceable>index_name</replaceable> from the table
+ <replaceable>tbl_name</replaceable>. In MySQL 3.22 or later,
+ <literal>DROP INDEX</literal> is mapped to an <literal>ALTER
+ TABLE</literal> statement to drop the index. See
+ <xref linkend="alter-table"/>. <literal>DROP INDEX</literal> doesn't
+ do anything prior to MySQL 3.22.
+
+ <!-- end_description_for_help_topic -->
+ </para>
+
+ </section>
+
+ <section id="drop-table">
+
+ <title id='title-drop-table'>&title-drop-table;</title>
+
+ <indexterm type="function">
+ <primary>DROP TABLE</primary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>deleting</primary>
+ <secondary>table</secondary>
+ </indexterm>
+
+ <indexterm type="concept">
+ <primary>table</primary>
+ <secondary>deleting</secondary>
+ </indexterm>
+
+ <!-- example_for_help_topic DROP TABLE -->
+
+ <programlisting>
+ DROP [TEMPORARY] TABLE [IF EXISTS]
+ <replaceable>tbl_name</replaceable> [, <replaceable>tbl_name</replaceable>] ...
+ [RESTRICT | CASCADE]
+ </programlisting>
+
+ <!-- description_for_help_topic DROP TABLE DROP TABLE EXISTS IF TEMPORARY RESTRICT CASCADE -->
+
+ <para>
+ <literal>DROP TABLE</literal> removes one or more tables. You must
+ have the <literal>DROP</literal> privilege for each table. All table
+ data and the table definition are <emphasis>removed</emphasis>, so
+ <emphasis>be careful</emphasis> with this statement!
+ </para>
+
+ <para>
+ In MySQL 3.22 or later, you can use the keywords <literal>IF
+ EXISTS</literal> to prevent an error from occurring for tables that
+ don't exist. As of MySQL 4.1, a <literal>NOTE</literal> is generated
+ for each non-existent table when using <literal>IF EXISTS</literal>.
+ See <xref linkend="show-warnings"/>.
+ </para>
+
+ <para>
+ <literal>RESTRICT</literal> and <literal>CASCADE</literal> are
+ allowed to make porting easier. For the moment, they do nothing.
+ </para>
+
+ <para>
+ <emphasis role="bold">Note</emphasis>: <literal>DROP TABLE</literal>
+ automatically commits the current active transaction, unless you are
+ using MySQL 4.1 or higher and the <literal>TEMPORARY</literal>
+ keyword.
+
+ <!-- end_description_for_help_topic -->
+ </para>
+
+ <para>
+ The <literal>TEMPORARY</literal> keyword is ignored in MySQL 4.0. As
+ of 4.1, it has the following effect:
+ </para>
+
+ <itemizedlist>
+
+ <listitem><para>
+ The statement drops only <literal>TEMPORARY</literal> tables.
+ </para></listitem>
+
+ <listitem><para>
+ The statement doesn't end a running transaction.
+ </para></listitem>
+
+ <listitem><para>
+ No access rights are checked. (A <literal>TEMPORARY</literal> table
+ is visible only to the client that created it, so no check is
+ necessary.)
+ </para></listitem>
+
+ </itemizedlist>
+
+ <para>
+ Using <literal>TEMPORARY</literal> is a good way to ensure that you
+ don't accidentally drop a non-<literal>TEMPORARY</literal> table.
+ </para>
+
+ </section>
+
+ <section id="rename-table">
+
+ <title id='title-rename-table'>&title-rename-table;</title>
+
+ <indexterm type="function">
+ <primary>RENAME TABLE</primary>
+ </indexterm>
+
+ <!-- description_for_help_topic RENAME TABLE -->
+
+ <programlisting>
+ RENAME TABLE <replaceable>tbl_name</replaceable> TO <replaceable>new_tbl_name</replaceable>
+ [, <replaceable>tbl_name2</replaceable> TO <replaceable>new_tbl_name2</replaceable>] ...
+ </programlisting>
+
+ <para>
+ This statement renames one or more tables. It was added in MySQL
+ 3.23.23.
+ </para>
+
+ <para>
+ 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 <literal>old_table</literal>,
+ you can create another table <literal>new_table</literal> that has
+ the same structure but is empty, and then replace the existing table
+ with the empty one as follows:
+
+ <!-- end_description_for_help_topic -->
+ </para>
+
+ <!-- example_for_help_topic RENAME TABLE -->
+
+ <programlisting>
+ CREATE TABLE <replaceable>new_table</replaceable> (...);
+ RENAME TABLE <replaceable>old_table</replaceable> TO <replaceable>backup_table</replaceable>, <replaceable>new_table</replaceable> TO <replaceable>old_table</replaceable>;
+ </programlisting>
+
+ <para>
+ 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 no table named
+ <literal>tmp_table</literal> currently exists):
+ </para>
+
+ <programlisting>
+ RENAME TABLE <replaceable>old_table</replaceable> TO <replaceable>tmp_table</replaceable>,
+ <replaceable>new_table</replaceable> TO <replaceable>old_table</replaceable>,
+ <replaceable>tmp_table</replaceable> TO <replaceable>new_table</replaceable>;
+ </programlisting>
+
+ <para>
+ As long as two databases are on the same filesystem you can also
+ rename a table to move it from one database to another:
+ </para>
+
+ <programlisting>
+ RENAME TABLE <replaceable>current_db.tbl_name</replaceable> TO <replaceable>other_db.tbl_name;</replaceable>
+ </programlisting>
+
+ <para>
+ When you execute <literal>RENAME</literal>, you can't have any
+ locked tables or active transactions. You must also have the
+ <literal>ALTER</literal> and <literal>DROP</literal> privileges on
+ the original table, and the <literal>CREATE</literal> and
+ <literal>INSERT</literal> privileges on the new table.
+ </para>
+
+ <para>
+ If MySQL encounters any errors in a multiple-table rename, it does a
+ reverse rename for all renamed tables to get everything back to the
+ original state.
+ </para>
+
+ </section>
+
+ </section>
+
+
<section id="data-manipulation">
<title id='title-data-manipulation'>&title-data-manipulation;</title>
@@ -5267,3064 +8324,8 @@
</section>
- <section id="data-definition">
-
- <title id='title-data-definition'>&title-data-definition;</title>
-
-<!-- help_category Data Definition -->
-
- <section id="alter-database">
-
- <title id='title-alter-database'>&title-alter-database;</title>
-
- <indexterm type="function">
- <primary>ALTER DATABASE</primary>
- </indexterm>
-
- <indexterm type="function">
- <primary>ALTER SCHEMA</primary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>altering</primary>
- <secondary>database</secondary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>database</primary>
- <secondary>altering</secondary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>altering</primary>
- <secondary>schema</secondary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>schema</primary>
- <secondary>altering</secondary>
- </indexterm>
-
-<!-- example_for_help_topic ALTER DATABASE -->
-
-<programlisting>
-ALTER {DATABASE | SCHEMA} [<replaceable>db_name</replaceable>]
- <replaceable>alter_specification</replaceable> [, <replaceable>alter_specification</replaceable>] ...
-
-<replaceable>alter_specification</replaceable>:
- [DEFAULT] CHARACTER SET <replaceable>charset_name</replaceable>
- | [DEFAULT] COLLATE <replaceable>collation_name</replaceable>
-</programlisting>
-
-<!-- description_for_help_topic ALTER DATABASE CHARACTER SET SCHEMA -->
-
- <para>
- <literal>ALTER DATABASE</literal> allows you to change the overall
- characteristics of a database. These characteristics are stored in
- the <filename>db.opt</filename> file in the database directory. To
- use <literal>ALTER DATABASE</literal>, you need the
- <literal>ALTER</literal> privilege on the database.
-
-<!-- end_description_for_help_topic -->
- </para>
-
- <para>
- The <literal>CHARACTER SET</literal> clause changes the default
- database character set. The <literal>COLLATE</literal> clause
- changes the default database collation. Character set and collation
- names are discussed in <xref linkend="charset"/>.
- </para>
-
-<!-- It's really 4.1.0, but with a different syntax than in 4.1.1. -->
-
-<!-- (COLLATE is not supported.) -->
-
- <para>
- <literal>ALTER DATABASE</literal> was added in MySQL 4.1.1.
- Beginning with MySQL 4.1.8, the database name can be omitted. The
- statement applies to the default database in this case.
- <literal>ALTER SCHEMA</literal> can be used as of MySQL 5.0.2.
- </para>
-
- </section>
-
- <section id="alter-table">
-
- <title id='title-alter-table'>&title-alter-table;</title>
-
- <indexterm type="function">
- <primary>ALTER TABLE</primary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>changing</primary>
- <secondary>table</secondary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>table</primary>
- <secondary>changing</secondary>
- </indexterm>
-
-<!-- example_for_help_topic ALTER TABLE -->
-
-<programlisting>
-ALTER [IGNORE] TABLE <replaceable>tbl_name</replaceable>
- <replaceable>alter_specification</replaceable> [, <replaceable>alter_specification</replaceable>] ...
-
-<replaceable>alter_specification</replaceable>:
- ADD [COLUMN] <replaceable>column_definition</replaceable> [FIRST | AFTER <replaceable>col_name</replaceable> ]
- | ADD [COLUMN] (<replaceable>column_definition</replaceable>,...)
- | ADD INDEX [<replaceable>index_name</replaceable>] [<replaceable>index_type</replaceable>] (<replaceable>index_col_name</replaceable>,...)
- | ADD [CONSTRAINT [<replaceable>symbol</replaceable>]]
- PRIMARY KEY [<replaceable>index_type</replaceable>] (<replaceable>index_col_name</replaceable>,...)
- | ADD [CONSTRAINT [<replaceable>symbol</replaceable>]]
- UNIQUE [<replaceable>index_name</replaceable>] [<replaceable>index_type</replaceable>] (<replaceable>index_col_name</replaceable>,...)
- | ADD [FULLTEXT|SPATIAL] [<replaceable>index_name</replaceable>] (<replaceable>index_col_name</replaceable>,...)
- | ADD [CONSTRAINT [<replaceable>symbol</replaceable>]]
- FOREIGN KEY [<replaceable>index_name</replaceable>] (<replaceable>index_col_name</replaceable>,...)
- [<replaceable>reference_definition</replaceable>]
- | ALTER [COLUMN] <replaceable>col_name</replaceable> {SET DEFAULT <replaceable>literal</replaceable> | DROP DEFAULT}
- | CHANGE [COLUMN] <replaceable>old_col_name</replaceable> <replaceable>column_definition</replaceable>
- [FIRST|AFTER <replaceable>col_name</replaceable>]
- | MODIFY [COLUMN] <replaceable>column_definition</replaceable> [FIRST | AFTER <replaceable>col_name</replaceable>]
- | DROP [COLUMN] <replaceable>col_name</replaceable>
- | DROP PRIMARY KEY
- | DROP INDEX <replaceable>index_name</replaceable>
- | DROP FOREIGN KEY <replaceable>fk_symbol</replaceable>
- | DISABLE KEYS
- | ENABLE KEYS
- | RENAME [TO] <replaceable>new_tbl_name</replaceable>
- | ORDER BY <replaceable>col_name</replaceable>
- | CONVERT TO CHARACTER SET <replaceable>charset_name</replaceable> [COLLATE <replaceable>collation_name</replaceable>]
- | [DEFAULT] CHARACTER SET <replaceable>charset_name</replaceable> [COLLATE <replaceable>collation_name</replaceable>]
- | DISCARD TABLESPACE
- | IMPORT TABLESPACE
- | <replaceable>table_options</replaceable>
-</programlisting>
-
-<!-- description_for_help_topic ALTER TABLE ADD ALTER AFTER AVG_ROW_LENGTH BY COLUMN FIRST INDEX PRIMARY KEY KEYS UNIQUE FULLTEXT SPATIAL CONSTRAINT DROP DISABLE ENABLE RENAME ORDER MODIFY CHANGE DEFAULT SET FOREIGN IGNORE ENGINE TYPE -->
-
- <para>
- <literal>ALTER TABLE</literal> allows 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.
-
-<!-- end_description_for_help_topic -->
- </para>
-
- <para>
- The syntax for many of the allowable alterations is similar to
- clauses of the <literal>CREATE TABLE</literal> statement. This
- includes <replaceable>table_options</replaceable> modifications, for
- options such as <literal>ENGINE</literal>,
- <literal>AUTO_INCREMENT</literal>, and
- <literal>AVG_ROW_LENGTH</literal>. See
- <xref linkend="create-table"/>.
- </para>
-
- <para>
- Some operations may result in warnings if attempted on a table for
- which the storage engine does not support the operation. In MySQL
- 4.1 and up, these warnings can be displayed with <literal>SHOW
- WARNINGS</literal>. See <xref linkend="show-warnings"/>.
- </para>
-
- <para>
- If you use <literal>ALTER TABLE</literal> to change a column
- specification but <literal>DESCRIBE
- <replaceable>tbl_name</replaceable></literal> indicates that your
- column was not changed, it is possible that MySQL ignored your
- modification for one of the reasons described in
- <xref linkend="silent-column-changes"/>. For example, if you try to
- change a <literal>VARCHAR</literal> column to
- <literal>CHAR</literal>, MySQL still uses <literal>VARCHAR</literal>
- if the table contains other variable-length columns.
- </para>
-
- <para>
- <literal>ALTER TABLE</literal> works by making a temporary copy of
- the original table. The alteration is performed on the copy, then
- the original table is deleted and the new one is renamed. While
- <literal>ALTER TABLE</literal> is executing, the original table is
- readable by other clients. Updates and writes to the table are
- stalled until the new table is ready, then are automatically
- redirected to the new table without any failed updates.
- </para>
-
- <para>
- Note that if you use any other option to <literal>ALTER
- TABLE</literal> than <literal>RENAME</literal>, 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). We plan to
- fix this in the future, but because <literal>ALTER TABLE</literal>
- is not a statement that is normally used frequently, this isn't high
- on our TODO list. For <literal>MyISAM</literal> tables, you can
- speed up the index re-creation operation (which is the slowest part
- of the alteration process) by setting the
- <literal>myisam_sort_buffer_size</literal> system variable to a high
- value.
- </para>
-
- <itemizedlist>
-
- <listitem><para>
- To use <literal>ALTER TABLE</literal>, you need
- <literal>ALTER</literal>, <literal>INSERT</literal>, and
- <literal>CREATE</literal> privileges for the table.
- </para></listitem>
-
- <listitem><para>
- <literal>IGNORE</literal> is a MySQL extension to standard SQL. It
- controls how <literal>ALTER TABLE</literal> works if there are
- duplicates on unique keys in the new table or if warnings occur
- when <literal>STRICT</literal> mode is enabled. If
- <literal>IGNORE</literal> isn't specified, the copy is aborted and
- rolled back if duplicate-key errors occur. If
- <literal>IGNORE</literal> is specified, then for rows with
- duplicates on a unique key, only the first row is used. The others
- conflicting rows are deleted. Wrong values are truncated to the
- closest matching acceptable value.
- </para></listitem>
-
- <listitem><para>
- You can issue multiple <literal>ADD</literal>,
- <literal>ALTER</literal>, <literal>DROP</literal>, and
- <literal>CHANGE</literal> clauses in a single <literal>ALTER
- TABLE</literal> statement. This is a MySQL extension to standard
- SQL, which allows only one of each clause per <literal>ALTER
- TABLE</literal> statement. For example, to drop multiple columns in
- a single statement:
- </para>
-
-<programlisting>
-mysql> ALTER TABLE t2 DROP COLUMN c, DROP COLUMN d;
-</programlisting></listitem>
-
- <listitem><para>
- <literal>CHANGE <replaceable>col_name</replaceable></literal>,
- <literal>DROP <replaceable>col_name</replaceable></literal>, and
- <literal>DROP INDEX</literal> are MySQL extensions to standard SQL.
- </para></listitem>
-
- <listitem><para>
- <literal>MODIFY</literal> is an Oracle extension to <literal>ALTER
- TABLE</literal>.
- </para></listitem>
-
- <listitem><para>
- The word <literal>COLUMN</literal> is purely optional and can be
- omitted.
- </para></listitem>
-
- <listitem><para>
- If you use <literal>ALTER TABLE <replaceable>tbl_name</replaceable>
- RENAME TO <replaceable>new_tbl_name</replaceable></literal> without
- any other options, MySQL simply renames any files that correspond
- to the table <replaceable>tbl_name</replaceable>. There is no need
- to create a temporary table. (You can also use the <literal>RENAME
- TABLE</literal> statement to rename tables. See
- <xref linkend="rename-table"/>.)
- </para></listitem>
-
- <listitem><para>
- <replaceable>column_definition</replaceable> clauses use the same
- syntax for <literal>ADD</literal> and <literal>CHANGE</literal> as
- for <literal>CREATE TABLE</literal>. Note that this syntax includes
- the column name, not just the column type. See
- <xref linkend="create-table"/>.
- </para></listitem>
-
- <listitem><para>
- You can rename a column using a <literal>CHANGE
- <replaceable>old_col_name</replaceable>
- <replaceable>column_definition</replaceable></literal> clause. To
- do so, specify the old and new column names and the type that the
- column currently has. For example, to rename an
- <literal>INTEGER</literal> column from <literal>a</literal> to
- <literal>b</literal>, you can do this:
- </para>
-
-<programlisting>
-mysql> ALTER TABLE t1 CHANGE a b INTEGER;
-</programlisting>
-
- <para>
- If you want to change a column's type but not the name,
- <literal>CHANGE</literal> syntax still requires an old and new
- column name, even if they are the same. For example:
- </para>
-
-<programlisting>
-mysql> ALTER TABLE t1 CHANGE b b BIGINT NOT NULL;
-</programlisting>
-
- <para>
- However, as of MySQL 3.22.16a, you can also use
- <literal>MODIFY</literal> to change a column's type without
- renaming it:
- </para>
-
-<programlisting>
-mysql> ALTER TABLE t1 MODIFY b BIGINT NOT NULL;
-</programlisting></listitem>
-
- <listitem><para>
- If you use <literal>CHANGE</literal> or <literal>MODIFY</literal>
- 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.
- </para></listitem>
-
- <listitem><para>
- When you change a column type using <literal>CHANGE</literal> or
- <literal>MODIFY</literal>, MySQL tries to convert existing column
- values to the new type as well as possible.
- </para></listitem>
-
- <listitem><para>
- In MySQL 3.22 or later, you can use <literal>FIRST</literal> or
- <literal>AFTER <replaceable>col_name</replaceable></literal> to add
- a column at a specific position within a table row. The default is
- to add the column last. From MySQL 4.0.1 on, you can also use
- <literal>FIRST</literal> and <literal>AFTER</literal> in
- <literal>CHANGE</literal> or <literal>MODIFY</literal> operations.
- </para>
-
- <indexterm type="function">
- <primary>ALTER COLUMN</primary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>changing</primary>
- <secondary>column</secondary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>column</primary>
- <secondary>changing</secondary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>changing</primary>
- <secondary>field</secondary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>field</primary>
- <secondary>changing</secondary>
- </indexterm></listitem>
-
- <listitem><para>
- <literal>ALTER COLUMN</literal> specifies a new default value for a
- column or removes the old default value. If the old default is
- removed and the column can be <literal>NULL</literal>, the new
- default is <literal>NULL</literal>. If the column cannot be
- <literal>NULL</literal>, MySQL assigns a default value, as
- described in <xref linkend="create-table"/>.
- </para>
-
- <indexterm type="function">
- <primary>DROP INDEX</primary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>deleting</primary>
- <secondary>index</secondary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>index</primary>
- <secondary>deleting</secondary>
- </indexterm></listitem>
-
- <listitem><para>
- <literal>DROP INDEX</literal> removes an index. This is a MySQL
- extension to standard SQL. See <xref linkend="drop-index"/>.
- </para></listitem>
-
- <listitem><para>
- 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.
- </para></listitem>
-
- <listitem><para>
- If a table contains only one column, the column cannot be dropped.
- If what you intend is to remove the table, use <literal>DROP
- TABLE</literal> instead.
- </para></listitem>
-
- <listitem><indexterm type="function">
- <primary>DROP PRIMARY KEY</primary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>deleting</primary>
- <secondary>primary key</secondary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>primary key</primary>
- <secondary>deleting</secondary>
- </indexterm>
-
- <para>
- <literal>DROP PRIMARY KEY</literal> drops the primary index. (Prior
- to MySQL 4.1.2, if no primary index exists, <literal>DROP PRIMARY
- KEY</literal> drops the first <literal>UNIQUE</literal> index in
- the table. MySQL marks the first <literal>UNIQUE</literal> key as
- the <literal>PRIMARY KEY</literal> if no <literal>PRIMARY
- KEY</literal> was specified explicitly.)
- </para>
-
- <indexterm type="function">
- <primary>UNIQUE</primary>
- </indexterm>
-
- <indexterm type="function">
- <primary>PRIMARY KEY</primary>
- </indexterm>
-
- <para>
- If you add a <literal>UNIQUE INDEX</literal> or <literal>PRIMARY
- KEY</literal> to a table, it is stored before any non-unique index
- so that MySQL can detect duplicate keys as early as possible.
- </para>
-
- <indexterm type="function">
- <primary>ORDER BY</primary>
- </indexterm></listitem>
-
- <listitem><para>
- <literal>ORDER BY</literal> allows 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 mainly
- useful when you know that you are mostly going to query the rows in
- a certain order; by using this option after big 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.
- </para>
-
- <indexterm type="function">
- <primary>ALTER TABLE</primary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>changing</primary>
- <secondary>table</secondary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>table</primary>
- <secondary>changing</secondary>
- </indexterm></listitem>
-
- <listitem><para>
- If you use <literal>ALTER TABLE</literal> on a
- <literal>MyISAM</literal> table, all non-unique indexes are created
- in a separate batch (as for <literal>REPAIR TABLE</literal>). This
- should make <literal>ALTER TABLE</literal> much faster when you
- have many indexes.
- </para>
-
- <para>
- As of MySQL 4.0, this feature can be activated explicitly.
- <literal>ALTER TABLE ... DISABLE KEYS</literal> tells MySQL to stop
- updating non-unique indexes for a <literal>MyISAM</literal> table.
- <literal>ALTER TABLE ... ENABLE KEYS</literal> 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 <literal>ALTER TABLE ... DISABLE
- KEYS</literal> requires the <literal>INDEX</literal> privilege in
- addition to the privileges mentioned earlier.
- </para></listitem>
-
- <listitem><indexterm type="concept">
- <primary>foreign keys</primary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>references</primary>
- </indexterm>
-
- <para>
- The <literal>FOREIGN KEY</literal> and
- <literal>REFERENCES</literal> clauses are supported by the
- <literal>InnoDB</literal> storage engine, which implements
- <literal>ADD [CONSTRAINT [<replaceable>symbol</replaceable>]]
- FOREIGN KEY (...) REFERENCES ... (...)</literal>. See
- <xref linkend="innodb-foreign-key-constraints"/>. For other storage
- engines, the clauses are parsed but ignored. The
- <literal>CHECK</literal> clause is parsed but ignored by all
- storage engines. See <xref linkend="create-table"/>. 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
- <xref linkend="differences-from-ansi"/>.
- </para></listitem>
-
- <listitem><indexterm type="function">
- <primary>DROP FOREIGN KEY</primary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>deleting</primary>
- <secondary>foreign key</secondary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>foreign key</primary>
- <secondary>deleting</secondary>
- </indexterm>
-
- <para>
- Starting from MySQL 4.0.13, <literal>InnoDB</literal> supports the
- use of <literal>ALTER TABLE</literal> to drop foreign keys:
- </para>
-
-<programlisting>
-ALTER TABLE <replaceable>yourtablename</replaceable> DROP FOREIGN KEY <replaceable>fk_symbol</replaceable>;
-</programlisting>
-
- <para>
- For more information, see
- <xref linkend="innodb-foreign-key-constraints"/>.
- </para></listitem>
-
- <listitem><para>
- <literal>ALTER TABLE</literal> ignores the <literal>DATA
- DIRECTORY</literal> and <literal>INDEX DIRECTORY</literal> table
- options.
- </para></listitem>
-
- <listitem><indexterm type="function">
- <primary>CONVERT TO</primary>
- </indexterm>
-
- <para>
- From MySQL 4.1.2 on, if you want to change the table default
- character set and all character columns (<literal>CHAR</literal>,
- <literal>VARCHAR</literal>, <literal>TEXT</literal>) to a new
- character set, use a statement like this:
- </para>
-
-<programlisting>
-ALTER TABLE <replaceable>tbl_name</replaceable> CONVERT TO CHARACTER SET <replaceable>charset_name</replaceable>;
-</programlisting>
-
- <para>
- This is useful, for example, after upgrading from MySQL 4.0.x to
- 4.1.x. See <xref linkend="charset-upgrading"/>.
- </para>
-
- <para>
- <emphasis role="bold">Warning:</emphasis> The preceding operation
- converts column values between the character sets. This is
- <emphasis>not</emphasis> what you want if you have a column in one
- character set (like <literal>latin1</literal>) but the stored
- values actually use some other, incompatible character set (like
- <literal>utf8</literal>). In this case, you have to do the
- following for each such column:
- </para>
-
-<programlisting>
-ALTER TABLE t1 CHANGE c1 c1 BLOB;
-ALTER TABLE t1 CHANGE c1 c1 TEXT CHARACTER SET utf8;
-</programlisting>
-
- <para>
- The reason this works is that there is no conversion when you
- convert to or from <literal>BLOB</literal> columns.
- </para>
-
- <para>
- If you specify <literal>CONVERT TO CHARACTER SET binary</literal>,
- the <literal>CHAR</literal>, <literal>VARCHAR</literal>, and
- <literal>TEXT</literal> columns are converted to their
- corresponding binary string types (<literal>BINARY</literal>,
- <literal>VARBINARY</literal>, <literal>BLOB</literal>). This means
- that the columns no longer will have a character set and a
- subsequent <literal>CONVERT TO</literal> operation will not apply
- to them.
- </para>
-
- <para>
- To change only the <emphasis>default</emphasis> character set for a
- table, use this statement:
- </para>
-
-<programlisting>
-ALTER TABLE <replaceable>tbl_name</replaceable> DEFAULT CHARACTER SET <replaceable>charset_name</replaceable>;
-</programlisting>
-
- <para>
- The word <literal>DEFAULT</literal> is optional. The default
- character set is the character set that is used if you don't
- specify the character set for a new column you add to a table (for
- example, with <literal>ALTER TABLE ... ADD column</literal>).
- </para>
-
- <para>
- <emphasis role="bold">Warning:</emphasis> From MySQL 4.1.2 and up,
- <literal>ALTER TABLE ... DEFAULT CHARACTER SET</literal> and
- <literal>ALTER TABLE ... CHARACTER SET</literal> are equivalent and
- change only the default table character set. In MySQL 4.1 releases
- before 4.1.2, <literal>ALTER TABLE ... DEFAULT CHARACTER
- SET</literal> changes the default character set, but <literal>ALTER
- TABLE ... CHARACTER SET</literal> (without
- <literal>DEFAULT</literal>) changes the default character set
- <emphasis>and also</emphasis> converts all columns to the new
- character set.
- </para></listitem>
-
- <listitem><indexterm type="function">
- <primary>DISCARD TABLESPACE</primary>
- </indexterm>
-
- <indexterm type="function">
- <primary>IMPORT TABLESPACE</primary>
- </indexterm>
-
- <para>
- For an <literal>InnoDB</literal> table that is created with its own
- tablespace in an <filename>.ibd</filename> file, that file can be
- discarded and imported. To discard the <filename>.ibd</filename>
- file, use this statement:
- </para>
-
-<programlisting>
-ALTER TABLE <replaceable>tbl_name</replaceable> DISCARD TABLESPACE;
-</programlisting>
-
- <para>
- This deletes the current <filename>.ibd</filename> 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.
- </para>
-
- <para>
- To import the backup <filename>.ibd</filename> file back into the
- table, copy it into the database directory, then issue this
- statement:
- </para>
-
-<programlisting>
-ALTER TABLE <replaceable>tbl_name</replaceable> IMPORT TABLESPACE;
-</programlisting>
-
- <para>
- See <xref linkend="multiple-tablespaces"/>.
- </para></listitem>
-
- <listitem><indexterm type="function">
- <primary>mysql_info()</primary>
- </indexterm>
-
- <para>
- With the <literal>mysql_info()</literal> C API function, you can
- find out how many records were copied, and (when
- <literal>IGNORE</literal> is used) how many records were deleted
- due to duplication of unique key values. See
- <xref linkend="mysql-info"/>.
- </para></listitem>
-
- </itemizedlist>
-
- <para>
- Here are some examples that show uses of <literal>ALTER
- TABLE</literal>. Begin with a table <literal>t1</literal> that is
- created as shown here:
- </para>
-
-<programlisting>
-mysql> CREATE TABLE t1 (a INTEGER,b CHAR(10));
-</programlisting>
-
- <para>
- To rename the table from <literal>t1</literal> to
- <literal>t2</literal>:
- </para>
-
-<programlisting>
-mysql> ALTER TABLE t1 RENAME t2;
-</programlisting>
-
- <para>
- To change column <literal>a</literal> from
- <literal>INTEGER</literal> to <literal>TINYINT NOT NULL</literal>
- (leaving the name the same), and to change column
- <literal>b</literal> from <literal>CHAR(10)</literal> to
- <literal>CHAR(20)</literal> as well as renaming it from
- <literal>b</literal> to <literal>c</literal>:
- </para>
-
-<programlisting>
-mysql> ALTER TABLE t2 MODIFY a TINYINT NOT NULL, CHANGE b c CHAR(20);
-</programlisting>
-
- <para>
- To add a new <literal>TIMESTAMP</literal> column named
- <literal>d</literal>:
- </para>
-
-<programlisting>
-mysql> ALTER TABLE t2 ADD d TIMESTAMP;
-</programlisting>
-
- <para>
- To add indexes on column <literal>d</literal> and on column
- <literal>a</literal>:
- </para>
-
-<programlisting>
-mysql> ALTER TABLE t2 ADD INDEX (d), ADD INDEX (a);
-</programlisting>
-
- <para>
- To remove column <literal>c</literal>:
- </para>
-
-<programlisting>
-mysql> ALTER TABLE t2 DROP COLUMN c;
-</programlisting>
-
- <para>
- To add a new <literal>AUTO_INCREMENT</literal> integer column named
- <literal>c</literal>:
- </para>
-
-<programlisting>
-mysql> ALTER TABLE t2 ADD c INT UNSIGNED NOT NULL AUTO_INCREMENT,
- -> ADD PRIMARY KEY (c);
-</programlisting>
-
- <para>
- Note that we indexed <literal>c</literal> (as a <literal>PRIMARY
- KEY</literal>), because <literal>AUTO_INCREMENT</literal> columns
- must be indexed, and also that we declare <literal>c</literal> as
- <literal>NOT NULL</literal>, because primary key columns cannot be
- <literal>NULL</literal>.
- </para>
-
- <para>
- When you add an <literal>AUTO_INCREMENT</literal> column, column
- values are filled in with sequence numbers for you automatically.
- For <literal>MyISAM</literal> tables, you can set the first sequence
- number by executing <literal>SET
- INSERT_ID=<replaceable>value</replaceable></literal> before
- <literal>ALTER TABLE</literal> or by using the
- <literal>AUTO_INCREMENT=<replaceable>value</replaceable></literal>
- table option. See <xref linkend="set-option"/>.
- </para>
-
- <para>
- From MySQL 5.0.3, you can use the <literal>ALTER TABLE ...
- AUTO_INCREMENT=<replaceable>value</replaceable></literal> table
- option for <literal>InnoDB</literal> tables to set the sequence
- number for new rows if the value is greater than the maximum value
- in the <literal>AUTO_INCREMENT</literal> column. If the value is
- less than the maximum column value, no error message is given and
- the current sequence value is not changed.
- </para>
-
- <para>
- With <literal>MyISAM</literal> tables, if you don't change the
- <literal>AUTO_INCREMENT</literal> column, the sequence number is not
- affected. If you drop an <literal>AUTO_INCREMENT</literal> column
- and then add another <literal>AUTO_INCREMENT</literal> column, the
- numbers are resequenced beginning with 1.
- </para>
-
- <para>
- See <xref linkend="alter-table-problems"/>.
- </para>
-
- </section>
-
- <section id="create-database">
-
- <title id='title-create-database'>&title-create-database;</title>
-
- <indexterm type="function">
- <primary>CREATE DATABASE</primary>
- </indexterm>
-
- <indexterm type="function">
- <primary>CREATE SCHEMA</primary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>creating</primary>
- <secondary>database</secondary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>database</primary>
- <secondary>creating</secondary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>creating</primary>
- <secondary>schema</secondary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>schema</primary>
- <secondary>creating</secondary>
- </indexterm>
-
-<!-- example_for_help_topic CREATE DATABASE -->
-
-<programlisting>
-CREATE {DATABASE | SCHEMA} [IF NOT EXISTS] <replaceable>db_name</replaceable>
- [<replaceable>create_specification</replaceable> [, <replaceable>create_specification</replaceable>] ...]
-
-<replaceable>create_specification</replaceable>:
- [DEFAULT] CHARACTER SET <replaceable>charset_name</replaceable>
- | [DEFAULT] COLLATE <replaceable>collation_name</replaceable>
-</programlisting>
-
-<!-- description_for_help_topic CREATE DATABASE CREATE DATABASE SCHEMA IF EXISTS NOT -->
-
- <para>
- <literal>CREATE DATABASE</literal> creates a database with the given
- name. To use <literal>CREATE DATABASE</literal>, you need the
- <literal>CREATE</literal> privilege on the database.
-
-<!-- end_description_for_help_topic -->
- </para>
-
- <para>
- Rules for allowable database names are given in
- <xref linkend="legal-names"/>. An error occurs if the database
- exists and you didn't specify <literal>IF NOT EXISTS</literal>.
- </para>
-
- <para>
- As of MySQL 4.1.1, <literal>create_specification</literal> options
- can be given to specify database characteristics. Database
- characteristics are stored in the <filename>db.opt</filename> file
- in the database directory. The <literal>CHARACTER SET</literal>
- clause specifies the default database character set. The
- <literal>COLLATE</literal> clause specifies the default database
- collation. Character set and collation names are discussed in
- <xref linkend="charset"/>.
- </para>
-
- <para>
- Databases in MySQL are implemented as directories containing files
- that correspond to tables in the database. Because there are no
- tables in a database when it is initially created, the
- <literal>CREATE DATABASE</literal> statement only creates a
- directory under the MySQL data directory (and the
- <filename>db.opt</filename> file, for MySQL 4.1.1 and up).
- </para>
-
- <para>
- If you manually create a directory under the data directory (for
- example, with <command>mkdir</command>), the server considers it a
- database directory and it shows up in the output of <literal>SHOW
- DATABASES</literal>.
- </para>
-
- <para>
- <literal>CREATE SCHEMA</literal> can be used as of MySQL 5.0.2.
- </para>
-
- <indexterm type="concept">
- <primary><command>mysqladmin</command></primary>
- </indexterm>
-
- <para>
- You can also use the <command>mysqladmin</command> program to create
- databases. See <xref linkend="mysqladmin"/>.
- </para>
-
- </section>
-
- <section id="create-index">
-
- <title id='title-create-index'>&title-create-index;</title>
-
- <indexterm type="function">
- <primary>CREATE INDEX</primary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>indexes</primary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>indexes</primary>
- <secondary>multiple-part</secondary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>multiple-part index</primary>
- </indexterm>
-
-<!-- example_for_help_topic CREATE INDEX -->
-
-<programlisting>
-CREATE [UNIQUE|FULLTEXT|SPATIAL] INDEX <replaceable>index_name</replaceable>
- [USING <replaceable>index_type</replaceable>]
- ON <replaceable>tbl_name</replaceable> (<replaceable>index_col_name</replaceable>,...)
-
-<replaceable>index_col_name</replaceable>:
- <replaceable>col_name</replaceable> [(<replaceable>length</replaceable>)] [ASC | DESC]
-</programlisting>
-
-<!-- description_for_help_topic CREATE INDEX BTREE RTREE INDEX CREATE FULLTEXT SPATIAL -->
-
- <para>
- In MySQL 3.22 or later, <literal>CREATE INDEX</literal> is mapped to
- an <literal>ALTER TABLE</literal> statement to create indexes. See
- <xref linkend="alter-table"/>. The <literal>CREATE INDEX</literal>
- statement doesn't do anything prior to MySQL 3.22.
-
-<!-- end_description_for_help_topic -->
- </para>
-
- <para>
- Normally, you create all indexes on a table at the time the table
- itself is created with <literal>CREATE TABLE</literal>. See
- <xref linkend="create-table"/>. <literal>CREATE INDEX</literal>
- allows you to add indexes to existing tables.
- </para>
-
- <para>
- A column list of the form <literal>(col1,col2,...)</literal> creates
- a multiple-column index. Index values are formed by concatenating
- the values of the given columns.
- </para>
-
- <para>
- For <literal>CHAR</literal> and <literal>VARCHAR</literal> columns,
- indexes can be created that use only part of a column, using
- <literal><replaceable>col_name</replaceable>(<replaceable>length</replaceable>)</literal>
- syntax to index a prefix consisting of the first
- <replaceable>length</replaceable> characters of each column value.
- <literal>BLOB</literal> and <literal>TEXT</literal> columns also can
- be indexed, but a prefix length <emphasis>must</emphasis> be given.
- </para>
-
- <para>
- The statement shown here creates an index using the first 10
- characters of the <literal>name</literal> column:
- </para>
-
-<programlisting>
-CREATE INDEX part_of_name ON customer (name(10));
-</programlisting>
-
- <para>
- Because most names usually differ in the first 10 characters, this
- index should not be much slower than an index created from the
- entire <literal>name</literal> column. Also, using partial columns
- for indexes can make the index file much smaller, which could save a
- lot of disk space and might also speed up <literal>INSERT</literal>
- operations!
- </para>
-
- <para>
- Prefixes can be up to 255 bytes long (or 1000 bytes for
- <literal>MyISAM</literal> and <literal>InnoDB</literal> tables as of
- MySQL 4.1.2). Note that prefix limits are measured in bytes, whereas
- the prefix length in <literal>CREATE INDEX</literal> statements is
- interpreted as number of characters. Take this into account when
- specifying a prefix length for a column that uses a multi-byte
- character set.
- </para>
-
- <para>
- You can add an index on a column that can have
- <literal>NULL</literal> values only if you are using MySQL 3.23.2 or
- newer and are using the <literal>MyISAM</literal>,
- <literal>InnoDB</literal>, or <literal>BDB</literal> table type. You
- can only add an index on a <literal>BLOB</literal> or
- <literal>TEXT</literal> column if you are using MySQL 3.23.2 or
- newer and are using the <literal>MyISAM</literal> or
- <literal>BDB</literal> table type, or MySQL 4.0.14 or newer and the
- <literal>InnoDB</literal> table type.
- </para>
-
- <para>
- An <replaceable>index_col_name</replaceable> specification can end
- with <literal>ASC</literal> or <literal>DESC</literal>. 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.
- </para>
-
- <para>
- From MySQL 4.1.0 on, some storage engines allow you to specify an
- index type when creating an index. The syntax for the
- <replaceable>index_type</replaceable> specifier is <literal>USING
- type_name</literal>. The allowable <literal>type_name</literal>
- 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 <replaceable>index_type</replaceable>
- specifier is given.
- </para>
-
- <informaltable>
- <tgroup cols="2">
- <colspec colwidth="20*"/>
- <colspec colwidth="50*"/>
- <tbody>
- <row>
- <entry>
- <emphasis role="bold">Storage Engine</emphasis>
- </entry>
- <entry>
- <emphasis role="bold">Allowable Index Types</emphasis>
- </entry>
- </row>
- <row>
- <entry>
- <literal>MyISAM</literal>
- </entry>
- <entry>
- <literal>BTREE</literal>
- </entry>
- </row>
- <row>
- <entry>
- <literal>InnoDB</literal>
- </entry>
- <entry>
- <literal>BTREE</literal>
- </entry>
- </row>
- <row>
- <entry>
- <literal>MEMORY/HEAP</literal>
- </entry>
- <entry>
- <literal>HASH</literal>, <literal>BTREE</literal>
- </entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>
- Example:
- </para>
-
-<programlisting>
-CREATE TABLE lookup (id INT) ENGINE = MEMORY;
-CREATE INDEX id_index USING BTREE ON lookup (id);
-</programlisting>
-
- <para>
- <literal>TYPE type_name</literal> can be used as a synonym for
- <literal>USING type_name</literal> to specify an index type.
- However, <literal>USING</literal> is the preferred form. Also, the
- index name that precedes the index type in the index specification
- syntax is not optional with <literal>TYPE</literal>. This is
- because, unlike <literal>USING</literal>, <literal>TYPE</literal> is
- not a reserved word and thus is interpreted as an index name.
- </para>
-
- <para>
- If you specify an index type that is not legal for a storage engine,
- but there is another index type available that the engine can use
- without affecting query results, the engine uses the available type.
- </para>
-
- <para>
- For more information about how MySQL uses indexes, see
- <xref linkend="mysql-indexes"/>.
- </para>
-
- <para>
- <literal>FULLTEXT</literal> indexes can index only
- <literal>CHAR</literal>, <literal>VARCHAR</literal>, and
- <literal>TEXT</literal> columns, and only in
- <literal>MyISAM</literal> tables. <literal>FULLTEXT</literal>
- indexes are available in MySQL 3.23.23 or later.
- <xref linkend="fulltext-search"/>.
- </para>
-
- <para>
- <literal>SPATIAL</literal> indexes can index only spatial columns,
- and only in <literal>MyISAM</literal> tables.
- <literal>SPATIAL</literal> indexes are available in MySQL 4.1 or
- later. Spatial column types are described in
- <xref linkend="spatial-extensions-in-mysql"/>.
- </para>
-
- </section>
-
- <section id="create-table">
-
- <title id='title-create-table'>&title-create-table;</title>
-
- <indexterm type="function">
- <primary>CREATE TABLE</primary>
- </indexterm>
-
-<!-- example_for_help_topic CREATE TABLE -->
-
-<programlisting>
-CREATE [TEMPORARY] TABLE [IF NOT EXISTS] <replaceable>tbl_name</replaceable>
- [(<replaceable>create_definition</replaceable>,...)]
- [<replaceable>table_options</replaceable>] [<replaceable>select_statement</replaceable>]
-</programlisting>
-
- <para>
- Or:
- </para>
-
-<programlisting>
-CREATE [TEMPORARY] TABLE [IF NOT EXISTS] <replaceable>tbl_name</replaceable>
- [(] LIKE <replaceable>old_tbl_name</replaceable> [)];
-
-<replaceable>create_definition</replaceable>:
- <replaceable>column_definition</replaceable>
- | [CONSTRAINT [<replaceable>symbol</replaceable>]] PRIMARY KEY [<replaceable>index_type</replaceable>] (<replaceable>index_col_name</replaceable>,...)
- | KEY [<replaceable>index_name</replaceable>] [<replaceable>index_type</replaceable>] (<replaceable>index_col_name</replaceable>,...)
- | INDEX [<replaceable>index_name</replaceable>] [<replaceable>index_type</replaceable>] (<replaceable>index_col_name</replaceable>,...)
- | [CONSTRAINT [<replaceable>symbol</replaceable>]] UNIQUE [INDEX]
- [<replaceable>index_name</replaceable>] [<replaceable>index_type</replaceable>] (<replaceable>index_col_name</replaceable>,...)
- | [FULLTEXT|SPATIAL] [INDEX] [<replaceable>index_name</replaceable>] (<replaceable>index_col_name</replaceable>,...)
- | [CONSTRAINT [<replaceable>symbol</replaceable>]] FOREIGN KEY
- [<replaceable>index_name</replaceable>] (<replaceable>index_col_name</replaceable>,...) [<replaceable>reference_definition</replaceable>]
- | CHECK (<replaceable>expr</replaceable>)
-
-<replaceable>column_definition</replaceable>:
- <replaceable>col_name</replaceable> <replaceable>type</replaceable> [NOT NULL | NULL] [DEFAULT <replaceable>default_value</replaceable>]
- [AUTO_INCREMENT] [UNIQUE [KEY] | [PRIMARY] KEY]
- [COMMENT '<replaceable>string</replaceable>'] [<replaceable>reference_definition</replaceable>]
-
-<replaceable>type</replaceable>:
- TINYINT[(<replaceable>length</replaceable>)] [UNSIGNED] [ZEROFILL]
- | SMALLINT[(<replaceable>length</replaceable>)] [UNSIGNED] [ZEROFILL]
- | MEDIUMINT[(<replaceable>length</replaceable>)] [UNSIGNED] [ZEROFILL]
- | INT[(<replaceable>length</replaceable>)] [UNSIGNED] [ZEROFILL]
- | INTEGER[(<replaceable>length</replaceable>)] [UNSIGNED] [ZEROFILL]
- | BIGINT[(<replaceable>length</replaceable>)] [UNSIGNED] [ZEROFILL]
- | REAL[(<replaceable>length</replaceable>,<replaceable>decimals</replaceable>)] [UNSIGNED] [ZEROFILL]
- | DOUBLE[(<replaceable>length</replaceable>,<replaceable>decimals</replaceable>)] [UNSIGNED] [ZEROFILL]
- | FLOAT[(<replaceable>length</replaceable>,<replaceable>decimals</replaceable>)] [UNSIGNED] [ZEROFILL]
- | DECIMAL(<replaceable>length</replaceable>,<replaceable>decimals</replaceable>) [UNSIGNED] [ZEROFILL]
- | NUMERIC(<replaceable>length</replaceable>,<replaceable>decimals</replaceable>) [UNSIGNED] [ZEROFILL]
- | DATE
- | TIME
- | TIMESTAMP
- | DATETIME
- | CHAR(<replaceable>length</replaceable>) [BINARY | ASCII | UNICODE]
- | VARCHAR(<replaceable>length</replaceable>) [BINARY]
- | TINYBLOB
- | BLOB
- | MEDIUMBLOB
- | LONGBLOB
- | TINYTEXT [BINARY]
- | TEXT [BINARY]
- | MEDIUMTEXT [BINARY]
- | LONGTEXT [BINARY]
- | ENUM(<replaceable>value1</replaceable>,<replaceable>value2</replaceable>,<replaceable>value3</replaceable>,...)
- | SET(<replaceable>value1</replaceable>,<replaceable>value2</replaceable>,<replaceable>value3</replaceable>,...)
- | <replaceable>spatial_type</replaceable>
-
-<replaceable>index_col_name</replaceable>:
- <replaceable>col_name</replaceable> [(<replaceable>length</replaceable>)] [ASC | DESC]
-
-<replaceable>reference_definition</replaceable>:
- REFERENCES <replaceable>tbl_name</replaceable> [(<replaceable>index_col_name</replaceable>,...)]
- [MATCH FULL | MATCH PARTIAL | MATCH SIMPLE]
- [ON DELETE <replaceable>reference_option</replaceable>]
- [ON UPDATE <replaceable>reference_option</replaceable>]
-
-<replaceable>reference_option</replaceable>:
- RESTRICT | CASCADE | SET NULL | NO ACTION
-
-<replaceable>table_options</replaceable>: <replaceable>table_option</replaceable> [<replaceable>table_option</replaceable>] ...
-
-<replaceable>table_option</replaceable>:
- {ENGINE|TYPE} = <replaceable>engine_name</replaceable>
- | AUTO_INCREMENT = <replaceable>value</replaceable>
- | AVG_ROW_LENGTH = <replaceable>value</replaceable>
- | [DEFAULT] CHARACTER SET <replaceable>charset_name</replaceable> [COLLATE <replaceable>collation_name</replaceable>]
- | CHECKSUM = {0 | 1}
- | COMMENT = '<replaceable>string</replaceable>'
- | MAX_ROWS = <replaceable>value</replaceable>
- | MIN_ROWS = <replaceable>value</replaceable>
- | PACK_KEYS = {0 | 1 | DEFAULT}
- | PASSWORD = '<replaceable>string</replaceable>'
- | DELAY_KEY_WRITE = {0 | 1}
- | ROW_FORMAT = {DEFAULT|DYNAMIC|FIXED|COMPRESSED|REDUNDANT|COMPACT}
- | RAID_TYPE = { 1 | STRIPED | RAID0 }
- RAID_CHUNKS = <replaceable>value</replaceable>
- RAID_CHUNKSIZE = <replaceable>value</replaceable>
- | UNION = (<replaceable>tbl_name</replaceable>[,<replaceable>tbl_name</replaceable>]...)
- | INSERT_METHOD = { NO | FIRST | LAST }
- | DATA DIRECTORY = '<replaceable>absolute path to directory</replaceable>'
- | INDEX DIRECTORY = '<replaceable>absolute path to directory</replaceable>'
-
-<replaceable>select_statement:</replaceable>
- [IGNORE | REPLACE] [AS] SELECT ... (<replaceable>Some legal select statement</replaceable>)
-</programlisting>
-
-<!-- description_for_help_topic CREATE TABLE ENGINE TYPE KEY CREATE DATA ACTION ARCHIVE AVG_ROW_LENGTH BERKELEYDB BDB BY CASCADE CHECK CHECKSUM COMMENT COMPACT CONSTRAINT COMPRESSED CSV FEDERATED FIXED DYNAMIC DEFAULT DELAY_KEY_WRITE DELETE DIRECTORY INDEX FIRST FOREIGN RAID_TYPE RAID_CHUNKS RAID_CHUNKSIZE ROW_FORMAT FULL FULLTEXT HEAP INNOBASE INNODB ISAM INSERT_METHOD MAX_ROWS MIN_ROWS PACK_KEYS PARTIAL RAID0 STRIPED MERGE MRG_MYISAM MYISAM NDB NDBCLUSTER NO REDUNDANT REFERENCES SERIAL -->
-
- <para>
- <literal>CREATE TABLE</literal> creates a table with the given name.
- You must have the <literal>CREATE</literal> privilege for the table.
- </para>
-
- <para>
- Rules for allowable table names are given in
- <xref linkend="legal-names"/>. By default, the table is created in
- the current database. An error occurs if the table exists, if there
- is no current database, or if the database does not exist.
-
-<!-- end_description_for_help_topic -->
- </para>
-
- <para>
- In MySQL 3.22 or later, the table name can be specified as
- <replaceable>db_name.tbl_name</replaceable> to create the table in a
- specific database. This works whether or not there is a current
- database. If you use quoted identifiers, quote the database and
- table names separately. For example,
- <literal>`mydb`.`mytbl`</literal> is legal, but
- <literal>`mydb.mytbl`</literal> is not.
- </para>
-
- <para>
- From MySQL 3.23 on, you can use the <literal>TEMPORARY</literal>
- keyword when creating a table. A <literal>TEMPORARY</literal> 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-<literal>TEMPORARY</literal> table of the same name. (The
- existing table is hidden until the temporary table is dropped.) From
- MySQL 4.0.2 on, you must have the <literal>CREATE TEMPORARY
- TABLES</literal> privilege to be able to create temporary tables.
- </para>
-
- <para>
- In MySQL 3.23 or later, you can use the keywords <literal>IF NOT
- EXISTS</literal> so that an error does not occur if the table
- exists. Note that there is no verification that the existing table
- has a structure identical to that indicated by the <literal>CREATE
- TABLE</literal> statement. Also, if you use <literal>IF NOT
- EXISTS</literal> in a <literal>CREATE TABLE ... SELECT</literal>
- statement, any records selected by the <literal>SELECT</literal>
- part are inserted regardless of whether the table already exists.
- </para>
-
- <para>
- MySQL represents each table by an <filename>.frm</filename> table
- format (definition) file in the database directory. The storage
- engine for the table might create other files as well. In the case
- of <literal>MyISAM</literal> tables, the storage engine creates data
- and index files. Thus, for each <literal>MyISAM</literal> table
- <replaceable>tbl_name</replaceable>, there are three disk files:
- </para>
-
- <informaltable>
- <tgroup cols="2">
- <colspec colwidth="30*"/>
- <colspec colwidth="70*"/>
- <tbody>
- <row>
- <entry>
- <emphasis role="bold">File</emphasis>
- </entry>
- <entry>
- <emphasis role="bold">Purpose</emphasis>
- </entry>
- </row>
- <row>
- <entry>
- <literal><replaceable>tbl_name</replaceable>.frm</literal>
- </entry>
- <entry>
- Table format (definition) file
- </entry>
- </row>
- <row>
- <entry>
- <literal><replaceable>tbl_name</replaceable>.MYD</literal>
- </entry>
- <entry>
- Data file
- </entry>
- </row>
- <row>
- <entry>
- <literal><replaceable>tbl_name</replaceable>.MYI</literal>
- </entry>
- <entry>
- Index file
- </entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>
- The files created by each storage engine to represent tables are
- described in <xref linkend="storage-engines"/>.
- </para>
-
- <para>
- For general information on the properties of the various column
- types, see <xref linkend="column-types"/>. For information about
- spatial column types, see
- <xref linkend="spatial-extensions-in-mysql"/>.
- </para>
-
- <itemizedlist>
-
- <listitem><para>
- If neither <literal>NULL</literal> nor <literal>NOT NULL</literal>
- is specified, the column is treated as though
- <literal>NULL</literal> had been specified.
- </para></listitem>
-
- <listitem><para>
- An integer column can have the additional attribute
- <literal>AUTO_INCREMENT</literal>. When you insert a value of
- <literal>NULL</literal> (recommended) or <literal>0</literal> into
- an indexed <literal>AUTO_INCREMENT</literal> column, the column is
- set to the next sequence value. Typically this is
- <literal><replaceable>value</replaceable>+1</literal>, where
- <replaceable>value</replaceable> is the largest value for the
- column currently in the table. <literal>AUTO_INCREMENT</literal>
- sequences begin with <literal>1</literal>. Such a column must be
- defined as one of the integer types as described in
- <xref linkend="numeric-type-overview"/>. (The value 1.0 is
- <emphasis role="bold">not</emphasis> an integer.) See
- <xref linkend="mysql-insert-id"/>.
- </para>
-
- <para>
- As of MySQL 4.1.1, specifying the
- <literal>NO_AUTO_VALUE_ON_ZERO</literal> flag for the
- <literal>--sql-mode</literal> server option or the
- <literal>sql_mode</literal> system variable allows you to store
- <literal>0</literal> in <literal>AUTO_INCREMENT</literal> columns
- as <literal>0</literal> without generating a new sequence value.
- See <xref linkend="server-options"/>.
- </para>
-
- <para>
- <emphasis role="bold">Note</emphasis>: There can be only one
- <literal>AUTO_INCREMENT</literal> column per table, it must be
- indexed, and it cannot have a <literal>DEFAULT</literal> value. As
- of MySQL 3.23, an <literal>AUTO_INCREMENT</literal> 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
- ``wrap'' over from positive to negative and also to ensure that you
- don't accidentally get an <literal>AUTO_INCREMENT</literal> column
- that contains <literal>0</literal>.
- </para>
-
- <para>
- For <literal>MyISAM</literal> and <literal>BDB</literal> tables,
- you can specify an <literal>AUTO_INCREMENT</literal> secondary
- column in a multiple-column key. See
- <xref linkend="example-auto-increment"/>.
- </para>
-
- <indexterm type="concept">
- <primary>ODBC compatibility</primary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>compatibility</primary>
- <secondary>with ODBC</secondary>
- </indexterm>
-
- <para>
- To make MySQL compatible with some ODBC applications, you can find
- the <literal>AUTO_INCREMENT</literal> value for the last inserted
- row with the following query:
- </para>
-
-<programlisting>
-SELECT * FROM <replaceable>tbl_name</replaceable> WHERE <replaceable>auto_col</replaceable> IS NULL
-</programlisting></listitem>
-
- <listitem><para>
- As of MySQL 4.1, character column definitions can include a
- <literal>CHARACTER SET</literal> attribute to specify the character
- set and, optionally, a collation for the column. For details, see
- <xref linkend="charset"/>. <literal>CHARSET</literal> is a synonym
- for <literal>CHARACTER SET</literal>.
- </para>
-
-<programlisting>
-CREATE TABLE t (c CHAR(20) CHARACTER SET utf8 COLLATE utf8_bin);
-</programlisting>
-
- <para>
- Also as of 4.1, MySQL interprets length specifications in character
- column definitions in characters. (Earlier versions interpret them
- in bytes.)
- </para></listitem>
-
- <listitem><para>
- <literal>NULL</literal> values are handled differently for
- <literal>TIMESTAMP</literal> columns than for other column types.
- Before MySQL 4.1.6, you cannot store a literal
- <literal>NULL</literal> in a <literal>TIMESTAMP</literal> column;
- setting the column to <literal>NULL</literal> sets it to the
- current date and time. Because <literal>TIMESTAMP</literal> columns
- behave this way, the <literal>NULL</literal> and <literal>NOT
- NULL</literal> attributes do not apply in the normal way and are
- ignored if you specify them. On the other hand, to make it easier
- for MySQL clients to use <literal>TIMESTAMP</literal> columns, the
- server reports that such columns can be assigned
- <literal>NULL</literal> values (which is true), even though
- <literal>TIMESTAMP</literal> never actually contains a
- <literal>NULL</literal> value. You can see this when you use
- <literal>DESCRIBE <replaceable>tbl_name</replaceable></literal> to
- get a description of your table.
- </para>
-
- <para>
- Note that setting a <literal>TIMESTAMP</literal> column to
- <literal>0</literal> is not the same as setting it to
- <literal>NULL</literal>, because <literal>0</literal> is a valid
- <literal>TIMESTAMP</literal> value.
- </para></listitem>
-
- <listitem><indexterm type="concept">
- <primary>default values</primary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>default values</primary>
- <secondary>implicit</secondary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>implicit default values</primary>
- </indexterm>
-
- <indexterm type="function">
- <primary>DEFAULT value clause</primary>
- </indexterm>
-
- <para>
- The <literal>DEFAULT</literal> 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 <literal>NOW()</literal> or
- <literal>CURRENT_DATE</literal>. The exception is that you can
- specify <literal>CURRENT_TIMESTAMP</literal> as the default for a
- <literal>TIMESTAMP</literal> column as of MySQL 4.1.2. See
- <xref linkend="timestamp-4-1"/>.
- </para>
-
- <para>
- Prior to MySQL 5.0.2, if a column definition includes no explicit
- <literal>DEFAULT</literal> value, MySQL determines the default
- value as follows:
- </para>
-
- <para>
- If the column can take <literal>NULL</literal> as a value, the
- column is defined with an explicit <literal>DEFAULT NULL</literal>
- clause.
- </para>
-
- <para>
- If the column cannot take <literal>NULL</literal> as the value,
- MySQL defines the column with an explicit
- <literal>DEFAULT</literal> clause, using the implicit default value
- for the column data type. Implicit defaults are defined as follows:
- </para>
-
- <itemizedlist>
-
- <listitem><para>
- For numeric types other than those declared with the
- <literal>AUTO_INCREMENT</literal> attribute, the default is
- <literal>0</literal>. For an <literal>AUTO_INCREMENT</literal>
- column, the default value is the next value in the sequence.
- </para></listitem>
-
- <listitem><para>
- For date and time types other than <literal>TIMESTAMP</literal>,
- the default is the appropriate ``zero'' value for the type. For
- the first <literal>TIMESTAMP</literal> column in a table, the
- default value is the current date and time. See
- <xref linkend="date-and-time-types"/>.
- </para></listitem>
-
- <listitem><para>
- For string types other than <literal>ENUM</literal>, the default
- value is the empty string. For <literal>ENUM</literal>, the
- default is the first enumeration value.
- </para></listitem>
-
- </itemizedlist>
-
- <para>
- <literal>BLOB</literal> and <literal>TEXT</literal> columns cannot
- be assigned a default value.
- </para>
-
- <para>
- As of MySQL 5.0.2, if a column definition includes no explicit
- <literal>DEFAULT</literal> value, MySQL determines the default
- value as follows:
- </para>
-
- <para>
- If the column can take <literal>NULL</literal> as a value, the
- column is defined with an explicit <literal>DEFAULT NULL</literal>
- clause. This is the same as before 5.0.2.
- </para>
-
- <para>
- If the column cannot take <literal>NULL</literal> as the value,
- MySQL defines the column with no explicit
- <literal>DEFAULT</literal> clause. For data entry, if an
- <literal>INSERT</literal> or <literal>REPLACE</literal> statement
- includes no value for the column, MySQL handles the column
- according to the SQL mode in effect at the time:
- </para>
-
- <itemizedlist>
-
- <listitem><para>
- If strict mode is not enabled, MySQL sets the column to the
- implicit default value for the column data type.
- </para></listitem>
-
- <listitem><para>
- If strict mode is enabled, an error occurs for transactional
- tables and the statement is rolled back. For non-transactional
- tables, an error occurs, but if this happens for the the second or
- subsequent row of a multiple-row statement, the preceding rows
- will have been inserted.
- </para></listitem>
-
- </itemizedlist>
-
- <para>
- Suppose that a table <literal>t</literal> is defined as follows:
- </para>
-
-<programlisting>
-CREATE TABLE t (i INT NOT NULL);
-</programlisting>
-
- <para>
- In this case, <literal>i</literal> has no explicit default, so in
- strict mode all of the following statements produce an error in
- strict mode and no row is inserted. For non strict mode, only the
- third statement produces an error; the implicit default is inserted
- for the first two, but the third fails because
- <literal>DEFAULT(i)</literal> cannot produce a value:
- </para>
-
-<programlisting>
-INSERT INTO t VALUES();
-INSERT INTO t VALUES(DEFAULT);
-INSERT INTO t VALUES(DEFAULT(i));
-</programlisting>
-
- <para>
- See <xref linkend="server-sql-mode"/>.
- </para>
-
- <para>
- For a given table, you can use the <literal>SHOW CREATE
- TABLE</literal> statement to see which columns have an explicit
- <literal>DEFAULT</literal> clause.
- </para></listitem>
-
- <listitem><indexterm type="concept">
- <primary>column comments</primary>
- </indexterm>
-
- <para>
- A comment for a column can be specified with the
- <literal>COMMENT</literal> option. The comment is displayed by the
- <literal>SHOW CREATE TABLE</literal> and <literal>SHOW FULL
- COLUMNS</literal> statements. This option is operational as of
- MySQL 4.1. (It is allowed but ignored in earlier versions.)
- </para></listitem>
-
- <listitem><para>
- From MySQL 4.1.0 on, the attribute <literal>SERIAL</literal> can be
- used as an alias for <literal>BIGINT UNSIGNED NOT NULL
- AUTO_INCREMENT UNIQUE</literal>.
- </para></listitem>
-
- <listitem><para>
- <literal>KEY</literal> is normally a synonym for
- <literal>INDEX</literal>. From MySQL 4.1, the key attribute
- <literal>PRIMARY KEY</literal> can also be specified as just
- <literal>KEY</literal> when given in a column definition. This was
- implemented for compatibility with other database systems.
- </para></listitem>
-
- <listitem><para>
- In MySQL, a <literal>UNIQUE</literal> index is one in which all
- values in the index must be distinct. An error occurs if you try to
- add a new row with a key that matches an existing row. The
- exception to this is that if a column in the index is allowed to
- contain <literal>NULL</literal> values, it can contain multiple
- <literal>NULL</literal> values. This exception does not apply to
- <literal>BDB</literal> tables, for which an indexed column allows
- only a single <literal>NULL</literal>.
- </para></listitem>
-
- <listitem><indexterm type="type">
- <primary>PRIMARY KEY</primary>
- </indexterm>
-
- <para>
- A <literal>PRIMARY KEY</literal> is a unique <literal>KEY</literal>
- where all key columns must be defined as <literal>NOT
- NULL</literal>. If they are not explicitly declared as <literal>NOT
- NULL</literal>, MySQL declares them so implicitly (and silently). A
- table can have only one <literal>PRIMARY KEY</literal>. If you
- don't have a <literal>PRIMARY KEY</literal> and an application asks
- for the <literal>PRIMARY KEY</literal> in your tables, MySQL
- returns the first <literal>UNIQUE</literal> index that has no
- <literal>NULL</literal> columns as the <literal>PRIMARY
- KEY</literal>.
- </para></listitem>
-
- <listitem><para>
- In the created table, a <literal>PRIMARY KEY</literal> is placed
- first, followed by all <literal>UNIQUE</literal> 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 <literal>UNIQUE</literal> keys.
- </para></listitem>
-
- <listitem><para>
- A <literal>PRIMARY KEY</literal> can be a multiple-column index.
- However, you cannot create a multiple-column index using the
- <literal>PRIMARY KEY</literal> key attribute in a column
- specification. Doing so only marks that single column as primary.
- You must use a separate <literal>PRIMARY KEY(index_col_name,
- ...)</literal> clause.
- </para></listitem>
-
- <listitem><para>
- If a <literal>PRIMARY KEY</literal> or <literal>UNIQUE</literal>
- index consists of only one column that has an integer type, you can
- also refer to the column as <literal>_rowid</literal> in
- <literal>SELECT</literal> statements (new in MySQL 3.23.11).
- </para></listitem>
-
- <listitem><para>
- In MySQL, the name of a <literal>PRIMARY KEY</literal> is
- <literal>PRIMARY</literal>. For other indexes, if you don't assign
- a name, the index is assigned the same name as the first indexed
- column, with an optional suffix (<literal>_2</literal>,
- <literal>_3</literal>, <literal>...</literal>) to make it unique.
- You can see index names for a table using <literal>SHOW INDEX FROM
- <replaceable>tbl_name</replaceable></literal>. See
- <xref linkend="show-index"/>.
- </para></listitem>
-
- <listitem><para>
- From MySQL 4.1.0 on, some storage engines allow you to specify an
- index type when creating an index. The syntax for the
- <replaceable>index_type</replaceable> specifier is <literal>USING
- type_name</literal>.
- </para>
-
- <para>
- Example:
- </para>
-
-<programlisting>
-CREATE TABLE lookup
- (id INT, INDEX USING BTREE (id))
- ENGINE = MEMORY;
-</programlisting>
-
- <para>
- For details about <literal>USING</literal>, see
- <xref linkend="create-index"/>.
- </para>
-
- <para>
- For more information about how MySQL uses indexes, see
- <xref linkend="mysql-indexes"/>.
- </para></listitem>
-
- <listitem><indexterm type="concept">
- <primary><literal>NULL</literal> values</primary>
- <secondary>and indexes</secondary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>indexes</primary>
- <secondary>and <literal>NULL</literal> values</secondary>
- </indexterm>
-
- <para>
- Only the <literal>MyISAM</literal>, <literal>InnoDB</literal>,
- <literal>BDB</literal>, and (as of MySQL 4.0.2)
- <literal>MEMORY</literal> storage engines support indexes on
- columns that can have <literal>NULL</literal> values. In other
- cases, you must declare indexed columns as <literal>NOT
- NULL</literal> or an error results.
- </para></listitem>
-
- <listitem><para>
- With
- <literal><replaceable>col_name</replaceable>(<replaceable>length</replaceable>)</literal>
- syntax in an index specification, you can create an index that uses
- only the first <replaceable>length</replaceable> characters of a
- <literal>CHAR</literal> or <literal>VARCHAR</literal> column.
- Indexing only a prefix of column values like this can make the
- index file much smaller. See <xref linkend="indexes"/>.
- </para>
-
- <indexterm type="concept">
- <primary><literal>BLOB</literal> columns</primary>
- <secondary>indexing</secondary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>indexes</primary>
- <secondary>and <literal>BLOB</literal> columns</secondary>
- </indexterm>
-
- <indexterm type="concept">
- <primary><literal>TEXT</literal> columns</primary>
- <secondary>indexing</secondary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>indexes</primary>
- <secondary>and <literal>TEXT</literal> columns</secondary>
- </indexterm>
-
- <para>
- The <literal>MyISAM</literal> and (as of MySQL 4.0.14)
- <literal>InnoDB</literal> storage engines also support indexing on
- <literal>BLOB</literal> and <literal>TEXT</literal> columns. When
- indexing a <literal>BLOB</literal> or <literal>TEXT</literal>
- column, you <emphasis>must</emphasis> specify a prefix length for
- the index. For example:
- </para>
-
-<programlisting>
-CREATE TABLE test (blob_col BLOB, INDEX(blob_col(10)));
-</programlisting>
-
- <para>
- Prefixes can be up to 255 bytes long (or 1000 bytes for
- <literal>MyISAM</literal> and <literal>InnoDB</literal> tables as
- of MySQL 4.1.2). Note that prefix limits are measured in bytes,
- whereas the prefix length in <literal>CREATE TABLE</literal>
- statements is interpreted as number of characters. Take this into
- account when specifying a prefix length for a column that uses a
- multi-byte character set.
- </para></listitem>
-
- <listitem><para>
- An <replaceable>index_col_name</replaceable> specification can end
- with <literal>ASC</literal> or <literal>DESC</literal>. 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.
- </para></listitem>
-
- <listitem><para>
- When you use <literal>ORDER BY</literal> or <literal>GROUP
- BY</literal> with a <literal>TEXT</literal> or
- <literal>BLOB</literal> column, the server sorts values using only
- the initial number of bytes indicated by the
- <literal>max_sort_length</literal> system variable. See
- <xref linkend="blob"/>.
- </para></listitem>
-
- <listitem><para>
- In MySQL 3.23.23 or later, you can create special
- <literal>FULLTEXT</literal> indexes. They are used for full-text
- search. Only the <literal>MyISAM</literal> table type supports
- <literal>FULLTEXT</literal> indexes. They can be created only from
- <literal>CHAR</literal>, <literal>VARCHAR</literal>, and
- <literal>TEXT</literal> columns. Indexing always happens over the
- entire column; partial indexing is not supported and any prefix
- length is ignored if specified. See
- <xref linkend="fulltext-search"/> for details of operation.
- </para></listitem>
-
- <listitem><para>
- In MySQL 4.1 or later, you can create <literal>SPATIAL</literal>
- indexes on spatial column types. Spatial types are supported only
- for <literal>MyISAM</literal> tables and indexed columns must be
- declared as <literal>NOT NULL</literal>. See
- <xref linkend="spatial-extensions-in-mysql"/>.
- </para></listitem>
-
- <listitem><para>
- In MySQL 3.23.44 or later, <literal>InnoDB</literal> tables support
- checking of foreign key constraints. See <xref linkend="innodb"/>.
- Note that the <literal>FOREIGN KEY</literal> syntax in
- <literal>InnoDB</literal> is more restrictive than the syntax
- presented for the <literal>CREATE TABLE</literal> statement at the
- beginning of this section: The columns of the referenced table must
- always be explicitly named. <literal>InnoDB</literal> supports both
- <literal>ON DELETE</literal> and <literal>ON UPDATE</literal>
- actions on foreign keys as of MySQL 3.23.50 and 4.0.8,
- respectively. For the precise syntax, see
- <xref linkend="innodb-foreign-key-constraints"/>.
- </para>
-
- <para>
- For other storage engines, MySQL Server parses the <literal>FOREIGN
- KEY</literal> and <literal>REFERENCES</literal> syntax in
- <literal>CREATE TABLE</literal> statements, but without further
- action being taken. The <literal>CHECK</literal> clause is parsed
- but ignored by all storage engines. See
- <xref linkend="ansi-diff-foreign-keys"/>.
- </para></listitem>
-
- <listitem><para>
- For <literal>MyISAM</literal> and <literal>ISAM</literal> tables,
- each <literal>NULL</literal> column takes one bit extra, rounded up
- to the nearest byte. The maximum record length in bytes can be
- calculated as follows:
- </para>
-
-<programlisting>
-row length = 1
- + (<replaceable>sum of column lengths</replaceable>)
- + (<replaceable>number of NULL columns</replaceable> + <replaceable>delete_flag</replaceable> + 7)/8
- + (<replaceable>number of variable-length columns</replaceable>)
-</programlisting>
-
- <para>
- <replaceable>delete_flag</replaceable> is 1 for tables with static
- record format. Static tables use a bit in the row record for a flag
- that indicates whether the row has been deleted.
- <replaceable>delete_flag</replaceable> is 0 for dynamic tables
- because the flag is stored in the dynamic row header.
- </para>
-
- <para>
- These calculations do not apply for <literal>InnoDB</literal>
- tables, for which storage size is no different for
- <literal>NULL</literal> columns than for <literal>NOT
- NULL</literal> columns.
- </para></listitem>
-
- </itemizedlist>
-
- <para>
- The <replaceable>table_options</replaceable> part of the
- <literal>CREATE TABLE</literal> syntax can be used in MySQL 3.23 and
- above.
- </para>
-
- <para>
- The <literal>ENGINE</literal> and <literal>TYPE</literal> options
- specify the storage engine for the table. <literal>ENGINE</literal>
- was added in MySQL 4.0.18 (for 4.0) and 4.1.2 (for 4.1). It is the
- preferred option name as of those versions, and
- <literal>TYPE</literal> has become deprecated.
- <literal>TYPE</literal> is supported throughout the 4.x series, but
- likely will be removed in MySQL 5.1.
- </para>
-
- <para>
- The <literal>ENGINE</literal> and <literal>TYPE</literal> options
- take the following values:
- </para>
-
- <informaltable>
- <tgroup cols="2">
- <colspec colwidth="25*"/>
- <colspec colwidth="70*"/>
- <tbody>
- <row>
- <entry>
- <emphasis role="bold">Storage Engine</emphasis>
- </entry>
- <entry>
- <emphasis role="bold">Description</emphasis>
- </entry>
- </row>
- <row>
- <entry>
- <literal>ARCHIVE</literal>
- </entry>
- <entry>
- The archving storage engine. See
- <xref linkend="archive-storage-engine"/>.
- </entry>
- </row>
- <row>
- <entry>
- <literal>BDB</literal>
- </entry>
- <entry>
- Transaction-safe tables with page locking. See
- <xref linkend="bdb-storage-engine"/>.
- </entry>
- </row>
- <row>
- <entry>
- <literal>BerkeleyDB</literal>
- </entry>
- <entry>
- An alias for <literal>BDB</literal>.
- </entry>
- </row>
- <row>
- <entry>
- <literal>CSV</literal>
- </entry>
- <entry>
- Tables that store rows in comma-separated values format. See
- <xref linkend="csv-storage-engine"/>.
- </entry>
- </row>
- <row>
- <entry>
- <literal>EXAMPLE</literal>
- </entry>
- <entry>
- An example engine. See
- <xref linkend="example-storage-engine"/>.
- </entry>
- </row>
- <row>
- <entry>
- <literal>FEDERATED</literal>
- </entry>
- <entry>
- Storage engine that accesses remote tables. See
- <xref linkend="federated-storage-engine"/>.
- </entry>
- </row>
- <row>
- <entry>
- <literal>HEAP</literal>
- </entry>
- <entry>
- The data for this table is stored only in memory. See
- <xref linkend="memory-storage-engine"/>.
- </entry>
- </row>
- <row>
- <entry>
- <literal>ISAM</literal>
- </entry>
- <entry>
- The original MySQL storage engine. See
- <xref linkend="isam-storage-engine"/>.
- </entry>
- </row>
- <row>
- <entry>
- <literal>InnoDB</literal>
- </entry>
- <entry>
- Transaction-safe tables with row locking and foreign keys.
- See <xref linkend="innodb"/>.
- </entry>
- </row>
- <row>
- <entry>
- <literal>MEMORY</literal>
- </entry>
- <entry>
- An alias for <literal>HEAP</literal>. (Actually, as of MySQL
- 4.1, <literal>MEMORY</literal> is the preferred term.)
- </entry>
- </row>
- <row>
- <entry>
- <literal>MERGE</literal>
- </entry>
- <entry>
- A collection of <literal>MyISAM</literal> tables used as one
- table. See <xref linkend="merge-storage-engine"/>.
- </entry>
- </row>
- <row>
- <entry>
- <literal>MRG_MyISAM</literal>
- </entry>
- <entry>
- An alias for <literal>MERGE</literal>.
- </entry>
- </row>
- <row>
- <entry>
- <literal>MyISAM</literal>
- </entry>
- <entry>
- The binary portable storage engine that is the improved
- replacement for <literal>ISAM</literal>. See
- <xref linkend="myisam-storage-engine"/>.
- </entry>
- </row>
- <row>
- <entry>
- <literal>NDB</literal>
- </entry>
- <entry>
- Alias for <literal>NDBCLUSTER</literal>.
- </entry>
- </row>
- <row>
- <entry>
- <literal>NDBCLUSTER</literal>
- </entry>
- <entry>
- Clustered, fault-tolerant, memory-based tables. See
- <xref linkend="ndbcluster"/>.
- </entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>
- See <xref linkend="storage-engines"/>.
- </para>
-
- <para>
- If a storage engine is specified that is not available, MySQL uses
- <literal>MyISAM</literal> instead. For example, if a table
- definition includes the <literal>ENGINE=BDB</literal> option but the
- MySQL server does not support <literal>BDB</literal> tables, the
- table is created as a <literal>MyISAM</literal> 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 4.1.1, a warning
- occurs if the storage engine specification is not honored.
- </para>
-
- <para>
- The other table options are used to optimize the behavior of the
- table. In most cases, you don't have to specify any of them. The
- options work for all storage engines unless otherwise indicated:
- </para>
-
- <itemizedlist>
-
- <listitem><para>
- <literal>AUTO_INCREMENT</literal>
- </para>
-
- <para>
- The initial <literal>AUTO_INCREMENT</literal> value for the table.
- This works for <literal>MyISAM</literal> only, for
- <literal>MEMORY</literal> as of MySQL 4.1, and for
- <literal>InnoDB</literal> as of MySQL 5.0.3. To set the first
- auto-increment value for engines that do not support the
- <literal>AUTO_INCREMENT</literal> table option, insert a dummy row
- with a value one less than the desired value after creating the
- table, and then delete the dummy row.
- </para>
-
- <para>
- For engines that support the <literal>AUTO_INCREMENT</literal>
- table option in <literal>CREATE TABLE</literal> statements, you can
- also use <literal>ALTER TABLE <replaceable>tbl_name</replaceable>
- AUTO_INCREMENT = <replaceable>n</replaceable></literal> to reset
- the <literal>AUTO_INCREMENT</literal> value.
- </para></listitem>
-
- <listitem><para>
- <literal>AVG_ROW_LENGTH</literal>
- </para>
-
- <para>
- An approximation of the average row length for your table. You need
- to set this only for large tables with variable-size records.
- </para>
-
- <para>
- When you create a <literal>MyISAM</literal> table, MySQL uses the
- product of the <literal>MAX_ROWS</literal> and
- <literal>AVG_ROW_LENGTH</literal> options to decide how big the
- resulting table is. If you don't specify either option, the maximum
- size for a table is 4GB (or 2GB if your operating system only
- supports 2GB tables). The reason for this is just to keep down the
- pointer sizes to make the index smaller and faster if you don't
- really need big files. If you want all your tables to be able to
- grow above the 4GB limit and are willing to have your smaller
- tables slightly slower and larger than necessary, you may increase
- the default pointer size by setting the
- <literal>myisam_data_pointer_size</literal> system variable, which
- was added in MySQL 4.1.2. See
- <xref linkend="server-system-variables"/>.
- </para></listitem>
-
- <listitem><para>
- <literal>[DEFAULT] CHARACTER SET</literal>
- </para>
-
- <para>
- Specify a default character set for the table.
- <literal>CHARSET</literal> is a synonym
- </para>
-
- <para>
- for <literal>CHARACTER SET</literal>.
- </para></listitem>
-
- <listitem><para>
- <literal>COLLATE</literal>
- </para>
-
- <para>
- Specify a default collation for the table.
- </para></listitem>
-
- <listitem><para>
- <literal>CHECKSUM</literal>
- </para>
-
- <para>
- 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
- <literal>CHECKSUM TABLE</literal> statement reports the checksum.
- (<literal>MyISAM</literal> only.)
- </para></listitem>
-
- <listitem><para>
- <literal>COMMENT</literal>
- </para>
-
- <para>
- A comment for your table, up to 60 characters long.
- </para></listitem>
-
- <listitem><para>
- <literal>MAX_ROWS</literal>
- </para>
-
- <para>
- The maximum number of rows you plan to store in the table. This is
- not a hard limit, but rather an indicator that the table must be
- able to store at least this many rows.
- </para></listitem>
-
- <listitem><para>
- <literal>MIN_ROWS</literal>
- </para>
-
- <para>
- The minimum number of rows you plan to store in the table.
- </para></listitem>
-
- <listitem><para>
- <literal>PACK_KEYS</literal>
- </para>
-
- <para>
- 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
- <literal>DEFAULT</literal> (MySQL 4.0) tells the storage engine to
- only pack long <literal>CHAR</literal>/<literal>VARCHAR</literal>
- columns. (<literal>MyISAM</literal> and <literal>ISAM</literal>
- only.)
- </para>
-
- <para>
- If you don't use <literal>PACK_KEYS</literal>, the default is to
- only pack strings, not numbers. If you use
- <literal>PACK_KEYS=1</literal>, numbers are packed as well.
- </para>
-
- <para>
- When packing binary number keys, MySQL uses prefix compression:
- </para>
-
- <para>
- <itemizedlist>
-
- <listitem><para>
- Every key needs one extra byte to indicate how many bytes of the
- previous key are the same for the next key.
- </para></listitem>
-
- <listitem><para>
- The pointer to the row is stored in high-byte-first order
- directly after the key, to improve compression.
- </para></listitem>
-
- </itemizedlist>
- </para>
-
- <para>
- This means that if you have many equal keys on two consecutive
- rows, all following ``same'' keys usually only take two bytes
- (including the pointer to the row). Compare this to the ordinary
- case where the following keys takes <literal>storage_size_for_key +
- pointer_size</literal> (where the pointer size is usually 4).
- Conversely, you get a big 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 isn't a key
- that can have <literal>NULL</literal> values. (In this case, the
- packed key length is stored in the same byte that is used to mark
- if a key is <literal>NULL</literal>.)
- </para></listitem>
-
- <listitem><para>
- <literal>PASSWORD</literal>
- </para>
-
- <para>
- Encrypt the <filename>.frm</filename> file with a password. This
- option doesn't do anything in the standard MySQL version.
- </para></listitem>
-
- <listitem><para>
- <literal>DELAY_KEY_WRITE</literal>
- </para>
-
- <para>
- Set this to 1 if you want to delay key updates for the table until
- the table is closed. (<literal>MyISAM</literal> only.)
- </para></listitem>
-
- <listitem><para>
- <literal>ROW_FORMAT</literal>
- </para>
-
- <para>
- Defines how the rows should be stored. Currently this option works
- only with <literal>MyISAM</literal> tables. The option value can
- <literal>FIXED</literal> or <literal>DYNAMIC</literal> for static
- or variable-length row format. <command>myisampack</command> sets
- the type to <literal>COMPRESSED</literal>. See
- <xref linkend="myisam-table-formats"/>.
- </para>
-
- <para>
- Starting with MySQL/InnoDB-5.0.3, InnoDB records are stored in a
- more compact format (<literal>ROW_FORMAT=COMPACT</literal>) by
- default. The old format can be requested by specifying
- <literal>ROW_FORMAT=REDUNDANT</literal>.
- </para></listitem>
-
- <listitem><para>
- <literal>RAID_TYPE</literal>
-
- <indexterm type="concept">
- <primary>RAID</primary>
- <secondary>table type</secondary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>tables</primary>
- <secondary>RAID</secondary>
- </indexterm>
- </para>
-
- <para>
- Note: This information applies only before MySQL 5.0.
- <literal>RAID</literal> support has been removed as of MySQL 5.0.
- </para>
-
- <para>
- The <literal>RAID_TYPE</literal> option can help you to exceed the
- 2GB/4GB limit for the <literal>MyISAM</literal> data file (not the
- index file) on operating systems that don't support big files. This
- option is unnecessary and not recommended for filesystems that
- support big files.
- </para>
-
- <para>
- You can get more speed from the I/O bottleneck by putting
- <literal>RAID</literal> directories on different physical disks.
- The only allowed <literal>RAID_TYPE</literal> is
- <literal>STRIPED</literal>. <literal>1</literal> and
- <literal>RAID0</literal> are aliases for
- <literal>STRIPED</literal>.
- </para>
-
- <para>
- If you specify the <literal>RAID_TYPE</literal> option for a
- <literal>MyISAM</literal> table, specify the
- <literal>RAID_CHUNKS</literal> and
- <literal>RAID_CHUNKSIZE</literal> options as well. The maximum
- <literal>RAID_CHUNKS</literal> value is 255.
- <literal>MyISAM</literal> creates <literal>RAID_CHUNKS</literal>
- subdirectories named <filename>00</filename>,
- <filename>01</filename>, <filename>02</filename>, ...
- <filename>09</filename>, <filename>0a</filename>,
- <filename>0b</filename>, ... in the database directory. In each of
- these directories, <literal>MyISAM</literal> creates a file
- <filename><replaceable>tbl_name</replaceable>.MYD</filename>. When
- writing data to the data file, the <literal>RAID</literal> handler
- maps the first <literal>RAID_CHUNKSIZE*1024</literal> bytes to the
- first file, the next <literal>RAID_CHUNKSIZE*1024</literal> bytes
- to the next file, and so on.
- </para>
-
- <para>
- <literal>RAID_TYPE</literal> works on any operating system, as long
- as you have built MySQL with the <literal>--with-raid</literal>
- option to <command>configure</command>. To determine whether a
- server supports <literal>RAID</literal> tables, use <literal>SHOW
- VARIABLES LIKE 'have_raid'</literal> to see whether the variable
- value is <literal>YES</literal>.
- </para></listitem>
-
- <listitem><para>
- <literal>UNION</literal>
- </para>
-
- <para>
- <literal>UNION</literal> is used when you want to use a collection
- of identical tables as one. This works only with
- <literal>MERGE</literal> tables. See
- <xref linkend="merge-storage-engine"/>.
- </para>
-
- <para>
- For the moment, you must have <literal>SELECT</literal>,
- <literal>UPDATE</literal>, and <literal>DELETE</literal> privileges
- for the tables you map to a <literal>MERGE</literal> table.
- Originally, all used tables had to be in the same database as the
- <literal>MERGE</literal> table itself. This restriction has been
- lifted as of MySQL 4.1.1.
- </para></listitem>
-
- <listitem><para>
- <literal>INSERT_METHOD</literal>
- </para>
-
- <para>
- If you want to insert data in a <literal>MERGE</literal> table, you
- have to specify with <literal>INSERT_METHOD</literal> into which
- table the row should be inserted. <literal>INSERT_METHOD</literal>
- is an option useful for <literal>MERGE</literal> tables only. Use a
- value of <literal>FIRST</literal> or <literal>LAST</literal> to
- have inserts go to the first or last table, or a value of
- <literal>NO</literal> to prevent inserts. This option was
- introduced in MySQL 4.0.0. See
- <xref linkend="merge-storage-engine"/>.
- </para></listitem>
-
- <listitem><para>
- <literal>DATA DIRECTORY</literal> , <literal>INDEX
- DIRECTORY</literal>
- </para>
-
- <para>
- By using <literal>DATA
- DIRECTORY='<replaceable>directory</replaceable>'</literal> or
- <literal>INDEX
- DIRECTORY='<replaceable>directory</replaceable>'</literal> you can
- specify where the <literal>MyISAM</literal> storage engine should
- put a table's data file and index file. Note that the directory
- should be a full path to the directory (not a relative path).
- </para>
-
- <para>
- These options work only for <literal>MyISAM</literal> tables from
- MySQL 4.0 on, when you are not using the
- <literal>--skip-symbolic-links</literal> option. Your operating
- system must also have a working, thread-safe
- <literal>realpath()</literal> call. See
- <xref linkend="symbolic-links-to-tables"/>.
- </para></listitem>
-
- </itemizedlist>
-
- <indexterm type="concept">
- <primary>copying tables</primary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>tables</primary>
- <secondary>copying</secondary>
- </indexterm>
-
- <para>
- As of MySQL 3.23, you can create one table from another by adding a
- <literal>SELECT</literal> statement at the end of the
- <literal>CREATE TABLE</literal> statement:
- </para>
-
-<programlisting>
-CREATE TABLE <replaceable>new_tbl</replaceable> SELECT * FROM <replaceable>orig_tbl</replaceable>;
-</programlisting>
-
- <para>
- MySQL creates new columns for all elements in the
- <literal>SELECT</literal>. For example:
- </para>
-
-<programlisting>
-mysql> CREATE TABLE test (a INT NOT NULL AUTO_INCREMENT,
- -> PRIMARY KEY (a), KEY(b))
- -> TYPE=MyISAM SELECT b,c FROM test2;
-</programlisting>
-
- <para>
- This creates a <literal>MyISAM</literal> table with three columns,
- <literal>a</literal>, <literal>b</literal>, and
- <literal>c</literal>. Notice that the columns from the
- <literal>SELECT</literal> statement are appended to the right side
- of the table, not overlapped onto it. Take the following example:
- </para>
-
-<programlisting>
-mysql> SELECT * FROM foo;
-+---+
-| n |
-+---+
-| 1 |
-+---+
-
-mysql> CREATE TABLE bar (m INT) SELECT n FROM foo;
-Query OK, 1 row affected (0.02 sec)
-Records: 1 Duplicates: 0 Warnings: 0
-
-mysql> SELECT * FROM bar;
-+------+---+
-| m | n |
-+------+---+
-| NULL | 1 |
-+------+---+
-1 row in set (0.00 sec)
-</programlisting>
-
- <para>
- For each row in table <literal>foo</literal>, a row is inserted in
- <literal>bar</literal> with the values from <literal>foo</literal>
- and default values for the new columns.
- </para>
-
- <para>
- If any errors occur while copying the data to the table, it is
- automatically dropped and not created.
- </para>
-
- <para>
- <literal>CREATE TABLE ... SELECT</literal> 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
- <literal>SELECT</literal> statement:
- </para>
-
-<programlisting>
-mysql> CREATE TABLE bar (UNIQUE (n)) SELECT n FROM foo;
-</programlisting>
-
- <para>
- Some conversion of column types might occur. For example, the
- <literal>AUTO_INCREMENT</literal> attribute is not preserved, and
- <literal>VARCHAR</literal> columns can become
- <literal>CHAR</literal> columns.
- </para>
-
- <para>
- When creating a table with <literal>CREATE ... SELECT</literal>,
- make sure to alias any function calls or expressions in the query.
- If you do not, the <literal>CREATE</literal> statement might fail or
- result in undesirable column names.
- </para>
-
-<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;
-</programlisting>
-
- <para>
- As of MySQL 4.1, you can explicitly specify the type for a generated
- column:
- </para>
-
-<programlisting>
-CREATE TABLE foo (a TINYINT NOT NULL) SELECT b+1 AS a FROM bar;
-</programlisting>
-
- <para>
- In MySQL 4.1, you can also use <literal>LIKE</literal> to create an
- empty table based on the definition of another table, including any
- column attributes and indexes the original table has:
- </para>
-
-<programlisting>
-CREATE TABLE <replaceable>new_tbl</replaceable> LIKE <replaceable>orig_tbl</replaceable>;
-</programlisting>
-
- <para>
- <literal>CREATE TABLE ... LIKE</literal> does not copy any
- <literal>DATA DIRECTORY</literal> or <literal>INDEX
- DIRECTORY</literal> table options that were specified for the
- original table, or any foreign key definitions.
- </para>
-
- <para>
- You can precede the <literal>SELECT</literal> by
- <literal>IGNORE</literal> or <literal>REPLACE</literal> to indicate
- how to handle records that duplicate unique key values. With
- <literal>IGNORE</literal>, new records that duplicate an existing
- record on a unique key value are discarded. With
- <literal>REPLACE</literal>, new records replace records that have
- the same unique key value. If neither <literal>IGNORE</literal> nor
- <literal>REPLACE</literal> is specified, duplicate unique key values
- result in an error.
- </para>
-
- <para>
- To ensure that the update log/binary log can be used to re-create
- the original tables, MySQL does not allow concurrent inserts during
- <literal>CREATE TABLE ... SELECT</literal>.
- </para>
-
- <section id="silent-column-changes">
-
- <title id='title-silent-column-changes'>&title-silent-column-changes;</title>
-
- <indexterm type="concept">
- <primary>silent column changes</primary>
- </indexterm>
-
- <para>
- In some cases, MySQL silently changes column specifications from
- those given in a <literal>CREATE TABLE</literal> or <literal>ALTER
- TABLE</literal> statement. These might be changes to a data type,
- to attributes associated with a data type, or to an index
- specification.
- </para>
-
- <para>
- Possible data type changes are given in the following list. These
- occur prior to MySQL 5.0.3. (As of 5.0.3 an error occurs if a
- column cannot be created using the specified data type.)
- </para>
-
- <itemizedlist>
-
- <listitem><para>
- <literal>VARCHAR</literal> columns with a length less than four
- are changed to <literal>CHAR</literal>.
- </para></listitem>
-
- <listitem><para>
- 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 (<literal>VARCHAR</literal>,
- <literal>TEXT</literal>, or <literal>BLOB</literal>), all
- <literal>CHAR</literal> columns longer than three characters are
- changed to <literal>VARCHAR</literal> columns. This doesn't affect
- how you use the columns in any way; in MySQL,
- <literal>VARCHAR</literal> is just a different way to store
- characters. MySQL performs this conversion because it saves space
- and makes table operations faster. See
- <xref linkend="storage-engines"/>.
- </para></listitem>
-
- <listitem><para>
- From MySQL 4.1.0 to MySQL 5.0.2, a <literal>CHAR</literal> or
- <literal>VARCHAR</literal> column with a length specification
- greater than 255 is converted to the smallest
- <literal>TEXT</literal> type that can hold values of the given
- length. For example, <literal>VARCHAR(500)</literal> is converted
- to <literal>TEXT</literal>, and <literal>VARCHAR(200000)</literal>
- is converted to <literal>MEDIUMTEXT</literal>. Note that this
- conversion results in a change in behavior with regard to
- treatment of trailing spaces.
- </para>
-
- <para>
- Similar conversions occur for <literal>BINARY</literal> and
- <literal>VARBINARY</literal>, except that they are converted to a
- <literal>BLOB</literal> type.
- </para>
-
- <para>
- From MySQL 5.0.3 on, <literal>CHAR</literal> and
- <literal>BINARY</literal> columns with a length specification
- greater than 255 are not silently converted. Instead, an error
- occurs. From MySQL 5.0.6 on, silent conversion of
- <literal>VARCHAR</literal> and <literal>VARBINARY</literal>
- columns with a length specification greater than 65,535 does not
- occur if strict SQL mode is enabled. Instead, an error occurs.
- </para></listitem>
-
- <listitem><para>
- For a specification of
- <literal>DECIMAL(<replaceable>M</replaceable>,<replaceable>D</replaceable>)</literal>,
- if <replaceable>M</replaceable> is not larger than
- <replaceable>D</replaceable>, it is adjusted upward. For example,
- <literal>DECIMAL(10,10)</literal> becomes
- <literal>DECIMAL(11,10)</literal>.
- </para></listitem>
-
- </itemizedlist>
-
- <para>
- Other silent column specification changes include changes to
- attribute or index specifications:
- </para>
-
- <itemizedlist>
-
- <listitem><para>
- <literal>TIMESTAMP</literal> display sizes are discarded from
- MySQL 4.1 on, due to changes made to the
- <literal>TIMESTAMP</literal> column type in that version. Before
- MySQL 4.1, <literal>TIMESTAMP</literal> display sizes must be even
- and in the range from 2 to 14. If you specify a display size of 0
- or greater than 14, the size is coerced to 14. Odd-valued sizes in
- the range from 1 to 13 are coerced to the next higher even number.
- </para></listitem>
-
- <listitem><para>
- Before MySQL 4.1.6, you cannot store a literal
- <literal>NULL</literal> in a <literal>TIMESTAMP</literal> column;
- setting it to <literal>NULL</literal> sets it to the current date
- and time. Because <literal>TIMESTAMP</literal> columns behave this
- way, the <literal>NULL</literal> and <literal>NOT NULL</literal>
- attributes do not apply in the normal way and are ignored if you
- specify them. <literal>DESCRIBE
- <replaceable>tbl_name</replaceable></literal> always reports that
- a <literal>TIMESTAMP</literal> column can be assigned
- <literal>NULL</literal> values.
- </para></listitem>
-
- <listitem><para>
- Columns that are part of a <literal>PRIMARY KEY</literal> are made
- <literal>NOT NULL</literal> even if not declared that way.
- </para></listitem>
-
- <listitem><para>
- Starting from MySQL 3.23.51, trailing spaces are automatically
- deleted from <literal>ENUM</literal> and <literal>SET</literal>
- member values when the table is created.
- </para></listitem>
-
- <listitem><para>
- MySQL maps certain column types used by other SQL database vendors
- to MySQL types. See <xref linkend="other-vendor-column-types"/>.
- </para></listitem>
-
- <listitem><para>
- If you include a <literal>USING</literal> clause to specify an
- index type that is not legal for a storage engine, but there is
- another index type available that the engine can use without
- affecting query results, the engine uses the available type.
- </para></listitem>
-
- </itemizedlist>
-
- <para>
- To see whether MySQL used a column type other than the one you
- specified, issue a <literal>DESCRIBE</literal> or <literal>SHOW
- CREATE TABLE</literal> statement after creating or altering your
- table.
- </para>
-
- <indexterm type="concept">
- <primary><command>myisampack</command></primary>
- </indexterm>
-
- <para>
- Certain other column type changes can occur if you compress a table
- using <command>myisampack</command>. See
- <xref linkend="compressed-format"/>.
- </para>
-
- </section>
-
- </section>
-
- <section id="drop-database">
-
- <title id='title-drop-database'>&title-drop-database;</title>
-
- <indexterm type="function">
- <primary>DROP DATABASE</primary>
- </indexterm>
-
- <indexterm type="function">
- <primary>DROP SCHEMA</primary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>deleting</primary>
- <secondary>database</secondary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>database</primary>
- <secondary>deleting</secondary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>deleting</primary>
- <secondary>schema</secondary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>schema</primary>
- <secondary>deleting</secondary>
- </indexterm>
-
-<!-- example_for_help_topic DROP DATABASE -->
-
-<programlisting>
-DROP {DATABASE | SCHEMA} [IF EXISTS] <replaceable>db_name</replaceable>
-</programlisting>
-
-<!-- description_for_help_topic DROP DATABASE DROP DATABASE SCHEMA EXISTS IF -->
-
- <para>
- <literal>DROP DATABASE</literal> drops all tables in the database
- and deletes the database. Be <emphasis>very</emphasis> careful with
- this statement! To use <literal>DROP DATABASE</literal>, you need
- the <literal>DROP</literal> privilege on the database.
- </para>
-
- <para>
- In MySQL 3.22 or later, you can use the keywords <literal>IF
- EXISTS</literal> to prevent an error from occurring if the database
- doesn't exist.
- </para>
-
- <para>
- <literal>DROP SCHEMA</literal> can be used as of MySQL 5.0.2.
-
-<!-- end_description_for_help_topic -->
- </para>
-
- <para>
- If you use <literal>DROP DATABASE</literal> on a symbolically linked
- database, both the link and the original database are deleted.
- </para>
-
- <para>
- As of MySQL 4.1.2, <literal>DROP DATABASE</literal> returns the
- number of tables that were removed. This corresponds to the number
- of <filename>.frm</filename> files removed.
- </para>
-
- <para>
- The <literal>DROP DATABASE</literal> statement removes from the
- given database directory those files and directories that MySQL
- itself may create during normal operation:
- </para>
-
- <itemizedlist>
-
- <listitem><para>
- All files with these extensions:
- </para>
-
- <informaltable>
- <tgroup cols="4">
- <colspec colwidth="10*"/>
- <colspec colwidth="10*"/>
- <colspec colwidth="10*"/>
- <colspec colwidth="10*"/>
- <tbody>
- <row>
- <entry>
- <literal>.BAK</literal>
- </entry>
- <entry>
- <literal>.DAT</literal>
- </entry>
- <entry>
- <literal>.HSH</literal>
- </entry>
- <entry>
- <literal>.ISD</literal>
- </entry>
- </row>
- <row>
- <entry>
- <literal>.ISM</literal>
- </entry>
- <entry>
- <literal>.ISM</literal>
- </entry>
- <entry>
- <literal>.MRG</literal>
- </entry>
- <entry>
- <literal>.MYD</literal>
- </entry>
- </row>
- <row>
- <entry>
- <literal>.MYI</literal>
- </entry>
- <entry>
- <literal>.db</literal>
- </entry>
- <entry>
- <literal>.frm</literal>
- </entry>
- <entry></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable></listitem>
-
- <listitem><para>
- All subdirectories with names that consist of two hex digits
- <literal>00</literal>-<literal>ff</literal>. These are
- subdirectories used for <literal>RAID</literal> tables.
- </para></listitem>
-
- <listitem><para>
- The <filename>db.opt</filename> file, if it exists.
- </para></listitem>
-
- </itemizedlist>
-
- <para>
- 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 <literal>DROP DATABASE</literal>
- statement again.
- </para>
-
- <indexterm type="concept">
- <primary><command>mysqladmin</command></primary>
- </indexterm>
-
- <para>
- You can also drop databases with <command>mysqladmin</command>. See
- <xref linkend="mysqladmin"/>.
- </para>
-
- </section>
-
- <section id="drop-index">
-
- <title id='title-drop-index'>&title-drop-index;</title>
-
- <indexterm type="function">
- <primary>DROP INDEX</primary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>deleting</primary>
- <secondary>index</secondary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>index</primary>
- <secondary>deleting</secondary>
- </indexterm>
-
-<!-- example_for_help_topic DROP INDEX -->
-
-<programlisting>
-DROP INDEX <replaceable>index_name</replaceable> ON <replaceable>tbl_name</replaceable>
-</programlisting>
-
-<!-- description_for_help_topic DROP INDEX DROP INDEX -->
-
- <para>
- <literal>DROP INDEX</literal> drops the index named
- <replaceable>index_name</replaceable> from the table
- <replaceable>tbl_name</replaceable>. In MySQL 3.22 or later,
- <literal>DROP INDEX</literal> is mapped to an <literal>ALTER
- TABLE</literal> statement to drop the index. See
- <xref linkend="alter-table"/>. <literal>DROP INDEX</literal> doesn't
- do anything prior to MySQL 3.22.
-
-<!-- end_description_for_help_topic -->
- </para>
-
- </section>
-
- <section id="drop-table">
-
- <title id='title-drop-table'>&title-drop-table;</title>
-
- <indexterm type="function">
- <primary>DROP TABLE</primary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>deleting</primary>
- <secondary>table</secondary>
- </indexterm>
-
- <indexterm type="concept">
- <primary>table</primary>
- <secondary>deleting</secondary>
- </indexterm>
-
-<!-- example_for_help_topic DROP TABLE -->
-
-<programlisting>
-DROP [TEMPORARY] TABLE [IF EXISTS]
- <replaceable>tbl_name</replaceable> [, <replaceable>tbl_name</replaceable>] ...
- [RESTRICT | CASCADE]
-</programlisting>
-
-<!-- description_for_help_topic DROP TABLE DROP TABLE EXISTS IF TEMPORARY RESTRICT CASCADE -->
-
- <para>
- <literal>DROP TABLE</literal> removes one or more tables. You must
- have the <literal>DROP</literal> privilege for each table. All table
- data and the table definition are <emphasis>removed</emphasis>, so
- <emphasis>be careful</emphasis> with this statement!
- </para>
-
- <para>
- In MySQL 3.22 or later, you can use the keywords <literal>IF
- EXISTS</literal> to prevent an error from occurring for tables that
- don't exist. As of MySQL 4.1, a <literal>NOTE</literal> is generated
- for each non-existent table when using <literal>IF EXISTS</literal>.
- See <xref linkend="show-warnings"/>.
- </para>
-
- <para>
- <literal>RESTRICT</literal> and <literal>CASCADE</literal> are
- allowed to make porting easier. For the moment, they do nothing.
- </para>
-
- <para>
- <emphasis role="bold">Note</emphasis>: <literal>DROP TABLE</literal>
- automatically commits the current active transaction, unless you are
- using MySQL 4.1 or higher and the <literal>TEMPORARY</literal>
- keyword.
-
-<!-- end_description_for_help_topic -->
- </para>
-
- <para>
- The <literal>TEMPORARY</literal> keyword is ignored in MySQL 4.0. As
- of 4.1, it has the following effect:
- </para>
-
- <itemizedlist>
-
- <listitem><para>
- The statement drops only <literal>TEMPORARY</literal> tables.
- </para></listitem>
-
- <listitem><para>
- The statement doesn't end a running transaction.
- </para></listitem>
-
- <listitem><para>
- No access rights are checked. (A <literal>TEMPORARY</literal> table
- is visible only to the client that created it, so no check is
- necessary.)
- </para></listitem>
-
- </itemizedlist>
-
- <para>
- Using <literal>TEMPORARY</literal> is a good way to ensure that you
- don't accidentally drop a non-<literal>TEMPORARY</literal> table.
- </para>
-
- </section>
-
- <section id="rename-table">
-
- <title id='title-rename-table'>&title-rename-table;</title>
-
- <indexterm type="function">
- <primary>RENAME TABLE</primary>
- </indexterm>
-
-<!-- description_for_help_topic RENAME TABLE -->
-
-<programlisting>
-RENAME TABLE <replaceable>tbl_name</replaceable> TO <replaceable>new_tbl_name</replaceable>
- [, <replaceable>tbl_name2</replaceable> TO <replaceable>new_tbl_name2</replaceable>] ...
-</programlisting>
-
- <para>
- This statement renames one or more tables. It was added in MySQL
- 3.23.23.
- </para>
-
- <para>
- 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 <literal>old_table</literal>,
- you can create another table <literal>new_table</literal> that has
- the same structure but is empty, and then replace the existing table
- with the empty one as follows:
-
-<!-- end_description_for_help_topic -->
- </para>
-
-<!-- example_for_help_topic RENAME TABLE -->
-
-<programlisting>
-CREATE TABLE <replaceable>new_table</replaceable> (...);
-RENAME TABLE <replaceable>old_table</replaceable> TO <replaceable>backup_table</replaceable>, <replaceable>new_table</replaceable> TO <replaceable>old_table</replaceable>;
-</programlisting>
-
- <para>
- 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 no table named
- <literal>tmp_table</literal> currently exists):
- </para>
-
-<programlisting>
-RENAME TABLE <replaceable>old_table</replaceable> TO <replaceable>tmp_table</replaceable>,
- <replaceable>new_table</replaceable> TO <replaceable>old_table</replaceable>,
- <replaceable>tmp_table</replaceable> TO <replaceable>new_table</replaceable>;
-</programlisting>
-
- <para>
- As long as two databases are on the same filesystem you can also
- rename a table to move it from one database to another:
- </para>
-
-<programlisting>
-RENAME TABLE <replaceable>current_db.tbl_name</replaceable> TO <replaceable>other_db.tbl_name;</replaceable>
-</programlisting>
-
- <para>
- When you execute <literal>RENAME</literal>, you can't have any
- locked tables or active transactions. You must also have the
- <literal>ALTER</literal> and <literal>DROP</literal> privileges on
- the original table, and the <literal>CREATE</literal> and
- <literal>INSERT</literal> privileges on the new table.
- </para>
-
- <para>
- If MySQL encounters any errors in a multiple-table rename, it does a
- reverse rename for all renamed tables to get everything back to the
- original state.
- </para>
-
- </section>
-
- </section>
-
+
+
<section id="basic-user-commands">
<title id='title-basic-user-commands'>&title-basic-user-commands;</title>
| Thread |
|---|
| • bk commit - mysqldoc@docsrva tree (jon:1.2936) | jon | 5 Jul |
