Содержание
- 12.1. Data Definition Statements
- 12.1.1.
ALTER DATABASE
Синтаксис - 12.1.2.
ALTER EVENT
Синтаксис - 12.1.3.
ALTER LOGFILE GROUP
Синтаксис - 12.1.4.
ALTER FUNCTION
Синтаксис - 12.1.5.
ALTER PROCEDURE
Синтаксис - 12.1.6.
ALTER SERVER
Синтаксис - 12.1.7.
ALTER TABLE
Синтаксис - 12.1.8.
ALTER TABLESPACE
Синтаксис - 12.1.9.
ALTER VIEW
Синтаксис - 12.1.10.
CREATE DATABASE
Синтаксис - 12.1.11.
CREATE EVENT
Синтаксис - 12.1.12.
CREATE FUNCTION
Синтаксис - 12.1.13.
CREATE INDEX
Синтаксис - 12.1.14.
CREATE LOGFILE GROUP
Синтаксис - 12.1.15.
CREATE PROCEDURE
andCREATE FUNCTION
Синтаксис - 12.1.16.
CREATE SERVER
Синтаксис - 12.1.17.
CREATE TABLE
Синтаксис - 12.1.18.
CREATE TABLESPACE
Синтаксис - 12.1.19.
CREATE TRIGGER
Синтаксис - 12.1.20.
CREATE VIEW
Синтаксис - 12.1.21.
DROP DATABASE
Синтаксис - 12.1.22.
DROP EVENT
Синтаксис - 12.1.23.
DROP FUNCTION
Синтаксис - 12.1.24.
DROP INDEX
Синтаксис - 12.1.25.
DROP LOGFILE GROUP
Синтаксис - 12.1.26.
DROP PROCEDURE
andDROP FUNCTION
Синтаксис - 12.1.27.
DROP SERVER
Синтаксис - 12.1.28.
DROP TABLE
Синтаксис - 12.1.29.
DROP TABLESPACE
Синтаксис - 12.1.30.
DROP TRIGGER
Синтаксис - 12.1.31.
DROP VIEW
Синтаксис - 12.1.32.
RENAME TABLE
Синтаксис - 12.1.33.
TRUNCATE TABLE
Синтаксис
- 12.1.1.
- 12.2. Data Manipulation Statements
- 12.3. MySQL Transactional and Locking Statements
- 12.3.1.
START TRANSACTION
,COMMIT
, andROLLBACK
Синтаксис - 12.3.2. Statements That Cannot Be Rolled Back
- 12.3.3. Statements That Cause an Implicit Commit
- 12.3.4.
SAVEPOINT
andROLLBACK TO SAVEPOINT
Синтаксис - 12.3.5.
LOCK TABLES
andUNLOCK TABLES
Синтаксис - 12.3.6.
SET TRANSACTION
Синтаксис - 12.3.7. XA Transactions
- 12.3.1.
- 12.4. Replication Statements
- 12.5. SQL Синтаксис for Prepared Statements
- 12.6. MySQL Compound-Statement Синтаксис
- 12.7. Database Administration Statements
- 12.8. MySQL Utility Statements
This chapter describes the syntax for the SQL statements supported by MySQL.
- 12.1.1.
ALTER DATABASE
Синтаксис - 12.1.2.
ALTER EVENT
Синтаксис - 12.1.3.
ALTER LOGFILE GROUP
Синтаксис - 12.1.4.
ALTER FUNCTION
Синтаксис - 12.1.5.
ALTER PROCEDURE
Синтаксис - 12.1.6.
ALTER SERVER
Синтаксис - 12.1.7.
ALTER TABLE
Синтаксис - 12.1.8.
ALTER TABLESPACE
Синтаксис - 12.1.9.
ALTER VIEW
Синтаксис - 12.1.10.
CREATE DATABASE
Синтаксис - 12.1.11.
CREATE EVENT
Синтаксис - 12.1.12.
CREATE FUNCTION
Синтаксис - 12.1.13.
CREATE INDEX
Синтаксис - 12.1.14.
CREATE LOGFILE GROUP
Синтаксис - 12.1.15.
CREATE PROCEDURE
andCREATE FUNCTION
Синтаксис - 12.1.16.
CREATE SERVER
Синтаксис - 12.1.17.
CREATE TABLE
Синтаксис - 12.1.18.
CREATE TABLESPACE
Синтаксис - 12.1.19.
CREATE TRIGGER
Синтаксис - 12.1.20.
CREATE VIEW
Синтаксис - 12.1.21.
DROP DATABASE
Синтаксис - 12.1.22.
DROP EVENT
Синтаксис - 12.1.23.
DROP FUNCTION
Синтаксис - 12.1.24.
DROP INDEX
Синтаксис - 12.1.25.
DROP LOGFILE GROUP
Синтаксис - 12.1.26.
DROP PROCEDURE
andDROP FUNCTION
Синтаксис - 12.1.27.
DROP SERVER
Синтаксис - 12.1.28.
DROP TABLE
Синтаксис - 12.1.29.
DROP TABLESPACE
Синтаксис - 12.1.30.
DROP TRIGGER
Синтаксис - 12.1.31.
DROP VIEW
Синтаксис - 12.1.32.
RENAME TABLE
Синтаксис - 12.1.33.
TRUNCATE TABLE
Синтаксис
ALTER {DATABASE | SCHEMA} [db_name
]alter_specification
... ALTER {DATABASE | SCHEMA}db_name
UPGRADE DATA DIRECTORY NAMEalter_specification
: [DEFAULT] CHARACTER SET [=]charset_name
| [DEFAULT] COLLATE [=]collation_name
ALTER DATABASE
enables you to
change the overall characteristics of a database. These
characteristics are stored in the db.opt
file
in the database directory. To use ALTER
DATABASE
, you need the
ALTER
privilege on the database.
ALTER
SCHEMA
is a synonym for ALTER
DATABASE
.
The database name can be omitted from the first syntax, in which case the statement applies to the default database.
National Language Characteristics
The CHARACTER SET
clause changes the default
database character set. The COLLATE
clause
changes the default database collation. Section 9.1, “Character Set Support”,
discusses character set and collation names.
You can see what character sets and collations are available
using, respectively, the SHOW CHARACTER
SET
and SHOW COLLATION
statements. See Section 12.7.5.4, “SHOW CHARACTER SET
Синтаксис”, and
Section 12.7.5.5, “SHOW COLLATION
Синтаксис”, for more information.
If you change the default character set or collation for a
database, stored routines that use the database defaults must be
dropped and recreated so that they use the new defaults. (In a
stored routine, variables with character data types use the
database defaults if the character set or collation are not
specified explicitly. See Section 12.1.15, “CREATE PROCEDURE
and
CREATE FUNCTION
Синтаксис”.)
Upgrading from Versions Older than MySQL 5.1
The syntax that includes the UPGRADE DATA DIRECTORY
NAME
clause updates the name of the directory associated
with the database to use the encoding implemented in MySQL 5.1 for
mapping database names to database directory names (see
Section 8.2.3, “Mapping of Identifiers to File Names”). This clause is for use
under these conditions:
It is intended when upgrading MySQL to 5.1 or later from older versions.
It is intended to update a database directory name to the current encoding format if the name contains special characters that need encoding.
The statement is used by mysqlcheck (as invoked by mysql_upgrade).
For example, if a database in MySQL 5.0 has the name
a-b-c
, the name contains instances of the
-
(dash) character. In MySQL 5.0, the database
directory is also named a-b-c
, which is not
necessarily safe for all file systems. In MySQL 5.1 and later, the
same database name is encoded as a@002db@002dc
to produce a file system-neutral directory name.
When a MySQL installation is upgraded to MySQL 5.1 or later from
an older version,the server displays a name such as
a-b-c
(which is in the old format) as
#mysql50#a-b-c
, and you must refer to the name
using the #mysql50#
prefix. Use
UPGRADE DATA DIRECTORY NAME
in this case to
explicitly tell the server to re-encode the database directory
name to the current encoding format:
ALTER DATABASE `#mysql50#a-b-c` UPGRADE DATA DIRECTORY NAME;
After executing this statement, you can refer to the database as
a-b-c
without the special
#mysql50#
prefix.
ALTER [DEFINER = {user
| CURRENT_USER }] EVENTevent_name
[ON SCHEDULEschedule
] [ON COMPLETION [NOT] PRESERVE] [RENAME TOnew_event_name
] [ENABLE | DISABLE | DISABLE ON SLAVE] [COMMENT 'comment
'] [DOevent_body
]
The ALTER EVENT
statement changes
one or more of the characteristics of an existing event without
the need to drop and recreate it. The syntax for each of the
DEFINER
, ON SCHEDULE
,
ON COMPLETION
, COMMENT
,
ENABLE
/ DISABLE
, and
DO
clauses is exactly the same as
when used with CREATE EVENT
. (See
Section 12.1.11, “CREATE EVENT
Синтаксис”.)
Any user can alter an event defined on a database for which that
user has the EVENT
privilege. When
a user executes a successful ALTER
EVENT
statement, that user becomes the definer for the
affected event.
ALTER EVENT
works only with an
existing event:
mysql>ALTER EVENT no_such_event
>ON SCHEDULE
>EVERY '2:3' DAY_HOUR;
ERROR 1517 (HY000): Unknown event 'no_such_event'
In each of the following examples, assume that the event named
myevent
is defined as shown here:
CREATE EVENT myevent ON SCHEDULE EVERY 6 HOUR COMMENT 'A sample comment.' DO UPDATE myschema.mytable SET mycol = mycol + 1;
The following statement changes the schedule for
myevent
from once every six hours starting
immediately to once every twelve hours, starting four hours from
the time the statement is run:
ALTER EVENT myevent ON SCHEDULE EVERY 12 HOUR STARTS CURRENT_TIMESTAMP + INTERVAL 4 HOUR;
It is possible to change multiple characteristics of an event in a
single statement. This example changes the SQL statement executed
by myevent
to one that deletes all records from
mytable
; it also changes the schedule for the
event such that it executes once, one day after this
ALTER EVENT
statement is run.
ALTER EVENT myevent ON SCHEDULE AT CURRENT_TIMESTAMP + INTERVAL 1 DAY DO TRUNCATE TABLE myschema.mytable;
Specify the options in an ALTER
EVENT
statement only for those characteristics that you
want to change; omitted options keep their existing values. This
includes any default values for CREATE
EVENT
such as ENABLE
.
To disable myevent
, use this
ALTER EVENT
statement:
ALTER EVENT myevent DISABLE;
The ON SCHEDULE
clause may use expressions
involving built-in MySQL functions and user variables to obtain
any of the timestamp
or
interval
values which it contains. You
cannot use stored routines or user-defined functions in such
expressions, and you cannot use any table references; however, you
can use SELECT FROM DUAL
. This is true for both
ALTER EVENT
and
CREATE EVENT
statements. References
to stored routines, user-defined functions, and tables in such
cases are specifically not permitted, and fail with an error (see
Bug #22830).
Although an ALTER EVENT
statement
that contains another ALTER EVENT
statement in its DO
clause appears
to succeed, when the server attempts to execute the resulting
scheduled event, the execution fails with an error.
To rename an event, use the ALTER
EVENT
statement's RENAME TO
clause.
This statement renames the event myevent
to
yourevent
:
ALTER EVENT myevent RENAME TO yourevent;
You can also move an event to a different database using
ALTER EVENT ... RENAME TO ...
and
notation, as shown here:
db_name.event_name
ALTER EVENT olddb.myevent RENAME TO newdb.myevent;
To execute the previous statement, the user executing it must have
the EVENT
privilege on both the
olddb
and newdb
databases.
There is no RENAME EVENT
statement.
The value DISABLE ON SLAVE
is used on a
replication slave instead of ENABLED
or
DISABLED
to indicate an event that was created
on the master and replicated to the slave, but that is not
executed on the slave. Normally, DISABLE ON
SLAVE
is set automatically as required; however, there
are some circumstances under which you may want or need to change
it manually. See Section 15.4.1.8, “Replication of Invoked Features”,
for more information.
ALTER LOGFILE GROUPlogfile_group
ADD UNDOFILE 'file_name
' [INITIAL_SIZE [=]size
] [WAIT] ENGINE [=]engine_name
This statement adds an UNDO
file named
'file_name
' to an existing log file
group logfile_group
. An
ALTER LOGFILE GROUP
statement has
one and only one ADD UNDOFILE
clause. No
DROP UNDOFILE
clause is currently supported.
All MySQL Cluster Disk Data objects share the same namespace. This means that each Disk Data object must be uniquely named (and not merely each Disk Data object of a given type). For example, you cannot have a tablespace and an undo log file with the same name, or an undo log file and a data file with the same name.
The optional INITIAL_SIZE
parameter sets the
UNDO
file's initial size in bytes; if not
specified, the initial size default to 128M
(128 megabytes). You may optionally follow
size
with a one-letter abbreviation for
an order of magnitude, similar to those used in
my.cnf
. Generally, this is one of the letters
M
(for megabytes) or G
(for
gigabytes).
On 32-bit systems, the maximum supported value for
INITIAL_SIZE
is 4G
. (Bug
#29186)
The minimum permitted value for INITIAL_SIZE
is
1M
. (Bug #29574)
WAIT
is parsed but otherwise ignored. This
keyword currently has no effect, and is intended for future
expansion.
The ENGINE
parameter (required) determines the
storage engine which is used by this log file group, with
engine_name
being the name of the
storage engine. Currently, the only accepted values for
engine_name
are
“NDBCLUSTER
” and
“NDB
”. The two values
are equivalent.
Here is an example, which assumes that the log file group
lg_3
has already been created using
CREATE LOGFILE GROUP
(see
Section 12.1.14, “CREATE LOGFILE GROUP
Синтаксис”):
ALTER LOGFILE GROUP lg_3 ADD UNDOFILE 'undo_10.dat' INITIAL_SIZE=32M ENGINE=NDBCLUSTER;
When ALTER LOGFILE GROUP
is used
with ENGINE = NDBCLUSTER
(alternatively,
ENGINE = NDB
), an UNDO
log
file is created on each MySQL Cluster data node. You can verify
that the UNDO
files were created and obtain
information about them by querying the
INFORMATION_SCHEMA.FILES
table. For
example:
mysql>SELECT FILE_NAME, LOGFILE_GROUP_NUMBER, EXTRA
->FROM INFORMATION_SCHEMA.FILES
->WHERE LOGFILE_GROUP_NAME = 'lg_3';
+-------------+----------------------+----------------+ | FILE_NAME | LOGFILE_GROUP_NUMBER | EXTRA | +-------------+----------------------+----------------+ | newdata.dat | 0 | CLUSTER_NODE=3 | | newdata.dat | 0 | CLUSTER_NODE=4 | | undo_10.dat | 11 | CLUSTER_NODE=3 | | undo_10.dat | 11 | CLUSTER_NODE=4 | +-------------+----------------------+----------------+ 4 rows in set (0.01 sec)
(See Section 19.8, “The INFORMATION_SCHEMA FILES
Table”.)
Memory used for UNDO_BUFFER_SIZE
comes from the
global pool whose size is determined by the value of the
SharedGlobalMemory
data
node configuration parameter. This includes any default value
implied for this option by the setting of the
InitialLogFileGroup
data
node configuration parameter.
ALTER LOGFILE GROUP
is useful only
with Disk Data storage for MySQL Cluster. For more information,
see Section 16.5.11, “MySQL Cluster Disk Data Tables”.
ALTER FUNCTIONfunc_name
[characteristic
...]characteristic
: { CONTAINS SQL | NO SQL | READS SQL DATA | MODIFIES SQL DATA } | SQL SECURITY { DEFINER | INVOKER } | COMMENT 'string
'
This statement can be used to change the characteristics of a
stored function. More than one change may be specified in an
ALTER FUNCTION
statement. However,
you cannot change the parameters or body of a stored function
using this statement; to make such changes, you must drop and
re-create the function using DROP
FUNCTION
and CREATE
FUNCTION
.
You must have the ALTER ROUTINE
privilege for the function. (That privilege is granted
automatically to the function creator.) If binary logging is
enabled, the ALTER FUNCTION
statement might also require the
SUPER
privilege, as described in
Section 18.7, “Binary Logging of Stored Programs”.
ALTER PROCEDUREproc_name
[characteristic
...]characteristic
: COMMENT 'string
' | { CONTAINS SQL | NO SQL | READS SQL DATA | MODIFIES SQL DATA } | SQL SECURITY { DEFINER | INVOKER }
This statement can be used to change the characteristics of a
stored procedure. More than one change may be specified in an
ALTER PROCEDURE
statement. However,
you cannot change the parameters or body of a stored procedure
using this statement; to make such changes, you must drop and
re-create the procedure using DROP
PROCEDURE
and CREATE
PROCEDURE
.
You must have the ALTER ROUTINE
privilege for the procedure. By default, that privilege is granted
automatically to the procedure creator. This behavior can be
changed by disabling the
automatic_sp_privileges
system
variable. See Section 18.2.2, “Stored Routines and MySQL Privileges”.
ALTER SERVERserver_name
OPTIONS (option
[,option
] ...)
Alters the server information for
,
adjusting any of the options allowed in the
server_name
CREATE SERVER
statement. See
Section 12.1.16, “CREATE SERVER
Синтаксис”. The corresponding fields in the
mysql.servers
table are updated accordingly.
This statement requires the SUPER
privilege.
For example, to update the USER
option:
ALTER SERVER s OPTIONS (USER 'sally');
ALTER SERVER
does not cause an
automatic commit.
ALTER [ONLINE | OFFLINE] [IGNORE] TABLEtbl_name
[alter_specification
[,alter_specification
] ...] [partition_options
] ALTER [ONLINE | OFFLINE] [IGNORE] TABLEtbl_name
partition_options
alter_specification
:table_options
| ADD [COLUMN]col_name
column_definition
[FIRST | AFTERcol_name
] | ADD [COLUMN] (col_name
column_definition
,...) | ADD {INDEX|KEY} [index_name
] [index_type
] (index_col_name
,...) [index_option
] ... | ADD [CONSTRAINT [symbol
]] PRIMARY KEY [index_type
] (index_col_name
,...) [index_option
] ... | ADD [CONSTRAINT [symbol
]] UNIQUE [INDEX|KEY] [index_name
] [index_type
] (index_col_name
,...) [index_option
] ... | ADD FULLTEXT [INDEX|KEY] [index_name
] (index_col_name
,...) [index_option
] ... | ADD SPATIAL [INDEX|KEY] [index_name
] (index_col_name
,...) [index_option
] ... | ADD [CONSTRAINT [symbol
]] FOREIGN KEY [index_name
] (index_col_name
,...)reference_definition
| ALTER [COLUMN]col_name
{SET DEFAULTliteral
| DROP DEFAULT} | CHANGE [COLUMN]old_col_name
new_col_name
column_definition
[FIRST|AFTERcol_name
] | MODIFY [COLUMN]col_name
column_definition
[FIRST | AFTERcol_name
] | DROP [COLUMN]col_name
| DROP PRIMARY KEY | DROP {INDEX|KEY}index_name
| DROP FOREIGN KEYfk_symbol
| DISABLE KEYS | ENABLE KEYS | RENAME [TO]new_tbl_name
| ORDER BYcol_name
[,col_name
] ... | CONVERT TO CHARACTER SETcharset_name
[COLLATEcollation_name
] | [DEFAULT] CHARACTER SET [=]charset_name
[COLLATE [=]collation_name
] | DISCARD TABLESPACE | IMPORT TABLESPACE | FORCE | ADD PARTITION (partition_definition
) | DROP PARTITIONpartition_names
| TRUNCATE PARTITION {partition_names
| ALL } | COALESCE PARTITIONnumber
| REORGANIZE PARTITIONpartition_names
INTO (partition_definitions
) | ANALYZE PARTITION {partition_names
| ALL } | CHECK PARTITION {partition_names
| ALL } | OPTIMIZE PARTITION {partition_names
| ALL } | REBUILD PARTITION {partition_names
| ALL } | REPAIR PARTITION {partition_names
| ALL } | PARTITION BYpartitioning_expression
| REMOVE PARTITIONINGindex_col_name
:col_name
[(length
)] [ASC | DESC]index_type
: USING {BTREE | HASH}index_option
: KEY_BLOCK_SIZE [=]value
|index_type
| WITH PARSERparser_name
| COMMENT 'string
'table_options
:table_option
[[,]table_option
] ... (seeCREATE TABLE
options)partition_options
: (seeCREATE TABLE
options)
ALTER TABLE
changes the structure
of a 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 characteristics
such as the storage engine used for the table or the table
comment.
Partitioning-related clauses for ALTER
TABLE
can be used with partitioned tables for
repartitioning, for adding, dropping, merging, and splitting
partitions, and for performing partitioning maintenance. For more
information, see
Section 12.1.7.1, “ALTER TABLE
Partition Operations”.
Following the table name, specify the alterations to be made. If
none are given, ALTER TABLE
does
nothing.
The syntax for many of the permissible alterations is similar to
clauses of the CREATE TABLE
statement. See Section 12.1.17, “CREATE TABLE
Синтаксис”, for more
information.
Some operations may result in warnings if attempted on a table for
which the storage engine does not support the operation. These
warnings can be displayed with SHOW
WARNINGS
. See Section 12.7.5.41, “SHOW WARNINGS
Синтаксис”.
For information on troubleshooting ALTER
TABLE
, see Section C.5.7.1, “Problems with ALTER TABLE
”.
Storage, Performance, and Concurrency Considerations
In most cases, ALTER TABLE
makes a
temporary copy of the original table. MySQL waits for other
operations that are modifying the table, then proceeds. It
incorporates the alteration into the copy, deletes the original
table, and renames the new one. While ALTER
TABLE
is executing, the original table is readable by
other sessions. Updates and writes to the table that begin after
the ALTER TABLE
operation begins
are stalled until the new table is ready, then are automatically
redirected to the new table without any failed updates. The
temporary table is created in the database directory of the new
table. This can differ from the database directory of the original
table for ALTER TABLE
operations
that rename the table to a different database.
For MyISAM
tables, you can speed up index
re-creation (the slowest part of the alteration process) by
setting the
myisam_sort_buffer_size
system
variable to a high value.
For some operations, an in-place ALTER
TABLE
is possible that does not require a temporary
table:
For
ALTER TABLE
without any other options, MySQL simply renames any files that correspond to the tabletbl_name
RENAME TOnew_tbl_name
tbl_name
without making a copy. (You can also use theRENAME TABLE
statement to rename tables. See Section 12.1.32, “RENAME TABLE
Синтаксис”.) Any privileges granted specifically for the renamed table are not migrated to the new name. They must be changed manually.Alterations that modify only table metadata and not table data can be made immediately by altering the table's
.frm
file and not touching table contents. The following changes are fast alterations that can be made this way:Renaming a column, except for the
InnoDB
storage engine.Changing the default value of a column (except for
NDB
tables; see Limitations ofNDBCLUSTER
online operations).Changing the definition of an
ENUM
orSET
column by adding new enumeration or set members to the end of the list of valid member values, as long as the storage side of the data type does not change. For example, adding a member to aSET
column that has 8 members changes the required storage per value from 1 byte to 2 bytes; this will require a table copy. Adding members in the middle of the list causes renumbering of existing members, which requires a table copy.
ALTER TABLE ... ADD PARTITION
creates no temporary table except when used withNDB
tables.ADD
orDROP
operations forRANGE
orLIST
partitions are immediate operations or nearly so.ADD
orCOALESCE
operations forHASH
orKEY
partitions copy data between changed partitions; unlessLINEAR HASH
orLINEAR KEY
was used, this is much the same as creating a new table (although the operation is done partition by partition).REORGANIZE
operations copy only changed partitions and do not touch unchanged ones.Renaming an index, except for
InnoDB
.
You can force an ALTER TABLE
operation that
would otherwise not require a table copy to use the temporary
table method (as supported in MySQL 5.0) by setting the
old_alter_table
system variable
to ON
.
As of MySQL 5.5.11, you can also use
ALTER TABLE
to perform a
“null” alter operation that rebuilds the table.
Previously the tbl_name
FORCEFORCE
option was recognized but
ignored.
For NDBCLUSTER
tables, operations
that add and drop indexes on variable-width columns occur online,
without any table copying and without blocking concurrent DML
actions for most of their duration. See
Section 12.1.7.2, “ALTER TABLE
Online Operations”.
Usage Notes
To use
ALTER TABLE
, you needALTER
,CREATE
, andINSERT
privileges for the table. Renaming a table requiresALTER
andDROP
on the old table,ALTER
,CREATE
, andINSERT
on the new table.IGNORE
is a MySQL extension to standard SQL. It controls howALTER TABLE
works if there are duplicates on unique keys in the new table or if warnings occur when strict mode is enabled. IfIGNORE
is not specified, the copy is aborted and rolled back if duplicate-key errors occur. IfIGNORE
is specified, only the first row is used of rows with duplicates on a unique key. The other conflicting rows are deleted. Incorrect values are truncated to the closest matching acceptable value.Pending
INSERT DELAYED
statements are lost if a table is write locked andALTER TABLE
is used to modify the table structure.table_option
signifies a table option of the kind that can be used in theCREATE TABLE
statement, such asENGINE
,AUTO_INCREMENT
, orAVG_ROW_LENGTH
. (Section 12.1.17, “CREATE TABLE
Синтаксис”, lists all table options.) However,ALTER TABLE
ignores theDATA DIRECTORY
andINDEX DIRECTORY
table options.For example, to convert a table to be an
InnoDB
table, use this statement:ALTER TABLE t1 ENGINE = InnoDB;
When you specify an
ENGINE
clause,ALTER TABLE
rebuilds the table. This is true even if the table already has the specified storage engine.The outcome of attempting to change a table's storage engine is affected by whether the desired storage engine is available and the setting of the
NO_ENGINE_SUBSTITUTION
SQL mode, as described in Section 5.1.6, “Server SQL Modes”.To prevent inadvertent loss of data,
ALTER TABLE
cannot be used to change the storage engine of a table toMERGE
orBLACKHOLE
.To change the value of the
AUTO_INCREMENT
counter to be used for new rows, do this:ALTER TABLE t2 AUTO_INCREMENT =
value
;You cannot reset the counter to a value less than or equal to any that have already been used. For
MyISAM
, if the value is less than or equal to the maximum value currently in theAUTO_INCREMENT
column, the value is reset to the current maximum plus one. ForInnoDB
, if the value is less than the current maximum value in the column, no error occurs and the current sequence value is not changed.You can issue multiple
ADD
,ALTER
,DROP
, andCHANGE
clauses in a singleALTER TABLE
statement, separated by commas. This is a MySQL extension to standard SQL, which permits only one of each clause perALTER TABLE
statement. For example, to drop multiple columns in a single statement, do this:ALTER TABLE t2 DROP COLUMN c, DROP COLUMN d;
CHANGE
,col_name
DROP
, andcol_name
DROP INDEX
are MySQL extensions to standard SQL.The word
COLUMN
is optional and can be omitted.column_definition
clauses use the same syntax forADD
andCHANGE
as forCREATE TABLE
. See Section 12.1.17, “CREATE TABLE
Синтаксис”.You can rename a column using a
CHANGE
clause. To do so, specify the old and new column names and the definition that the column currently has. For example, to rename anold_col_name
new_col_name
column_definition
INTEGER
column froma
tob
, you can do this:ALTER TABLE t1 CHANGE a b INTEGER;
To change a column's type but not the name,
CHANGE
syntax still requires an old and new column name, even if they are the same. For example:ALTER TABLE t1 CHANGE b b BIGINT NOT NULL;
You can also use
MODIFY
to change a column's type without renaming it:ALTER TABLE t1 MODIFY b BIGINT NOT NULL;
MODIFY
is an extension toALTER TABLE
for Oracle compatibility.When you use
CHANGE
orMODIFY
,column_definition
must include the data type and all attributes that should apply to the new column, other than index attributes such asPRIMARY KEY
orUNIQUE
. Attributes present in the original definition but not specified for the new definition are not carried forward. Suppose that a columncol1
is defined asINT UNSIGNED DEFAULT 1 COMMENT 'my column'
and you modify the column as follows:ALTER TABLE t1 MODIFY col1 BIGINT;
The resulting column will be defined as
BIGINT
, but will not include the attributesUNSIGNED DEFAULT 1 COMMENT 'my column'
. To retain them, the statement should be:ALTER TABLE t1 MODIFY col1 BIGINT UNSIGNED DEFAULT 1 COMMENT 'my column';
When you change a data type using
CHANGE
orMODIFY
, MySQL tries to convert existing column values to the new type as well as possible.WarningThis conversion may result in alteration of data. For example, if you shorten a string column, values may be truncated. To prevent the operation from succeeding if conversions to the new data type would result in loss of data, enable strict SQL mode before using
ALTER TABLE
(see Section 5.1.6, “Server SQL Modes”).To add a column at a specific position within a table row, use
FIRST
orAFTER
. The default is to add the column last. You can also usecol_name
FIRST
andAFTER
inCHANGE
orMODIFY
operations to reorder columns within a table.ALTER ... SET DEFAULT
orALTER ... DROP DEFAULT
specify a new default value for a column or remove the old default value, respectively. If the old default is removed and the column can beNULL
, the new default isNULL
. If the column cannot beNULL
, MySQL assigns a default value as described in Section 10.1.4, “Data Type Default Values”.DROP INDEX
removes an index. This is a MySQL extension to standard SQL. See Section 12.1.24, “DROP INDEX
Синтаксис”. If you are unsure of the index name, useSHOW INDEX FROM
.tbl_name
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. If you use
CHANGE
orMODIFY
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.If a table contains only one column, the column cannot be dropped. If what you intend is to remove the table, use
DROP TABLE
instead.DROP PRIMARY KEY
drops the primary key. If there is no primary key, an error occurs.If you add a
UNIQUE INDEX
orPRIMARY KEY
to a table, MySQL stores it before any nonunique index to permit detection of duplicate keys as early as possible.Some storage engines permit you to specify an index type when creating an index. The syntax for the
index_type
specifier isUSING
. For details abouttype_name
USING
, see Section 12.1.13, “CREATE INDEX
Синтаксис”. The preferred position is after the column list. Support for use of the option before the column list will be removed in a future MySQL release.index_option
values specify additional options for an index.USING
is one such option. For details about permissibleindex_option
values, see Section 12.1.13, “CREATE INDEX
Синтаксис”.After an
ALTER TABLE
statement, it may be necessary to runANALYZE TABLE
to update index cardinality information. See Section 12.7.5.23, “SHOW INDEX
Синтаксис”.ORDER BY
enables you to create the new table with the rows in a specific order. Note that the table does not remain in this order after inserts and deletes. This option is useful primarily when you know that you are mostly to query the rows in a certain order most of the time. By using this option after major changes to the table, you might be able to get higher performance. In some cases, it might make sorting easier for MySQL if the table is in order by the column that you want to order it by later.ORDER BY
syntax permits one or more column names to be specified for sorting, each of which optionally can be followed byASC
orDESC
to indicate ascending or descending sort order, respectively. The default is ascending order. Only column names are permitted as sort criteria; arbitrary expressions are not permitted. This clause should be given last after any other clauses.ORDER BY
does not make sense forInnoDB
tables that contain a user-defined clustered index (PRIMARY KEY
orNOT NULL UNIQUE
index).InnoDB
always orders table rows according to such an index if one is present.ЗамечаниеWhen used on a partitioned table,
ALTER TABLE ... ORDER BY
orders rows within each partition only.If you use
ALTER TABLE
on aMyISAM
table, all nonunique indexes are created in a separate batch (as forREPAIR TABLE
). This should makeALTER TABLE
much faster when you have many indexes.This feature can be activated explicitly for a
MyISAM
table.ALTER TABLE ... DISABLE KEYS
tells MySQL to stop updating nonunique indexes.ALTER TABLE ... ENABLE KEYS
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. UsingALTER TABLE ... DISABLE KEYS
requires theINDEX
privilege in addition to the privileges mentioned earlier.While the nonunique indexes are disabled, they are ignored for statements such as
SELECT
andEXPLAIN
that otherwise would use them.If
ALTER TABLE
for anInnoDB
table results in changes to column values (for example, because a column is truncated),InnoDB
'sFOREIGN KEY
constraint checks do not notice possible violations caused by changing the values.The
FOREIGN KEY
andREFERENCES
clauses are supported by theInnoDB
storage engine, which implementsADD [CONSTRAINT [
. See Section 13.3.5.4, “symbol
]] FOREIGN KEY (...) REFERENCES ... (...)FOREIGN KEY
Constraints”. For other storage engines, the clauses are parsed but ignored. TheCHECK
clause is parsed but ignored by all storage engines. See Section 12.1.17, “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 Section 1.8.5, “MySQL Differences from Standard SQL”.ImportantThe inline
REFERENCES
specifications where the references are defined as part of the column specification are silently ignored byInnoDB
. InnoDB only acceptsREFERENCES
clauses defined as part of a separateFOREIGN KEY
specification.ЗамечаниеPartitioned tables do not support foreign keys. See Section 17.5, “Restrictions and Limitations on Partitioning”, for more information.
InnoDB
supports the use ofALTER TABLE
to drop foreign keys:ALTER TABLE
tbl_name
DROP FOREIGN KEYfk_symbol
;For more information, see Section 13.3.5.4, “
FOREIGN KEY
Constraints”.You cannot add a foreign key and drop a foreign key in separate clauses of a single
ALTER TABLE
statement. You must use separate statements.For an
InnoDB
table that is created with its own tablespace in an.ibd
file, that file can be discarded and imported. To discard the.ibd
file, use this statement:ALTER TABLE
tbl_name
DISCARD TABLESPACE;This deletes the current
.ibd
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.To import the backup
.ibd
file back into the table, copy it into the database directory, and then issue this statement:ALTER TABLE
tbl_name
IMPORT TABLESPACE;The tablespace file must have been created on the server into which it is imported later.
If you want to change the table default character set and all character columns (
CHAR
,VARCHAR
,TEXT
) to a new character set, use a statement like this:ALTER TABLE
tbl_name
CONVERT TO CHARACTER SETcharset_name
;For a column that has a data type of
VARCHAR
or one of theTEXT
types,CONVERT TO CHARACTER SET
will change the data type as necessary to ensure that the new column is long enough to store as many characters as the original column. For example, aTEXT
column has two length bytes, which store the byte-length of values in the column, up to a maximum of 65,535. For alatin1
TEXT
column, each character requires a single byte, so the column can store up to 65,535 characters. If the column is converted toutf8
, each character might require up to three bytes, for a maximum possible length of 3 × 65,535 = 196,605 bytes. That length will not fit in aTEXT
column's length bytes, so MySQL will convert the data type toMEDIUMTEXT
, which is the smallest string type for which the length bytes can record a value of 196,605. Similarly, aVARCHAR
column might be converted toMEDIUMTEXT
.To avoid data type changes of the type just described, do not use
CONVERT TO CHARACTER SET
. Instead, useMODIFY
to change individual columns. For example:ALTER TABLE t MODIFY latin1_text_col TEXT CHARACTER SET utf8; ALTER TABLE t MODIFY latin1_varchar_col VARCHAR(
M
) CHARACTER SET utf8;If you specify
CONVERT TO CHARACTER SET binary
, theCHAR
,VARCHAR
, andTEXT
columns are converted to their corresponding binary string types (BINARY
,VARBINARY
,BLOB
). This means that the columns no longer will have a character set and a subsequentCONVERT TO
operation will not apply to them.If
charset_name
isDEFAULT
, the database character set is used.WarningThe
CONVERT TO
operation converts column values between the character sets. This is not what you want if you have a column in one character set (likelatin1
) but the stored values actually use some other, incompatible character set (likeutf8
). In this case, you have to do the following for each such column:ALTER TABLE t1 CHANGE c1 c1 BLOB; ALTER TABLE t1 CHANGE c1 c1 TEXT CHARACTER SET utf8;
The reason this works is that there is no conversion when you convert to or from
BLOB
columns.To change only the default character set for a table, use this statement:
ALTER TABLE
tbl_name
DEFAULT CHARACTER SETcharset_name
;The word
DEFAULT
is optional. The default character set is the character set that is used if you do not specify the character set for columns that you add to a table later (for example, withALTER TABLE ... ADD column
).
With the mysql_info()
C API
function, you can find out how many rows were copied by
ALTER TABLE
, and (when
IGNORE
is used) how many rows were deleted due
to duplication of unique key values. See
Section 21.9.3.35, “mysql_info()
”.
Partitioning-related clauses for ALTER
TABLE
can be used with partitioned tables for
repartitioning, for adding, dropping, merging, and splitting
partitions, and for performing partitioning maintenance.
Simply using a
partition_options
clause withALTER TABLE
on a partitioned table repartitions the table according to the partitioning scheme defined by thepartition_options
. This clause always begins withPARTITION BY
, and follows the same syntax and other rules as apply to thepartition_options
clause forCREATE TABLE
(see Section 12.1.17, “CREATE TABLE
Синтаксис”, for more detailed information), and can also be used to partition an existing table that is not already partitioned. For example, consider a (nonpartitioned) table defined as shown here:CREATE TABLE t1 ( id INT, year_col INT );
This table can be partitioned by
HASH
, using theid
column as the partitioning key, into 8 partitions by means of this statement:ALTER TABLE t1 PARTITION BY HASH(id) PARTITIONS 8;
The table that results from using an
ALTER TABLE ... PARTITION BY
statement must follow the same rules as one created usingCREATE TABLE ... PARTITION BY
. This includes the rules governing the relationship between any unique keys (including any primary key) that the table might have, and the column or columns used in the partitioning expression, as discussed in Section 17.5.1, “Partitioning Keys, Primary Keys, and Unique Keys”. TheCREATE TABLE ... PARTITION BY
rules for specifying the number of partitions also apply toALTER TABLE ... PARTITION BY
.The
partition_definition
clause forALTER TABLE ADD PARTITION
supports the same options as the clause of the same name for theCREATE TABLE
statement. (See Section 12.1.17, “CREATE TABLE
Синтаксис”, for the syntax and description.) Suppose that you have the partitioned table created as shown here:CREATE TABLE t1 ( id INT, year_col INT ) PARTITION BY RANGE (year_col) ( PARTITION p0 VALUES LESS THAN (1991), PARTITION p1 VALUES LESS THAN (1995), PARTITION p2 VALUES LESS THAN (1999) );
You can add a new partition
p3
to this table for storing values less than2002
as follows:ALTER TABLE t1 ADD PARTITION (PARTITION p3 VALUES LESS THAN (2002));
DROP PARTITION
can be used to drop one or moreRANGE
orLIST
partitions. This statement cannot be used withHASH
orKEY
partitions; instead, useCOALESCE PARTITION
(see below). Any data that was stored in the dropped partitions named in thepartition_names
list is discarded. For example, given the tablet1
defined previously, you can drop the partitions namedp0
andp1
as shown here:ALTER TABLE t1 DROP PARTITION p0, p1;
ЗамечаниеDROP PARTITION
does not work with tables that use theNDBCLUSTER
storage engine. See Section 17.3.1, “Management ofRANGE
andLIST
Partitions”, and Section 16.1.6, “Known Limitations of MySQL Cluster”.ADD PARTITION
andDROP PARTITION
do not currently supportIF [NOT] EXISTS
. It is also not possible to rename a partition or a partitioned table. Instead, if you wish to rename a partition, you must drop and re-create the partition; if you wish to rename a partitioned table, you must instead drop all partitions, rename the table, and then add back the partitions that were dropped.Beginning with MySQL 5.5.0, it is possible to delete rows from selected partitions using the
TRUNCATE PARTITION
option. This option takes a comma-separated list of one or more partition names. For example, consider the tablet1
as defined here:CREATE TABLE t1 ( id INT, year_col INT ) PARTITION BY RANGE (year_col) ( PARTITION p0 VALUES LESS THAN (1991), PARTITION p1 VALUES LESS THAN (1995), PARTITION p2 VALUES LESS THAN (1999), PARTITION p3 VALUES LESS THAN (2003), PARTITION p4 VALUES LESS THAN (2007) );
To delete all rows from partition
p0
, you can use the following statement:ALTER TABLE t1 TRUNCATE PARTITION p0;
The statement just shown has the same effect as the following
DELETE
statement:DELETE FROM t1 WHERE year_col < 1991;
When truncating multiple partitions, the partitions do not have to be contiguous: This can greatly simplify delete operations on partitioned tables that would otherwise require very complex
WHERE
conditions if done withDELETE
statements. For example, this statement deletes all rows from partitionsp1
andp3
:ALTER TABLE t1 TRUNCATE PARTITION p1, p3;
An equivalent
DELETE
statement is shown here:DELETE FROM t1 WHERE (year_col >= 1991 AND year_col < 1995) OR (year_col >= 2003 AND year_col < 2007);
You can also use the
ALL
keyword in place of the list of partition names; in this case, the statement acts on all partitions in the table.TRUNCATE PARTITION
merely deletes rows; it does not alter the definition of the table itself, or of any of its partitions.ЗамечаниеTRUNCATE PARTITION
does not work with subpartitions.You can verify that the rows were dropped by checking the
INFORMATION_SCHEMA.PARTITIONS
table, using a query such as this one:SELECT PARTITION_NAME, TABLE_ROWS FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_NAME = 't1';
TRUNCATE PARTITION
is supported only for partitioned tables that use theMyISAM
,InnoDB
, orMEMORY
storage engine. It also works onBLACKHOLE
tables (but has no effect). It is not supported forARCHIVE
tables.COALESCE PARTITION
can be used with a table that is partitioned byHASH
orKEY
to reduce the number of partitions bynumber
. Suppose that you have created tablet2
using the following definition:CREATE TABLE t2 ( name VARCHAR (30), started DATE ) PARTITION BY HASH( YEAR(started) ) PARTITIONS 6;
You can reduce the number of partitions used by
t2
from 6 to 4 using the following statement:ALTER TABLE t2 COALESCE PARTITION 2;
The data contained in the last
number
partitions will be merged into the remaining partitions. In this case, partitions 4 and 5 will be merged into the first 4 partitions (the partitions numbered 0, 1, 2, and 3).To change some but not all the partitions used by a partitioned table, you can use
REORGANIZE PARTITION
. This statement can be used in several ways:To merge a set of partitions into a single partition. This can be done by naming several partitions in the
partition_names
list and supplying a single definition forpartition_definition
.To split an existing partition into several partitions. You can accomplish this by naming a single partition for
partition_names
and providing multiplepartition_definitions
.To change the ranges for a subset of partitions defined using
VALUES LESS THAN
or the value lists for a subset of partitions defined usingVALUES IN
.This statement may also be used without the
option on tables that are automatically partitioned usingpartition_names
INTO (partition_definitions
)HASH
partitioning to force redistribution of data. (Currently, onlyNDBCLUSTER
tables are automatically partitioned in this way.) This is useful in MySQL Cluster where, after you have added new MySQL Cluster data nodes online to an existing MySQL Cluster, you wish to redistribute existing MySQL Cluster table data to the new data nodes. In such cases, you should invoke the satement with theONLINE
option; in other words, as shown here:ALTER ONLINE TABLE
table
REORGANIZE PARTITION;You cannot perform other DDL concurrently with online table reorganization—that is, no other DDL statements can be issued while an
ALTER ONLINE TABLE ... REORGANIZE PARTITION
statement is executing. For more information about adding MySQL Cluster data nodes online, see Section 16.5.12, “Adding MySQL Cluster Data Nodes Online”.Attempting to use
REORGANIZE PARTITION
without the
option on explicitly partitioned tables results in the error REORGANIZE PARTITION without parameters can only be used on auto-partitioned tables using HASH partitioning.partition_names
INTO (partition_definitions
)
ЗамечаниеFor partitions that have not been explicitly named, MySQL automatically provides the default names
p0
,p1
,p2
, and so on. The same is true with regard to subpartitions.For more detailed information about and examples of
ALTER TABLE ... REORGANIZE PARTITION
statements, see Section 17.3.1, “Management ofRANGE
andLIST
Partitions”.Several additional options provide partition maintenance and repair functionality analogous to that implemented for nonpartitioned tables by statements such as
CHECK TABLE
andREPAIR TABLE
(which are also supported for partitioned tables; see Section 12.7.2, “Table Maintenance Statements” for more information). These includeANALYZE PARTITION
,CHECK PARTITION
,OPTIMIZE PARTITION
,REBUILD PARTITION
, andREPAIR PARTITION
. Each of these options takes apartition_names
clause consisting of one or more names of partitions, separated by commas. The partitions must already exist in the table to be altered. You can also use theALL
keyword in place ofpartition_names
, in which case the statement acts on all partitions in the table. For more information and examples, see Section 17.3.3, “Maintenance of Partitions”.The
ANALYZE PARTITION
,CHECK PARTITION
,OPTIMIZE PARTITION
, andREPAIR PARTITION
options are not permitted for tables which are not partitioned.REMOVE PARTITIONING
enables you to remove a table's partitioning without otherwise affecting the table or its data. This option can be combined with otherALTER TABLE
options such as those used to add, drop, or rename drop columns or indexes.Using the
ENGINE
option withALTER TABLE
changes the storage engine used by the table without affecting the partitioning.
Only a single instance of any one of the following options can
be used in a given ALTER TABLE
statement: PARTITION BY
, ADD
PARTITION
, DROP PARTITION
,
TRUNCATE PARTITION
, REORGANIZE
PARTITION
, or COALESCE PARTITION
,
ANALYZE PARTITION
, CHECK
PARTITION
, OPTIMIZE PARTITION
,
REBUILD PARTITION
, REMOVE
PARTITIONING
.
For example, the following two statements are invalid:
ALTER TABLE t1 ANALYZE PARTITION p1, ANALYZE PARTITION p2; ALTER TABLE t1 ANALYZE PARTITION p1, CHECK PARTITION p2;
In the first case, you can analyze partitions
p1
and p2
of table
t1
concurrently using a single statement with
a single ANALYZE PARTITION
option that lists
both of the partitions to be analyzed, like this:
ALTER TABLE t1 ANALYZE PARTITION p1, p2;
In the second case, it is not possible to perform
ANALYZE
and CHECK
operations on different partitions of the same table
concurrently. Instead, you must issue two separate statements,
like this:
ALTER TABLE t1 ANALYZE PARTITION p1; ALTER TABLE t1 CHECK PARTITION p2;
Operations that add and drop indexes on variable-width columns
of NDBCLUSTER
tables occur online.
Online operations are noncopying; that is, they do not require
that indexes be re-created. They do not lock the table being
altered from access my other API nodes in a MySQL Cluster (but
see Limitations later in this section).
Such operations do not require single user mode for
NDBCLUSTER
table alterations made
in a cluster with multiple API nodes; transactions can continue
uninterrupted during online DDL operations.
The ONLINE
keyword can be used to perform
online ADD COLUMN
, ADD
INDEX
(including CREATE INDEX
statements), and DROP INDEX
operations on
NDBCLUSTER
tables. Online renaming
of NDBCLUSTER
tables is also
supported.
The ONLINE
and OFFLINE
keywords are supported only in MySQL Cluster. For standard MySQL
Server 5.5 releases:
The server determines automatically whether an
ADD INDEX
orDROP INDEX
operation can be (and is) performed online or offline; if the column is of a variable-width data type, the operation is performed online. It is not possible to override the server behavior in this regard.Attempting to use the
ONLINE
orOFFLINE
keyword in anALTER TABLE
,CREATE INDEX
, orDROP INDEX
statement results in an error.
Currently you cannot add disk-based columns to
NDBCLUSTER
tables online. This
means that, if you wish to add an in-memory column to an
NDBCLUSTER
table that uses a
table-level STORAGE DISK
option, you must
declare the new column as using memory-based storage explicitly.
For example—assuming that you have already created
tablespace ts1
—suppose that you create
table t1
as follows:
mysql>CREATE TABLE t1 (
>c1 INT NOT NULL PRIMARY KEY,
>c2 VARCHAR(30)
>)
>TABLESPACE ts1 STORAGE DISK
>ENGINE NDBCLUSTER;
Query OK, 0 rows affected (1.73 sec) Records: 0 Duplicates: 0 Warnings: 0
You can add a new in-memory column to this table online as shown here:
mysql> ALTER ONLINE TABLE t1 ADD COLUMN c3 INT COLUMN_FORMAT DYNAMIC STORAGE MEMORY;
Query OK, 0 rows affected (1.25 sec)
Records: 0 Duplicates: 0 Warnings: 0
This statement fails if the STORAGE MEMORY
option is omitted:
mysql> ALTER ONLINE TABLE t1 ADD COLUMN c3 INT COLUMN_FORMAT DYNAMIC;
ERROR 1235 (42000): This version of MySQL doesn't yet support
'ALTER ONLINE TABLE t1 ADD COLUMN c3 INT COLUMN_FORMAT DYNAMIC'
If you omit the COLUMN_FORMAT DYNAMIC
option,
the dynamic column format is employed automatically, but a
warning is issued, as shown here:
mysql>ALTER ONLINE TABLE t1 ADD COLUMN c3 INT STORAGE MEMORY;
Query OK, 0 rows affected, 1 warning (1.17 sec) Records: 0 Duplicates: 0 Warnings: 0 mysql>SHOW WARNINGS;
+---------+------+---------------------------------------------------------------+ | Level | Code | Message | +---------+------+---------------------------------------------------------------+ | Warning | 1478 | Converted FIXED field to DYNAMIC to enable on-line ADD COLUMN | +---------+------+---------------------------------------------------------------+ 1 row in set (0.00 sec) mysql>SHOW CREATE TABLE t1\G
*************************** 1. row *************************** Table: t1 Create Table: CREATE TABLE `t1` ( `c1` int(11) NOT NULL, `c2` varchar(30) DEFAULT NULL, `c3` int(11) /*!50120 STORAGE MEMORY */ /*!50120 COLUMN_FORMAT DYNAMIC */ DEFAULT NULL, `t4` int(11) /*!50120 STORAGE MEMORY */ DEFAULT NULL, PRIMARY KEY (`c1`) ) /*!50100 TABLESPACE ts_1 STORAGE DISK */ ENGINE=ndbcluster DEFAULT CHARSET=latin1 1 row in set (0.03 sec)
The STORAGE
and
COLUMN_FORMAT
keywords are supported only
in MySQL Cluster; in any other version of MySQL, attempting to
use either of these keywords in a CREATE
TABLE
or ALTER TABLE
statement results in an error.
It is also possible to use the statement ALTER ONLINE
TABLE ... REORGANIZE PARTITION
with no
option on partition_names
INTO
(partition_definitions
)NDBCLUSTER
tables. This
can be used to redistribute MySQL Cluster data among new data
nodes that have been added to the cluster online. For more
information about this statement, see
Section 12.1.7.1, “ALTER TABLE
Partition Operations” For more
information about adding data nodes online to a MySQL Cluster,
see Section 16.5.12, “Adding MySQL Cluster Data Nodes Online”.
Limitations of NDBCLUSTER
online operations
Online DROP COLUMN
operations are not
supported.
Online ALTER TABLE
,
CREATE INDEX
, or
DROP INDEX
statements that add
columns or add or drop indexes are subject to the following
limitations:
A given online
ALTER TABLE
can use only one ofADD COLUMN
,ADD INDEX
, orDROP INDEX
. One or more columns can be added online in a single statement; only one index may be created or dropped online in a single statement.The table being altered is not locked with respect to API nodes other than the one on which an online
ALTER TABLE
ADD COLUMN
,ADD INDEX
, orDROP INDEX
operation (orCREATE INDEX
orDROP INDEX
statement) is run. However, the table is locked against any other operations originating on the same API node while the online operation is being executed.The table to be altered must have an explicit primary key; the hidden primary key created by the
NDBCLUSTER
storage engine is not sufficient for this purpose.The storage engine used by the table cannot be changed online.
When used with MySQL Cluster Disk Data tables, it is not possible to change the storage type (
DISK
orMEMORY
) of a column online. This means, that when you add or drop an index in such a way that the operation would be performed online, and you want the storage type of the column or columns to be changed, you must use theOFFLINE
keyword in the statement that adds or drops the index.
Columns to be added online must meet the following criteria:
The columns must be dynamic; that is, it must be possible to create them using
COLUMN_FORMAT DYNAMIC
. If you omit theCOLUMN_FORMAT DYNAMIC
option, the dynamic column format is employed automatically.The columns must permit
NULL
values and not have any explicit default value other thanNULL
. Columns added online are automatically created asDEFAULT NULL
, as can be seen here:mysql>
CREATE TABLE t1 (
>c1 INT NOT NULL AUTO_INCREMENT PRIMARY KEY
>) ENGINE=NDBCLUSTER;
Query OK, 0 rows affected (1.44 sec) mysql>ALTER ONLINE TABLE t1
>ADD COLUMN c2 INT,
>ADD COLUMN c3 INT;
Query OK, 0 rows affected, 2 warnings (0.93 sec) mysql>SHOW CREATE TABLE t1\G
*************************** 1. row *************************** Table: t1 Create Table: CREATE TABLE `t1` ( `c1` int(11) NOT NULL AUTO_INCREMENT, `c2` int(11) DEFAULT NULL, `c3` int(11) DEFAULT NULL, PRIMARY KEY (`c1`) ) ENGINE=ndbcluster DEFAULT CHARSET=latin1 1 row in set (0.00 sec)The columns must be added following any existing columns. If you attempt to add a column online before any existing columns or using the
FIRST
keyword, the statement fails with an error.Existing table columns cannot be reordered online.
The preceding limitations do not apply to operations that merely rename tables or columns.
For online ALTER TABLE
operations
on NDBCLUSTER
tables, fixed-format
columns are converted to dynamic when they are added online, or
when indexes are created or dropped online, as shown here:
mysql>CREATE TABLE t1 (
>c1 INT NOT NULL AUTO_INCREMENT PRIMARY KEY
>) ENGINE=NDBCLUSTER;
Query OK, 0 rows affected (1.44 sec) mysql>ALTER ONLINE TABLE t1 ADD COLUMN c2 INT, ADD COLUMN c3 INT;
Query OK, 0 rows affected, 2 warnings (0.93 sec) Records: 0 Duplicates: 0 Warnings: 0 mysql>SHOW WARNINGS;
+---------+------+---------------------------------------------------------------+ | Level | Code | Message | +---------+------+---------------------------------------------------------------+ | Warning | 1475 | Converted FIXED field to DYNAMIC to enable on-line ADD COLUMN | | Warning | 1475 | Converted FIXED field to DYNAMIC to enable on-line ADD COLUMN | +---------+------+---------------------------------------------------------------+ 2 rows in set (0.00 sec)
Existing columns, including the table's primary key, need not be dynamic; only the column or columns to be added online must be dynamic.
mysql>CREATE TABLE t2 (
>c1 INT NOT NULL AUTO_INCREMENT PRIMARY KEY COLUMN_FORMAT FIXED
>) ENGINE=NDBCLUSTER;
Query OK, 0 rows affected (2.10 sec) mysql>ALTER ONLINE TABLE t2 ADD COLUMN c2 INT;
Query OK, 0 rows affected, 1 warning (0.78 sec) Records: 0 Duplicates: 0 Warnings: 0 mysql>SHOW WARNINGS;
+---------+------+---------------------------------------------------------------+ | Level | Code | Message | +---------+------+---------------------------------------------------------------+ | Warning | 1475 | Converted FIXED field to DYNAMIC to enable on-line ADD COLUMN | +---------+------+---------------------------------------------------------------+ 1 row in set (0.00 sec)
Columns are not converted from FIXED
to
DYNAMIC
column format by renaming operations.
For more information about COLUMN_FORMAT
, see
Section 12.1.17, “CREATE TABLE
Синтаксис”.
The KEY
, CONSTRAINT
, and
IGNORE
keywords are supported in
ALTER TABLE
statements using the
ONLINE
keyword.
Begin with a table t1
that is created as
shown here:
CREATE TABLE t1 (a INTEGER,b CHAR(10));
To rename the table from t1
to
t2
:
ALTER TABLE t1 RENAME t2;
To change column a
from
INTEGER
to TINYINT NOT
NULL
(leaving the name the same), and to change column
b
from CHAR(10)
to
CHAR(20)
as well as renaming it from
b
to c
:
ALTER TABLE t2 MODIFY a TINYINT NOT NULL, CHANGE b c CHAR(20);
To add a new TIMESTAMP
column
named d
:
ALTER TABLE t2 ADD d TIMESTAMP;
To add an index on column d
and a
UNIQUE
index on column a
:
ALTER TABLE t2 ADD INDEX (d), ADD UNIQUE (a);
To remove column c
:
ALTER TABLE t2 DROP COLUMN c;
To add a new AUTO_INCREMENT
integer column
named c
:
ALTER TABLE t2 ADD c INT UNSIGNED NOT NULL AUTO_INCREMENT, ADD PRIMARY KEY (c);
We indexed c
(as a PRIMARY
KEY
) because AUTO_INCREMENT
columns
must be indexed, and we declare c
as
NOT NULL
because primary key columns cannot
be NULL
.
For NDB
tables, it is also possible
to change the storage type used for a table or column. For
example, consider an NDB
table
created as shown here:
mysql> CREATE TABLE t1 (c1 INT) TABLESPACE ts_1 ENGINE NDB;
Query OK, 0 rows affected (1.27 sec)
To convert this table to disk-based storage, you can use the
following ALTER TABLE
statement:
mysql>ALTER TABLE t1 TABLESPACE ts_1 STORAGE DISK;
Query OK, 0 rows affected (2.99 sec) Records: 0 Duplicates: 0 Warnings: 0 mysql>SHOW CREATE TABLE t1\G
*************************** 1. row *************************** Table: t1 Create Table: CREATE TABLE `t1` ( `c1` int(11) DEFAULT NULL ) /*!50100 TABLESPACE ts_1 STORAGE DISK */ ENGINE=ndbcluster DEFAULT CHARSET=latin1 1 row in set (0.01 sec)
It is not necessary that the tablespace was referenced when the
table was originally created; however, the tablespace must be
referenced by the ALTER TABLE
:
mysql>CREATE TABLE t2 (c1 INT) ts_1 ENGINE NDB;
Query OK, 0 rows affected (1.00 sec) mysql>ALTER TABLE t2 STORAGE DISK;
ERROR 1005 (HY000): Can't create table 'c.#sql-1750_3' (errno: 140) mysql>ALTER TABLE t2 TABLESPACE ts_1 STORAGE DISK;
Query OK, 0 rows affected (3.42 sec) Records: 0 Duplicates: 0 Warnings: 0 mysql>SHOW CREATE TABLE t2\G
*************************** 1. row *************************** Table: t1 Create Table: CREATE TABLE `t2` ( `c1` int(11) DEFAULT NULL ) /*!50100 TABLESPACE ts_1 STORAGE DISK */ ENGINE=ndbcluster DEFAULT CHARSET=latin1 1 row in set (0.01 sec)
To change the storage type of an individual column, you can use
ALTER TABLE ... MODIFY [COLUMN]
. For example,
suppose you create a MySQL Cluster Disk Data table with two
columns, using this CREATE TABLE
statement:
mysql>CREATE TABLE t3 (c1 INT, c2 INT)
->TABLESPACE ts_1 STORAGE DISK ENGINE NDB;
Query OK, 0 rows affected (1.34 sec)
To change column c2
from disk-based to
in-memory storage, include a STORAGE MEMORY clause in the column
definition used by the ALTER TABLE statement, as shown here:
mysql> ALTER TABLE t3 MODIFY c2 INT STORAGE MEMORY;
Query OK, 0 rows affected (3.14 sec)
Records: 0 Duplicates: 0 Warnings: 0
You can make an in-memory column into a disk-based column by
using STORAGE DISK
in a similar fashion.
Column c1
uses disk-based storage, since this
is the default for the table (determined by the table-level
STORAGE DISK
clause in the
CREATE TABLE
statement). However,
column c2
uses in-memory storage, as can be
seen here in the output of SHOW CREATE
TABLE
:
mysql> SHOW CREATE TABLE t3\G
*************************** 1. row ***************************
Table: t3
Create Table: CREATE TABLE `t3` (
`c1` int(11) DEFAULT NULL,
`c2` int(11) /*!50120 STORAGE MEMORY */ DEFAULT NULL
) /*!50100 TABLESPACE ts_1 STORAGE DISK */ ENGINE=ndbcluster DEFAULT CHARSET=latin1
1 row in set (0.02 sec)
When you add an AUTO_INCREMENT
column, column
values are filled in with sequence numbers automatically. For
MyISAM
tables, you can set the first sequence
number by executing SET
INSERT_ID=
before
value
ALTER TABLE
or by using the
AUTO_INCREMENT=
table option. See Section 5.1.3, “Server System Variables”.
value
With MyISAM
tables, if you do not change the
AUTO_INCREMENT
column, the sequence number is
not affected. If you drop an AUTO_INCREMENT
column and then add another AUTO_INCREMENT
column, the numbers are resequenced beginning with 1.
When replication is used, adding an
AUTO_INCREMENT
column to a table might not
produce the same ordering of the rows on the slave and the
master. This occurs because the order in which the rows are
numbered depends on the specific storage engine used for the
table and the order in which the rows were inserted. If it is
important to have the same order on the master and slave, the
rows must be ordered before assigning an
AUTO_INCREMENT
number. Assuming that you want
to add an AUTO_INCREMENT
column to the table
t1
, the following statements produce a new
table t2
identical to t1
but with an AUTO_INCREMENT
column:
CREATE TABLE t2 (id INT AUTO_INCREMENT PRIMARY KEY) SELECT * FROM t1 ORDER BY col1, col2;
This assumes that the table t1
has columns
col1
and col2
.
This set of statements will also produce a new table
t2
identical to t1
, with
the addition of an AUTO_INCREMENT
column:
CREATE TABLE t2 LIKE t1; ALTER TABLE t2 ADD id INT AUTO_INCREMENT PRIMARY KEY; INSERT INTO t2 SELECT * FROM t1 ORDER BY col1, col2;
To guarantee the same ordering on both master and slave,
all columns of t1
must
be referenced in the ORDER BY
clause.
Regardless of the method used to create and populate the copy
having the AUTO_INCREMENT
column, the final
step is to drop the original table and then rename the copy:
DROP t1; ALTER TABLE t2 RENAME t1;
ALTER TABLESPACEtablespace_name
{ADD|DROP} DATAFILE 'file_name
' [INITIAL_SIZE [=]size
] [WAIT] ENGINE [=]engine_name
This statement can be used either to add a new data file, or to drop a data file from a tablespace.
The ADD DATAFILE
variant enables you to specify
an initial size using an INITIAL_SIZE
clause,
where size
is measured in bytes; the
default value is 128M
(128 megabytes). You may
optionally follow this integer value with a one-letter
abbreviation for an order of magnitude, similar to those used in
my.cnf
. Generally, this is one of the letters
M
(for megabytes) or G
(for
gigabytes).
All MySQL Cluster Disk Data objects share the same namespace. This means that each Disk Data object must be uniquely named (and not merely each Disk Data object of a given type). For example, you cannot have a tablespace and an data file with the same name, or an undo log file and a tablespace with the same name.
On 32-bit systems, the maximum supported value for
INITIAL_SIZE
is 4G
. (Bug
#29186)
INITIAL_SIZE
is rounded, explicitly, as for
CREATE TABLESPACE
.
Once a data file has been created, its size cannot be changed;
however, you can add more data files to the tablespace using
additional ALTER TABLESPACE ... ADD DATAFILE
statements.
Using DROP DATAFILE
with
ALTER TABLESPACE
drops the data
file 'file_name
' from the tablespace.
This file must already have been added to the tablespace using
CREATE TABLESPACE
or
ALTER TABLESPACE
; otherwise an
error will result.
Both ALTER TABLESPACE ... ADD DATAFILE
and
ALTER TABLESPACE ... DROP DATAFILE
require an
ENGINE
clause which specifies the storage
engine used by the tablespace. Currently, the only accepted values
for engine_name
are
NDB
and
NDBCLUSTER
.
WAIT
is parsed but otherwise ignored, and so
has no effect in MySQL 5.5. It is intended for future
expansion.
When ALTER TABLESPACE ... ADD DATAFILE
is used
with ENGINE = NDB
, a data file is created on
each Cluster data node. You can verify that the data files were
created and obtain information about them by querying the
INFORMATION_SCHEMA.FILES
table. For
example, the following query shows all data files belonging to the
tablespace named newts
:
mysql>SELECT LOGFILE_GROUP_NAME, FILE_NAME, EXTRA
->FROM INFORMATION_SCHEMA.FILES
->WHERE TABLESPACE_NAME = 'newts' AND FILE_TYPE = 'DATAFILE';
+--------------------+--------------+----------------+ | LOGFILE_GROUP_NAME | FILE_NAME | EXTRA | +--------------------+--------------+----------------+ | lg_3 | newdata.dat | CLUSTER_NODE=3 | | lg_3 | newdata.dat | CLUSTER_NODE=4 | | lg_3 | newdata2.dat | CLUSTER_NODE=3 | | lg_3 | newdata2.dat | CLUSTER_NODE=4 | +--------------------+--------------+----------------+ 2 rows in set (0.03 sec)
See Section 19.8, “The INFORMATION_SCHEMA FILES
Table”.
ALTER TABLESPACE
is useful only
with Disk Data storage for MySQL Cluster. See
Section 16.5.11, “MySQL Cluster Disk Data Tables”.
ALTER [ALGORITHM = {UNDEFINED | MERGE | TEMPTABLE}] [DEFINER = {user
| CURRENT_USER }] [SQL SECURITY { DEFINER | INVOKER }] VIEWview_name
[(column_list
)] ASselect_statement
[WITH [CASCADED | LOCAL] CHECK OPTION]
This statement changes the definition of a view, which must exist.
The syntax is similar to that for CREATE
VIEW
and the effect is the same as for
CREATE OR REPLACE
VIEW
. See Section 12.1.20, “CREATE VIEW
Синтаксис”. This statement
requires the CREATE VIEW
and
DROP
privileges for the view, and
some privilege for each column referred to in the
SELECT
statement.
ALTER VIEW
is permitted only to the
definer or users with the SUPER
privilege.
CREATE {DATABASE | SCHEMA} [IF NOT EXISTS]db_name
[create_specification
] ...create_specification
: [DEFAULT] CHARACTER SET [=]charset_name
| [DEFAULT] COLLATE [=]collation_name
CREATE DATABASE
creates a database
with the given name. To use this statement, you need the
CREATE
privilege for the database.
CREATE
SCHEMA
is a synonym for CREATE
DATABASE
.
An error occurs if the database exists and you did not specify
IF NOT EXISTS
.
As of MySQL 5.5.3, CREATE DATABASE
is not permitted within a session that has an active
LOCK TABLES
statement.
create_specification
options specify
database characteristics. Database characteristics are stored in
the db.opt
file in the database directory.
The CHARACTER SET
clause specifies the default
database character set. The COLLATE
clause
specifies the default database collation.
Section 9.1, “Character Set Support”, discusses character set and collation
names.
A database in MySQL is implemented as a directory containing files
that correspond to tables in the database. Because there are no
tables in a database when it is initially created, the
CREATE DATABASE
statement creates
only a directory under the MySQL data directory and the
db.opt
file. Rules for permissible database
names are given in Section 8.2, “Schema Object Names”. If a database
name contains special characters, the name for the database
directory contains encoded versions of those characters as
described in Section 8.2.3, “Mapping of Identifiers to File Names”.
If you manually create a directory under the data directory (for
example, with mkdir), the server considers it a
database directory and it shows up in the output of
SHOW DATABASES
.
You can also use the mysqladmin program to create databases. See Section 4.5.2, “mysqladmin — Client for Administering a MySQL Server”.
CREATE [DEFINER = {user
| CURRENT_USER }] EVENT [IF NOT EXISTS]event_name
ON SCHEDULEschedule
[ON COMPLETION [NOT] PRESERVE] [ENABLE | DISABLE | DISABLE ON SLAVE] [COMMENT 'comment
'] DOevent_body
;schedule
: ATtimestamp
[+ INTERVALinterval
] ... | EVERYinterval
[STARTStimestamp
[+ INTERVAL interval] ...] [ENDStimestamp
[+ INTERVAL interval] ...]interval
:quantity
{YEAR | QUARTER | MONTH | DAY | HOUR | MINUTE | WEEK | SECOND | YEAR_MONTH | DAY_HOUR | DAY_MINUTE | DAY_SECOND | HOUR_MINUTE | HOUR_SECOND | MINUTE_SECOND}
This statement creates and schedules a new event. The event will not run unless the Event Scheduler is enabled. For information about checking Event Scheduler status and enabling it if necessary, see Section 18.4.2, “Event Scheduler Configuration”.
CREATE EVENT
requires the
EVENT
privilege for the schema in
which the event is to be created. It might also require the
SUPER
privilege, depending on the
DEFINER
value, as described later in this
section.
The minimum requirements for a valid CREATE
EVENT
statement are as follows:
The keywords
CREATE EVENT
plus an event name, which uniquely identifies the event in a database schema.An
ON SCHEDULE
clause, which determines when and how often the event executes.A
DO
clause, which contains the SQL statement to be executed by an event.
This is an example of a minimal CREATE
EVENT
statement:
CREATE EVENT myevent ON SCHEDULE AT CURRENT_TIMESTAMP + INTERVAL 1 HOUR DO UPDATE myschema.mytable SET mycol = mycol + 1;
The previous statement creates an event named
myevent
. This event executes once—one
hour following its creation—by running an SQL statement that
increments the value of the myschema.mytable
table's mycol
column by 1.
The event_name
must be a valid MySQL
identifier with a maximum length of 64 characters. Event names are
not case sensitive, so you cannot have two events named
myevent
and MyEvent
in the
same schema. In general, the rules governing event names are the
same as those for names of stored routines. See
Section 8.2, “Schema Object Names”.
An event is associated with a schema. If no schema is indicated as
part of event_name
, the default
(current) schema is assumed. To create an event in a specific
schema, qualify the event name with a schema using
syntax.
schema_name
.event_name
The DEFINER
clause specifies the MySQL account
to be used when checking access privileges at event execution
time. If a user
value is given, it
should be a MySQL account specified as
'
(the same format used in the user_name
'@'host_name
'GRANT
statement), CURRENT_USER
, or
CURRENT_USER()
. The default
DEFINER
value is the user who executes the
CREATE EVENT
statement. This is the
same as specifying DEFINER = CURRENT_USER
explicitly.
If you specify the DEFINER
clause, these rules
determine the legal DEFINER
user values:
If you do not have the
SUPER
privilege, the only legaluser
value is your own account, either specified literally or by usingCURRENT_USER
. You cannot set the definer to some other account.If you have the
SUPER
privilege, you can specify any syntactically legal account name. If the account does not actually exist, a warning is generated.Although it is possible to create an event with a nonexistent
DEFINER
account, an error occurs at event execution time if the account does not exist.
For more information about event security, see Section 18.6, “Access Control for Stored Programs and Views”.
Within an event, the CURRENT_USER()
function returns the account used to check privileges at event
execution time, which is the DEFINER
user. For
information about user auditing within events, see
Section 5.5.10, “Auditing MySQL Account Activity”.
IF NOT EXISTS
has the same meaning for
CREATE EVENT
as for
CREATE TABLE
: If an event named
event_name
already exists in the same
schema, no action is taken, and no error results. (However, a
warning is generated in such cases.)
The ON SCHEDULE
clause determines when, how
often, and for how long the event_body
defined for the event repeats. This clause takes one of two forms:
AT
is used for a one-time event. It specifies that the event executes one time only at the date and time given bytimestamp
timestamp
, which must include both the date and time, or must be an expression that resolves to a datetime value. You may use a value of either theDATETIME
orTIMESTAMP
type for this purpose. If the date is in the past, a warning occurs, as shown here:mysql>
SELECT NOW();
+---------------------+ | NOW() | +---------------------+ | 2006-02-10 23:59:01 | +---------------------+ 1 row in set (0.04 sec) mysql>CREATE EVENT e_totals
->ON SCHEDULE AT '2006-02-10 23:59:00'
->DO INSERT INTO test.totals VALUES (NOW());
Query OK, 0 rows affected, 1 warning (0.00 sec) mysql>SHOW WARNINGS\G
*************************** 1. row *************************** Level: Note Code: 1588 Message: Event execution time is in the past and ON COMPLETION NOT PRESERVE is set. The event was dropped immediately after creation.CREATE EVENT
statements which are themselves invalid—for whatever reason—fail with an error.You may use
CURRENT_TIMESTAMP
to specify the current date and time. In such a case, the event acts as soon as it is created.To create an event which occurs at some point in the future relative to the current date and time—such as that expressed by the phrase “three weeks from now”—you can use the optional clause
+ INTERVAL
. Theinterval
interval
portion consists of two parts, a quantity and a unit of time, and follows the same syntax rules that govern intervals used in theDATE_ADD()
function (see Section 11.7, “Date and Time Functions”. The units keywords are also the same, except that you cannot use any units involving microseconds when defining an event. With some interval types, complex time units may be used. For example, “two minutes and ten seconds” can be expressed as+ INTERVAL '2:10' MINUTE_SECOND
.You can also combine intervals. For example,
AT CURRENT_TIMESTAMP + INTERVAL 3 WEEK + INTERVAL 2 DAY
is equivalent to “three weeks and two days from now”. Each portion of such a clause must begin with+ INTERVAL
.To repeat actions at a regular interval, use an
EVERY
clause. TheEVERY
keyword is followed by aninterval
as described in the previous discussion of theAT
keyword. (+ INTERVAL
is not used withEVERY
.) For example,EVERY 6 WEEK
means “every six weeks”.Although
+ INTERVAL
clauses are not permitted in anEVERY
clause, you can use the same complex time units permitted in a+ INTERVAL
.An
EVERY
clause may contain an optionalSTARTS
clause.STARTS
is followed by atimestamp
value that indicates when the action should begin repeating, and may also use+ INTERVAL
to specify an amount of time “from now”. For example,interval
EVERY 3 MONTH STARTS CURRENT_TIMESTAMP + INTERVAL 1 WEEK
means “every three months, beginning one week from now”. Similarly, you can express “every two weeks, beginning six hours and fifteen minutes from now” asEVERY 2 WEEK STARTS CURRENT_TIMESTAMP + INTERVAL '6:15' HOUR_MINUTE
. Not specifyingSTARTS
is the same as usingSTARTS CURRENT_TIMESTAMP
—that is, the action specified for the event begins repeating immediately upon creation of the event.An
EVERY
clause may contain an optionalENDS
clause. TheENDS
keyword is followed by atimestamp
value that tells MySQL when the event should stop repeating. You may also use+ INTERVAL
withinterval
ENDS
; for instance,EVERY 12 HOUR STARTS CURRENT_TIMESTAMP + INTERVAL 30 MINUTE ENDS CURRENT_TIMESTAMP + INTERVAL 4 WEEK
is equivalent to “every twelve hours, beginning thirty minutes from now, and ending four weeks from now”. Not usingENDS
means that the event continues executing indefinitely.ENDS
supports the same syntax for complex time units asSTARTS
does.You may use
STARTS
,ENDS
, both, or neither in anEVERY
clause.If a repeating event does not terminate within its scheduling interval, the result may be multiple instances of the event executing simultaneously. If this is undesirable, you should institute a mechanism to prevent simultaneous instances. For example, you could use the
GET_LOCK()
function, or row or table locking.
The ON SCHEDULE
clause may use expressions
involving built-in MySQL functions and user variables to obtain
any of the timestamp
or
interval
values which it contains. You
may not use stored functions or user-defined functions in such
expressions, nor may you use any table references; however, you
may use SELECT FROM DUAL
. This is true for both
CREATE EVENT
and
ALTER EVENT
statements. References
to stored functions, user-defined functions, and tables in such
cases are specifically not permitted, and fail with an error (see
Bug #22830).
Times in the ON SCHEDULE
clause are interpreted
using the current session
time_zone
value. This becomes the
event time zone; that is, the time zone that is used for event
scheduling and is in effect within the event as it executes. These
times are converted to UTC and stored along with the event time
zone in the mysql.event
table. This enables
event execution to proceed as defined regardless of any subsequent
changes to the server time zone or daylight saving time effects.
For additional information about representation of event times,
see Section 18.4.4, “Event Metadata”. See also
Section 12.7.5.19, “SHOW EVENTS
Синтаксис”, and Section 19.7, “The INFORMATION_SCHEMA EVENTS
Table”.
Normally, once an event has expired, it is immediately dropped.
You can override this behavior by specifying ON
COMPLETION PRESERVE
. Using ON COMPLETION NOT
PRESERVE
merely makes the default nonpersistent behavior
explicit.
You can create an event but prevent it from being active using the
DISABLE
keyword. Alternatively, you can use
ENABLE
to make explicit the default status,
which is active. This is most useful in conjunction with
ALTER EVENT
(see
Section 12.1.2, “ALTER EVENT
Синтаксис”).
A third value may also appear in place of
ENABLED
or DISABLED
;
DISABLE ON SLAVE
is set for the status of an
event on a replication slave to indicate that the event was
created on the master and replicated to the slave, but is not
executed on the slave. See
Section 15.4.1.8, “Replication of Invoked Features”.
You may supply a comment for an event using a
COMMENT
clause.
comment
may be any string of up to 64
characters that you wish to use for describing the event. The
comment text, being a string literal, must be surrounded by
quotation marks.
The DO
clause specifies an action
carried by the event, and consists of an SQL statement. Nearly any
valid MySQL statement that can be used in a stored routine can
also be used as the action statement for a scheduled event. (See
Section E.1, “Restrictions on Stored Programs”.) For example, the
following event e_hourly
deletes all rows from
the sessions
table once per hour, where this
table is part of the site_activity
schema:
CREATE EVENT e_hourly ON SCHEDULE EVERY 1 HOUR COMMENT 'Clears out sessions table each hour.' DO DELETE FROM site_activity.sessions;
MySQL stores the sql_mode
system
variable setting that is in effect at the time an event is
created, and always executes the event with this setting in force,
regardless of the current server SQL mode.
A CREATE EVENT
statement that
contains an ALTER EVENT
statement
in its DO
clause appears to
succeed; however, when the server attempts to execute the
resulting scheduled event, the execution fails with an error.
Statements such as SELECT
or
SHOW
that merely return a result
set have no effect when used in an event; the output from these
is not sent to the MySQL Monitor, nor is it stored anywhere.
However, you can use statements such as
SELECT ...
INTO
and
INSERT INTO ...
SELECT
that store a result. (See the next example in
this section for an instance of the latter.)
The schema to which an event belongs is the default schema for
table references in the DO
clause.
Any references to tables in other schemas must be qualified with
the proper schema name.
As with stored routines, you can use compound-statement syntax in
the DO
clause by using the
BEGIN
and END
keywords, as
shown here:
delimiter | CREATE EVENT e_daily ON SCHEDULE EVERY 1 DAY COMMENT 'Saves total number of sessions then clears the table each day' DO BEGIN INSERT INTO site_activity.totals (time, total) SELECT CURRENT_TIMESTAMP, COUNT(*) FROM site_activity.sessions; DELETE FROM site_activity.sessions; END | delimiter ;
This example uses the delimiter
command to
change the statement delimiter. See
Section 18.1, “Defining Stored Programs”.
More complex compound statements, such as those used in stored routines, are possible in an event. This example uses local variables, an error handler, and a flow control construct:
delimiter | CREATE EVENT e ON SCHEDULE EVERY 5 SECOND DO BEGIN DECLARE v INTEGER; DECLARE CONTINUE HANDLER FOR SQLEXCEPTION BEGIN END; SET v = 0; WHILE v < 5 DO INSERT INTO t1 VALUES (0); UPDATE t2 SET s1 = s1 + 1; SET v = v + 1; END WHILE; END | delimiter ;
There is no way to pass parameters directly to or from events; however, it is possible to invoke a stored routine with parameters within an event:
CREATE EVENT e_call_myproc ON SCHEDULE AT CURRENT_TIMESTAMP + INTERVAL 1 DAY DO CALL myproc(5, 27);
If an event's definer has the SUPER
privilege, the event can read and write global variables. As
granting this privilege entails a potential for abuse, extreme
care must be taken in doing so.
Generally, any statements that are valid in stored routines may be used for action statements executed by events. For more information about statements permissible within stored routines, see Section 18.2.1, “Stored Routine Синтаксис”. You can create an event as part of a stored routine, but an event cannot be created by another event.
The CREATE FUNCTION
statement is
used to create stored functions and user-defined functions (UDFs):
For information about creating stored functions, see Section 12.1.15, “
CREATE PROCEDURE
andCREATE FUNCTION
Синтаксис”.For information about creating user-defined functions, see Section 12.7.3.1, “
CREATE FUNCTION
Синтаксис for User-Defined Functions”.
CREATE [ONLINE|OFFLINE] [UNIQUE|FULLTEXT|SPATIAL] INDEXindex_name
[index_type
] ONtbl_name
(index_col_name
,...) [index_option
] ...index_col_name
:col_name
[(length
)] [ASC | DESC]index_type
: USING {BTREE | HASH}index_option
: KEY_BLOCK_SIZE [=]value
|index_type
| WITH PARSERparser_name
| COMMENT 'string
'
CREATE INDEX
is mapped to an
ALTER TABLE
statement to create
indexes. See Section 12.1.7, “ALTER TABLE
Синтаксис”.
CREATE INDEX
cannot be used to
create a PRIMARY KEY
; use
ALTER TABLE
instead. For more
information about indexes, see Section 7.3.1, “How MySQL Uses Indexes”.
Normally, you create all indexes on a table at the time the table
itself is created with CREATE
TABLE
. See Section 12.1.17, “CREATE TABLE
Синтаксис”. This
guideline is especially important for InnoDB
tables, where the primary key determines the physical layout of
rows in the data file. CREATE INDEX
enables you to add indexes to existing tables.
A column list of the form (col1,col2,...)
creates a multiple-column index. Index key values are formed by
concatenating the values of the given columns.
Indexes can be created that use only the leading part of column
values, using
syntax to specify an index prefix length:
col_name
(length
)
Prefixes can be specified for
CHAR
,VARCHAR
,BINARY
, andVARBINARY
columns.BLOB
andTEXT
columns also can be indexed, but a prefix length must be given.Prefix lengths are given in characters for nonbinary string types and in bytes for binary string types. That is, index entries consist of the first
length
characters of each column value forCHAR
,VARCHAR
, andTEXT
columns, and the firstlength
bytes of each column value forBINARY
,VARBINARY
, andBLOB
columns.For spatial columns, prefix values cannot be given, as described later in this section.
The statement shown here creates an index using the first 10
characters of the name
column:
CREATE INDEX part_of_name ON customer (name(10));
If names in the column usually differ in the first 10 characters,
this index should not be much slower than an index created from
the entire name
column. Also, using column
prefixes for indexes can make the index file much smaller, which
could save a lot of disk space and might also speed up
INSERT
operations.
Prefix support and lengths of prefixes (where supported) are
storage engine dependent. For example, a prefix can be up to 1000
bytes long for MyISAM
tables, and 767 bytes for
InnoDB
tables. The
NDBCLUSTER
storage engine does not support
prefixes (see
Section 16.1.6.6, “Unsupported or Missing Features in MySQL Cluster”).
Prefix limits are measured in bytes, whereas the prefix length
in CREATE INDEX
statements is
interpreted as number of characters for nonbinary data types
(CHAR
,
VARCHAR
,
TEXT
). Take this into account
when specifying a prefix length for a column that uses a
multi-byte character set.
Indexes on variable-width columns of
NDBCLUSTER
tables are created online;
that is, without any table copying. The table is not locked
against access from other MySQL Cluster API nodes, although it is
locked against other operations on the same
API node for the duration of the operation. This is done
automatically by the server whenever it determines that it is
possible to do so; you do not have to use any special SQL syntax
or server options to cause it to happen.
In standard MySQL 5.5 releases, it is not possible to
override the server when it determines that an index is to be
created without table copying. In MySQL Cluster, you can create
indexes offline (which causes the table to be locked to all API
nodes in the cluster) using the OFFLINE
keyword. The rules and limitations governing CREATE
OFFLINE INDEX
and CREATE ONLINE INDEX
are the same as for ALTER OFFLINE TABLE ... ADD
INDEX
and ALTER ONLINE TABLE ... ADD
INDEX
. You cannot cause the noncopying creation of an
index that would normally be created offline by using the
ONLINE
keyword: If it is not possible to
perform the CREATE INDEX
operation
without table copying, the server ignores the
ONLINE
keyword. For more information, see
Section 12.1.7.2, “ALTER TABLE
Online Operations”.
The ONLINE
and OFFLINE
keywords are available only in MySQL Cluster; attempting to use
these keywords in standard MySQL Server 5.5 releases results in
a syntax error.
A UNIQUE
index creates a constraint such that
all values in the index must be distinct. An error occurs if you
try to add a new row with a key value that matches an existing
row. For all engines, a UNIQUE
index permits
multiple NULL
values for columns that can
contain NULL
. If you specify a prefix value for
a column in a UNIQUE
index, the column values
must be unique within the prefix.
FULLTEXT
indexes are supported only for
MyISAM
tables and can include only
CHAR
,
VARCHAR
, and
TEXT
columns. Indexing always
happens over the entire column; column prefix indexing is not
supported and any prefix length is ignored if specified. See
Section 11.9, “Full-Text Search Functions”, for details of operation.
The MyISAM
, InnoDB
,
NDB
, and ARCHIVE
storage engines support spatial columns such as
(POINT
and GEOMETRY
.
(Section 11.17, “Spatial Extensions”, describes the spatial data
types.) However, support for spatial column indexing varies among
engines. Spatial and nonspatial indexes are available according to
the following rules.
Spatial indexes (created using SPATIAL INDEX
)
have these characteristics:
Available only for
MyISAM
tables. SpecifyingSPATIAL INDEX
for other storage engines results in an error.Indexed columns must be
NOT NULL
.In MySQL 5.5, column prefix lengths are prohibited. The full width of each column is indexed.
Characteristics of nonspatial indexes (created with
INDEX
, UNIQUE
, or
PRIMARY KEY
):
Permitted for any storage engine that supports spatial columns except
ARCHIVE
.Columns can be
NULL
unless the index is a primary key.For each spatial column in a non-
SPATIAL
index exceptPOINT
columns, a column prefix length must be specified. (This is the same requirement as for indexedBLOB
columns.) The prefix length is given in bytes.The index type for a non-
SPATIAL
index depends on the storage engine. Currently, B-tree is used.
In MySQL 5.5:
An index_col_name
specification can end
with ASC
or DESC
. These
keywords are permitted 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.
Following the index column list, index options can be given. An
index_option
value can be any of the
following:
KEY_BLOCK_SIZE [=]
value
This option provides a hint to the storage engine about the size in bytes to use for index key blocks. The engine is permitted to change the value if necessary. A value of 0 indicates that the default value should be used.
index_type
Some storage engines permit you to specify an index type when creating an index. The permissible index type values supported by different storage engines are shown in the following table. Where multiple index types are listed, the first one is the default when no index type specifier is given.
Storage Engine Permissible Index Types MyISAM
BTREE
InnoDB
BTREE
MEMORY
/HEAP
HASH
,BTREE
NDB
HASH
,BTREE
(see note in text)Пример:
CREATE TABLE lookup (id INT) ENGINE = MEMORY; CREATE INDEX id_index ON lookup (id) USING BTREE;
BTREE
indexes are implemented by theNDBCLUSTER
storage engine as T-tree indexes.ЗамечаниеFor indexes on
NDB
table columns, theUSING
option can be specified only for a unique index or primary key.USING HASH
prevents the creation of an implicit ordered index; otherwise, creating a unique index or primary key on anNDB
table automatically results in the creation of both an ordered index and a hash index, each of which indexes the same set of columns.This means that a query using a unique index or primary key on a
NULL
column is always handled byNDB
with a full scan of the table. In particular, if you plan to use anIS NULL
orIS NOT NULL
condition involving a unique index or primary key column of anNDB
table, you should create any such index withoutUSING HASH
.The
index_type
clause cannot be used together withSPATIAL INDEX
.If you specify an index type that is not legal for a given storage engine, but there is another index type available that the engine can use without affecting query results, the engine uses the available type. The parser recognizes
RTREE
as a type name, but currently this cannot be specified for any storage engine.Use of this option before the
ON
clause is deprecated; support for use of the option in this position will be removed in a future MySQL release. If antbl_name
index_type
option is given in both the earlier and later positions, the final option applies.TYPE
is recognized as a synonym fortype_name
USING
. However,type_name
USING
is the preferred form.WITH PARSER
parser_name
This option can be used only with
FULLTEXT
indexes. It associates a parser plugin with the index if full-text indexing and searching operations need special handling. See Section 22.2, “The MySQL Plugin API”, for details on creating plugins.COMMENT '
string
'As of MySQL 5.5.3, index definitions can include an optional comment of up to 1024 characters.
CREATE LOGFILE GROUPlogfile_group
ADD UNDOFILE 'undo_file
' [INITIAL_SIZE [=]initial_size
] [UNDO_BUFFER_SIZE [=]undo_buffer_size
] [REDO_BUFFER_SIZE [=]redo_buffer_size
] [NODEGROUP [=]nodegroup_id
] [WAIT] [COMMENT [=]comment_text
] ENGINE [=]engine_name
This statement creates a new log file group named
logfile_group
having a single
UNDO
file named
'undo_file
'. A
CREATE LOGFILE GROUP
statement has
one and only one ADD UNDOFILE
clause. For rules
covering the naming of log file groups, see
Section 8.2, “Schema Object Names”.
All MySQL Cluster Disk Data objects share the same namespace. This means that each Disk Data object must be uniquely named (and not merely each Disk Data object of a given type). For example, you cannot have a tablespace and a log file group with the same name, or a tablespace and a data file with the same name.
In MySQL Cluster NDB 7.2, you can have only one log file group per Cluster at any given time. (See Bug #16386)
The optional INITIAL_SIZE
parameter sets the
UNDO
file's initial size; if not specified, it
defaults to 128M
(128 megabytes). The optional
UNDO_BUFFER_SIZE
parameter sets the size used
by the UNDO
buffer for the log file group; The
default value for UNDO_BUFFER_SIZE
is
8M
(eight megabytes); this value cannot exceed
the amount of system memory available. Both of these parameters
are specified in bytes. You may optionally follow either or both
of these with a one-letter abbreviation for an order of magnitude,
similar to those used in my.cnf
. Generally,
this is one of the letters M
(for megabytes)
or G
(for gigabytes).
The memory used for both INITIAL_SIZE
and
UNDO_BUFFER_SIZE
comes from the global pool
whose size is determined by the value of the
SharedGlobalMemory
data
node configuration parameter. This includes any default value
implied for these options by the setting of the
InitialLogFileGroup
data
node configuration parameter.
The maximum permitted for UNDO_BUFFER_SIZE
is
600M
.
On 32-bit systems, the maximum supported value for
INITIAL_SIZE
is 4G
.
The minimum permitted value for INITIAL_SIZE
is
1M
.
The ENGINE
option determines the storage engine
to be used by this log file group, with
engine_name
being the name of the
storage engine. In MySQL 5.5, this must be
NDB
(or
NDBCLUSTER
). If
ENGINE
is not set, MySQL tries to use the
engine specified by the
default_storage_engine
server
system variable (formerly
storage_engine
). In any case, if
the engine is not specified as NDB
or
NDBCLUSTER
, the CREATE
LOGFILE GROUP
statement appears to succeed but actually
fails to create the log file group, as shown here:
mysql>CREATE LOGFILE GROUP lg1
->ADD UNDOFILE 'undo.dat' INITIAL_SIZE = 10M;
Query OK, 0 rows affected, 1 warning (0.00 sec) mysql>SHOW WARNINGS;
+-------+------+------------------------------------------------------------------------------------------------+ | Level | Code | Message | +-------+------+------------------------------------------------------------------------------------------------+ | Error | 1478 | Table storage engine 'InnoDB' does not support the create option 'TABLESPACE or LOGFILE GROUP' | +-------+------+------------------------------------------------------------------------------------------------+ 1 row in set (0.00 sec) mysql>DROP LOGFILE GROUP lg1 ENGINE = NDB;
ERROR 1529 (HY000): Failed to drop LOGFILE GROUP mysql>CREATE LOGFILE GROUP lg1
->ADD UNDOFILE 'undo.dat' INITIAL_SIZE = 10M
->ENGINE = NDB;
Query OK, 0 rows affected (2.97 sec)
The fact that the CREATE LOGFILE GROUP
statement does not actually return an error when a
non-NDB
storage engine is named, but rather
appears to succeed, is a known issue which we hope to address in a
future release of MySQL Cluster.
REDO_BUFFER_SIZE
,
NODEGROUP
, WAIT
, and
COMMENT
are parsed but ignored, and so have no
effect in MySQL 5.5. These options are intended for
future expansion.
When used with ENGINE [=] NDB
, a log file group
and associated UNDO
log file are created on
each Cluster data node. You can verify that the
UNDO
files were created and obtain information
about them by querying the
INFORMATION_SCHEMA.FILES
table. For
example:
mysql>SELECT LOGFILE_GROUP_NAME, LOGFILE_GROUP_NUMBER, EXTRA
->FROM INFORMATION_SCHEMA.FILES
->WHERE FILE_NAME = 'undo_10.dat';
+--------------------+----------------------+----------------+ | LOGFILE_GROUP_NAME | LOGFILE_GROUP_NUMBER | EXTRA | +--------------------+----------------------+----------------+ | lg_3 | 11 | CLUSTER_NODE=3 | | lg_3 | 11 | CLUSTER_NODE=4 | +--------------------+----------------------+----------------+ 2 rows in set (0.06 sec)
CREATE LOGFILE GROUP
is useful only
with Disk Data storage for MySQL Cluster. See
Section 16.5.11, “MySQL Cluster Disk Data Tables”.
CREATE [DEFINER = {user
| CURRENT_USER }] PROCEDUREsp_name
([proc_parameter
[,...]]) [characteristic
...]routine_body
CREATE [DEFINER = {user
| CURRENT_USER }] FUNCTIONsp_name
([func_parameter
[,...]]) RETURNStype
[characteristic
...]routine_body
proc_parameter
: [ IN | OUT | INOUT ]param_name
type
func_parameter
:param_name
type
type
:Any valid MySQL data type
characteristic
: COMMENT 'string
' | LANGUAGE SQL | [NOT] DETERMINISTIC | { CONTAINS SQL | NO SQL | READS SQL DATA | MODIFIES SQL DATA } | SQL SECURITY { DEFINER | INVOKER }routine_body
:Valid SQL routine statement
These statements create stored routines. By default, a routine is
associated with the default database. To associate the routine
explicitly with a given database, specify the name as
db_name.sp_name
when you create it.
The CREATE FUNCTION
statement is
also used in MySQL to support UDFs (user-defined functions). See
Section 22.3, “Adding New Functions to MySQL”. A UDF can be regarded as an
external stored function. Stored functions share their namespace
with UDFs. See Section 8.2.4, “Function Name Parsing and Resolution”, for the
rules describing how the server interprets references to different
kinds of functions.
To invoke a stored procedure, use the
CALL
statement (see
Section 12.2.1, “CALL
Синтаксис”). To invoke a stored function, refer to it
in an expression. The function returns a value during expression
evaluation.
CREATE PROCEDURE
and
CREATE FUNCTION
require the
CREATE ROUTINE
privilege. They
might also require the SUPER
privilege, depending on the DEFINER
value, as
described later in this section. If binary logging is enabled,
CREATE FUNCTION
might require the
SUPER
privilege, as described in
Section 18.7, “Binary Logging of Stored Programs”.
By default, MySQL automatically grants the
ALTER ROUTINE
and
EXECUTE
privileges to the routine
creator. This behavior can be changed by disabling the
automatic_sp_privileges
system
variable. See Section 18.2.2, “Stored Routines and MySQL Privileges”.
The DEFINER
and SQL SECURITY
clauses specify the security context to be used when checking
access privileges at routine execution time, as described later in
this section.
If the routine name is the same as the name of a built-in SQL function, a syntax error occurs unless you use a space between the name and the following parenthesis when defining the routine or invoking it later. For this reason, avoid using the names of existing SQL functions for your own stored routines.
The IGNORE_SPACE
SQL mode
applies to built-in functions, not to stored routines. It is
always permissible to have spaces after a stored routine name,
regardless of whether
IGNORE_SPACE
is enabled.
The parameter list enclosed within parentheses must always be
present. If there are no parameters, an empty parameter list of
()
should be used. Parameter names are not case
sensitive.
Each parameter is an IN
parameter by default.
To specify otherwise for a parameter, use the keyword
OUT
or INOUT
before the
parameter name.
Specifying a parameter as IN
,
OUT
, or INOUT
is valid
only for a PROCEDURE
. For a
FUNCTION
, parameters are always regarded as
IN
parameters.
An IN
parameter passes a value into a
procedure. The procedure might modify the value, but the
modification is not visible to the caller when the procedure
returns. An OUT
parameter passes a value from
the procedure back to the caller. Its initial value is
NULL
within the procedure, and its value is
visible to the caller when the procedure returns. An
INOUT
parameter is initialized by the caller,
can be modified by the procedure, and any change made by the
procedure is visible to the caller when the procedure returns.
For each OUT
or INOUT
parameter, pass a user-defined variable in the
CALL
statement that invokes the
procedure so that you can obtain its value when the procedure
returns. If you are calling the procedure from within another
stored procedure or function, you can also pass a routine
parameter or local routine variable as an IN
or
INOUT
parameter.
The following example shows a simple stored procedure that uses an
OUT
parameter:
mysql>delimiter //
mysql>CREATE PROCEDURE simpleproc (OUT param1 INT)
->BEGIN
->SELECT COUNT(*) INTO param1 FROM t;
->END//
Query OK, 0 rows affected (0.00 sec) mysql>delimiter ;
mysql>CALL simpleproc(@a);
Query OK, 0 rows affected (0.00 sec) mysql>SELECT @a;
+------+ | @a | +------+ | 3 | +------+ 1 row in set (0.00 sec)
The example uses the mysql client
delimiter
command to change the statement
delimiter from ;
to //
while
the procedure is being defined. This enables the
;
delimiter used in the procedure body to be
passed through to the server rather than being interpreted by
mysql itself. See
Section 18.1, “Defining Stored Programs”.
The RETURNS
clause may be specified only for a
FUNCTION
, for which it is mandatory. It
indicates the return type of the function, and the function body
must contain a RETURN
statement. If the
value
RETURN
statement returns a value of
a different type, the value is coerced to the proper type. For
example, if a function specifies an
ENUM
or
SET
value in the
RETURNS
clause, but the
RETURN
statement returns an
integer, the value returned from the function is the string for
the corresponding ENUM
member of
set of SET
members.
The following example function takes a parameter, performs an
operation using an SQL function, and returns the result. In this
case, it is unnecessary to use delimiter
because the function definition contains no internal
;
statement delimiters:
mysql>CREATE FUNCTION hello (s CHAR(20))
mysql>RETURNS CHAR(50) DETERMINISTIC
->RETURN CONCAT('Hello, ',s,'!');
Query OK, 0 rows affected (0.00 sec) mysql>SELECT hello('world');
+----------------+ | hello('world') | +----------------+ | Hello, world! | +----------------+ 1 row in set (0.00 sec)
Parameter types and function return types can be declared to use
any valid data type, except that the COLLATE
attribute cannot be used prior to MySQL 5.5.3. As of 5.5.3,
COLLATE
can be used if preceded by the
CHARACTER SET
attribute.
The routine_body
consists of a valid
SQL routine statement. This can be a simple statement such as
SELECT
or
INSERT
, or a compound statement
written using BEGIN
and END
.
Compound statements can contain declarations, loops, and other
control structure statements. The syntax for these statements is
described in Section 12.6, “MySQL Compound-Statement Синтаксис”.
MySQL permits routines to contain DDL statements, such as
CREATE
and DROP
. MySQL also
permits stored procedures (but not stored functions) to contain
SQL transaction statements such as
COMMIT
. Stored functions may not
contain statements that perform explicit or implicit commit or
rollback. Support for these statements is not required by the SQL
standard, which states that each DBMS vendor may decide whether to
permit them.
Statements that return a result set can be used within a stored
procedure but not within a stored function. This prohibition
includes SELECT
statements that do
not have an INTO
clause and other
statements such as var_list
SHOW
,
EXPLAIN
, and
CHECK TABLE
. For statements that
can be determined at function definition time to return a result
set, a Not allowed to return a result set from a
function
error occurs
(ER_SP_NO_RETSET
). For statements
that can be determined only at runtime to return a result set, a
PROCEDURE %s can't return a result set in the given
context
error occurs
(ER_SP_BADSELECT
).
USE
statements within stored
routines are not permitted. When a routine is invoked, an implicit
USE
is
performed (and undone when the routine terminates). The causes the
routine to have the given default database while it executes.
References to objects in databases other than the routine default
database should be qualified with the appropriate database name.
db_name
For additional information about statements that are not permitted in stored routines, see Section E.1, “Restrictions on Stored Programs”.
For information about invoking stored procedures from within
programs written in a language that has a MySQL interface, see
Section 12.2.1, “CALL
Синтаксис”.
MySQL stores the sql_mode
system
variable setting that is in effect at the time a routine is
created, and always executes the routine with this setting in
force, regardless of the server SQL mode in effect when
the routine is invoked.
The switch from the SQL mode of the invoker to that of the routine occurs after evaluation of arguments and assignment of the resulting values to routine parameters. If you define a routine in strict SQL mode but invoke it in nonstrict mode, assignment of arguments to routine parameters does not take place in strict mode. If you require that expressions passed to a routine be assigned in strict SQL mode, you should invoke the routine with strict mode in effect.
The COMMENT
characteristic is a MySQL
extension, and may be used to describe the stored routine. This
information is displayed by the SHOW CREATE
PROCEDURE
and SHOW CREATE
FUNCTION
statements.
The LANGUAGE
characteristic indicates the
language in which the routine is written. The server ignores this
characteristic; only SQL routines are supported.
A routine is considered “deterministic” if it always
produces the same result for the same input parameters, and
“not deterministic” otherwise. If neither
DETERMINISTIC
nor NOT
DETERMINISTIC
is given in the routine definition, the
default is NOT DETERMINISTIC
. To declare that a
function is deterministic, you must specify
DETERMINISTIC
explicitly.
Assessment of the nature of a routine is based on the
“honesty” of the creator: MySQL does not check that a
routine declared DETERMINISTIC
is free of
statements that produce nondeterministic results. However,
misdeclaring a routine might affect results or affect performance.
Declaring a nondeterministic routine as
DETERMINISTIC
might lead to unexpected results
by causing the optimizer to make incorrect execution plan choices.
Declaring a deterministic routine as
NONDETERMINISTIC
might diminish performance by
causing available optimizations not to be used.
If binary logging is enabled, the DETERMINISTIC
characteristic affects which routine definitions MySQL accepts.
See Section 18.7, “Binary Logging of Stored Programs”.
A routine that contains the NOW()
function (or its synonyms) or
RAND()
is nondeterministic, but it
might still be replication-safe. For
NOW()
, the binary log includes the
timestamp and replicates correctly.
RAND()
also replicates correctly as
long as it is called only a single time during the execution of a
routine. (You can consider the routine execution timestamp and
random number seed as implicit inputs that are identical on the
master and slave.)
Several characteristics provide information about the nature of data use by the routine. In MySQL, these characteristics are advisory only. The server does not use them to constrain what kinds of statements a routine will be permitted to execute.
CONTAINS SQL
indicates that the routine does not contain statements that read or write data. This is the default if none of these characteristics is given explicitly. Examples of such statements areSET @x = 1
orDO RELEASE_LOCK('abc')
, which execute but neither read nor write data.NO SQL
indicates that the routine contains no SQL statements.READS SQL DATA
indicates that the routine contains statements that read data (for example,SELECT
), but not statements that write data.MODIFIES SQL DATA
indicates that the routine contains statements that may write data (for example,INSERT
orDELETE
).
The SQL SECURITY
characteristic can be
DEFINER
or INVOKER
to
specify the security context; that is, whether the routine
executes using the privileges of the account named in the routine
DEFINER
clause or the user who invokes it. This
account must have permission to access the database with which the
routine is associated. The default value is
DEFINER
. The user who invokes the routine must
have the EXECUTE
privilege for it,
as must the DEFINER
account if the routine
executes in definer security context.
The DEFINER
clause specifies the MySQL account
to be used when checking access privileges at routine execution
time for routines that have the SQL SECURITY
DEFINER
characteristic.
If a user
value is given for the
DEFINER
clause, it should be a MySQL account
specified as
'
(the same format used in the user_name
'@'host_name
'GRANT
statement), CURRENT_USER
, or
CURRENT_USER()
. The default
DEFINER
value is the user who executes the
CREATE PROCEDURE
or
CREATE FUNCTION
or statement. This
is the same as specifying DEFINER =
CURRENT_USER
explicitly.
If you specify the DEFINER
clause, these rules
determine the legal DEFINER
user values:
If you do not have the
SUPER
privilege, the only legaluser
value is your own account, either specified literally or by usingCURRENT_USER
. You cannot set the definer to some other account.If you have the
SUPER
privilege, you can specify any syntactically legal account name. If the account does not actually exist, a warning is generated.Although it is possible to create a routine with a nonexistent
DEFINER
account, an error occurs at routine execution time if theSQL SECURITY
value isDEFINER
but the definer account does not exist.
For more information about stored routine security, see Section 18.6, “Access Control for Stored Programs and Views”.
Within a stored routine that is defined with the SQL
SECURITY DEFINER
characteristic,
CURRENT_USER
returns the routine's
DEFINER
value. For information about user
auditing within stored routines, see
Section 5.5.10, “Auditing MySQL Account Activity”.
Consider the following procedure, which displays a count of the
number of MySQL accounts listed in the
mysql.user
table:
CREATE DEFINER = 'admin'@'localhost' PROCEDURE account_count() BEGIN SELECT 'Number of accounts:', COUNT(*) FROM mysql.user; END;
The procedure is assigned a DEFINER
account of
'admin'@'localhost'
no matter which user
defines it. It executes with the privileges of that account no
matter which user invokes it (because the default security
characteristic is DEFINER
). The procedure
succeeds or fails depending on whether invoker has the
EXECUTE
privilege for it and
'admin'@'localhost'
has the
SELECT
privilege for the
mysql.user
table.
Now suppose that the procedure is defined with the SQL
SECURITY INVOKER
characteristic:
CREATE DEFINER = 'admin'@'localhost' PROCEDURE account_count() SQL SECURITY INVOKER BEGIN SELECT 'Number of accounts:', COUNT(*) FROM mysql.user; END;
The procedure still has a DEFINER
of
'admin'@'localhost'
, but in this case, it
executes with the privileges of the invoking user. Thus, the
procedure succeeds or fails depending on whether the invoker has
the EXECUTE
privilege for it and
the SELECT
privilege for the
mysql.user
table.
The server handles the data type of a routine parameter, local
routine variable created with
DECLARE
, or function return value
as follows:
Assignments are checked for data type mismatches and overflow. Conversion and overflow problems result in warnings, or errors in strict SQL mode.
Only scalar values can be assigned. For example, a statement such as
SET x = (SELECT 1, 2)
is invalid.For character data types, if there is a
CHARACTER SET
attribute in the declaration, the specified character set and its default collation is used. If theCOLLATE
attribute is also present, that collation is used rather than the default collation. If there is noCHARACTER SET
attribute, the database character set and collation in effect at routine creation time are used. (The database character set and collation are given by the value of thecharacter_set_database
andcollation_database
system variables.)Prior to MySQL 5.5.3, if there is a
CHARACTER SET
attribute in the declaration, theCOLLATE
attribute is not supported, and the character set's default collation is used. (This includes use ofBINARY
, which in this context specifies the binary collation of the character set.) If there is noCHARACTER SET
attribute, the database character set and its default collation (rather than the database collation) are used.If you change the database default character set or collation, stored routines that use the database defaults must be dropped and recreated so that they use the new defaults.
CREATE SERVERserver_name
FOREIGN DATA WRAPPERwrapper_name
OPTIONS (option
[,option
] ...)option
: { HOSTcharacter-literal
| DATABASEcharacter-literal
| USERcharacter-literal
| PASSWORDcharacter-literal
| SOCKETcharacter-literal
| OWNERcharacter-literal
| PORTnumeric-literal
}
This statement creates the definition of a server for use with the
FEDERATED
storage engine. The
CREATE SERVER
statement creates a
new row within the servers
table within the
mysql
database. This statement requires the
SUPER
privilege.
The
should be a unique reference to the server. Server definitions are
global within the scope of the server, it is not possible to
qualify the server definition to a specific database.
server_name
has a
maximum length of 64 characters (names longer than 64 characters
are silently truncated), and is case insensitive. You may specify
the name as a quoted string.
server_name
The
should be wrapper_name
mysql
, and may be quoted with single
quotation marks. Other values for
are not
currently supported.
wrapper_name
For each
you
must specify either a character literal or numeric literal.
Character literals are UTF-8, support a maximum length of 64
characters and default to a blank (empty) string. String literals
are silently truncated to 64 characters. Numeric literals must be
a number between 0 and 9999, default value is 0.
option
Note that the OWNER
option is currently not
applied, and has no effect on the ownership or operation of the
server connection that is created.
The CREATE SERVER
statement creates
an entry in the mysql.servers
table that can
later be used with the CREATE TABLE
statement when creating a FEDERATED
table. The
options that you specify will be used to populate the columns in
the mysql.servers
table. The table columns are
Server_name
, Host
,
Db
, Username
,
Password
, Port
and
Socket
.
For example:
CREATE SERVER s FOREIGN DATA WRAPPER mysql OPTIONS (USER 'Remote', HOST '192.168.1.106', DATABASE 'test');
The data stored in the table can be used when creating a
connection to a FEDERATED
table:
CREATE TABLE t (s1 INT) ENGINE=FEDERATED CONNECTION='s';
For more information, see
Section 13.11, “The FEDERATED
Storage Engine”.
CREATE SERVER
does not cause an
automatic commit.
CREATE [TEMPORARY] TABLE [IF NOT EXISTS]tbl_name
(create_definition
,...) [table_options
] [partition_options
]
Or:
CREATE [TEMPORARY] TABLE [IF NOT EXISTS]tbl_name
[(create_definition
,...)] [table_options
] [partition_options
]select_statement
Or:
CREATE [TEMPORARY] TABLE [IF NOT EXISTS]tbl_name
{ LIKEold_tbl_name
| (LIKEold_tbl_name
) }
create_definition
:col_name
column_definition
| [CONSTRAINT [symbol
]] PRIMARY KEY [index_type
] (index_col_name
,...) [index_option
] ... | {INDEX|KEY} [index_name
] [index_type
] (index_col_name
,...) [index_option
] ... | [CONSTRAINT [symbol
]] UNIQUE [INDEX|KEY] [index_name
] [index_type
] (index_col_name
,...) [index_option
] ... | {FULLTEXT|SPATIAL} [INDEX|KEY] [index_name
] (index_col_name
,...) [index_option
] ... | [CONSTRAINT [symbol
]] FOREIGN KEY [index_name
] (index_col_name
,...)reference_definition
| CHECK (expr
)column_definition
:data_type
[NOT NULL | NULL] [DEFAULTdefault_value
] [AUTO_INCREMENT] [UNIQUE [KEY] | [PRIMARY] KEY] [COMMENT 'string
'] [COLUMN_FORMAT {FIXED|DYNAMIC|DEFAULT}] [STORAGE {DISK|MEMORY|DEFAULT}] [reference_definition
]data_type
: BIT[(length
)] | TINYINT[(length
)] [UNSIGNED] [ZEROFILL] | SMALLINT[(length
)] [UNSIGNED] [ZEROFILL] | MEDIUMINT[(length
)] [UNSIGNED] [ZEROFILL] | INT[(length
)] [UNSIGNED] [ZEROFILL] | INTEGER[(length
)] [UNSIGNED] [ZEROFILL] | BIGINT[(length
)] [UNSIGNED] [ZEROFILL] | REAL[(length
,decimals
)] [UNSIGNED] [ZEROFILL] | DOUBLE[(length
,decimals
)] [UNSIGNED] [ZEROFILL] | FLOAT[(length
,decimals
)] [UNSIGNED] [ZEROFILL] | DECIMAL[(length
[,decimals
])] [UNSIGNED] [ZEROFILL] | NUMERIC[(length
[,decimals
])] [UNSIGNED] [ZEROFILL] | DATE | TIME | TIMESTAMP | DATETIME | YEAR | CHAR[(length
)] [CHARACTER SETcharset_name
] [COLLATEcollation_name
] | VARCHAR(length
) [CHARACTER SETcharset_name
] [COLLATEcollation_name
] | BINARY[(length
)] | VARBINARY(length
) | TINYBLOB | BLOB | MEDIUMBLOB | LONGBLOB | TINYTEXT [BINARY] [CHARACTER SETcharset_name
] [COLLATEcollation_name
] | TEXT [BINARY] [CHARACTER SETcharset_name
] [COLLATEcollation_name
] | MEDIUMTEXT [BINARY] [CHARACTER SETcharset_name
] [COLLATEcollation_name
] | LONGTEXT [BINARY] [CHARACTER SETcharset_name
] [COLLATEcollation_name
] | ENUM(value1
,value2
,value3
,...) [CHARACTER SETcharset_name
] [COLLATEcollation_name
] | SET(value1
,value2
,value3
,...) [CHARACTER SETcharset_name
] [COLLATEcollation_name
] |spatial_type
index_col_name
:col_name
[(length
)] [ASC | DESC]index_type
: USING {BTREE | HASH}index_option
: KEY_BLOCK_SIZE [=]value
|index_type
| WITH PARSERparser_name
| COMMENT 'string
'reference_definition
: REFERENCEStbl_name
(index_col_name
,...) [MATCH FULL | MATCH PARTIAL | MATCH SIMPLE] [ON DELETEreference_option
] [ON UPDATEreference_option
]reference_option
: RESTRICT | CASCADE | SET NULL | NO ACTIONtable_options
:table_option
[[,]table_option
] ...table_option
: ENGINE [=]engine_name
| AUTO_INCREMENT [=]value
| AVG_ROW_LENGTH [=]value
| [DEFAULT] CHARACTER SET [=]charset_name
| CHECKSUM [=] {0 | 1} | [DEFAULT] COLLATE [=]collation_name
| COMMENT [=] 'string
' | CONNECTION [=] 'connect_string
' | DATA DIRECTORY [=] 'absolute path to directory
' | DELAY_KEY_WRITE [=] {0 | 1} | INDEX DIRECTORY [=] 'absolute path to directory
' | INSERT_METHOD [=] { NO | FIRST | LAST } | KEY_BLOCK_SIZE [=]value
| MAX_ROWS [=]value
| MIN_ROWS [=]value
| PACK_KEYS [=] {0 | 1 | DEFAULT} | PASSWORD [=] 'string
' | ROW_FORMAT [=] {DEFAULT|DYNAMIC|FIXED|COMPRESSED|REDUNDANT|COMPACT} | TABLESPACEtablespace_name
[STORAGE {DISK|MEMORY|DEFAULT}] | UNION [=] (tbl_name
[,tbl_name
]...)partition_options
: PARTITION BY { [LINEAR] HASH(expr
) | [LINEAR] KEY(column_list
) | RANGE{(expr
) | COLUMNS(column_list
)} | LIST{(expr
) | COLUMNS(column_list
)} } [PARTITIONSnum
] [SUBPARTITION BY { [LINEAR] HASH(expr
) | [LINEAR] KEY(column_list
) } [SUBPARTITIONSnum
] ] [(partition_definition
[,partition_definition
] ...)]partition_definition
: PARTITIONpartition_name
[VALUES {LESS THAN {(expr
|value_list
) |MAXVALUE
} | IN (value_list
)}] [[STORAGE] ENGINE [=]engine_name
] [COMMENT [=]'comment_text'
] [DATA DIRECTORY [=] ''] [INDEX DIRECTORY [=] '
data_dir
'] [MAX_ROWS [=]
index_dir
max_number_of_rows
] [MIN_ROWS [=]min_number_of_rows
] [TABLESPACE [=]tablespace_name
] [NODEGROUP [=]node_group_id
] [(subpartition_definition
[,subpartition_definition
] ...)]subpartition_definition
: SUBPARTITIONlogical_name
[[STORAGE] ENGINE [=]engine_name
] [COMMENT [=]'comment_text'
] [DATA DIRECTORY [=] ''] [INDEX DIRECTORY [=] '
data_dir
'] [MAX_ROWS [=]
index_dir
max_number_of_rows
] [MIN_ROWS [=]min_number_of_rows
] [TABLESPACE [=]tablespace_name
] [NODEGROUP [=]node_group_id
]select_statement:
[IGNORE | REPLACE] [AS] SELECT ... (Some legal select statement
)
CREATE TABLE
creates a table with
the given name. You must have the
CREATE
privilege for the table.
Rules for permissible table names are given in
Section 8.2, “Schema Object Names”. By default, the table is created in
the default database, using the
InnoDB
storage engine. An error
occurs if the table exists, if there is no default database, or if
the database does not exist.
The table name can be specified as
db_name.tbl_name
to create the table in
a specific database. This works regardless of whether there is a
default database, assuming that the database exists. If you use
quoted identifiers, quote the database and table names separately.
For example, write `mydb`.`mytbl`
, not
`mydb.mytbl`
.
You can use the TEMPORARY
keyword when creating
a table. A TEMPORARY
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-TEMPORARY
table of the same name. (The existing table is hidden until the
temporary table is dropped.) To create temporary tables, you must
have the CREATE TEMPORARY TABLES
privilege.
CREATE TABLE
does not
automatically commit the current active transaction if you use
the TEMPORARY
keyword.
The keywords IF NOT EXISTS
prevent an error
from occurring if the table exists. However, there is no
verification that the existing table has a structure identical to
that indicated by the CREATE TABLE
statement.
MySQL represents each table by an .frm
table
format (definition) file in the database directory. The storage
engine for the table might create other files as well. In the case
of MyISAM
tables, the storage engine creates
data and index files. Thus, for each MyISAM
table tbl_name
, there are three disk
files.
File | Purpose |
---|---|
| Table format (definition) file |
| Data file |
| Index file |
Глава 13, Storage Engines, describes what files each storage engine creates to represent tables. If a table name contains special characters, the names for the table files contain encoded versions of those characters as described in Section 8.2.3, “Mapping of Identifiers to File Names”.
data_type
represents the data type in a
column definition. spatial_type
represents a spatial data type. The data type syntax shown is
representative only. For a full description of the syntax
available for specifying column data types, as well as information
about the properties of each type, see
Глава 10, Data Types, and
Section 11.17, “Spatial Extensions”.
Some attributes do not apply to all data types.
AUTO_INCREMENT
applies only to integer and
floating-point types. DEFAULT
does not apply to
the BLOB
or
TEXT
types.
If neither
NULL
norNOT NULL
is specified, the column is treated as thoughNULL
had been specified.An integer or floating-point column can have the additional attribute
AUTO_INCREMENT
. When you insert a value ofNULL
(recommended) or0
into an indexedAUTO_INCREMENT
column, the column is set to the next sequence value. Typically this is
, wherevalue
+1value
is the largest value for the column currently in the table.AUTO_INCREMENT
sequences begin with1
.To retrieve an
AUTO_INCREMENT
value after inserting a row, use theLAST_INSERT_ID()
SQL function or themysql_insert_id()
C API function. See Section 11.14, “Information Functions”, and Section 21.9.3.37, “mysql_insert_id()
”.If the
NO_AUTO_VALUE_ON_ZERO
SQL mode is enabled, you can store0
inAUTO_INCREMENT
columns as0
without generating a new sequence value. See Section 5.1.6, “Server SQL Modes”.ЗамечаниеThere can be only one
AUTO_INCREMENT
column per table, it must be indexed, and it cannot have aDEFAULT
value. AnAUTO_INCREMENT
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 do not accidentally get anAUTO_INCREMENT
column that contains0
.For
MyISAM
tables, you can specify anAUTO_INCREMENT
secondary column in a multiple-column key. See Section 3.6.9, “UsingAUTO_INCREMENT
”.To make MySQL compatible with some ODBC applications, you can find the
AUTO_INCREMENT
value for the last inserted row with the following query:SELECT * FROM
tbl_name
WHEREauto_col
IS NULLFor information about
InnoDB
andAUTO_INCREMENT
, see Section 13.3.5.3, “AUTO_INCREMENT
Handling inInnoDB
”. For information aboutAUTO_INCREMENT
and MySQL Replication, see Section 15.4.1.1, “Replication andAUTO_INCREMENT
”.Character data types (
CHAR
,VARCHAR
,TEXT
) can includeCHARACTER SET
andCOLLATE
attributes to specify the character set and collation for the column. For details, see Section 9.1, “Character Set Support”.CHARSET
is a synonym forCHARACTER SET
. Пример:CREATE TABLE t (c CHAR(20) CHARACTER SET utf8 COLLATE utf8_bin);
MySQL 5.5 interprets length specifications in character column definitions in characters. (Versions before MySQL 4.1 interpreted them in bytes.) Lengths for
BINARY
andVARBINARY
are in bytes.The
DEFAULT
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 asNOW()
orCURRENT_DATE
. The exception is that you can specifyCURRENT_TIMESTAMP
as the default for aTIMESTAMP
column. See Section 10.3.1.1, “TIMESTAMP
Properties”.If a column definition includes no explicit
DEFAULT
value, MySQL determines the default value as described in Section 10.1.4, “Data Type Default Values”.BLOB
andTEXT
columns cannot be assigned a default value.CREATE TABLE
fails if a date-valued default is not correct according to theNO_ZERO_IN_DATE
SQL mode, even if strict SQL mode is not enabled. For example,c1 DATE DEFAULT '2010-00-00'
causesCREATE TABLE
to fail withInvalid default value for 'c1'
.A comment for a column can be specified with the
COMMENT
option, up to 1024 characters long (255 characters before MySQL 5.5.3). The comment is displayed by theSHOW CREATE TABLE
andSHOW FULL COLUMNS
statements.In MySQL Cluster, it is also possible to specify a data storage format for individual columns of
NDB
tables usingCOLUMN_FORMAT
. Permissible column formats areFIXED
,DYNAMIC
, andDEFAULT
.FIXED
is used to specify fixed-width storage,DYNAMIC
permits the column to be variable-width, andDEFAULT
causes the column to use fixed-width or variable-width storage as determined by the column's data type (possibly overridden by aROW_FORMAT
specifier).For
NDB
tables, the default value forCOLUMN_FORMAT
isDEFAULT
.COLUMN_FORMAT
currently has no effect on columns of tables using storage engines other thanNDB
. TheCOLUMN_FORMAT
keyword is supported only in the build of mysqld that is supplied with MySQL Cluster; it is not recognized in any other version of MySQL, where attempting to useCOLUMN_FORMAT
causes a syntax error.For
NDB
tables, it is also possible to specify whether the column is stored on disk or in memory by using aSTORAGE
clause.STORAGE DISK
causes the column to be stored on disk, andSTORAGE MEMORY
causes in-memory storage to be used. TheCREATE TABLE
statement used must still include aTABLESPACE
clause:mysql>
CREATE TABLE t1 (
->c1 INT STORAGE DISK,
->c2 INT STORAGE MEMORY
->) ENGINE NDB;
ERROR 1005 (HY000): Can't create table 'c.t1' (errno: 140) mysql>CREATE TABLE t1 (
->c1 INT STORAGE DISK,
->c2 INT STORAGE MEMORY
->) TABLESPACE ts_1 ENGINE NDB;
Query OK, 0 rows affected (1.06 sec)For
NDB
tables,STORAGE DEFAULT
is equivalent toSTORAGE MEMORY
.The
STORAGE
clause has no effect on tables using storage engines other thanNDB
. TheSTORAGE
keyword is supported only in the build of mysqld that is supplied with MySQL Cluster; it is not recognized in any other version of MySQL, where any attempt to use theSTORAGE
keyword causes a syntax error.KEY
is normally a synonym forINDEX
. The key attributePRIMARY KEY
can also be specified as justKEY
when given in a column definition. This was implemented for compatibility with other database systems.A
UNIQUE
index creates a constraint such that all values in the index must be distinct. An error occurs if you try to add a new row with a key value that matches an existing row. For all engines, aUNIQUE
index permits multipleNULL
values for columns that can containNULL
.A
PRIMARY KEY
is a unique index where all key columns must be defined asNOT NULL
. If they are not explicitly declared asNOT NULL
, MySQL declares them so implicitly (and silently). A table can have only onePRIMARY KEY
. The name of aPRIMARY KEY
is alwaysPRIMARY
, which thus cannot be used as the name for any other kind of index.If you do not have a
PRIMARY KEY
and an application asks for thePRIMARY KEY
in your tables, MySQL returns the firstUNIQUE
index that has noNULL
columns as thePRIMARY KEY
.In
InnoDB
tables, keep thePRIMARY KEY
short to minimize storage overhead for secondary indexes. Each secondary index entry contains a copy of the primary key columns for the corresponding row. (See Section 13.3.11, “InnoDB
Table and Index Structures”.)In the created table, a
PRIMARY KEY
is placed first, followed by allUNIQUE
indexes, and then the nonunique indexes. This helps the MySQL optimizer to prioritize which index to use and also more quickly to detect duplicatedUNIQUE
keys.A
PRIMARY KEY
can be a multiple-column index. However, you cannot create a multiple-column index using thePRIMARY KEY
key attribute in a column specification. Doing so only marks that single column as primary. You must use a separatePRIMARY KEY(
clause.index_col_name
, ...)If a
PRIMARY KEY
orUNIQUE
index consists of only one column that has an integer type, you can also refer to the column as_rowid
inSELECT
statements.In MySQL, the name of a
PRIMARY KEY
isPRIMARY
. For other indexes, if you do not assign a name, the index is assigned the same name as the first indexed column, with an optional suffix (_2
,_3
,...
) to make it unique. You can see index names for a table usingSHOW INDEX FROM
. See Section 12.7.5.23, “tbl_name
SHOW INDEX
Синтаксис”.Some storage engines permit you to specify an index type when creating an index. The syntax for the
index_type
specifier isUSING
.type_name
Пример:
CREATE TABLE lookup (id INT, INDEX USING BTREE (id)) ENGINE = MEMORY;
The preferred position for
USING
is after the index column list. It can be given before the column list, but support for use of the option in that position is deprecated and will be removed in a future MySQL release.index_option
values specify additional options for an index.USING
is one such option. For details about permissibleindex_option
values, see Section 12.1.13, “CREATE INDEX
Синтаксис”.For more information about indexes, see Section 7.3.1, “How MySQL Uses Indexes”.
In MySQL 5.5, only the
MyISAM
,InnoDB
, andMEMORY
storage engines support indexes on columns that can haveNULL
values. In other cases, you must declare indexed columns asNOT NULL
or an error results.For
CHAR
,VARCHAR
,BINARY
, andVARBINARY
columns, indexes can be created that use only the leading part of column values, using
syntax to specify an index prefix length.col_name
(length
)BLOB
andTEXT
columns also can be indexed, but a prefix length must be given. Prefix lengths are given in characters for nonbinary string types and in bytes for binary string types. That is, index entries consist of the firstlength
characters of each column value forCHAR
,VARCHAR
, andTEXT
columns, and the firstlength
bytes of each column value forBINARY
,VARBINARY
, andBLOB
columns. Indexing only a prefix of column values like this can make the index file much smaller. See Section 7.3.4, “Column Indexes”.Only the
MyISAM
andInnoDB
storage engines support indexing onBLOB
andTEXT
columns. For example:CREATE TABLE test (blob_col BLOB, INDEX(blob_col(10)));
Prefixes can be up to 1000 bytes long (767 bytes for
InnoDB
tables). Note that prefix limits are measured in bytes, whereas the prefix length inCREATE TABLE
statements is interpreted as number of characters for nonbinary data types (CHAR
,VARCHAR
,TEXT
). Take this into account when specifying a prefix length for a column that uses a multi-byte character set.An
index_col_name
specification can end withASC
orDESC
. These keywords are permitted 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.When you use
ORDER BY
orGROUP BY
on aTEXT
orBLOB
column in aSELECT
, the server sorts values using only the initial number of bytes indicated by themax_sort_length
system variable. See Section 10.4.3, “TheBLOB
andTEXT
Types”.You can create special
FULLTEXT
indexes, which are used for full-text searches. Only theMyISAM
storage engine supportsFULLTEXT
indexes. They can be created only fromCHAR
,VARCHAR
, andTEXT
columns. Indexing always happens over the entire column; column prefix indexing is not supported and any prefix length is ignored if specified. See Section 11.9, “Full-Text Search Functions”, for details of operation. AWITH PARSER
clause can be specified as anindex_option
value to associate a parser plugin with the index if full-text indexing and searching operations need special handling. This clause is legal only forFULLTEXT
indexes. See Section 22.2, “The MySQL Plugin API”, for details on creating plugins.You can create
SPATIAL
indexes on spatial data types. Spatial types are supported only forMyISAM
tables and indexed columns must be declared asNOT NULL
. See Section 11.17, “Spatial Extensions”.As of MySQL 5.5.3, index definitions can include an optional comment of up to 1024 characters.
InnoDB
tables support checking of foreign key constraints. See Section 13.3, “TheInnoDB
Storage Engine”. Note that theFOREIGN KEY
syntax inInnoDB
is more restrictive than the syntax presented for theCREATE TABLE
statement at the beginning of this section: The columns of the referenced table must always be explicitly named.InnoDB
supports bothON DELETE
andON UPDATE
actions on foreign keys. For the precise syntax, see Section 13.3.5.4, “FOREIGN KEY
Constraints”.For other storage engines, MySQL Server parses and ignores the
FOREIGN KEY
andREFERENCES
syntax inCREATE TABLE
statements. TheCHECK
clause is parsed but ignored by all storage engines. See Section 1.8.5.4, “Foreign Key Differences”.ImportantFor users familiar with the ANSI/ISO SQL Standard, please note that no storage engine, including
InnoDB
, recognizes or enforces theMATCH
clause used in referential integrity constraint definitions. Use of an explicitMATCH
clause will not have the specified effect, and also causesON DELETE
andON UPDATE
clauses to be ignored. For these reasons, specifyingMATCH
should be avoided.The
MATCH
clause in the SQL standard controls howNULL
values in a composite (multiple-column) foreign key are handled when comparing to a primary key.InnoDB
essentially implements the semantics defined byMATCH SIMPLE
, which permit a foreign key to be all or partiallyNULL
. In that case, the (child table) row containing such a foreign key is permitted to be inserted, and does not match any row in the referenced (parent) table. It is possible to implement other semantics using triggers.Additionally, MySQL and
InnoDB
require that the referenced columns be indexed for performance. However, the system does not enforce a requirement that the referenced columns beUNIQUE
or be declaredNOT NULL
. The handling of foreign key references to nonunique keys or keys that containNULL
values is not well defined for operations such asUPDATE
orDELETE CASCADE
. You are advised to use foreign keys that reference onlyUNIQUE
andNOT NULL
keys.Furthermore,
InnoDB
does not recognize or support “inlineREFERENCES
specifications” (as defined in the SQL standard) where the references are defined as part of the column specification.InnoDB
acceptsREFERENCES
clauses only when specified as part of a separateFOREIGN KEY
specification. For other storage engines, MySQL Server parses and ignores foreign key specifications.ЗамечаниеPartitioned tables do not support foreign keys. See Section 17.5, “Restrictions and Limitations on Partitioning”, for more information.
There is a hard limit of 4096 columns per table, but the effective maximum may be less for a given table and depends on the factors discussed in Section E.10.4, “Table Column-Count and Row-Size Limits”.
The TABLESPACE
and STORAGE
table options are employed only with
NDBCLUSTER
tables. The tablespace
named tablespace_name
must already have
been created using CREATE
TABLESPACE
. STORAGE
determines the
type of storage used (disk or memory), and can be one of
DISK
, MEMORY
, or
DEFAULT
.
TABLESPACE ... STORAGE DISK
assigns a table to
a MySQL Cluster Disk Data tablespace. See
Section 16.5.11, “MySQL Cluster Disk Data Tables”, for more information.
A STORAGE
clause cannot be used in a
CREATE TABLE
statement without a
TABLESPACE
clause.
The ENGINE
table option specifies the storage
engine for the table.
The ENGINE
table option takes the storage
engine names shown in the following table.
Storage Engine | Описание |
---|---|
InnoDB | Transaction-safe tables with row locking and foreign keys. The default
storage engine for new tables. See
Section 13.3, “The InnoDB Storage Engine”, and in particular
Section 13.3.1, “InnoDB as the Default MySQL Storage Engine” if you have MySQL
experience but are new to InnoDB . |
MyISAM | The binary portable storage engine that is primarily used for read-only
or read-mostly workloads. See
Section 13.5, “The MyISAM Storage Engine”. |
MEMORY | The data for this storage engine is stored only in memory. See
Section 13.6, “The MEMORY Storage Engine”. |
CSV | Tables that store rows in comma-separated values format. See
Section 13.7, “The CSV Storage Engine”. |
ARCHIVE | The archiving storage engine. See
Section 13.8, “The ARCHIVE Storage Engine”. |
EXAMPLE | An example engine. See Section 13.12, “The EXAMPLE Storage Engine”. |
FEDERATED | Storage engine that accesses remote tables. See
Section 13.11, “The FEDERATED Storage Engine”. |
HEAP | This is a synonym for MEMORY . |
MERGE | A collection of MyISAM tables used as one table. Also
known as MRG_MyISAM . See
Section 13.10, “The MERGE Storage Engine”. |
ISAM (OBSOLETE) | Not available in MySQL 5.5. If you are upgrading to MySQL
5.5 from a previous version, you should
convert any existing ISAM tables to
MyISAM before
performing the upgrade. |
NDBCLUSTER | Clustered, fault-tolerant, memory-based tables. Also known as
NDB . See
Глава 16, MySQL Cluster NDB 7.2. |
If a storage engine is specified that is not available, MySQL uses
the default engine instead. Normally, this is
MyISAM
. For example, if a table definition
includes the ENGINE=INNODB
option but the MySQL
server does not support INNODB
tables, the
table is created as a MyISAM
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 nontransactional (to get more speed). In MySQL
5.5, a warning occurs if the storage engine
specification is not honored.
Engine substitution can be controlled by the setting of the
NO_ENGINE_SUBSTITUTION
SQL mode,
as described in Section 5.1.6, “Server SQL Modes”.
The older TYPE
option was synonymous with
ENGINE
. TYPE
was
deprecated in MySQL 4.0 and removed in MySQL 5.5. When
upgrading to MySQL 5.5 or later, you must convert existing
applications that rely on TYPE
to use
ENGINE
instead.
The other table options are used to optimize the behavior of the
table. In most cases, you do not have to specify any of them.
These options apply to all storage engines unless otherwise
indicated. Options that do not apply to a given storage engine may
be accepted and remembered as part of the table definition. Such
options then apply if you later use ALTER
TABLE
to convert the table to use a different storage
engine.
AUTO_INCREMENT
The initial
AUTO_INCREMENT
value for the table. In MySQL 5.5, this works forMyISAM
,MEMORY
,InnoDB
, andARCHIVE
tables. To set the first auto-increment value for engines that do not support theAUTO_INCREMENT
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.For engines that support the
AUTO_INCREMENT
table option inCREATE TABLE
statements, you can also useALTER TABLE
to reset thetbl_name
AUTO_INCREMENT =N
AUTO_INCREMENT
value. The value cannot be set lower than the maximum value currently in the column.AVG_ROW_LENGTH
An approximation of the average row length for your table. You need to set this only for large tables with variable-size rows.
When you create a
MyISAM
table, MySQL uses the product of theMAX_ROWS
andAVG_ROW_LENGTH
options to decide how big the resulting table is. If you don't specify either option, the maximum size forMyISAM
data and index files is 256TB by default. (If your operating system does not support files that large, table sizes are constrained by the file size limit.) If you want to keep down the pointer sizes to make the index smaller and faster and you don't really need big files, you can decrease the default pointer size by setting themyisam_data_pointer_size
system variable. (See Section 5.1.3, “Server System Variables”.) If you want all your tables to be able to grow above the default limit and are willing to have your tables slightly slower and larger than necessary, you can increase the default pointer size by setting this variable. Setting the value to 7 permits table sizes up to 65,536TB.[DEFAULT] CHARACTER SET
Specify a default character set for the table.
CHARSET
is a synonym forCHARACTER SET
. If the character set name isDEFAULT
, the database character set is used.CHECKSUM
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
CHECKSUM TABLE
statement reports the checksum. (MyISAM
only.)[DEFAULT] COLLATE
Specify a default collation for the table.
COMMENT
A comment for the table, up to 2048 characters long (60 characters before MySQL 5.5.3).
CONNECTION
The connection string for a
FEDERATED
table.ЗамечаниеOlder versions of MySQL used a
COMMENT
option for the connection string.DATA DIRECTORY
,INDEX DIRECTORY
By using
DATA DIRECTORY='
ordirectory
'INDEX DIRECTORY='
you can specify where thedirectory
'MyISAM
storage engine should put a table's data file and index file. The directory must be the full path name to the directory, not a relative path.ImportantTable-level
DATA DIRECTORY
andINDEX DIRECTORY
options are ignored for partitioned tables. (Bug #32091)These options work only when you are not using the
--skip-symbolic-links
option. Your operating system must also have a working, thread-saferealpath()
call. See Section 7.11.3.1.2, “Using Symbolic Links for Tables on Unix”, for more complete information.If a
MyISAM
table is created with noDATA DIRECTORY
option, the.MYD
file is created in the database directory. By default, ifMyISAM
finds an existing.MYD
file in this case, it overwrites it. The same applies to.MYI
files for tables created with noINDEX DIRECTORY
option. To suppress this behavior, start the server with the--keep_files_on_create
option, in which caseMyISAM
will not overwrite existing files and returns an error instead.If a
MyISAM
table is created with aDATA DIRECTORY
orINDEX DIRECTORY
option and an existing.MYD
or.MYI
file is found, MyISAM always returns an error. It will not overwrite a file in the specified directory.ImportantYou cannot use path names that contain the MySQL data directory with
DATA DIRECTORY
orINDEX DIRECTORY
. This includes partitioned tables and individual table partitions. (See Bug #32167.)DELAY_KEY_WRITE
Set this to 1 if you want to delay key updates for the table until the table is closed. See the description of the
delay_key_write
system variable in Section 5.1.3, “Server System Variables”. (MyISAM
only.)INSERT_METHOD
If you want to insert data into a
MERGE
table, you must specify withINSERT_METHOD
the table into which the row should be inserted.INSERT_METHOD
is an option useful forMERGE
tables only. Use a value ofFIRST
orLAST
to have inserts go to the first or last table, or a value ofNO
to prevent inserts. See Section 13.10, “TheMERGE
Storage Engine”.KEY_BLOCK_SIZE
This option provides a hint to the storage engine about the size in bytes to use for index key blocks. The engine is permitted to change the value if necessary. A value of 0 indicates that the default value should be used. Individual index definitions can specify a
KEY_BLOCK_SIZE
value of their own to override the table value.MAX_ROWS
The maximum number of rows you plan to store in the table. This is not a hard limit, but rather a hint to the storage engine that the table must be able to store at least this many rows.
The
NDB
storage engine treats this value as a maxmimum. If you plan to create very large MySQL Cluster tables (containing millions of rows), you should use this option to insure thatNDB
allocates sufficient number of index slots in the hash table used for storing hashes of the table's primary keys by settingMAX_ROWS = 2 *
, whererows
rows
is the number of rows that you expect to insert into the table.The maximum
MAX_ROWS
value is 4294967295; larger values are truncated to this limit.MIN_ROWS
The minimum number of rows you plan to store in the table. The
MEMORY
storage engine uses this option as a hint about memory use.PACK_KEYS
PACK_KEYS
takes effect only withMyISAM
tables. Set this option to 1 if you want to have smaller indexes. This usually makes updates slower and reads faster. Setting the option to 0 disables all packing of keys. Setting it toDEFAULT
tells the storage engine to pack only longCHAR
,VARCHAR
,BINARY
, orVARBINARY
columns.If you do not use
PACK_KEYS
, the default is to pack strings, but not numbers. If you usePACK_KEYS=1
, numbers are packed as well.When packing binary number keys, MySQL uses prefix compression:
Every key needs one extra byte to indicate how many bytes of the previous key are the same for the next key.
The pointer to the row is stored in high-byte-first order directly after the key, to improve compression.
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
storage_size_for_key + pointer_size
(where the pointer size is usually 4). Conversely, you get a significant benefit from prefix compression only if you have many numbers that are the same. If all keys are totally different, you use one byte more per key, if the key is not a key that can haveNULL
values. (In this case, the packed key length is stored in the same byte that is used to mark if a key isNULL
.)PASSWORD
This option is unused. If you have a need to scramble your
.frm
files and make them unusable to any other MySQL server, please contact our sales department.RAID_TYPE
RAID
support has been removed as of MySQL 5.0.ROW_FORMAT
Defines how the rows should be stored. For
MyISAM
tables, the option value can beFIXED
orDYNAMIC
for static or variable-length row format. myisampack sets the type toCOMPRESSED
. See Section 13.5.3, “MyISAM
Table Storage Formats”.For
InnoDB
tables, rows are stored in compact format (ROW_FORMAT=COMPACT
) by default. The noncompact format used in older versions of MySQL can still be requested by specifyingROW_FORMAT=REDUNDANT
.ЗамечаниеWhen executing a
CREATE TABLE
statement, if you specify a row format which is not supported by the storage engine that is used for the table, the table is created using that storage engine's default row format. The information reported in this column in response toSHOW TABLE STATUS
is the actual row format used. This may differ from the value in theCreate_options
column because the originalCREATE TABLE
definition is retained during creation.UNION
is used when you want to access a collection of identicalMyISAM
tables as one. This works only withMERGE
tables. See Section 13.10, “TheMERGE
Storage Engine”.You must have
SELECT
,UPDATE
, andDELETE
privileges for the tables you map to aMERGE
table.ЗамечаниеFormerly, all tables used had to be in the same database as the
MERGE
table itself. This restriction no longer applies.
partition_options
can be used to
control partitioning of the table created with
CREATE TABLE
.
Not all options shown in the syntax for
partition_options
at the beginning of
this section are available for all partitioning types. Please
see the listings for the following individual types for
information specific to each type, and see
Глава 17, Partitioning, for more complete information
about the workings of and uses for partitioning in MySQL, as
well as additional examples of table creation and other
statements relating to MySQL partitioning.
If used, a partition_options
clause
begins with PARTITION BY
. This clause contains
the function that is used to determine the partition; the function
returns an integer value ranging from 1 to
num
, where
num
is the number of partitions. (The
maximum number of user-defined partitions which a table may
contain is 1024; the number of subpartitions—discussed later
in this section—is included in this maximum.) The choices
that are available for this function in MySQL 5.5 are
shown in the following list:
HASH(
: Hashes one or more columns to create a key for placing and locating rows.expr
)expr
is an expression using one or more table columns. This can be any legal MySQL expression (including MySQL functions) that yields a single integer value. For example, these are both validCREATE TABLE
statements usingPARTITION BY HASH
:CREATE TABLE t1 (col1 INT, col2 CHAR(5)) PARTITION BY HASH(col1); CREATE TABLE t1 (col1 INT, col2 CHAR(5), col3 DATETIME) PARTITION BY HASH ( YEAR(col3) );
You may not use either
VALUES LESS THAN
orVALUES IN
clauses withPARTITION BY HASH
.PARTITION BY HASH
uses the remainder ofexpr
divided by the number of partitions (that is, the modulus). For examples and additional information, see Section 17.2.4, “HASH
Partitioning”.The
LINEAR
keyword entails a somewhat different algorithm. In this case, the number of the partition in which a row is stored is calculated as the result of one or more logicalAND
operations. For discussion and examples of linear hashing, see Section 17.2.4.1, “LINEAR HASH
Partitioning”.KEY(
: This is similar tocolumn_list
)HASH
, except that MySQL supplies the hashing function so as to guarantee an even data distribution. Thecolumn_list
argument is simply a list of table columns. This example shows a simple table partitioned by key, with 4 partitions:CREATE TABLE tk (col1 INT, col2 CHAR(5), col3 DATE) PARTITION BY KEY(col3) PARTITIONS 4;
For tables that are partitioned by key, you can employ linear partitioning by using the
LINEAR
keyword. This has the same effect as with tables that are partitioned byHASH
. That is, the partition number is found using the&
operator rather than the modulus (see Section 17.2.4.1, “LINEAR HASH
Partitioning”, and Section 17.2.5, “KEY
Partitioning”, for details). This example uses linear partitioning by key to distribute data between 5 partitions:CREATE TABLE tk (col1 INT, col2 CHAR(5), col3 DATE) PARTITION BY LINEAR KEY(col3) PARTITIONS 5;
You may not use either
VALUES LESS THAN
orVALUES IN
clauses withPARTITION BY KEY
.RANGE
: In this case,expr
shows a range of values using a set ofVALUES LESS THAN
operators. When using range partitioning, you must define at least one partition usingVALUES LESS THAN
. You cannot useVALUES IN
with range partitioning.When used with a table partitioned by
RANGE
,VALUES LESS THAN
must be used with either an integer literal value or an expression that evaluates to a single integer value. In MySQL 5.5, this limitation can be overcome in a table that is defined usingPARTITION BY RANGE COLUMNS
, as described later in this section.Suppose that you have a table that you wish to partition on a column containing year values, according to the following scheme.
Partition Number: Years Range: 0 1990 and earlier 1 1991 to 1994 2 1995 to 1998 3 1999 to 2002 4 2003 to 2005 5 2006 and later A table implementing such a partitioning scheme can be realized by the
CREATE TABLE
statement shown here:CREATE TABLE t1 ( year_col INT, some_data INT ) PARTITION BY RANGE (year_col) ( PARTITION p0 VALUES LESS THAN (1991), PARTITION p1 VALUES LESS THAN (1995), PARTITION p2 VALUES LESS THAN (1999), PARTITION p3 VALUES LESS THAN (2002), PARTITION p4 VALUES LESS THAN (2006), PARTITION p5 VALUES LESS THAN MAXVALUE );
PARTITION ... VALUES LESS THAN ...
statements work in a consecutive fashion.VALUES LESS THAN MAXVALUE
works to specify “leftover” values that are greater than the maximum value otherwise specified.Note that
VALUES LESS THAN
clauses work sequentially in a manner similar to that of thecase
portions of aswitch ... case
block (as found in many programming languages such as C, Java, and PHP). That is, the clauses must be arranged in such a way that the upper limit specified in each successiveVALUES LESS THAN
is greater than that of the previous one, with the one referencingMAXVALUE
coming last of all in the list.RANGE COLUMNS(
: This variant oncolumn_list
)RANGE
was introduced in MySQL 5.5.0 to facilitate partition pruning for queries using range conditions on multiple columns (that is, having conditions such asWHERE a = 1 AND b < 10
orWHERE a = 1 AND b = 10 AND c < 10
). It enables you to specify value ranges in multiple columns by using a list of columns in theCOLUMNS
clause and a set of column values in eachPARTITION ... VALUES LESS THAN (
partition definition clause. (In the simplest case, this set consists of a single column.) The maximum number of columns that can be referenced in thevalue_list
)column_list
andvalue_list
is 16.The
column_list
used in theCOLUMNS
clause may contain only names of columns; each column in the list must be one of the following MySQL data types: the integer types; the string types; and time or date column types. Columns usingBLOB
,TEXT
,SET
,ENUM
,BIT
, or spatial data types are not permitted; columns that use floating-point number types are also not permitted. You also may not use functions or arithmetic expressions in theCOLUMNS
clause.The
VALUES LESS THAN
clause used in a partition definition must specify a literal value for each column that appears in theCOLUMNS()
clause; that is, the list of values used for eachVALUES LESS THAN
clause must contain the same number of values as there are columns listed in theCOLUMNS
clause. An attempt to use more or fewer values in aVALUES LESS THAN
clause than there are in theCOLUMNS
clause causes the statement to fail with the error Inconsistency in usage of column lists for partitioning.... You cannot useNULL
for any value appearing inVALUES LESS THAN
. It is possible to useMAXVALUE
more than once for a given column other than the first, as shown in this example:CREATE TABLE rc ( a INT NOT NULL, b INT NOT NULL ) PARTITION BY RANGE COLUMNS(a,b) ( PARTITION p0 VALUES LESS THAN (10,5), PARTITION p1 VALUES LESS THAN (20,10), PARTITION p2 VALUES LESS THAN (MAXVALUE,15), PARTITION p3 VALUES LESS THAN (MAXVALUE,MAXVALUE) );
Each value used in a
VALUES LESS THAN
value list must match the type of the corresponding column exactly; no conversion is made. For example, you cannot use the string"1"
for a value that matches a column that uses an integer type (you must use the numeral1
instead), nor can you use the numeral1
for a value that matches a column that uses a string type (in such a case, you must use a quoted string:"1"
).For more information, see Section 17.2.1, “
RANGE
Partitioning”, and Section 17.4, “Partition Pruning”.LIST(
: This is useful when assigning partitions based on a table column with a restricted set of possible values, such as a state or country code. In such a case, all rows pertaining to a certain state or country can be assigned to a single partition, or a partition can be reserved for a certain set of states or countries. It is similar toexpr
)RANGE
, except that onlyVALUES IN
may be used to specify permissible values for each partition.VALUES IN
is used with a list of values to be matched. For instance, you could create a partitioning scheme such as the following:CREATE TABLE client_firms ( id INT, name VARCHAR(35) ) PARTITION BY LIST (id) ( PARTITION r0 VALUES IN (1, 5, 9, 13, 17, 21), PARTITION r1 VALUES IN (2, 6, 10, 14, 18, 22), PARTITION r2 VALUES IN (3, 7, 11, 15, 19, 23), PARTITION r3 VALUES IN (4, 8, 12, 16, 20, 24) );
When using list partitioning, you must define at least one partition using
VALUES IN
. You cannot useVALUES LESS THAN
withPARTITION BY LIST
.ЗамечаниеFor tables partitioned by
LIST
, the value list used withVALUES IN
must consist of integer values only. In MySQL 5.5, you can overcome this limitation using partitioning byLIST COLUMNS
, which is described later in this section.LIST COLUMNS(
: This variant oncolumn_list
)LIST
was introduced in MySQL 5.5.0 to facilitate partition pruning for queries using comparison conditions on multiple columns (that is, having conditions such asWHERE a = 5 AND b = 5
orWHERE a = 1 AND b = 10 AND c = 5
). It enables you to specify values in multiple columns by using a list of columns in theCOLUMNS
clause and a set of column values in eachPARTITION ... VALUES IN (
partition definition clause.value_list
)The rules governing regarding data types for the column list used in
LIST COLUMNS(
and the value list used in VALUES IN(column_list
)value_list
) are the as those for the column list used inRANGE COLUMNS(
and the value list used incolumn_list
)VALUES LESS THAN(
, respectively, except that in thevalue_list
)VALUES IN
clause,MAXVALUE
is not permitted, and you may useNULL
.There is one important difference between the list of values used for
VALUES IN
withPARTITION BY LIST COLUMNS
as opposed to when it is used withPARTITION BY LIST
. When used withPARTITION BY LIST COLUMNS
, each element in theVALUES IN
clause must be a set of column values; the number of values in each set must be the same as the number of columns used in the COLUMNS clause, and the data types of these values must match those of the columns (and occur in the same order). In the simplest case, the set consists of a single column. The maximum number of columns that can be used in thecolumn_list
and in the elements making up thevalue_list
is 16.The table defined by the following
CREATE TABLE
statement provides an example of a table usingLIST COLUMNS
partitioning:CREATE TABLE lc ( a INT NULL, b INT NULL ) PARTITION BY LIST COLUMNS(a,b) ( PARTITION p0 VALUES IN( (0,0), (NULL,NULL) ), PARTITION p1 VALUES IN( (0,1), (0,2), (0,3), (1,1), (1,2) ), PARTITION p2 VALUES IN( (1,0), (2,0), (2,1), (3,0), (3,1) ), PARTITION p3 VALUES IN( (1,3), (2,2), (2,3), (3,2), (3,3) ) );
The number of partitions may optionally be specified with a
PARTITIONS
clause, wherenum
num
is the number of partitions. If both this clause and anyPARTITION
clauses are used,num
must be equal to the total number of any partitions that are declared usingPARTITION
clauses.ЗамечаниеWhether or not you use a
PARTITIONS
clause in creating a table that is partitioned byRANGE
orLIST
, you must still include at least onePARTITION VALUES
clause in the table definition (see below).A partition may optionally be divided into a number of subpartitions. This can be indicated by using the optional
SUBPARTITION BY
clause. Subpartitioning may be done byHASH
orKEY
. Either of these may beLINEAR
. These work in the same way as previously described for the equivalent partitioning types. (It is not possible to subpartition byLIST
orRANGE
.)The number of subpartitions can be indicated using the
SUBPARTITIONS
keyword followed by an integer value.Rigorous checking of the value used in
PARTITIONS
orSUBPARTITIONS
clauses is applied and this value must adhere to the following rules:The value must be a positive, nonzero integer.
No leading zeros are permitted.
The value must be an integer literal, and cannot not be an expression. For example,
PARTITIONS 0.2E+01
is not permitted, even though0.2E+01
evaluates to2
. (Bug #15890)
The expression (expr
) used in a
PARTITION BY
clause cannot refer to any
columns not in the table being created; such references are
specifically not permitted and cause the statement to fail with
an error. (Bug #29444)
Each partition may be individually defined using a
partition_definition
clause. The
individual parts making up this clause are as follows:
PARTITION
: This specifies a logical name for the partition.partition_name
A
VALUES
clause: For range partitioning, each partition must include aVALUES LESS THAN
clause; for list partitioning, you must specify aVALUES IN
clause for each partition. This is used to determine which rows are to be stored in this partition. See the discussions of partitioning types in Глава 17, Partitioning, for syntax examples.An optional
COMMENT
clause may be used to specify a string that describes the partition. Пример:COMMENT = 'Data for the years previous to 1999'
DATA DIRECTORY
andINDEX DIRECTORY
may be used to indicate the directory where, respectively, the data and indexes for this partition are to be stored. Both the
and thedata_dir
must be absolute system path names. Пример:index_dir
CREATE TABLE th (id INT, name VARCHAR(30), adate DATE) PARTITION BY LIST(YEAR(adate)) ( PARTITION p1999 VALUES IN (1995, 1999, 2003) DATA DIRECTORY = '
/var/appdata/95/data
' INDEX DIRECTORY = '/var/appdata/95/idx
', PARTITION p2000 VALUES IN (1996, 2000, 2004) DATA DIRECTORY = '/var/appdata/96/data
' INDEX DIRECTORY = '/var/appdata/96/idx
', PARTITION p2001 VALUES IN (1997, 2001, 2005) DATA DIRECTORY = '/var/appdata/97/data
' INDEX DIRECTORY = '/var/appdata/97/idx
', PARTITION p2002 VALUES IN (1998, 2002, 2006) DATA DIRECTORY = '/var/appdata/98/data
' INDEX DIRECTORY = '/var/appdata/98/idx
' );DATA DIRECTORY
andINDEX DIRECTORY
behave in the same way as in theCREATE TABLE
statement'stable_option
clause as used forMyISAM
tables.One data directory and one index directory may be specified per partition. If left unspecified, the data and indexes are stored by default in the table's database directory.
On Windows, the
DATA DIRECTORY
andINDEX DIRECTORY
options are not supported for individual partitions or subpartitions. These options are ignored on Windows, except that a warning is generated. (Bug #30459)ЗамечаниеThe
DATA DIRECTORY
andINDEX DIRECTORY
options are ignored for creating partitioned tables ifNO_DIR_IN_CREATE
is in effect. (Bug #24633)MAX_ROWS
andMIN_ROWS
may be used to specify, respectively, the maximum and minimum number of rows to be stored in the partition. The values formax_number_of_rows
andmin_number_of_rows
must be positive integers. As with the table-level options with the same names, these act only as “suggestions” to the server and are not hard limits.The optional
TABLESPACE
clause may be used to designate a tablespace for the partition. Used for MySQL Cluster only.The partitioning handler accepts a
[STORAGE] ENGINE
option for bothPARTITION
andSUBPARTITION
. Currently, the only way in which this can be used is to set all partitions or all subpartitions to the same storage engine, and an attempt to set different storage engines for partitions or subpartitions in the same table will give rise to the error ERROR 1469 (HY000): The mix of handlers in the partitions is not permitted in this version of MySQL. We expect to lift this restriction on partitioning in a future MySQL release.The
NODEGROUP
option can be used to make this partition act as part of the node group identified bynode_group_id
. This option is applicable only to MySQL Cluster.The partition definition may optionally contain one or more
subpartition_definition
clauses. Each of these consists at a minimum of theSUBPARTITION
, wherename
name
is an identifier for the subpartition. Except for the replacement of thePARTITION
keyword withSUBPARTITION
, the syntax for a subpartition definition is identical to that for a partition definition.Subpartitioning must be done by
HASH
orKEY
, and can be done only onRANGE
orLIST
partitions. See Section 17.2.6, “Subpartitioning”.
Partitions can be modified, merged, added to tables, and dropped
from tables. For basic information about the MySQL statements to
accomplish these tasks, see Section 12.1.7, “ALTER TABLE
Синтаксис”. For
more detailed descriptions and examples, see
Section 17.3, “Partition Management”.
The original CREATE TABLE
statement, including all specifications and table options are
stored by MySQL when the table is created. The information is
retained so that if you change storage engines, collations or
other settings using an ALTER
TABLE
statement, the original table options specified
are retained. This enables you to change between
InnoDB
and MyISAM
table
types even though the row formats supported by the two engines
are different.
Because the text of the original statement is retained, but due
to the way that certain values and options may be silently
reconfigured (such as the ROW_FORMAT
), the
active table definition (accessible through
DESCRIBE
or with
SHOW TABLE STATUS
) and the table
creation string (accessible through SHOW
CREATE TABLE
) will report different values.
You can create one table from another by adding a
SELECT
statement at the end of the
CREATE TABLE
statement:
CREATE TABLEnew_tbl
SELECT * FROMorig_tbl
;
For more information, see Section 12.1.17.1, “CREATE TABLE ...
SELECT
Синтаксис”.
Use LIKE
to create an empty table based on the
definition of another table, including any column attributes and
indexes defined in the original table:
CREATE TABLEnew_tbl
LIKEorig_tbl
;
The copy is created using the same version of the table storage
format as the original table. The
SELECT
privilege is required on the
original table.
LIKE
works only for base tables, not for views.
Beginning with MySQL 5.5.3, you cannot execute CREATE
TABLE
or CREATE TABLE ... LIKE
while a LOCK TABLES
statement is
in effect.
Also as of MySQL 5.5.3,
CREATE TABLE ...
LIKE
makes the same checks as
CREATE TABLE
and does not just
copy the .frm
file. This means that if the
current SQL mode is different from the mode in effect when the
original table was created, the table definition might be
considered invalid for the new mode and the statement will fail.
CREATE TABLE ... LIKE
does not preserve any
DATA DIRECTORY
or INDEX
DIRECTORY
table options that were specified for the
original table, or any foreign key definitions.
If the original table is a TEMPORARY
table,
CREATE TABLE ... LIKE
does not preserve
TEMPORARY
. To create a
TEMPORARY
destination table, use
CREATE TEMPORARY TABLE ... LIKE
.
You can create one table from another by adding a
SELECT
statement at the end of
the CREATE TABLE
statement:
CREATE TABLEnew_tbl
SELECT * FROMorig_tbl
;
MySQL creates new columns for all elements in the
SELECT
. For example:
mysql>CREATE TABLE test (a INT NOT NULL AUTO_INCREMENT,
->PRIMARY KEY (a), KEY(b))
->ENGINE=MyISAM SELECT b,c FROM test2;
This creates a MyISAM
table with
three columns, a
, b
, and
c
. The ENGINE
option is
part of the CREATE TABLE
statement, and should not be used following the
SELECT
; this would result in a
syntax error. The same is true for other
CREATE TABLE
options such as
CHARSET
.
Notice that the columns from the
SELECT
statement are appended to
the right side of the table, not overlapped onto it. Take the
following example:
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)
For each row in table foo
, a row is inserted
in bar
with the values from
foo
and default values for the new columns.
In a table resulting from
CREATE TABLE ...
SELECT
, columns named only in the
CREATE TABLE
part come first.
Columns named in both parts or only in the
SELECT
part come after that. The
data type of SELECT
columns can
be overridden by also specifying the column in the
CREATE TABLE
part.
If any errors occur while copying the data to the table, it is automatically dropped and not created.
You can precede the SELECT
by
IGNORE
or
REPLACE
to indicate how to handle
rows that duplicate unique key values. With
IGNORE
, new rows that duplicate an existing
row on a unique key value are discarded. With
REPLACE
, new rows replace rows
that have the same unique key value. If neither
IGNORE
nor
REPLACE
is specified, duplicate
unique key values result in an error.
Because the ordering of the rows in the underlying
SELECT
statements cannot always
be determined, CREATE TABLE ... IGNORE SELECT
and CREATE TABLE ... REPLACE SELECT
statements in MySQL 5.5.18 and later are flagged as unsafe for
statement-based replication. With this change, such statements
produce a warning in the log when using statement-based mode and
are logged using the row-based format when using
MIXED
mode. See also
Section 15.1.2.1, “Advantages and Disadvantages of Statement-Based and Row-Based
Replication”.
CREATE TABLE ...
SELECT
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
SELECT
statement:
mysql> CREATE TABLE bar (UNIQUE (n)) SELECT n FROM foo;
Some conversion of data types might occur. For example, the
AUTO_INCREMENT
attribute is not preserved,
and VARCHAR
columns can become
CHAR
columns. Retrained
attributes are NULL
(or NOT
NULL
) and, for those columns that have them,
CHARACTER SET
, COLLATION
,
COMMENT
, and the DEFAULT
clause.
When creating a table with
CREATE
TABLE ... SELECT
, make sure to alias any function
calls or expressions in the query. If you do not, the
CREATE
statement might fail or result in
undesirable column names.
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;
You can also explicitly specify the data type for a generated column:
CREATE TABLE foo (a TINYINT NOT NULL) SELECT b+1 AS a FROM bar;
For CREATE TABLE
... SELECT
, if IF NOT EXISTS
is
given and the destination table already exists, the result is
version dependent. Before MySQL 5.5.6, MySQL handles the
statement as follows:
The table definition given in the
CREATE TABLE
part is ignored. No error occurs, even if the definition does not match that of the existing table. MySQL attempts to insert the rows from theSELECT
part anyway.If there is a mismatch between the number of columns in the table and the number of columns produced by the
SELECT
part, the selected values are assigned to the rightmost columns. For example, if the table containsn
columns and theSELECT
producesm
columns, wherem
<n
, the selected values are assigned to them
rightmost columns in the table. Each of the initialn
–m
columns is assigned its default value, either that specified explicitly in the column definition or the implicit column data type default if the definition contains no default. If theSELECT
part produces too many columns (m
>n
), an error occurs.If strict SQL mode is enabled and any of these initial columns do not have an explicit default value, the statement fails with an error.
The following example illustrates IF NOT
EXISTS
handling:
mysql>CREATE TABLE t1 (i1 INT DEFAULT 0, i2 INT, i3 INT, i4 INT);
Query OK, 0 rows affected (0.05 sec) mysql>CREATE TABLE IF NOT EXISTS t1 (c1 CHAR(10)) SELECT 1, 2;
Query OK, 1 row affected, 1 warning (0.01 sec) Records: 1 Duplicates: 0 Warnings: 0 mysql>SELECT * FROM t1;
+------+------+------+------+ | i1 | i2 | i3 | i4 | +------+------+------+------+ | 0 | NULL | 1 | 2 | +------+------+------+------+ 1 row in set (0.00 sec)
As of MySQL 5.5.6, handling of
CREATE
TABLE IF NOT EXISTS ... SELECT
statements was changed
for the case that the destination table already exists. This
change also involves a change in MySQL 5.1 beginning with
5.1.51.
Previously, for
CREATE TABLE IF NOT EXISTS ... SELECT
, MySQL produced a warning that the table exists, but inserted the rows and wrote the statement to the binary log anyway. By contrast,CREATE TABLE ... SELECT
(withoutIF NOT EXISTS
) failed with an error, but MySQL inserted no rows and did not write the statement to the binary log.MySQL now handles both statements the same way when the destination table exists, in that neither statement inserts rows or is written to the binary log. The difference between them is that MySQL produces a warning when
IF NOT EXISTS
is present and an error when it is not.
This change means that, for the preceding example, the
CREATE
TABLE IF NOT EXISTS ... SELECT
statement inserts
nothing into the destination table as of MySQL 5.5.6.
This change in handling of IF NOT EXISTS
results in an incompatibility for statement-based replication
from a MySQL 5.1 master with the original behavior and a MySQL
5.5 slave with the new behavior. Suppose that
CREATE
TABLE IF NOT EXISTS ... SELECT
is executed on the
master and the destination table exists. The result is that rows
are inserted on the master but not on the slave. (Row-based
replication does not have this problem.)
To address this issue, statement-based binary logging for
CREATE
TABLE IF NOT EXISTS ... SELECT
is changed in MySQL 5.1
as of 5.1.51:
If the destination table does not exist, there is no change: The statement is logged as is.
If the destination table does exist, the statement is logged as the equivalent pair of
CREATE TABLE IF NOT EXISTS
andINSERT ... SELECT
statements. (If theSELECT
in the original statement is preceded byIGNORE
orREPLACE
, theINSERT
becomesINSERT IGNORE
orREPLACE
, respectively.)
This change provides forward compatibility for statement-based replication from MySQL 5.1 to 5.5 because when the destination table exists, the rows will be inserted on both the master and slave. To take advantage of this compatibility measure, the 5.1 server must be at least 5.1.51 and the 5.5 server must be at least 5.5.6.
To upgrade an existing 5.1-to-5.5 replication scenario, upgrade the master first to 5.1.51 or higher. Note that this differs from the usual replication upgrade advice of upgrading the slave first.
A workaround for applications that wish to achieve the original
effect (rows inserted regardless of whether the destination
table exists) is to use
CREATE
TABLE IF NOT EXISTS
and
INSERT ...
SELECT
statements rather than
CREATE
TABLE IF NOT EXISTS ... SELECT
statements.
Along with the change just described, the following related
change was made: Previously, if an existing view was named as
the destination table for
CREATE
TABLE IF NOT EXISTS ... SELECT
, rows were inserted
into the underlying base table and the statement was written to
the binary log. As of MySQL 5.1.51 and 5.5.6, nothing is
inserted or logged.
To ensure that the binary log can be used to re-create the
original tables, MySQL does not permit concurrent inserts during
CREATE TABLE ...
SELECT
.
In some cases, MySQL silently changes column specifications from
those given in a CREATE TABLE
or
ALTER TABLE
statement. These
might be changes to a data type, to attributes associated with a
data type, or to an index specification.
All changes are subject to the internal row-size limit of 65,535 bytes, which may cause some attempts at data type changes to fail. See Section E.10.4, “Table Column-Count and Row-Size Limits”.
TIMESTAMP
display sizes are discarded.Also note that
TIMESTAMP
columns areNOT NULL
by default.Columns that are part of a
PRIMARY KEY
are madeNOT NULL
even if not declared that way.Trailing spaces are automatically deleted from
ENUM
andSET
member values when the table is created.MySQL maps certain data types used by other SQL database vendors to MySQL types. See Section 10.7, “Using Data Types from Other Database Engines”.
If you include a
USING
clause to specify an index type that is not legal for a given storage engine, but there is another index type available that the engine can use without affecting query results, the engine uses the available type.If strict SQL mode is not enabled, a
VARCHAR
column with a length specification greater than 65535 is converted toTEXT
, and aVARBINARY
column with a length specification greater than 65535 is converted toBLOB
. Otherwise, an error occurs in either of these cases.Specifying the
CHARACTER SET binary
attribute for a character data type causes the column to be created as the corresponding binary data type:CHAR
becomesBINARY
,VARCHAR
becomesVARBINARY
, andTEXT
becomesBLOB
. For theENUM
andSET
data types, this does not occur; they are created as declared. Suppose that you specify a table using this definition:CREATE TABLE t ( c1 VARCHAR(10) CHARACTER SET binary, c2 TEXT CHARACTER SET binary, c3 ENUM('a','b','c') CHARACTER SET binary );
The resulting table has this definition:
CREATE TABLE t ( c1 VARBINARY(10), c2 BLOB, c3 ENUM('a','b','c') CHARACTER SET binary );
To see whether MySQL used a data type other than the one you
specified, issue a DESCRIBE
or
SHOW CREATE TABLE
statement after
creating or altering the table.
Certain other data type changes can occur if you compress a table using myisampack. See Section 13.5.3.3, “Compressed Table Characteristics”.
CREATE TABLESPACEtablespace_name
ADD DATAFILE 'file_name
' USE LOGFILE GROUPlogfile_group
[EXTENT_SIZE [=]extent_size
] [INITIAL_SIZE [=]initial_size
] [AUTOEXTEND_SIZE [=]autoextend_size
] [MAX_SIZE [=]max_size
] [NODEGROUP [=]nodegroup_id
] [WAIT] [COMMENT [=]comment_text
] ENGINE [=]engine_name
This statement is used to create a tablespace, which can contain
one or more data files, providing storage space for tables. One
data file is created and added to the tablespace using this
statement. Additional data files may be added to the tablespace by
using the ALTER TABLESPACE
statement (see Section 12.1.8, “ALTER TABLESPACE
Синтаксис”). For rules
covering the naming of tablespaces, see
Section 8.2, “Schema Object Names”.
All MySQL Cluster Disk Data objects share the same namespace. This means that each Disk Data object must be uniquely named (and not merely each Disk Data object of a given type). For example, you cannot have a tablespace and a log file group with the same name, or a tablespace and a data file with the same name.
A log file group of one or more UNDO
log files
must be assigned to the tablespace to be created with the
USE LOGFILE GROUP
clause.
logfile_group
must be an existing log
file group created with CREATE LOGFILE
GROUP
(see Section 12.1.14, “CREATE LOGFILE GROUP
Синтаксис”).
Multiple tablespaces may use the same log file group for
UNDO
logging.
The EXTENT_SIZE
sets the size, in bytes, of the
extents used by any files belonging to the tablespace. The default
value is 1M. The minimum size is 32K, and theoretical maximum is
2G, although the practical maximum size depends on a number of
factors. In most cases, changing the extent size does not have any
measurable effect on performance, and the default value is
recommended for all but the most unusual situations.
An extent is a unit of disk space
allocation. One extent is filled with as much data as that extent
can contain before another extent is used. In theory, up to 65,535
(64K) extents may used per data file; however, the recommended
maximum is 32,768 (32K). The recommended maximum size for a single
data file is 32G—that is, 32K extents × 1 MB per
extent. In addition, once an extent is allocated to a given
partition, it cannot be used to store data from a different
partition; an extent cannot store data from more than one
partition. This means, for example that a tablespace having a
single datafile whose INITIAL_SIZE
is 256 MB
and whose EXTENT_SIZE
is 128M has just two
extents, and so can be used to store data from at most two
different disk data table partitions.
You can see how many extents remain free in a given data file by
querying the INFORMATION_SCHEMA.FILES
table, and so derive an estimate for how much space remains free
in the file. For further discussion and examples, see
Section 19.8, “The INFORMATION_SCHEMA FILES
Table”.
The INITIAL_SIZE
parameter sets the data file's
total size in bytes. Once the file has been created, its size
cannot be changed; however, you can add more data files to the
tablespace using ALTER TABLESPACE ... ADD
DATAFILE
. See Section 12.1.8, “ALTER TABLESPACE
Синтаксис”.
INITIAL_SIZE
is optional; its default value is
128M
.
On 32-bit systems, the maximum supported value for
INITIAL_SIZE
is 4G
. (Bug
#29186)
When setting EXTENT_SIZE
or
INITIAL_SIZE
(either or both), you may
optionally follow the number with a one-letter abbreviation for an
order of magnitude, similar to those used in
my.cnf
. Generally, this is one of the letters
M
(for megabytes) or G
(for
gigabytes).
INITIAL_SIZE
, EXTENT_SIZE
,
and UNDO_BUFFER_SIZE
are subject to rounding as
follows:
EXTENT_SIZE
andUNDO_BUFFER_SIZE
are each rounded up to the nearest whole multiple of 32K.INITIAL_SIZE
is rounded down to the nearest whole multiple of 32K.For data files, INITIAL_SIZE is subject to further rounding; the result just obtained is rounded up to the nearest whole multiple of
EXTENT_SIZE
(after any rounding).
The rounding just described is done explicitly, and a warning is
issued by the MySQL Server when any such rounding is performed.
The rounded values are also used by the NDB kernel for calculating
INFORMATION_SCHEMA.FILES
column
values and other purposes. However, to avoid an unexpected result,
we suggest that you always use whole multiples of 32K in
specifying these options.
AUTOEXTEND_SIZE
, MAX_SIZE
,
NODEGROUP
, WAIT
, and
COMMENT
are parsed but ignored, and so
currently have no effect. These options are intended for future
expansion.
The ENGINE
parameter determines the storage
engine which uses this tablespace, with
engine_name
being the name of the
storage engine. Currently, engine_name
must be one of the values NDB
or
NDBCLUSTER
.
When CREATE TABLESPACE
is used with
ENGINE = NDB
, a tablespace and associated data
file are created on each Cluster data node. You can verify that
the data files were created and obtain information about them by
querying the INFORMATION_SCHEMA.FILES
table. For example:
mysql>SELECT LOGFILE_GROUP_NAME, FILE_NAME, EXTRA
->FROM INFORMATION_SCHEMA.FILES
->WHERE TABLESPACE_NAME = 'newts' AND FILE_TYPE = 'DATAFILE';
+--------------------+-------------+----------------+ | LOGFILE_GROUP_NAME | FILE_NAME | EXTRA | +--------------------+-------------+----------------+ | lg_3 | newdata.dat | CLUSTER_NODE=3 | | lg_3 | newdata.dat | CLUSTER_NODE=4 | +--------------------+-------------+----------------+ 2 rows in set (0.01 sec)
(See Section 19.8, “The INFORMATION_SCHEMA FILES
Table”.)
CREATE TABLESPACE
is useful only
with Disk Data storage for MySQL Cluster. See
Section 16.5.11, “MySQL Cluster Disk Data Tables”.
To drop a primary key, the index name is always
PRIMARY
, which must be specified as a quoted
identifier because PRIMARY
is a reserved word:
DROP INDEX `PRIMARY` ON t;
CREATE [DEFINER = {user
| CURRENT_USER }] TRIGGERtrigger_name
trigger_time
trigger_event
ONtbl_name
FOR EACH ROWtrigger_body
This statement creates a new trigger. A trigger is a named
database object that is associated with a table, and that
activates when a particular event occurs for the table. The
trigger becomes associated with the table named
tbl_name
, which must refer to a
permanent table. You cannot associate a trigger with a
TEMPORARY
table or a view.
CREATE TRIGGER
requires the
TRIGGER
privilege for the table
associated with the trigger. The statement might also require the
SUPER
privilege, depending on the
DEFINER
value, as described later in this
section. If binary logging is enabled, CREATE
TRIGGER
might require the
SUPER
privilege, as described in
Section 18.7, “Binary Logging of Stored Programs”.
The DEFINER
clause determines the security
context to be used when checking access privileges at trigger
activation time. See later in this section for more information.
trigger_time
is the trigger action
time. It can be BEFORE
or
AFTER
to indicate that the trigger activates
before or after each row to be modified.
trigger_event
indicates the kind of
statement that activates the trigger. The
trigger_event
can be one of the
following:
INSERT
: The trigger is activated whenever a new row is inserted into the table; for example, throughINSERT
,LOAD DATA
, andREPLACE
statements.UPDATE
: The trigger is activated whenever a row is modified; for example, throughUPDATE
statements.DELETE
: The trigger is activated whenever a row is deleted from the table; for example, throughDELETE
andREPLACE
statements. However,DROP TABLE
andTRUNCATE TABLE
statements on the table do not activate this trigger, because they do not useDELETE
. Dropping a partition does not activateDELETE
triggers, either. See Section 12.1.33, “TRUNCATE TABLE
Синтаксис”.
It is important to understand that the
trigger_event
does not represent a
literal type of SQL statement that activates the trigger so much
as it represents a type of table operation. For example, an
INSERT
trigger is activated by not
only INSERT
statements but also
LOAD DATA
statements because both
statements insert rows into a table.
A potentially confusing example of this is the INSERT
INTO ... ON DUPLICATE KEY UPDATE ...
syntax: a
BEFORE INSERT
trigger will activate for every
row, followed by either an AFTER INSERT
trigger
or both the BEFORE UPDATE
and AFTER
UPDATE
triggers, depending on whether there was a
duplicate key for the row.
There cannot be two triggers for a given table that have the same
trigger action time and event. For example, you cannot have two
BEFORE UPDATE
triggers for a table. But you can
have a BEFORE UPDATE
and a BEFORE
INSERT
trigger, or a BEFORE UPDATE
and an AFTER UPDATE
trigger.
trigger_body
is the statement to
execute when the trigger activates. If you want to execute
multiple statements, use the
BEGIN ... END
compound statement construct. This also enables you to use the
same statements that are permissible within stored routines. See
Section 12.6.1, “BEGIN ... END
Compound-Statement Синтаксис”. Some statements are not permitted in
triggers; see Section E.1, “Restrictions on Stored Programs”.
You can refer to columns in the subject table (the table
associated with the trigger) by using the aliases
OLD
and NEW
.
OLD.
refers
to a column of an existing row before it is updated or deleted.
col_name
NEW.
refers
to the column of a new row to be inserted or an existing row after
it is updated.
col_name
MySQL stores the sql_mode
system
variable setting that is in effect at the time a trigger is
created, and always executes the trigger with this setting in
force, regardless of the server SQL mode in effect when
the event begins executing.
Currently, cascaded foreign key actions do not activate triggers.
The DEFINER
clause specifies the MySQL account
to be used when checking access privileges at trigger activation
time. If a user
value is given, it
should be a MySQL account specified as
'
(the same format used in the user_name
'@'host_name
'GRANT
statement), CURRENT_USER
, or
CURRENT_USER()
. The default
DEFINER
value is the user who executes the
CREATE TRIGGER
statement. This is
the same as specifying DEFINER = CURRENT_USER
explicitly.
If you specify the DEFINER
clause, these rules
determine the legal DEFINER
user values:
If you do not have the
SUPER
privilege, the only legaluser
value is your own account, either specified literally or by usingCURRENT_USER
. You cannot set the definer to some other account.If you have the
SUPER
privilege, you can specify any syntactically legal account name. If the account does not actually exist, a warning is generated.Although it is possible to create a trigger with a nonexistent
DEFINER
account, it is not a good idea for such triggers to be activated until the account actually does exist. Otherwise, the behavior with respect to privilege checking is undefined.
MySQL takes the DEFINER
user into account when
checking trigger privileges as follows:
At
CREATE TRIGGER
time, the user who issues the statement must have theTRIGGER
privilege.At trigger activation time, privileges are checked against the
DEFINER
user. This user must have these privileges:The
TRIGGER
privilege.The
SELECT
privilege for the subject table if references to table columns occur usingOLD.
orcol_name
NEW.
in the trigger definition.col_name
The
UPDATE
privilege for the subject table if table columns are targets ofSET NEW.
assignments in the trigger definition.col_name
=value
Whatever other privileges normally are required for the statements executed by the trigger.
For more information about trigger security, see Section 18.6, “Access Control for Stored Programs and Views”.
Within a trigger, the
CURRENT_USER()
function returns the
account used to check privileges at trigger activation time. This
is the DEFINER
user, not the user whose actions
caused the trigger to be activated. For information about user
auditing within triggers, see
Section 5.5.10, “Auditing MySQL Account Activity”.
If you use LOCK TABLES
to lock a
table that has triggers, the tables used within the trigger are
also locked, as described in
Section 12.3.5.2, “LOCK TABLES
and Triggers”.
In MySQL 5.5, you can write triggers containing
direct references to tables by name, such as the trigger named
testref
shown in this example:
CREATE TABLE test1(a1 INT); CREATE TABLE test2(a2 INT); CREATE TABLE test3(a3 INT NOT NULL AUTO_INCREMENT PRIMARY KEY); CREATE TABLE test4( a4 INT NOT NULL AUTO_INCREMENT PRIMARY KEY, b4 INT DEFAULT 0 ); delimiter | CREATE TRIGGER testref BEFORE INSERT ON test1 FOR EACH ROW BEGIN INSERT INTO test2 SET a2 = NEW.a1; DELETE FROM test3 WHERE a3 = NEW.a1; UPDATE test4 SET b4 = b4 + 1 WHERE a4 = NEW.a1; END; | delimiter ; INSERT INTO test3 (a3) VALUES (NULL), (NULL), (NULL), (NULL), (NULL), (NULL), (NULL), (NULL), (NULL), (NULL); INSERT INTO test4 (a4) VALUES (0), (0), (0), (0), (0), (0), (0), (0), (0), (0);
Suppose that you insert the following values into table
test1
as shown here:
mysql>INSERT INTO test1 VALUES
->(1), (3), (1), (7), (1), (8), (4), (4);
Query OK, 8 rows affected (0.01 sec) Records: 8 Duplicates: 0 Warnings: 0
As a result, the data in the four tables will be as follows:
mysql>SELECT * FROM test1;
+------+ | a1 | +------+ | 1 | | 3 | | 1 | | 7 | | 1 | | 8 | | 4 | | 4 | +------+ 8 rows in set (0.00 sec) mysql>SELECT * FROM test2;
+------+ | a2 | +------+ | 1 | | 3 | | 1 | | 7 | | 1 | | 8 | | 4 | | 4 | +------+ 8 rows in set (0.00 sec) mysql>SELECT * FROM test3;
+----+ | a3 | +----+ | 2 | | 5 | | 6 | | 9 | | 10 | +----+ 5 rows in set (0.00 sec) mysql>SELECT * FROM test4;
+----+------+ | a4 | b4 | +----+------+ | 1 | 3 | | 2 | 0 | | 3 | 1 | | 4 | 2 | | 5 | 0 | | 6 | 0 | | 7 | 1 | | 8 | 1 | | 9 | 0 | | 10 | 0 | +----+------+ 10 rows in set (0.00 sec)
CREATE [OR REPLACE] [ALGORITHM = {UNDEFINED | MERGE | TEMPTABLE}] [DEFINER = {user
| CURRENT_USER }] [SQL SECURITY { DEFINER | INVOKER }] VIEWview_name
[(column_list
)] ASselect_statement
[WITH [CASCADED | LOCAL] CHECK OPTION]
The CREATE VIEW
statement creates a
new view, or replaces an existing one if the OR
REPLACE
clause is given. If the view does not exist,
CREATE OR REPLACE
VIEW
is the same as CREATE
VIEW
. If the view does exist,
CREATE OR REPLACE
VIEW
is the same as ALTER
VIEW
.
The select_statement
is a
SELECT
statement that provides the
definition of the view. (When you select from the view, you select
in effect using the SELECT
statement.) select_statement
can select
from base tables or other views.
The view definition is “frozen” at creation time, so
changes to the underlying tables afterward do not affect the view
definition. For example, if a view is defined as SELECT
*
on a table, new columns added to the table later do
not become part of the view.
The ALGORITHM
clause affects how MySQL
processes the view. The DEFINER
and
SQL SECURITY
clauses specify the security
context to be used when checking access privileges at view
invocation time. The WITH CHECK OPTION
clause
can be given to constrain inserts or updates to rows in tables
referenced by the view. These clauses are described later in this
section.
The CREATE VIEW
statement requires
the CREATE VIEW
privilege for the
view, and some privilege for each column selected by the
SELECT
statement. For columns used
elsewhere in the SELECT
statement
you must have the SELECT
privilege.
If the OR REPLACE
clause is present, you must
also have the DROP
privilege for
the view. CREATE VIEW
might also
require the SUPER
privilege,
depending on the DEFINER
value, as described
later in this section.
When a view is referenced, privilege checking occurs as described later in this section.
A view belongs to a database. By default, a new view is created in
the default database. To create the view explicitly in a given
database, specify the name as
db_name.view_name
when you create it:
mysql> CREATE VIEW test.v AS SELECT * FROM t;
Within a database, base tables and views share the same namespace, so a base table and a view cannot have the same name.
Columns retrieved by the SELECT
statement can be simple references to table columns. They can also
be expressions that use functions, constant values, operators, and
so forth.
Views must have unique column names with no duplicates, just like
base tables. By default, the names of the columns retrieved by the
SELECT
statement are used for the
view column names. To define explicit names for the view columns,
the optional column_list
clause can be
given as a list of comma-separated identifiers. The number of
names in column_list
must be the same
as the number of columns retrieved by the
SELECT
statement.
Unqualified table or view names in the
SELECT
statement are interpreted
with respect to the default database. A view can refer to tables
or views in other databases by qualifying the table or view name
with the proper database name.
A view can be created from many kinds of
SELECT
statements. It can refer to
base tables or other views. It can use joins,
UNION
, and subqueries. The
SELECT
need not even refer to any
tables. The following example defines a view that selects two
columns from another table, as well as an expression calculated
from those columns:
mysql>CREATE TABLE t (qty INT, price INT);
mysql>INSERT INTO t VALUES(3, 50);
mysql>CREATE VIEW v AS SELECT qty, price, qty*price AS value FROM t;
mysql>SELECT * FROM v;
+------+-------+-------+ | qty | price | value | +------+-------+-------+ | 3 | 50 | 150 | +------+-------+-------+
A view definition is subject to the following restrictions:
The
SELECT
statement cannot contain a subquery in theFROM
clause.The
SELECT
statement cannot refer to system or user variables.Within a stored program, the definition cannot refer to program parameters or local variables.
The
SELECT
statement cannot refer to prepared statement parameters.Any table or view referred to in the definition must exist. However, after a view has been created, it is possible to drop a table or view that the definition refers to. In this case, use of the view results in an error. To check a view definition for problems of this kind, use the
CHECK TABLE
statement.The definition cannot refer to a
TEMPORARY
table, and you cannot create aTEMPORARY
view.Any tables named in the view definition must exist at definition time.
You cannot associate a trigger with a view.
Aliases for column names in the
SELECT
statement are checked against the maximum column length of 64 characters (not the maximum alias length of 256 characters).
ORDER BY
is permitted in a view definition, but
it is ignored if you select from a view using a statement that has
its own ORDER BY
.
For other options or clauses in the definition, they are added to
the options or clauses of the statement that references the view,
but the effect is undefined. For example, if a view definition
includes a LIMIT
clause, and you select from
the view using a statement that has its own
LIMIT
clause, it is undefined which limit
applies. This same principle applies to options such as
ALL
, DISTINCT
, or
SQL_SMALL_RESULT
that follow the
SELECT
keyword, and to clauses such
as INTO
, FOR UPDATE
,
LOCK IN SHARE MODE
, and
PROCEDURE
.
If you create a view and then change the query processing environment by changing system variables, that may affect the results that you get from the view:
mysql>CREATE VIEW v (mycol) AS SELECT 'abc';
Query OK, 0 rows affected (0.01 sec) mysql>SET sql_mode = '';
Query OK, 0 rows affected (0.00 sec) mysql>SELECT "mycol" FROM v;
+-------+ | mycol | +-------+ | mycol | +-------+ 1 row in set (0.01 sec) mysql>SET sql_mode = 'ANSI_QUOTES';
Query OK, 0 rows affected (0.00 sec) mysql>SELECT "mycol" FROM v;
+-------+ | mycol | +-------+ | abc | +-------+ 1 row in set (0.00 sec)
The DEFINER
and SQL SECURITY
clauses determine which MySQL account to use when checking access
privileges for the view when a statement is executed that
references the view. The legal SQL SECURITY
characteristic values are DEFINER
and
INVOKER
. These indicate that the required
privileges must be held by the user who defined or invoked the
view, respectively. The default SQL SECURITY
value is DEFINER
.
If a user
value is given for the
DEFINER
clause, it should be a MySQL account
specified as
'
(the same format used in the user_name
'@'host_name
'GRANT
statement), CURRENT_USER
, or
CURRENT_USER()
. The default
DEFINER
value is the user who executes the
CREATE VIEW
statement. This is the
same as specifying DEFINER = CURRENT_USER
explicitly.
If you specify the DEFINER
clause, these rules
determine the legal DEFINER
user values:
If you do not have the
SUPER
privilege, the only legaluser
value is your own account, either specified literally or by usingCURRENT_USER
. You cannot set the definer to some other account.If you have the
SUPER
privilege, you can specify any syntactically legal account name. If the account does not actually exist, a warning is generated.Although it is possible to create a view with a nonexistent
DEFINER
account, an error occurs when the view is referenced if theSQL SECURITY
value isDEFINER
but the definer account does not exist.
For more information about view security, see Section 18.6, “Access Control for Stored Programs and Views”.
Within a view definition,
CURRENT_USER
returns the view's
DEFINER
value by default. For views defined
with the SQL SECURITY INVOKER
characteristic,
CURRENT_USER
returns the account
for the view's invoker. For information about user auditing within
views, see Section 5.5.10, “Auditing MySQL Account Activity”.
Within a stored routine that is defined with the SQL
SECURITY DEFINER
characteristic,
CURRENT_USER
returns the routine's
DEFINER
value. This also affects a view defined
within such a routine, if the view definition contains a
DEFINER
value of
CURRENT_USER
.
View privileges are checked like this:
At view definition time, the view creator must have the privileges needed to use the top-level objects accessed by the view. For example, if the view definition refers to table columns, the creator must have some privilege for each column in the select list of the definition, and the
SELECT
privilege for each column used elsewhere in the definition. If the definition refers to a stored function, only the privileges needed to invoke the function can be checked. The privileges required at function invocation time can be checked only as it executes: For different invocations, different execution paths within the function might be taken.The user who references a view must have appropriate privileges to access it (
SELECT
to select from it,INSERT
to insert into it, and so forth.)When a view has been referenced, privileges for objects accessed by the view are checked against the privileges held by the view
DEFINER
account or invoker, depending on whether theSQL SECURITY
characteristic isDEFINER
orINVOKER
, respectively.If reference to a view causes execution of a stored function, privilege checking for statements executed within the function depend on whether the function
SQL SECURITY
characteristic isDEFINER
orINVOKER
. If the security characteristic isDEFINER
, the function runs with the privileges of theDEFINER
account. If the characteristic isINVOKER
, the function runs with the privileges determined by the view'sSQL SECURITY
characteristic.
Пример: A view might depend on a stored function, and that
function might invoke other stored routines. For example, the
following view invokes a stored function f()
:
CREATE VIEW v AS SELECT * FROM t WHERE t.id = f(t.name);
Suppose that f()
contains a statement such as
this:
IF name IS NULL then CALL p1(); ELSE CALL p2(); END IF;
The privileges required for executing statements within
f()
need to be checked when
f()
executes. This might mean that privileges
are needed for p1()
or p2()
,
depending on the execution path within f()
.
Those privileges must be checked at runtime, and the user who must
possess the privileges is determined by the SQL
SECURITY
values of the view v
and the
function f()
.
The DEFINER
and SQL SECURITY
clauses for views are extensions to standard SQL. In standard SQL,
views are handled using the rules for SQL SECURITY
DEFINER
. The standard says that the definer of the view,
which is the same as the owner of the view's schema, gets
applicable privileges on the view (for example,
SELECT
) and may grant them. MySQL
has no concept of a schema “owner”, so MySQL adds a
clause to identify the definer. The DEFINER
clause is an extension where the intent is to have what the
standard has; that is, a permanent record of who defined the view.
This is why the default DEFINER
value is the
account of the view creator.
The optional ALGORITHM
clause is a MySQL
extension to standard SQL. It affects how MySQL processes the
view. ALGORITHM
takes three values:
MERGE
, TEMPTABLE
, or
UNDEFINED
. The default algorithm is
UNDEFINED
if no ALGORITHM
clause is present. For more information, see
Section 18.5.2, “View Processing Algorithms”.
Some views are updatable. That is, you can use them in statements
such as UPDATE
,
DELETE
, or
INSERT
to update the contents of
the underlying table. For a view to be updatable, there must be a
one-to-one relationship between the rows in the view and the rows
in the underlying table. There are also certain other constructs
that make a view nonupdatable.
The WITH CHECK OPTION
clause can be given for
an updatable view to prevent inserts or updates to rows except
those for which the WHERE
clause in the
select_statement
is true.
In a WITH CHECK OPTION
clause for an updatable
view, the LOCAL
and CASCADED
keywords determine the scope of check testing when the view is
defined in terms of another view. The LOCAL
keyword restricts the CHECK OPTION
only to the
view being defined. CASCADED
causes the checks
for underlying views to be evaluated as well. When neither keyword
is given, the default is CASCADED
.
For more information about updatable views and the WITH
CHECK OPTION
clause, see
Section 18.5.3, “Updatable and Insertable Views”.
DROP {DATABASE | SCHEMA} [IF EXISTS] db_name
DROP DATABASE
drops all tables in
the database and deletes the database. Be
very careful with this statement! To use
DROP DATABASE
, you need the
DROP
privilege on the database.
DROP
SCHEMA
is a synonym for DROP
DATABASE
.
When a database is dropped, user privileges on the database are
not automatically dropped. See
Section 12.7.1.3, “GRANT
Синтаксис”.
IF EXISTS
is used to prevent an error from
occurring if the database does not exist.
If the default database is dropped, the default database is unset
(the DATABASE()
function returns
NULL
).
If you use DROP DATABASE
on a
symbolically linked database, both the link and the original
database are deleted.
DROP DATABASE
returns the number of
tables that were removed. This corresponds to the number of
.frm
files removed.
The DROP DATABASE
statement removes
from the given database directory those files and directories that
MySQL itself may create during normal operation:
All files with the following extensions.
.BAK
.DAT
.HSH
.MRG
.MYD
.MYI
.TRG
.TRN
.db
.frm
.ibd
.ndb
.par
The
db.opt
file, if it exists.
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
DROP DATABASE
statement again.
You can also drop databases with mysqladmin. See Section 4.5.2, “mysqladmin — Client for Administering a MySQL Server”.
DROP EVENT [IF EXISTS] event_name
This statement drops the event named
event_name
. The event immediately
ceases being active, and is deleted completely from the server.
If the event does not exist, the error ERROR 1517
(HY000): Unknown event
'event_name
' results. You
can override this and cause the statement to generate a warning
for nonexistent events instead using IF EXISTS
.
This statement requires the EVENT
privilege for the schema to which the event to be dropped belongs.
The DROP FUNCTION
statement is used
to drop stored functions and user-defined functions (UDFs):
For information about dropping stored functions, see Section 12.1.26, “
DROP PROCEDURE
andDROP FUNCTION
Синтаксис”.For information about dropping user-defined functions, see Section 12.7.3.2, “
DROP FUNCTION
Синтаксис”.
DROP [ONLINE|OFFLINE] INDEXindex_name
ONtbl_name
DROP INDEX
drops the index named
index_name
from the table
tbl_name
. This statement is mapped to
an ALTER TABLE
statement to drop
the index. See Section 12.1.7, “ALTER TABLE
Синтаксис”.
To drop a primary key, the index name is always
PRIMARY
, which must be specified as a quoted
identifier because PRIMARY
is a reserved word:
DROP INDEX `PRIMARY` ON t;
Indexes on variable-width columns of
NDBCLUSTER
tables are dropped online;
that is, without any table copying. The table is not locked
against access from other MySQL Cluster API nodes, although it is
locked against other operations on the same
API node for the duration of the operation. This is done
automatically by the server whenever it determines that it is
possible to do so; you do not have to use any special SQL syntax
or server options to cause it to happen.
In standard MySQL 5.5 releases, it is not possible to
override the server when it determines that an index is to be
dropped without table copying. In MySQL Cluster, you can drop
indexes offline (which causes the table to be locked for all API
nodes in the cluster) using the OFFLINE
keyword. The rules and limitations governing DROP OFFLINE
INDEX
and DROP ONLINE INDEX
are the
same as for ALTER OFFLINE TABLE ... DROP INDEX
and ALTER ONLINE TABLE ... DROP INDEX
. You
cannot cause the noncopying dropping of an index that would
normally be dropped offline by using the ONLINE
keyword: If it is not possible to perform the
DROP
operation without table copying, the
server ignores the ONLINE
keyword. For more
information, see Section 12.1.7.2, “ALTER TABLE
Online Operations”.
The ONLINE
and OFFLINE
keywords are available only in MySQL Cluster; attempting to use
these keywords in standard MySQL Server 5.5 releases results in
a syntax error.
DROP LOGFILE GROUPlogfile_group
ENGINE [=]engine_name
This statement drops the log file group named
logfile_group
. The log file group must
already exist or an error results. (For information on creating
log file groups, see Section 12.1.14, “CREATE LOGFILE GROUP
Синтаксис”.)
Before dropping a log file group, you must drop all tablespaces
that use that log file group for UNDO
logging.
The required ENGINE
clause provides the name of
the storage engine used by the log file group to be dropped.
Currently, the only permitted values for
engine_name
are
NDB
and
NDBCLUSTER
.
DROP LOGFILE GROUP
is useful only
with Disk Data storage for MySQL Cluster. See
Section 16.5.11, “MySQL Cluster Disk Data Tables”.
DROP {PROCEDURE | FUNCTION} [IF EXISTS] sp_name
This statement is used to drop a stored procedure or function.
That is, the specified routine is removed from the server. You
must have the ALTER ROUTINE
privilege for the routine. (If the
automatic_sp_privileges
system variable is
enabled, that privilege and EXECUTE
are granted automatically to the routine creator when the routine
is created and dropped from the creator when the routine is
dropped. See Section 18.2.2, “Stored Routines and MySQL Privileges”.)
The IF EXISTS
clause is a MySQL extension. It
prevents an error from occurring if the procedure or function does
not exist. A warning is produced that can be viewed with
SHOW WARNINGS
.
DROP FUNCTION
is also used to drop
user-defined functions (see Section 12.7.3.2, “DROP FUNCTION
Синтаксис”).
DROP SERVER [ IF EXISTS ] server_name
Drops the server definition for the server named
. The
corresponding row within the server_name
mysql.servers
table will be deleted. This statement requires the
SUPER
privilege.
Dropping a server for a table does not affect any
FEDERATED
tables that used this connection
information when they were created. See
Section 12.1.16, “CREATE SERVER
Синтаксис”.
DROP SERVER
does not cause an
automatic commit.
DROP [TEMPORARY] TABLE [IF EXISTS]tbl_name
[,tbl_name
] ... [RESTRICT | CASCADE]
DROP TABLE
removes one or more
tables. You must have the DROP
privilege for each table. All table data and the table definition
are removed, so be
careful with this statement! If any of the tables named
in the argument list do not exist, MySQL returns an error
indicating by name which nonexisting tables it was unable to drop,
but it also drops all of the tables in the list that do exist.
When a table is dropped, user privileges on the table are
not automatically dropped. See
Section 12.7.1.3, “GRANT
Синтаксис”.
Note that for a partitioned table, DROP
TABLE
permanently removes the table definition, all of
its partitions, and all of the data which was stored in those
partitions. It also removes the partitioning definition
(.par
) file associated with the dropped
table.
Use IF EXISTS
to prevent an error from
occurring for tables that do not exist. A NOTE
is generated for each nonexistent table when using IF
EXISTS
. See Section 12.7.5.41, “SHOW WARNINGS
Синтаксис”.
RESTRICT
and CASCADE
are
permitted to make porting easier. In MySQL 5.5, they
do nothing.
DROP TABLE
automatically commits
the current active transaction, unless you use the
TEMPORARY
keyword.
The TEMPORARY
keyword has the following
effects:
The statement drops only
TEMPORARY
tables.The statement does not end an ongoing transaction.
No access rights are checked. (A
TEMPORARY
table is visible only to the session that created it, so no check is necessary.)
Using TEMPORARY
is a good way to ensure that
you do not accidentally drop a non-TEMPORARY
table.
DROP TABLESPACEtablespace_name
ENGINE [=]engine_name
This statement drops a tablespace that was previously created
using CREATE TABLESPACE
(see
Section 12.1.18, “CREATE TABLESPACE
Синтаксис”).
The tablespace to be dropped must not contain any data files; in
other words, before you can drop a tablespace, you must first
drop each of its data files using ALTER TABLESPACE ...
DROP DATAFILE
(see
Section 12.1.8, “ALTER TABLESPACE
Синтаксис”).
The ENGINE
clause (required) specifies the
storage engine used by the tablespace. Currently, the only
accepted values for engine_name
are
NDB
and
NDBCLUSTER
.
DROP TABLESPACE
is useful only with
Disk Data storage for MySQL Cluster. See
Section 16.5.11, “MySQL Cluster Disk Data Tables”.
DROP TRIGGER [IF EXISTS] [schema_name
.]trigger_name
This statement drops a trigger. The schema (database) name is
optional. If the schema is omitted, the trigger is dropped from
the default schema. DROP TRIGGER
requires the TRIGGER
privilege for
the table associated with the trigger.
Use IF EXISTS
to prevent an error from
occurring for a trigger that does not exist. A
NOTE
is generated for a nonexistent trigger
when using IF EXISTS
. See
Section 12.7.5.41, “SHOW WARNINGS
Синтаксис”.
Triggers for a table are also dropped if you drop the table.
When upgrading from a version of MySQL older than MySQL 5.0.10
to 5.0.10 or newer—including all MySQL 5.5
releases—you must drop all triggers and re-create them.
Otherwise, DROP TRIGGER
does not
work for older triggers after the upgrade. See
Upgrading from MySQL 4.1 to 5.0, for
a suggested upgrade procedure.
DROP VIEW [IF EXISTS]view_name
[,view_name
] ... [RESTRICT | CASCADE]
DROP VIEW
removes one or more
views. You must have the DROP
privilege for each view. If any of the views named in the argument
list do not exist, MySQL returns an error indicating by name which
nonexisting views it was unable to drop, but it also drops all of
the views in the list that do exist.
The IF EXISTS
clause prevents an error from
occurring for views that don't exist. When this clause is given, a
NOTE
is generated for each nonexistent view.
See Section 12.7.5.41, “SHOW WARNINGS
Синтаксис”.
RESTRICT
and CASCADE
, if
given, are parsed and ignored.
RENAME TABLEtbl_name
TOnew_tbl_name
[,tbl_name2
TOnew_tbl_name2
] ...
This statement renames one or more tables.
The rename operation is done atomically, which means that no other
session can access any of the tables while the rename is running.
For example, if you have an existing table
old_table
, you can create another table
new_table
that has the same structure but is
empty, and then replace the existing table with the empty one as
follows (assuming that backup_table
does not
already exist):
CREATE TABLE new_table (...); RENAME TABLE old_table TO backup_table, new_table TO old_table;
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
tmp_table
does not already exist):
RENAME TABLE old_table TO tmp_table, new_table TO old_table, tmp_table TO new_table;
As long as two databases are on the same file system, you can use
RENAME TABLE
to move a table from
one database to another:
RENAME TABLEcurrent_db.tbl_name
TOother_db.tbl_name;
If there are any triggers associated with a table which is moved
to a different database using RENAME
TABLE
, then the statement fails with the error
Trigger in wrong schema.
RENAME TABLE
also works for views,
as long as you do not try to rename a view into a different
database.
Any privileges granted specifically for the renamed table or view are not migrated to the new name. They must be changed manually.
When you execute RENAME
, you cannot have any
locked tables or active transactions. You must also have the
ALTER
and
DROP
privileges on the original
table, and the CREATE
and
INSERT
privileges on the new table.
If MySQL encounters any errors in a multiple-table rename, it does a reverse rename for all renamed tables to return everything to its original state.
You cannot use RENAME
to rename a
TEMPORARY
table. However, you can use
ALTER TABLE
instead:
mysql> ALTER TABLE orig_name RENAME new_name;
TRUNCATE [TABLE] tbl_name
TRUNCATE TABLE
empties a table
completely. It requires the DROP
privilege.
Logically, TRUNCATE TABLE
is
similar to a DELETE
statement that
deletes all rows, or a sequence of DROP
TABLE
and CREATE TABLE
statements. To achieve high performance, it bypasses the DML
method of deleting data. Thus, it cannot be rolled back, it does
not cause ON DELETE
triggers to fire, and it
cannot be performed for InnoDB
tables with
parent-child foreign key relationships.
Although TRUNCATE TABLE
is similar
to DELETE
, it is classified as a
DDL statement rather than a DML statement. It differs from
DELETE
in the following ways in
MySQL 5.5:
Truncate operations drop and re-create the table, which is much faster than deleting rows one by one, particularly for large tables.
Truncate operations cause an implicit commit, and so cannot be rolled back.
Truncation operations cannot be performed if the session holds an active table lock.
TRUNCATE TABLE
fails for anInnoDB
table if there are anyFOREIGN KEY
constraints from other tables that reference the table. Foreign key constraints between columns of the same table are allowed.Truncation operations do not return a meaningful value for the number of deleted rows. The usual result is “0 rows affected,” which should be interpreted as “no information.”
As long as the table format file
is valid, the table can be re-created as an empty table withtbl_name
.frmTRUNCATE TABLE
, even if the data or index files have become corrupted.Any
AUTO_INCREMENT
value is reset to its start value. This is true even forMyISAM
andInnoDB
, which normally do not reuse sequence values.When used with partitioned tables,
TRUNCATE TABLE
preserves the partitioning; that is, the data and index files are dropped and re-created, while the partition definitions (.par
) file is unaffected.The
TRUNCATE TABLE
statement does not invokeON DELETE
triggers.
TRUNCATE TABLE
for a table closes
all handlers for the table that were opened with
HANDLER OPEN
.
TRUNCATE TABLE
is treated for
purposes of binary logging and replication as
DROP TABLE
followed by
CREATE TABLE
—that is, as DDL
rather than DML. This is due to the fact that, when using
InnoDB
and other transactional
storage engines where the transaction isolation level does not
permit statement-based logging (READ COMMITTED
or READ UNCOMMITTED
), the statement was not
logged and replicated when using STATEMENT
or
MIXED
logging mode. (Bug #36763) However, it is
still applied on replication slaves using
InnoDB
in the manner described
previously.
TRUNCATE TABLE
can be used with
Performance Schema summary tables, but the effect is to reset the
summary columns to 0 or NULL
, not to remove
rows. See Section 20.7.4, “Performance Schema Summary Tables”.
CALLsp_name
([parameter
[,...]]) CALLsp_name
[()]
The CALL
statement invokes a stored
procedure that was defined previously with
CREATE PROCEDURE
.
Stored procedures that take no arguments can be invoked without
parentheses. That is, CALL p()
and
CALL p
are equivalent.
CALL
can pass back values to its
caller using parameters that are declared as
OUT
or INOUT
parameters.
When the procedure returns, a client program can also obtain the
number of rows affected for the final statement executed within
the routine: At the SQL level, call the
ROW_COUNT()
function; from the C
API, call the
mysql_affected_rows()
function.
To get back a value from a procedure using an
OUT
or INOUT
parameter, pass
the parameter by means of a user variable, and then check the
value of the variable after the procedure returns. (If you are
calling the procedure from within another stored procedure or
function, you can also pass a routine parameter or local routine
variable as an IN
or INOUT
parameter.) For an INOUT
parameter, initialize
its value before passing it to the procedure. The following
procedure has an OUT
parameter that the
procedure sets to the current server version, and an
INOUT
value that the procedure increments by
one from its current value:
CREATE PROCEDURE p (OUT ver_param VARCHAR(25), INOUT incr_param INT) BEGIN # Set value of OUT parameter SELECT VERSION() INTO ver_param; # Increment value of INOUT parameter SET incr_param = incr_param + 1; END;
Before calling the procedure, initialize the variable to be passed
as the INOUT
parameter. After calling the
procedure, the values of the two variables will have been set or
modified:
mysql>SET @increment = 10;
mysql>CALL p(@version, @increment);
mysql>SELECT @version, @increment;
+--------------+------------+ | @version | @increment | +--------------+------------+ | 5.5.3-m3-log | 11 | +--------------+------------+
In prepared CALL
statements used
with PREPARE
and
EXECUTE
, placeholders can be used
for IN
parameters. For OUT
and INOUT
parameters, placeholder support is
available as of MySQL 5.5.3. These types of parameters can be used
as follows:
mysql>SET @increment = 10;
mysql>PREPARE s FROM 'CALL p(?, ?)';
mysql>EXECUTE s USING @version, @increment;
mysql>SELECT @version, @increment;
+--------------+------------+ | @version | @increment | +--------------+------------+ | 5.5.3-m3-log | 11 | +--------------+------------+
Before MySQL 5.5.3, placeholder support is not available for
OUT
or INOUT
parameters. To
work around this limitation for OUT
and
INOUT
parameters, forego the use of
placeholders; instead, refer to user variables in the
CALL
statement itself and do not
specify them in the EXECUTE
statement:
mysql>SET @increment = 10;
mysql>PREPARE s FROM 'CALL p(@version, @increment)';
mysql>EXECUTE s;
mysql>SELECT @version, @increment;
+--------------+------------+ | @version | @increment | +--------------+------------+ | 5.5.0-m2-log | 11 | +--------------+------------+
To write C programs that use the
CALL
SQL statement to execute
stored procedures that produce result sets, the
CLIENT_MULTI_RESULTS
flag must be enabled. This
is because each CALL
returns a
result to indicate the call status, in addition to any result sets
that might be returned by statements executed within the
procedure. CLIENT_MULTI_RESULTS
must also be
enabled if CALL
is used to execute
any stored procedure that contains prepared statements. It cannot
be determined when such a procedure is loaded whether those
statements will produce result sets, so it is necessary to assume
that they will.
CLIENT_MULTI_RESULTS
can be enabled when you
call mysql_real_connect()
, either
explicitly by passing the CLIENT_MULTI_RESULTS
flag itself, or implicitly by passing
CLIENT_MULTI_STATEMENTS
(which also enables
CLIENT_MULTI_RESULTS
). As of MySQL 5.5.3,
CLIENT_MULTI_RESULTS
is enabled by default.
To process the result of a CALL
statement executed using
mysql_query()
or
mysql_real_query()
, use a loop
that calls mysql_next_result()
to
determine whether there are more results. For an example, see
Section 21.9.13, “C API Support for Multiple Statement Execution”.
For programs written in a language that provides a MySQL
interface, there is no native method prior to MySQL 5.5.3 for
directly retrieving the results of OUT
or
INOUT
parameters from
CALL
statements. To get the
parameter values, pass user-defined variables to the procedure in
the CALL
statement and then execute
a SELECT
statement to produce a
result set containing the variable values. To handle an
INOUT
parameter, execute a statement prior to
the CALL
that sets the
corresponding user variable to the value to be passed to the
procedure.
The following example illustrates the technique (without error
checking) for the stored procedure p
described
earlier that has an OUT
parameter and an
INOUT
parameter:
mysql_query(mysql, "SET @increment = 10"); mysql_query(mysql, "CALL p(@version, @increment)"); mysql_query(mysql, "SELECT @version, @increment"); result = mysql_store_result(mysql); row = mysql_fetch_row(result); mysql_free_result(result);
After the preceding code executes, row[0]
and
row[1]
contain the values of
@version
and @increment
,
respectively.
As of MySQL 5.5.3, C programs can use the prepared-statement
interface to execute CALL
statements and access OUT
and
INOUT
parameters. This is done by processing
the result of a CALL
statement
using a loop that calls
mysql_stmt_next_result()
to
determine whether there are more results. For an example, see
Section 21.9.16, “C API Support for Prepared CALL
Statements”. Languages that
provide a MySQL interface can use prepared
CALL
statements to directly
retrieve OUT
and INOUT
procedure parameters.
Single-table syntax:
DELETE [LOW_PRIORITY] [QUICK] [IGNORE] FROMtbl_name
[WHEREwhere_condition
] [ORDER BY ...] [LIMITrow_count
]
Multiple-table syntax:
DELETE [LOW_PRIORITY] [QUICK] [IGNORE]tbl_name
[.*] [,tbl_name
[.*]] ... FROMtable_references
[WHEREwhere_condition
]
Or:
DELETE [LOW_PRIORITY] [QUICK] [IGNORE] FROMtbl_name
[.*] [,tbl_name
[.*]] ... USINGtable_references
[WHEREwhere_condition
]
For the single-table syntax, the
DELETE
statement deletes rows from
tbl_name
and returns a count of the
number of deleted rows. This count can be obtained by calling the
ROW_COUNT()
function (see
Section 11.14, “Information Functions”). The
WHERE
clause, if given, specifies the
conditions that identify which rows to delete. With no
WHERE
clause, all rows are deleted. If the
ORDER BY
clause is specified, the rows are
deleted in the order that is specified. The
LIMIT
clause places a limit on the number of
rows that can be deleted.
For the multiple-table syntax,
DELETE
deletes from each
tbl_name
the rows that satisfy the
conditions. In this case, ORDER BY
and
LIMIT
cannot be used.
where_condition
is an expression that
evaluates to true for each row to be deleted. It is specified as
described in Section 12.2.9, “SELECT
Синтаксис”.
Currently, you cannot delete from a table and select from the same table in a subquery.
You need the DELETE
privilege on a
table to delete rows from it. You need only the
SELECT
privilege for any columns
that are only read, such as those named in the
WHERE
clause.
As stated, a DELETE
statement with
no WHERE
clause deletes all rows. A faster way
to do this, when you do not need to know the number of deleted
rows, is to use TRUNCATE TABLE
.
However, within a transaction or if you have a lock on the table,
TRUNCATE TABLE
cannot be used
whereas DELETE
can. See
Section 12.1.33, “TRUNCATE TABLE
Синтаксис”, and
Section 12.3.5, “LOCK TABLES
and
UNLOCK
TABLES
Синтаксис”.
If you delete the row containing the maximum value for an
AUTO_INCREMENT
column, the value is not reused
for a MyISAM
or InnoDB
table. If you delete all rows in the table with DELETE
FROM
(without a
tbl_name
WHERE
clause) in
autocommit
mode, the sequence
starts over for all storage engines except
InnoDB
and MyISAM
. There are
some exceptions to this behavior for InnoDB
tables, as discussed in
Section 13.3.5.3, “AUTO_INCREMENT
Handling in InnoDB
”.
For MyISAM
tables, you can specify an
AUTO_INCREMENT
secondary column in a
multiple-column key. In this case, reuse of values deleted from
the top of the sequence occurs even for MyISAM
tables. See Section 3.6.9, “Using AUTO_INCREMENT
”.
The DELETE
statement supports the
following modifiers:
If you specify
LOW_PRIORITY
, the server delays execution of theDELETE
until no other clients are reading from the table. This affects only storage engines that use only table-level locking (such asMyISAM
,MEMORY
, andMERGE
).For
MyISAM
tables, if you use theQUICK
keyword, the storage engine does not merge index leaves during delete, which may speed up some kinds of delete operations.The
IGNORE
keyword causes MySQL to ignore all errors during the process of deleting rows. (Ошибки encountered during the parsing stage are processed in the usual manner.) Ошибки that are ignored due to the use ofIGNORE
are returned as warnings.
The speed of delete operations may also be affected by factors
discussed in Section 7.2.2.3, “Speed of DELETE
Statements”.
In MyISAM
tables, deleted rows are maintained
in a linked list and subsequent
INSERT
operations reuse old row
positions. To reclaim unused space and reduce file sizes, use the
OPTIMIZE TABLE
statement or the
myisamchk utility to reorganize tables.
OPTIMIZE TABLE
is easier to use,
but myisamchk is faster. See
Section 12.7.2.4, “OPTIMIZE TABLE
Синтаксис”, and Section 4.6.3, “myisamchk — MyISAM Table-Maintenance Utility”.
The QUICK
modifier affects whether index leaves
are merged for delete operations. DELETE QUICK
is most useful for applications where index values for deleted
rows are replaced by similar index values from rows inserted
later. In this case, the holes left by deleted values are reused.
DELETE QUICK
is not useful when deleted values
lead to underfilled index blocks spanning a range of index values
for which new inserts occur again. In this case, use of
QUICK
can lead to wasted space in the index
that remains unreclaimed. Here is an example of such a scenario:
Create a table that contains an indexed
AUTO_INCREMENT
column.Insert many rows into the table. Each insert results in an index value that is added to the high end of the index.
Delete a block of rows at the low end of the column range using
DELETE QUICK
.
In this scenario, the index blocks associated with the deleted
index values become underfilled but are not merged with other
index blocks due to the use of QUICK
. They
remain underfilled when new inserts occur, because new rows do not
have index values in the deleted range. Furthermore, they remain
underfilled even if you later use
DELETE
without
QUICK
, unless some of the deleted index values
happen to lie in index blocks within or adjacent to the
underfilled blocks. To reclaim unused index space under these
circumstances, use OPTIMIZE TABLE
.
If you are going to delete many rows from a table, it might be
faster to use DELETE QUICK
followed by
OPTIMIZE TABLE
. This rebuilds the
index rather than performing many index block merge operations.
The MySQL-specific LIMIT
option to
row_count
DELETE
tells the server the maximum
number of rows to be deleted before control is returned to the
client. This can be used to ensure that a given
DELETE
statement does not take too
much time. You can simply repeat the
DELETE
statement until the number
of affected rows is less than the LIMIT
value.
If the DELETE
statement includes an
ORDER BY
clause, rows are deleted in the order
specified by the clause. This is useful primarily in conjunction
with LIMIT
. For example, the following
statement finds rows matching the WHERE
clause,
sorts them by timestamp_column
, and deletes the
first (oldest) one:
DELETE FROM somelog WHERE user = 'jcole' ORDER BY timestamp_column LIMIT 1;
ORDER BY
may also be useful in some cases to
delete rows in an order required to avoid referential integrity
violations.
If you are deleting many rows from a large table, you may exceed
the lock table size for an InnoDB
table. To
avoid this problem, or simply to minimize the time that the table
remains locked, the following strategy (which does not use
DELETE
at all) might be helpful:
Select the rows not to be deleted into an empty table that has the same structure as the original table:
INSERT INTO t_copy SELECT * FROM t WHERE ... ;
Use
RENAME TABLE
to atomically move the original table out of the way and rename the copy to the original name:RENAME TABLE t TO t_old, t_copy TO t;
Drop the original table:
DROP TABLE t_old;
No other sessions can access the tables involved while
RENAME TABLE
executes, so the
rename operation is not subject to concurrency problems. See
Section 12.1.32, “RENAME TABLE
Синтаксис”.
You can specify multiple tables in a
DELETE
statement to delete rows
from one or more tables depending on the particular condition in
the WHERE
clause. However, you cannot use
ORDER BY
or LIMIT
in a
multiple-table DELETE
. The
table_references
clause lists the
tables involved in the join. Its syntax is described in
Section 12.2.9.2, “JOIN
Синтаксис”.
For the first multiple-table syntax, only matching rows from the
tables listed before the FROM
clause are
deleted. For the second multiple-table syntax, only matching rows
from the tables listed in the FROM
clause
(before the USING
clause) are deleted. The
effect is that you can delete rows from many tables at the same
time and have additional tables that are used only for searching:
DELETE t1, t2 FROM t1 INNER JOIN t2 INNER JOIN t3 WHERE t1.id=t2.id AND t2.id=t3.id;
Or:
DELETE FROM t1, t2 USING t1 INNER JOIN t2 INNER JOIN t3 WHERE t1.id=t2.id AND t2.id=t3.id;
These statements use all three tables when searching for rows to
delete, but delete matching rows only from tables
t1
and t2
.
The preceding examples use INNER JOIN
, but
multiple-table DELETE
statements
can use other types of join permitted in
SELECT
statements, such as
LEFT JOIN
. For example, to delete rows that
exist in t1
that have no match in
t2
, use a LEFT JOIN
:
DELETE t1 FROM t1 LEFT JOIN t2 ON t1.id=t2.id WHERE t2.id IS NULL;
The syntax permits .*
after each
tbl_name
for compatibility with
Access.
If you use a multiple-table DELETE
statement involving InnoDB
tables for which
there are foreign key constraints, the MySQL optimizer might
process tables in an order that differs from that of their
parent/child relationship. In this case, the statement fails and
rolls back. Instead, you should delete from a single table and
rely on the ON DELETE
capabilities that
InnoDB
provides to cause the other tables to be
modified accordingly.
If you declare an alias for a table, you must use the alias when referring to the table:
DELETE t1 FROM test AS t1, test2 WHERE ...
Table aliases in a multiple-table
DELETE
should be declared only in
the table_references
part of the
statement.
Correct:
DELETE a1, a2 FROM t1 AS a1 INNER JOIN t2 AS a2 WHERE a1.id=a2.id; DELETE FROM a1, a2 USING t1 AS a1 INNER JOIN t2 AS a2 WHERE a1.id=a2.id;
Incorrect:
DELETE t1 AS a1, t2 AS a2 FROM t1 INNER JOIN t2 WHERE a1.id=a2.id; DELETE FROM t1 AS a1, t2 AS a2 USING t1 INNER JOIN t2 WHERE a1.id=a2.id;
Declaration of aliases other than in the
table_references
part of the statement
should be avoided because that can lead to ambiguous statements
that have unexpected results such as deleting rows from the wrong
table. This is such a statement:
DELETE t1 AS a2 FROM t1 AS a1 INNER JOIN t2 AS a2;
Before MySQL 5.5.3, alias declarations outside the
table_references
part of the statement
are disallowed for the USING
variant of
multiple-table DELETE
syntax. As of
MySQL 5.5.3, alias declarations outside
table_references
are disallowed for all
multiple-table DELETE
statements.
Before MySQL 5.5.3, for alias references in the list of tables
from which to delete rows in a multiple-table delete, the default
database is used unless one is specified explicitly. For example,
if the default database is db1
, the following
statement does not work because the unqualified alias reference
a2
is interpreted as having a database of
db1
:
DELETE a1, a2 FROM db1.t1 AS a1 INNER JOIN db2.t2 AS a2 WHERE a1.id=a2.id;
To correctly match an alias that refers to a table outside the default database, you must explicitly qualify the reference with the name of the proper database:
DELETE a1, db2.a2 FROM db1.t1 AS a1 INNER JOIN db2.t2 AS a2 WHERE a1.id=a2.id;
As of MySQL 5.5.3, alias resolution does not require qualification and alias references should not be qualified with the database name. Qualified names are interpreted as referring to tables, not aliases.
DOexpr
[,expr
] ...
DO
executes the expressions but
does not return any results. In most respects,
DO
is shorthand for SELECT
, but has the
advantage that it is slightly faster when you do not care about
the result.
expr
, ...
DO
is useful primarily with
functions that have side effects, such as
RELEASE_LOCK()
.
HANDLERtbl_name
OPEN [ [AS]alias
] HANDLERtbl_name
READindex_name
{ = | <= | >= | < | > } (value1
,value2
,...) [ WHEREwhere_condition
] [LIMIT ... ] HANDLERtbl_name
READindex_name
{ FIRST | NEXT | PREV | LAST } [ WHEREwhere_condition
] [LIMIT ... ] HANDLERtbl_name
READ { FIRST | NEXT } [ WHEREwhere_condition
] [LIMIT ... ] HANDLERtbl_name
CLOSE
The HANDLER
statement provides
direct access to table storage engine interfaces. It is available
for MyISAM
and InnoDB
tables.
The HANDLER ... OPEN
statement opens a table,
making it accessible using subsequent HANDLER ...
READ
statements. This table object is not shared by
other sessions and is not closed until the session calls
HANDLER ... CLOSE
or the session terminates. If
you open the table using an alias, further references to the open
table with other HANDLER
statements
must use the alias rather than the table name.
The first HANDLER ... READ
syntax fetches a row
where the index specified satisfies the given values and the
WHERE
condition is met. If you have a
multiple-column index, specify the index column values as a
comma-separated list. Either specify values for all the columns in
the index, or specify values for a leftmost prefix of the index
columns. Suppose that an index my_idx
includes
three columns named col_a
,
col_b
, and col_c
, in that
order. The HANDLER
statement can
specify values for all three columns in the index, or for the
columns in a leftmost prefix. For example:
HANDLER ... READ my_idx = (col_a_val,col_b_val,col_c_val) ... HANDLER ... READ my_idx = (col_a_val,col_b_val) ... HANDLER ... READ my_idx = (col_a_val) ...
To employ the HANDLER
interface to
refer to a table's PRIMARY KEY
, use the quoted
identifier `PRIMARY`
:
HANDLER tbl_name
READ `PRIMARY` ...
The second HANDLER ... READ
syntax fetches a
row from the table in index order that matches the
WHERE
condition.
The third HANDLER ... READ
syntax fetches a row
from the table in natural row order that matches the
WHERE
condition. It is faster than
HANDLER
when a full table
scan is desired. Natural row order is the order in which rows are
stored in a tbl_name
READ
index_name
MyISAM
table data file. This
statement works for InnoDB
tables as well, but
there is no such concept because there is no separate data file.
Without a LIMIT
clause, all forms of
HANDLER ... READ
fetch a single row if one is
available. To return a specific number of rows, include a
LIMIT
clause. It has the same syntax as for the
SELECT
statement. See
Section 12.2.9, “SELECT
Синтаксис”.
HANDLER ... CLOSE
closes a table that was
opened with HANDLER ... OPEN
.
There are several reasons to use the
HANDLER
interface instead of normal
SELECT
statements:
HANDLER
is faster thanSELECT
:A designated storage engine handler object is allocated for the
HANDLER ... OPEN
. The object is reused for subsequentHANDLER
statements for that table; it need not be reinitialized for each one.There is less parsing involved.
There is no optimizer or query-checking overhead.
The table does not have to be locked between two handler requests.
The handler interface does not have to provide a consistent look of the data (for example, dirty reads are permitted), so the storage engine can use optimizations that
SELECT
does not normally permit.
For applications that use a low-level
ISAM
-like interface,HANDLER
makes it much easier to port them to MySQL.HANDLER
enables you to traverse a database in a manner that is difficult (or even impossible) to accomplish withSELECT
. TheHANDLER
interface is a more natural way to look at data when working with applications that provide an interactive user interface to the database.
HANDLER
is a somewhat low-level
statement. For example, it does not provide consistency. That is,
HANDLER ... OPEN
does not
take a snapshot of the table, and does not
lock the table. This means that after a HANDLER ...
OPEN
statement is issued, table data can be modified (by
the current session or other sessions) and these modifications
might be only partially visible to HANDLER ...
NEXT
or HANDLER ... PREV
scans.
An open handler can be closed and marked for reopen, in which case the handler loses its position in the table. This occurs when both of the following circumstances are true:
Any session executes
FLUSH TABLES
or DDL statements on the handler's table.The session in which the handler is open executes non-
HANDLER
statements that use tables.
TRUNCATE TABLE
for a table closes
all handlers for the table that were opened with
HANDLER OPEN
.
If a table is flushed with
FLUSH TABLES
was
opened with tbl_name
WITH READ LOCKHANDLER
, the handler is
implicitly flushed and loses its position.
INSERT [LOW_PRIORITY | DELAYED | HIGH_PRIORITY] [IGNORE] [INTO]tbl_name
[(col_name
,...)] {VALUES | VALUE} ({expr
| DEFAULT},...),(...),... [ ON DUPLICATE KEY UPDATEcol_name
=expr
[,col_name
=expr
] ... ]
Or:
INSERT [LOW_PRIORITY | DELAYED | HIGH_PRIORITY] [IGNORE] [INTO]tbl_name
SETcol_name
={expr
| DEFAULT}, ... [ ON DUPLICATE KEY UPDATEcol_name
=expr
[,col_name
=expr
] ... ]
Or:
INSERT [LOW_PRIORITY | HIGH_PRIORITY] [IGNORE] [INTO]tbl_name
[(col_name
,...)] SELECT ... [ ON DUPLICATE KEY UPDATEcol_name
=expr
[,col_name
=expr
] ... ]
INSERT
inserts new rows into an
existing table. The INSERT
... VALUES
and
INSERT ... SET
forms of the statement insert rows based on explicitly specified
values. The INSERT
... SELECT
form inserts rows selected from another table
or tables. INSERT
... SELECT
is discussed further in
Section 12.2.5.1, “INSERT ...
SELECT
Синтаксис”.
You can use REPLACE
instead of
INSERT
to overwrite old rows.
REPLACE
is the counterpart to
INSERT IGNORE
in
the treatment of new rows that contain unique key values that
duplicate old rows: The new rows are used to replace the old rows
rather than being discarded. See Section 12.2.8, “REPLACE
Синтаксис”.
tbl_name
is the table into which rows
should be inserted. The columns for which the statement provides
values can be specified as follows:
You can provide a comma-separated list of column names following the table name. In this case, a value for each named column must be provided by the
VALUES
list or theSELECT
statement.If you do not specify a list of column names for
INSERT ... VALUES
orINSERT ... SELECT
, values for every column in the table must be provided by theVALUES
list or theSELECT
statement. If you do not know the order of the columns in the table, useDESCRIBE
to find out.tbl_name
The
SET
clause indicates the column names explicitly.
Column values can be given in several ways:
If you are not running in strict SQL mode, any column not explicitly given a value is set to its default (explicit or implicit) value. For example, if you specify a column list that does not name all the columns in the table, unnamed columns are set to their default values. Default value assignment is described in Section 10.1.4, “Data Type Default Values”. See also Section 1.8.6.2, “Constraints on Invalid Data”.
If you want an
INSERT
statement to generate an error unless you explicitly specify values for all columns that do not have a default value, you should use strict mode. See Section 5.1.6, “Server SQL Modes”.Use the keyword
DEFAULT
to set a column explicitly to its default value. This makes it easier to writeINSERT
statements that assign values to all but a few columns, because it enables you to avoid writing an incompleteVALUES
list that does not include a value for each column in the table. Otherwise, you would have to write out the list of column names corresponding to each value in theVALUES
list.You can also use
DEFAULT(
as a more general form that can be used in expressions to produce a given column's default value.col_name
)If both the column list and the
VALUES
list are empty,INSERT
creates a row with each column set to its default value:INSERT INTO
tbl_name
() VALUES();In strict mode, an error occurs if any column doesn't have a default value. Otherwise, MySQL uses the implicit default value for any column that does not have an explicitly defined default.
You can specify an expression
expr
to provide a column value. This might involve type conversion if the type of the expression does not match the type of the column, and conversion of a given value can result in different inserted values depending on the data type. For example, inserting the string'1999.0e-2'
into anINT
,FLOAT
,DECIMAL(10,6)
, orYEAR
column results in the values1999
,19.9921
,19.992100
, and1999
being inserted, respectively. The reason the value stored in theINT
andYEAR
columns is1999
is that the string-to-integer conversion looks only at as much of the initial part of the string as may be considered a valid integer or year. For the floating-point and fixed-point columns, the string-to-floating-point conversion considers the entire string a valid floating-point value.An expression
expr
can refer to any column that was set earlier in a value list. For example, you can do this because the value forcol2
refers tocol1
, which has previously been assigned:INSERT INTO
tbl_name
(col1,col2) VALUES(15,col1*2);But the following is not legal, because the value for
col1
refers tocol2
, which is assigned aftercol1
:INSERT INTO
tbl_name
(col1,col2) VALUES(col2*2,15);One exception involves columns that contain
AUTO_INCREMENT
values. Because theAUTO_INCREMENT
value is generated after other value assignments, any reference to anAUTO_INCREMENT
column in the assignment returns a0
.
INSERT
statements that use
VALUES
syntax can insert multiple rows. To do
this, include multiple lists of column values, each enclosed
within parentheses and separated by commas. Пример:
INSERT INTO tbl_name
(a,b,c) VALUES(1,2,3),(4,5,6),(7,8,9);
The values list for each row must be enclosed within parentheses. The following statement is illegal because the number of values in the list does not match the number of column names:
INSERT INTO tbl_name
(a,b,c) VALUES(1,2,3,4,5,6,7,8,9);
VALUE
is a synonym for
VALUES
in this context. Neither implies
anything about the number of values lists, and either may be used
whether there is a single values list or multiple lists.
The affected-rows value for an
INSERT
can be obtained using the
ROW_COUNT()
function (see
Section 11.14, “Information Functions”), or the
mysql_affected_rows()
C API
function (see Section 21.9.3.1, “mysql_affected_rows()
”).
If you use an INSERT ...
VALUES
statement with multiple value lists or
INSERT ...
SELECT
, the statement returns an information string in
this format:
Records: 100 Duplicates: 0 Warnings: 0
Records
indicates the number of rows processed
by the statement. (This is not necessarily the number of rows
actually inserted because Duplicates
can be
nonzero.) Duplicates
indicates the number of
rows that could not be inserted because they would duplicate some
existing unique index value. Warnings
indicates
the number of attempts to insert column values that were
problematic in some way. Warnings can occur under any of the
following conditions:
Inserting
NULL
into a column that has been declaredNOT NULL
. For multiple-rowINSERT
statements orINSERT INTO ... SELECT
statements, the column is set to the implicit default value for the column data type. This is0
for numeric types, the empty string (''
) for string types, and the “zero” value for date and time types.INSERT INTO ... SELECT
statements are handled the same way as multiple-row inserts because the server does not examine the result set from theSELECT
to see whether it returns a single row. (For a single-rowINSERT
, no warning occurs whenNULL
is inserted into aNOT NULL
column. Instead, the statement fails with an error.)Setting a numeric column to a value that lies outside the column's range. The value is clipped to the closest endpoint of the range.
Assigning a value such as
'10.34 a'
to a numeric column. The trailing nonnumeric text is stripped off and the remaining numeric part is inserted. If the string value has no leading numeric part, the column is set to0
.Inserting a string into a string column (
CHAR
,VARCHAR
,TEXT
, orBLOB
) that exceeds the column's maximum length. The value is truncated to the column's maximum length.Inserting a value into a date or time column that is illegal for the data type. The column is set to the appropriate zero value for the type.
If you are using the C API, the information string can be obtained
by invoking the mysql_info()
function. See Section 21.9.3.35, “mysql_info()
”.
If INSERT
inserts a row into a
table that has an AUTO_INCREMENT
column, you
can find the value used for that column by using the SQL
LAST_INSERT_ID()
function. From
within the C API, use the
mysql_insert_id()
function.
However, you should note that the two functions do not always
behave identically. The behavior of
INSERT
statements with respect to
AUTO_INCREMENT
columns is discussed further in
Section 11.14, “Information Functions”, and
Section 21.9.3.37, “mysql_insert_id()
”.
The INSERT
statement supports the
following modifiers:
If you use the
DELAYED
keyword, the server puts the row or rows to be inserted into a buffer, and the client issuing theINSERT DELAYED
statement can then continue immediately. If the table is in use, the server holds the rows. When the table is free, the server begins inserting rows, checking periodically to see whether there are any new read requests for the table. If there are, the delayed row queue is suspended until the table becomes free again. See Section 12.2.5.2, “INSERT DELAYED
Синтаксис”.DELAYED
is ignored withINSERT ... SELECT
orINSERT ... ON DUPLICATE KEY UPDATE
.DELAYED
is also disregarded for anINSERT
that uses functions accessing tables or triggers, or that is called from a function or a trigger.If you use the
LOW_PRIORITY
keyword, execution of theINSERT
is delayed until no other clients are reading from the table. This includes other clients that began reading while existing clients are reading, and while theINSERT LOW_PRIORITY
statement is waiting. It is possible, therefore, for a client that issues anINSERT LOW_PRIORITY
statement to wait for a very long time (or even forever) in a read-heavy environment. (This is in contrast toINSERT DELAYED
, which lets the client continue at once. Note thatLOW_PRIORITY
should normally not be used withMyISAM
tables because doing so disables concurrent inserts. See Section 7.10.3, “Concurrent Inserts”.If you specify
HIGH_PRIORITY
, it overrides the effect of the--low-priority-updates
option if the server was started with that option. It also causes concurrent inserts not to be used. See Section 7.10.3, “Concurrent Inserts”.LOW_PRIORITY
andHIGH_PRIORITY
affect only storage engines that use only table-level locking (such asMyISAM
,MEMORY
, andMERGE
).If you use the
IGNORE
keyword, errors that occur while executing theINSERT
statement are treated as warnings instead. For example, withoutIGNORE
, a row that duplicates an existingUNIQUE
index orPRIMARY KEY
value in the table causes a duplicate-key error and the statement is aborted. WithIGNORE
, the row still is not inserted, but no error is issued.IGNORE
has a similar effect on inserts into partitioned tables where no partition matching a given value is found. WithoutIGNORE
, suchINSERT
statements are aborted with an error; however, whenINSERT IGNORE
is used, the insert operation fails silently for the row containing the unmatched value, but any rows that are matched are inserted. For an example, see Section 17.2.2, “LIST
Partitioning”.Data conversions that would trigger errors abort the statement if
IGNORE
is not specified. WithIGNORE
, invalid values are adjusted to the closest values and inserted; warnings are produced but the statement does not abort. You can determine with themysql_info()
C API function how many rows were actually inserted into the table.If you specify
ON DUPLICATE KEY UPDATE
, and a row is inserted that would cause a duplicate value in aUNIQUE
index orPRIMARY KEY
, anUPDATE
of the old row is performed. The affected-rows value per row is 1 if the row is inserted as a new row and 2 if an existing row is updated. See Section 12.2.5.3, “INSERT ... ON DUPLICATE KEY UPDATE
Синтаксис”.
Inserting into a table requires the
INSERT
privilege for the table. If
the ON DUPLICATE KEY UPDATE
clause is used and
a duplicate key causes an UPDATE
to
be performed instead, the statement requires the
UPDATE
privilege for the columns to
be updated. For columns that are read but not modified you need
only the SELECT
privilege (such as
for a column referenced only on the right hand side of an
col_name
=expr
assignment in an ON DUPLICATE KEY UPDATE
clause).
INSERT [LOW_PRIORITY | HIGH_PRIORITY] [IGNORE] [INTO]tbl_name
[(col_name
,...)] SELECT ... [ ON DUPLICATE KEY UPDATEcol_name
=expr
, ... ]
With INSERT ...
SELECT
, you can quickly insert many rows into a table
from one or many tables. For example:
INSERT INTO tbl_temp2 (fld_id) SELECT tbl_temp1.fld_order_id FROM tbl_temp1 WHERE tbl_temp1.fld_order_id > 100;
The following conditions hold for a
INSERT ...
SELECT
statements:
Specify
IGNORE
to ignore rows that would cause duplicate-key violations.DELAYED
is ignored withINSERT ... SELECT
.The target table of the
INSERT
statement may appear in theFROM
clause of theSELECT
part of the query. (This was not possible in some older versions of MySQL.) However, you cannot insert into a table and select from the same table in a subquery.When selecting from and inserting into a table at the same time, MySQL creates a temporary table to hold the rows from the
SELECT
and then inserts those rows into the target table. However, it remains true that you cannot useINSERT INTO t ... SELECT ... FROM t
whent
is aTEMPORARY
table, becauseTEMPORARY
tables cannot be referred to twice in the same statement (see Section C.5.7.2, “TEMPORARY
Table Problems”).AUTO_INCREMENT
columns work as usual.To ensure that the binary log can be used to re-create the original tables, MySQL does not permit concurrent inserts for
INSERT ... SELECT
statements.To avoid ambiguous column reference problems when the
SELECT
and theINSERT
refer to the same table, provide a unique alias for each table used in theSELECT
part, and qualify column names in that part with the appropriate alias.
In the values part of ON DUPLICATE KEY
UPDATE
, you can refer to columns in other tables, as
long as you do not use GROUP BY
in the
SELECT
part. One side effect is
that you must qualify nonunique column names in the values part.
The order in which rows are returned by a
SELECT
statement with no
ORDER BY
clause is not determined. This means
that, when using replication, there is no guarantee that such a
SELECT
returns rows in the same order on the
master and the slave; this can lead to inconsistencies between
them. To prevent this from occurring, you should always write
INSERT ... SELECT
statements that are to be
replicated as INSERT ... SELECT ... ORDER BY
. The choice of
column
column
does not matter as long as the
same order for returning the rows is enforced on both the master
and the slave. See also
Section 15.4.1.12, “Replication and LIMIT
”.
Due to this issue, beginning with MySQL 5.5.18,
INSERT ...
SELECT ON DUPLICATE KEY UPDATE
and
INSERT IGNORE ...
SELECT
statements are flagged as unsafe for
statement-based replication. With this change, such statements
produce a warning in the log when using statement-based mode and
are logged using the row-based format when using
MIXED
mode. (Bug #11758262, Bug #50439)
See also Section 15.1.2.1, “Advantages and Disadvantages of Statement-Based and Row-Based Replication”.
INSERT DELAYED ...
The DELAYED
option for the
INSERT
statement is a MySQL
extension to standard SQL that is very useful if you have
clients that cannot or need not wait for the
INSERT
to complete. This is a
common situation when you use MySQL for logging and you also
periodically run SELECT
and
UPDATE
statements that take a
long time to complete.
When a client uses INSERT
DELAYED
, it gets an okay from the server at once, and
the row is queued to be inserted when the table is not in use by
any other thread.
Another major benefit of using INSERT
DELAYED
is that inserts from many clients are bundled
together and written in one block. This is much faster than
performing many separate inserts.
Note that INSERT DELAYED
is
slower than a normal INSERT
if
the table is not otherwise in use. There is also the additional
overhead for the server to handle a separate thread for each
table for which there are delayed rows. This means that you
should use INSERT DELAYED
only
when you are really sure that you need it.
The queued rows are held only in memory until they are inserted
into the table. This means that if you terminate
mysqld forcibly (for example, with
kill -9
) or if mysqld dies
unexpectedly, any queued rows that have not been
written to disk are lost.
There are some constraints on the use of
DELAYED
:
INSERT DELAYED
works only withMyISAM
,MEMORY
,ARCHIVE
, andBLACKHOLE
tables. For engines that do not supportDELAYED
, an error occurs.An error occurs for
INSERT DELAYED
if used with a table that has been locked withLOCK TABLES
because the insert must be handled by a separate thread, not by the session that holds the lock.For
MyISAM
tables, if there are no free blocks in the middle of the data file, concurrentSELECT
andINSERT
statements are supported. Under these circumstances, you very seldom need to useINSERT DELAYED
withMyISAM
.INSERT DELAYED
should be used only forINSERT
statements that specify value lists. The server ignoresDELAYED
forINSERT ... SELECT
orINSERT ... ON DUPLICATE KEY UPDATE
statements.Because the
INSERT DELAYED
statement returns immediately, before the rows are inserted, you cannot useLAST_INSERT_ID()
to get theAUTO_INCREMENT
value that the statement might generate.DELAYED
rows are not visible toSELECT
statements until they actually have been inserted.Prior to MySQL 5.5.7,
INSERT DELAYED
was treated as a normalINSERT
if the statement inserted multiple rows, binary logging was enabled, and the global logging format was statement-based (that is, wheneverbinlog_format
was set toSTATEMENT
). Beginning with MySQL 5.5.7,INSERT DELAYED
is always handled as a simpleINSERT
(that is, without theDELAYED
option) whenever the value ofbinlog_format
isSTATEMENT
orMIXED
. (In the latter case, the statement no longer triggers a switch to row-based logging, and so is logged using the statement-based format.)This does not apply when using row-based binary logging mode (
binlog_format
set toROW
), in whichINSERT DELAYED
statements are always executed using theDELAYED
option as specified, and logged as row-update events.DELAYED
is ignored on slave replication servers, so thatINSERT DELAYED
is treated as a normalINSERT
on slaves. This is becauseDELAYED
could cause the slave to have different data than the master.Pending
INSERT DELAYED
statements are lost if a table is write locked andALTER TABLE
is used to modify the table structure.INSERT DELAYED
is not supported for views.INSERT DELAYED
is not supported for partitioned tables.
The following describes in detail what happens when you use the
DELAYED
option to
INSERT
or
REPLACE
. In this description, the
“thread” is the thread that received an
INSERT DELAYED
statement and
“handler” is the thread that handles all
INSERT DELAYED
statements for a
particular table.
When a thread executes a
DELAYED
statement for a table, a handler thread is created to process allDELAYED
statements for the table, if no such handler already exists.The thread checks whether the handler has previously acquired a
DELAYED
lock; if not, it tells the handler thread to do so. TheDELAYED
lock can be obtained even if other threads have aREAD
orWRITE
lock on the table. However, the handler waits for allALTER TABLE
locks orFLUSH TABLES
statements to finish, to ensure that the table structure is up to date.The thread executes the
INSERT
statement, but instead of writing the row to the table, it puts a copy of the final row into a queue that is managed by the handler thread. Any syntax errors are noticed by the thread and reported to the client program.The client cannot obtain from the server the number of duplicate rows or the
AUTO_INCREMENT
value for the resulting row, because theINSERT
returns before the insert operation has been completed. (If you use the C API, themysql_info()
function does not return anything meaningful, for the same reason.)The binary log is updated by the handler thread when the row is inserted into the table. In case of multiple-row inserts, the binary log is updated when the first row is inserted.
Each time that
delayed_insert_limit
rows are written, the handler checks whether anySELECT
statements are still pending. If so, it permits these to execute before continuing.When the handler has no more rows in its queue, the table is unlocked. If no new
INSERT DELAYED
statements are received withindelayed_insert_timeout
seconds, the handler terminates.If more than
delayed_queue_size
rows are pending in a specific handler queue, the thread requestingINSERT DELAYED
waits until there is room in the queue. This is done to ensure that mysqld does not use all memory for the delayed memory queue.The handler thread shows up in the MySQL process list with
delayed_insert
in theCommand
column. It is killed if you execute aFLUSH TABLES
statement or kill it withKILL
. However, before exiting, it first stores all queued rows into the table. During this time it does not accept any newthread_id
INSERT
statements from other threads. If you execute anINSERT DELAYED
statement after this, a new handler thread is created.Note that this means that
INSERT DELAYED
statements have higher priority than normalINSERT
statements if there is anINSERT DELAYED
handler running. Other update statements have to wait until theINSERT DELAYED
queue is empty, someone terminates the handler thread (withKILL
), or someone executes athread_id
FLUSH TABLES
.The following status variables provide information about
INSERT DELAYED
statements.Status Variable Meaning Delayed_insert_threads
Number of handler threads Delayed_writes
Number of rows written with INSERT DELAYED
Not_flushed_delayed_rows
Number of rows waiting to be written You can view these variables by issuing a
SHOW STATUS
statement or by executing a mysqladmin extended-status command.
If you specify ON DUPLICATE KEY UPDATE
, and a
row is inserted that would cause a duplicate value in a
UNIQUE
index or PRIMARY
KEY
, MySQL performs an
UPDATE
of the old row. For
example, if column a
is declared as
UNIQUE
and contains the value
1
, the following two statements have similar
effect:
INSERT INTO table (a,b,c) VALUES (1,2,3) ON DUPLICATE KEY UPDATE c=c+1; UPDATE table SET c=c+1 WHERE a=1;
(The effects are not identical for an InnoDB
table where a
is an auto-increment column.
With an auto-increment column, an INSERT
statement increases the auto-increment value but
UPDATE
does not.)
The ON DUPLICATE KEY UPDATE
clause can
contain multiple column assignments, separated by commas.
With ON DUPLICATE KEY UPDATE
, the
affected-rows value per row is 1 if the row is inserted as a new
row, and 2 if an existing row is updated.
If column b
is also unique, the
INSERT
is equivalent to this
UPDATE
statement instead:
UPDATE table SET c=c+1 WHERE a=1 OR b=2 LIMIT 1;
If a=1 OR b=2
matches several rows, only
one row is updated. In general, you should
try to avoid using an ON DUPLICATE KEY UPDATE
clause on tables with multiple unique indexes.
You can use the
VALUES(
function in the col_name
)UPDATE
clause to
refer to column values from the
INSERT
portion of the
INSERT ...
ON DUPLICATE KEY UPDATE
statement. In other words,
VALUES(
in the col_name
)ON DUPLICATE KEY UPDATE
clause refers
to the value of col_name
that would
be inserted, had no duplicate-key conflict occurred. This
function is especially useful in multiple-row inserts. The
VALUES()
function is meaningful
only in INSERT ... UPDATE
statements and
returns NULL
otherwise. Пример:
INSERT INTO table (a,b,c) VALUES (1,2,3),(4,5,6) ON DUPLICATE KEY UPDATE c=VALUES(a)+VALUES(b);
That statement is identical to the following two statements:
INSERT INTO table (a,b,c) VALUES (1,2,3) ON DUPLICATE KEY UPDATE c=3; INSERT INTO table (a,b,c) VALUES (4,5,6) ON DUPLICATE KEY UPDATE c=9;
If a table contains an AUTO_INCREMENT
column
and INSERT
... ON DUPLICATE KEY UPDATE
inserts or updates a row,
the LAST_INSERT_ID()
function
returns the AUTO_INCREMENT
value.
The DELAYED
option is ignored when you use
ON DUPLICATE KEY UPDATE
.
Because the results of
INSERT ...
SELECT
statements depend on the ordering of rows from
the SELECT
and this order cannot
always be guaranteed, it is possible when logging
INSERT ...
SELECT ON DUPLICATE KEY UPDATE
statements for the
master and the slave to diverge. Thus, in MySQL 5.5.18 and
later,
INSERT ...
SELECT ON DUPLICATE KEY UPDATE
statements are flagged
as unsafe for statement-based replication. With this change,
such statements produce a warning in the log when using
statement-based mode and are logged using the row-based format
when using MIXED
mode. See also
Section 15.1.2.1, “Advantages and Disadvantages of Statement-Based and Row-Based
Replication”.
LOAD DATA [LOW_PRIORITY | CONCURRENT] [LOCAL] INFILE 'file_name
' [REPLACE | IGNORE] INTO TABLEtbl_name
[CHARACTER SETcharset_name
] [{FIELDS | COLUMNS} [TERMINATED BY 'string
'] [[OPTIONALLY] ENCLOSED BY 'char
'] [ESCAPED BY 'char
'] ] [LINES [STARTING BY 'string
'] [TERMINATED BY 'string
'] ] [IGNOREnumber
LINES] [(col_name_or_user_var
,...)] [SETcol_name
=expr
,...]
The LOAD DATA
INFILE
statement reads rows from a text file into a
table at a very high speed. The file name must be given as a
literal string.
LOAD DATA
INFILE
is the complement of
SELECT ... INTO
OUTFILE
. (See Section 12.2.9, “SELECT
Синтаксис”.) To write data
from a table to a file, use
SELECT ... INTO
OUTFILE
. To read the file back into a table, use
LOAD DATA
INFILE
. The syntax of the FIELDS
and
LINES
clauses is the same for both statements.
Both clauses are optional, but FIELDS
must
precede LINES
if both are specified.
For more information about the efficiency of
INSERT
versus
LOAD DATA
INFILE
and speeding up
LOAD DATA
INFILE
, see Section 7.2.2.1, “Speed of INSERT
Statements”.
The character set indicated by the
character_set_database
system
variable is used to interpret the information in the file.
SET NAMES
and the setting of
character_set_client
do not
affect interpretation of input. If the contents of the input file
use a character set that differs from the default, it is usually
preferable to specify the character set of the file by using the
CHARACTER SET
clause. A character set of
binary
specifies “no conversion.”
LOAD DATA
INFILE
interprets all fields in the file as having the
same character set, regardless of the data types of the columns
into which field values are loaded. For proper interpretation of
file contents, you must ensure that it was written with the
correct character set. For example, if you write a data file with
mysqldump -T or by issuing a
SELECT ... INTO
OUTFILE
statement in mysql, be sure
to use a --default-character-set
option with
mysqldump or mysql so that
output is written in the character set to be used when the file is
loaded with LOAD DATA
INFILE
.
It is not possible to load data files that use the
ucs2
, utf16
, or
utf32
character set.
The character_set_filesystem
system variable controls the interpretation of the file name.
You can also load data files by using the
mysqlimport utility; it operates by sending a
LOAD DATA
INFILE
statement to the server. The
--local
option causes
mysqlimport to read data files from the client
host. You can specify the
--compress
option to get
better performance over slow networks if the client and server
support the compressed protocol. See
Section 4.5.5, “mysqlimport — A Data Import Program”.
If you use LOW_PRIORITY
, execution of the
LOAD DATA
statement is delayed
until no other clients are reading from the table. This affects
only storage engines that use only table-level locking (such as
MyISAM
, MEMORY
, and
MERGE
).
If you specify CONCURRENT
with a
MyISAM
table that satisfies the condition for
concurrent inserts (that is, it contains no free blocks in the
middle), other threads can retrieve data from the table while
LOAD DATA
is executing. Using this
option affects the performance of LOAD
DATA
a bit, even if no other thread is using the table
at the same time.
Prior to MySQL 5.5.1, CONCURRENT
was not
replicated when using statement-based replication (see Bug
#34628). However, it is replicated when using row-based
replication, regardless of the version. See
Section 15.4.1.13, “Replication and LOAD DATA
INFILE
”, for more
information.
The LOCAL
keyword, if specified, is interpreted
with respect to the client end of the connection:
If
LOCAL
is specified, the file is read by the client program on the client host and sent to the server. The file can be given as a full path name to specify its exact location. If given as a relative path name, the name is interpreted relative to the directory in which the client program was started.When using
LOCAL
withLOAD DATA
, a copy of the file is created in the server's temporary directory. This is not the directory determined by the value oftmpdir
orslave_load_tmpdir
, but rather the operating system's temporary directory, and is not configurable in the MySQL Server. (Typically the system temporary directory is/tmp
on Linux systems andC:\WINDOWS\TEMP
on Windows.) Lack of sufficient space for the copy in this directory can cause theLOAD DATA LOCAL
statement to fail.If
LOCAL
is not specified, the file must be located on the server host and is read directly by the server. The server uses the following rules to locate the file:If the file name is an absolute path name, the server uses it as given.
If the file name is a relative path name with one or more leading components, the server searches for the file relative to the server's data directory.
If a file name with no leading components is given, the server looks for the file in the database directory of the default database.
Note that, in the non-LOCAL
case, these rules
mean that a file named as ./myfile.txt
is
read from the server's data directory, whereas the file named as
myfile.txt
is read from the database
directory of the default database. For example, if
db1
is the default database, the following
LOAD DATA
statement reads the file
data.txt
from the database directory for
db1
, even though the statement explicitly loads
the file into a table in the db2
database:
LOAD DATA INFILE 'data.txt' INTO TABLE db2.my_table;
Windows path names are specified using forward slashes rather than backslashes. If you do use backslashes, you must double them.
For security reasons, when reading text files located on the
server, the files must either reside in the database directory or
be readable by all. Also, to use
LOAD DATA
INFILE
on server files, you must have the
FILE
privilege. See
Section 5.4.1, “Privileges Provided by MySQL”. For
non-LOCAL
load operations, if the
secure_file_priv
system variable
is set to a nonempty directory name, the file to be loaded must be
located in that directory.
Using LOCAL
is a bit slower than letting the
server access the files directly, because the contents of the file
must be sent over the connection by the client to the server. On
the other hand, you do not need the
FILE
privilege to load local files.
With LOCAL
, the default duplicate-key handling
behavior is the same as if IGNORE
is specified;
this is because the server has no way to stop transmission of the
file in the middle of the operation. IGNORE
is
explained further later in this section.
LOCAL
works only if your server and your client
both have been configured to permit it. For example, if
mysqld was started with
--local-infile=0
,
LOCAL
does not work. See
Section 5.3.5, “Security Issues with LOAD
DATA LOCAL
”.
On Unix, if you need LOAD DATA
to
read from a pipe, you can use the following technique (the example
loads a listing of the /
directory into the
table db1.t1
):
mkfifo /mysql/data/db1/ls.dat chmod 666 /mysql/data/db1/ls.dat find / -ls > /mysql/data/db1/ls.dat & mysql -e "LOAD DATA INFILE 'ls.dat' INTO TABLE t1" db1
Note that you must run the command that generates the data to be loaded and the mysql commands either on separate terminals, or run the data generation process in the background (as shown in the preceding example). If you do not do this, the pipe will block until data is read by the mysql process.
The REPLACE
and
IGNORE
keywords control handling of input rows
that duplicate existing rows on unique key values:
If you specify
REPLACE
, input rows replace existing rows. In other words, rows that have the same value for a primary key or unique index as an existing row. See Section 12.2.8, “REPLACE
Синтаксис”.If you specify
IGNORE
, input rows that duplicate an existing row on a unique key value are skipped. If you do not specify either option, the behavior depends on whether theLOCAL
keyword is specified. WithoutLOCAL
, an error occurs when a duplicate key value is found, and the rest of the text file is ignored. WithLOCAL
, the default behavior is the same as ifIGNORE
is specified; this is because the server has no way to stop transmission of the file in the middle of the operation.
If you want to ignore foreign key constraints during the load
operation, you can issue a SET foreign_key_checks =
0
statement before executing LOAD
DATA
.
If you use LOAD DATA
INFILE
on an empty MyISAM
table, all
nonunique indexes are created in a separate batch (as for
REPAIR TABLE
). Normally, this makes
LOAD DATA
INFILE
much faster when you have many indexes. In some
extreme cases, you can create the indexes even faster by turning
them off with ALTER TABLE ... DISABLE KEYS
before loading the file into the table and using ALTER
TABLE ... ENABLE KEYS
to re-create the indexes after
loading the file. See Section 7.2.2.1, “Speed of INSERT
Statements”.
For both the LOAD DATA
INFILE
and
SELECT ... INTO
OUTFILE
statements, the syntax of the
FIELDS
and LINES
clauses is
the same. Both clauses are optional, but FIELDS
must precede LINES
if both are specified.
If you specify a FIELDS
clause, each of its
subclauses (TERMINATED BY
,
[OPTIONALLY] ENCLOSED BY
, and ESCAPED
BY
) is also optional, except that you must specify at
least one of them.
If you specify no FIELDS
or
LINES
clause, the defaults are the same as if
you had written this:
FIELDS TERMINATED BY '\t' ENCLOSED BY '' ESCAPED BY '\\' LINES TERMINATED BY '\n' STARTING BY ''
(Backslash is the MySQL escape character within strings in SQL
statements, so to specify a literal backslash, you must specify
two backslashes for the value to be interpreted as a single
backslash. The escape sequences '\t'
and
'\n'
specify tab and newline characters,
respectively.)
In other words, the defaults cause
LOAD DATA
INFILE
to act as follows when reading input:
Look for line boundaries at newlines.
Do not skip over any line prefix.
Break lines into fields at tabs.
Do not expect fields to be enclosed within any quoting characters.
Interpret characters preceded by the escape character “
\
” as escape sequences. For example, “\t
”, “\n
”, and “\\
” signify tab, newline, and backslash, respectively. See the discussion ofFIELDS ESCAPED BY
later for the full list of escape sequences.
Conversely, the defaults cause
SELECT ... INTO
OUTFILE
to act as follows when writing output:
Write tabs between fields.
Do not enclose fields within any quoting characters.
Use “
\
” to escape instances of tab, newline, or “\
” that occur within field values.Write newlines at the ends of lines.
If you have generated the text file on a Windows system, you
might have to use LINES TERMINATED BY '\r\n'
to read the file properly, because Windows programs typically
use two characters as a line terminator. Some programs, such as
WordPad, might use \r
as a
line terminator when writing files. To read such files, use
LINES TERMINATED BY '\r'
.
If all the lines you want to read in have a common prefix that you
want to ignore, you can use LINES STARTING BY
'
to skip over
the prefix, and anything before it. If a line
does not include the prefix, the entire line is skipped. Suppose
that you issue the following statement:
prefix_string
'
LOAD DATA INFILE '/tmp/test.txt' INTO TABLE test FIELDS TERMINATED BY ',' LINES STARTING BY 'xxx';
If the data file looks like this:
xxx"abc",1 something xxx"def",2 "ghi",3
The resulting rows will be ("abc",1)
and
("def",2)
. The third row in the file is skipped
because it does not contain the prefix.
The IGNORE
option can be used to ignore lines at the start of
the file. For example, you can use number
LINESIGNORE 1
LINES
to skip over an initial header line containing
column names:
LOAD DATA INFILE '/tmp/test.txt' INTO TABLE test IGNORE 1 LINES;
When you use SELECT
... INTO OUTFILE
in tandem with
LOAD DATA
INFILE
to write data from a database into a file and
then read the file back into the database later, the field- and
line-handling options for both statements must match. Otherwise,
LOAD DATA
INFILE
will not interpret the contents of the file
properly. Suppose that you use
SELECT ... INTO
OUTFILE
to write a file with fields delimited by commas:
SELECT * INTO OUTFILE 'data.txt' FIELDS TERMINATED BY ',' FROM table2;
To read the comma-delimited file back in, the correct statement would be:
LOAD DATA INFILE 'data.txt' INTO TABLE table2 FIELDS TERMINATED BY ',';
If instead you tried to read in the file with the statement shown
following, it wouldn't work because it instructs
LOAD DATA
INFILE
to look for tabs between fields:
LOAD DATA INFILE 'data.txt' INTO TABLE table2 FIELDS TERMINATED BY '\t';
The likely result is that each input line would be interpreted as a single field.
LOAD DATA
INFILE
can be used to read files obtained from external
sources. For example, many programs can export data in
comma-separated values (CSV) format, such that lines have fields
separated by commas and enclosed within double quotation marks,
with an initial line of column names. If the lines in such a file
are terminated by carriage return/newline pairs, the statement
shown here illustrates the field- and line-handling options you
would use to load the file:
LOAD DATA INFILE 'data.txt' INTO TABLE tbl_name
FIELDS TERMINATED BY ',' ENCLOSED BY '"'
LINES TERMINATED BY '\r\n'
IGNORE 1 LINES;
If the input values are not necessarily enclosed within quotation
marks, use OPTIONALLY
before the
ENCLOSED BY
keywords.
Any of the field- or line-handling options can specify an empty
string (''
). If not empty, the FIELDS
[OPTIONALLY] ENCLOSED BY
and FIELDS ESCAPED
BY
values must be a single character. The
FIELDS TERMINATED BY
, LINES STARTING
BY
, and LINES TERMINATED BY
values
can be more than one character. For example, to write lines that
are terminated by carriage return/linefeed pairs, or to read a
file containing such lines, specify a LINES TERMINATED BY
'\r\n'
clause.
To read a file containing jokes that are separated by lines
consisting of %%
, you can do this
CREATE TABLE jokes (a INT NOT NULL AUTO_INCREMENT PRIMARY KEY, joke TEXT NOT NULL); LOAD DATA INFILE '/tmp/jokes.txt' INTO TABLE jokes FIELDS TERMINATED BY '' LINES TERMINATED BY '\n%%\n' (joke);
FIELDS [OPTIONALLY] ENCLOSED BY
controls
quoting of fields. For output
(SELECT ... INTO
OUTFILE
), if you omit the word
OPTIONALLY
, all fields are enclosed by the
ENCLOSED BY
character. An example of such
output (using a comma as the field delimiter) is shown here:
"1","a string","100.20" "2","a string containing a , comma","102.20" "3","a string containing a \" quote","102.20" "4","a string containing a \", quote and comma","102.20"
If you specify OPTIONALLY
, the
ENCLOSED BY
character is used only to enclose
values from columns that have a string data type (such as
CHAR
,
BINARY
,
TEXT
, or
ENUM
):
1,"a string",100.20 2,"a string containing a , comma",102.20 3,"a string containing a \" quote",102.20 4,"a string containing a \", quote and comma",102.20
Note that occurrences of the ENCLOSED BY
character within a field value are escaped by prefixing them with
the ESCAPED BY
character. Also note that if you
specify an empty ESCAPED BY
value, it is
possible to inadvertently generate output that cannot be read
properly by LOAD DATA
INFILE
. For example, the preceding output just shown
would appear as follows if the escape character is empty. Observe
that the second field in the fourth line contains a comma
following the quote, which (erroneously) appears to terminate the
field:
1,"a string",100.20 2,"a string containing a , comma",102.20 3,"a string containing a " quote",102.20 4,"a string containing a ", quote and comma",102.20
For input, the ENCLOSED BY
character, if
present, is stripped from the ends of field values. (This is true
regardless of whether OPTIONALLY
is specified;
OPTIONALLY
has no effect on input
interpretation.) Occurrences of the ENCLOSED BY
character preceded by the ESCAPED BY
character
are interpreted as part of the current field value.
If the field begins with the ENCLOSED BY
character, instances of that character are recognized as
terminating a field value only if followed by the field or line
TERMINATED BY
sequence. To avoid ambiguity,
occurrences of the ENCLOSED BY
character within
a field value can be doubled and are interpreted as a single
instance of the character. For example, if ENCLOSED BY
'"'
is specified, quotation marks are handled as shown
here:
"The ""BIG"" boss" -> The "BIG" boss The "BIG" boss -> The "BIG" boss The ""BIG"" boss -> The ""BIG"" boss
FIELDS ESCAPED BY
controls how to read or write
special characters:
For input, if the
FIELDS ESCAPED BY
character is not empty, occurrences of that character are stripped and the following character is taken literally as part of a field value. Some two-character sequences that are exceptions, where the first character is the escape character. These sequences are shown in the following table (using “\
” for the escape character). The rules forNULL
handling are described later in this section.Character Escape Sequence \0
An ASCII NUL ( 0x00
) character\b
A backspace character \n
A newline (linefeed) character \r
A carriage return character \t
A tab character. \Z
ASCII 26 (Control+Z) \N
NULL For more information about “
\
”-escape syntax, see Section 8.1.1, “String Literals”.If the
FIELDS ESCAPED BY
character is empty, escape-sequence interpretation does not occur.For output, if the
FIELDS ESCAPED BY
character is not empty, it is used to prefix the following characters on output:The
FIELDS ESCAPED BY
characterThe
FIELDS [OPTIONALLY] ENCLOSED BY
characterThe first character of the
FIELDS TERMINATED BY
andLINES TERMINATED BY
valuesASCII
0
(what is actually written following the escape character is ASCII “0
”, not a zero-valued byte)
If the
FIELDS ESCAPED BY
character is empty, no characters are escaped andNULL
is output asNULL
, not\N
. It is probably not a good idea to specify an empty escape character, particularly if field values in your data contain any of the characters in the list just given.
In certain cases, field- and line-handling options interact:
If
LINES TERMINATED BY
is an empty string andFIELDS TERMINATED BY
is nonempty, lines are also terminated withFIELDS TERMINATED BY
.If the
FIELDS TERMINATED BY
andFIELDS ENCLOSED BY
values are both empty (''
), a fixed-row (nondelimited) format is used. With fixed-row format, no delimiters are used between fields (but you can still have a line terminator). Instead, column values are read and written using a field width wide enough to hold all values in the field. ForTINYINT
,SMALLINT
,MEDIUMINT
,INT
, andBIGINT
, the field widths are 4, 6, 8, 11, and 20, respectively, no matter what the declared display width is.LINES TERMINATED BY
is still used to separate lines. If a line does not contain all fields, the rest of the columns are set to their default values. If you do not have a line terminator, you should set this to''
. In this case, the text file must contain all fields for each row.Fixed-row format also affects handling of
NULL
values, as described later. Note that fixed-size format does not work if you are using a multi-byte character set.
Handling of NULL
values varies according to the
FIELDS
and LINES
options in
use:
For the default
FIELDS
andLINES
values,NULL
is written as a field value of\N
for output, and a field value of\N
is read asNULL
for input (assuming that theESCAPED BY
character is “\
”).If
FIELDS ENCLOSED BY
is not empty, a field containing the literal wordNULL
as its value is read as aNULL
value. This differs from the wordNULL
enclosed withinFIELDS ENCLOSED BY
characters, which is read as the string'NULL'
.If
FIELDS ESCAPED BY
is empty,NULL
is written as the wordNULL
.With fixed-row format (which is used when
FIELDS TERMINATED BY
andFIELDS ENCLOSED BY
are both empty),NULL
is written as an empty string. Note that this causes bothNULL
values and empty strings in the table to be indistinguishable when written to the file because both are written as empty strings. If you need to be able to tell the two apart when reading the file back in, you should not use fixed-row format.
An attempt to load NULL
into a NOT
NULL
column causes assignment of the implicit default
value for the column's data type and a warning, or an error in
strict SQL mode. Implicit default values are discussed in
Section 10.1.4, “Data Type Default Values”.
Some cases are not supported by
LOAD DATA
INFILE
:
Fixed-size rows (
FIELDS TERMINATED BY
andFIELDS ENCLOSED BY
both empty) andBLOB
orTEXT
columns.If you specify one separator that is the same as or a prefix of another,
LOAD DATA INFILE
cannot interpret the input properly. For example, the followingFIELDS
clause would cause problems:FIELDS TERMINATED BY '"' ENCLOSED BY '"'
If
FIELDS ESCAPED BY
is empty, a field value that contains an occurrence ofFIELDS ENCLOSED BY
orLINES TERMINATED BY
followed by theFIELDS TERMINATED BY
value causesLOAD DATA INFILE
to stop reading a field or line too early. This happens becauseLOAD DATA INFILE
cannot properly determine where the field or line value ends.
The following example loads all columns of the
persondata
table:
LOAD DATA INFILE 'persondata.txt' INTO TABLE persondata;
By default, when no column list is provided at the end of the
LOAD DATA
INFILE
statement, input lines are expected to contain a
field for each table column. If you want to load only some of a
table's columns, specify a column list:
LOAD DATA INFILE 'persondata.txt' INTO TABLE persondata (col1,col2,...);
You must also specify a column list if the order of the fields in the input file differs from the order of the columns in the table. Otherwise, MySQL cannot tell how to match input fields with table columns.
The column list can contain either column names or user variables.
With user variables, the SET
clause enables you
to perform transformations on their values before assigning the
result to columns.
User variables in the SET
clause can be used in
several ways. The following example uses the first input column
directly for the value of t1.column1
, and
assigns the second input column to a user variable that is
subjected to a division operation before being used for the value
of t1.column2
:
LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, @var1) SET column2 = @var1/100;
The SET
clause can be used to supply values not
derived from the input file. The following statement sets
column3
to the current date and time:
LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, column2) SET column3 = CURRENT_TIMESTAMP;
You can also discard an input value by assigning it to a user variable and not assigning the variable to a table column:
LOAD DATA INFILE 'file.txt' INTO TABLE t1 (column1, @dummy, column2, @dummy, column3);
Use of the column/variable list and SET
clause
is subject to the following restrictions:
Assignments in the
SET
clause should have only column names on the left hand side of assignment operators.You can use subqueries in the right hand side of
SET
assignments. A subquery that returns a value to be assigned to a column may be a scalar subquery only. Also, you cannot use a subquery to select from the table that is being loaded.Lines ignored by an
IGNORE
clause are not processed for the column/variable list orSET
clause.User variables cannot be used when loading data with fixed-row format because user variables do not have a display width.
When processing an input line, LOAD
DATA
splits it into fields and uses the values according
to the column/variable list and the SET
clause,
if they are present. Then the resulting row is inserted into the
table. If there are BEFORE INSERT
or
AFTER INSERT
triggers for the table, they are
activated before or after inserting the row, respectively.
If an input line has too many fields, the extra fields are ignored and the number of warnings is incremented.
If an input line has too few fields, the table columns for which input fields are missing are set to their default values. Default value assignment is described in Section 10.1.4, “Data Type Default Values”.
An empty field value is interpreted differently than if the field value is missing:
For string types, the column is set to the empty string.
For numeric types, the column is set to
0
.For date and time types, the column is set to the appropriate “zero” value for the type. See Section 10.3, “Date and Time Types”.
These are the same values that result if you assign an empty
string explicitly to a string, numeric, or date or time type
explicitly in an INSERT
or
UPDATE
statement.
TIMESTAMP
columns are set to the
current date and time only if there is a NULL
value for the column (that is, \N
) and the
column is not declared to permit NULL
values,
or if the TIMESTAMP
column's
default value is the current timestamp and it is omitted from the
field list when a field list is specified.
LOAD DATA
INFILE
regards all input as strings, so you cannot use
numeric values for ENUM
or
SET
columns the way you can with
INSERT
statements. All
ENUM
and
SET
values must be specified as
strings.
BIT
values cannot be loaded using
binary notation (for example, b'011010'
). To
work around this, specify the values as regular integers and use
the SET
clause to convert them so that MySQL
performs a numeric type conversion and loads them into the
BIT
column properly:
shell>cat /tmp/bit_test.txt
2 127 shell>mysql test
mysql>LOAD DATA INFILE '/tmp/bit_test.txt'
->INTO TABLE bit_test (@var1) SET b= CAST(@var1 AS UNSIGNED);
Query OK, 2 rows affected (0.00 sec) Records: 2 Deleted: 0 Skipped: 0 Warnings: 0 mysql>SELECT BIN(b+0) FROM bit_test;
+----------+ | bin(b+0) | +----------+ | 10 | | 1111111 | +----------+ 2 rows in set (0.00 sec)
When the LOAD DATA
INFILE
statement finishes, it returns an information
string in the following format:
Records: 1 Deleted: 0 Skipped: 0 Warnings: 0
If you are using the C API, you can get information about the
statement by calling the
mysql_info()
function. See
Section 21.9.3.35, “mysql_info()
”.
Warnings occur under the same circumstances as when values are
inserted using the INSERT
statement
(see Section 12.2.5, “INSERT
Синтаксис”), except that
LOAD DATA
INFILE
also generates warnings when there are too few or
too many fields in the input row. The warnings are not stored
anywhere; the number of warnings can be used only as an indication
of whether everything went well.
You can use SHOW WARNINGS
to get a
list of the first max_error_count
warnings as information about what went wrong. See
Section 12.7.5.41, “SHOW WARNINGS
Синтаксис”.
LOAD XML [LOW_PRIORITY | CONCURRENT] [LOCAL] INFILE 'file_name
' [REPLACE | IGNORE] INTO TABLE [db_name
.]tbl_name
[CHARACTER SETcharset_name
] [ROWS IDENTIFIED BY '<tagname
>'] [IGNOREnumber
[LINES | ROWS]] [(column_or_user_var
,...)] [SETcol_name
=expr
,...]
The LOAD XML
statement reads data
from an XML file into a table. The
file_name
must be given as a literal
string. The tagname
in the optional
ROWS IDENTIFIED BY
clause must also be given as
a literal string, and must be surrounded by angle brackets
(<
and >
).
LOAD XML
acts as the complement of
running the mysql client in XML output mode
(that is, starting the client with the
--xml
option). To write data from a
table to an XML file, use a command such as the following one from
the system shell:
shell> mysql --xml -e 'SELECT * FROM mytable' > file.xml
To read the file back into a table, use
LOAD XML
INFILE
. By default, the <row>
element is considered to be the equivalent of a database table
row; this can be changed using the ROWS IDENTIFIED
BY
clause.
This statement supports three different XML formats:
Column names as attributes and column values as attribute values:
<
row
column1
="value1
"column2
="value2
" .../>Column names as tags and column values as the content of these tags:
<
row
> <column1
>value1
</column1
> <column2
>value2
</column2
> </row
>Column names are the
name
attributes of<field>
tags, and values are the contents of these tags:<row> <field name='
column1
'>value1
</field> <field name='column2
'>value2
</field> </row>This is the format used by other MySQL tools, such as mysqldump.
All 3 formats can be used in the same XML file; the import routine automatically detects the format for each row and interprets it correctly. Tags are matched based on the tag or attribute name and the column name.
The following clauses work essentially the same way for
LOAD XML
as they do for
LOAD DATA
:
LOW_PRIORITY
orCONCURRENT
LOCAL
REPLACE
orIGNORE
CHARACTER SET
(
column_or_user_var
,...)SET
See Section 12.2.6, “LOAD DATA INFILE
Синтаксис”, for more information about these
clauses.
The IGNORE
or number
LINESIGNORE
clause causes the
first number
ROWSnumber
rows in the XML file to be
skipped. It is analogous to the LOAD
DATA
statement's IGNORE ... LINES
clause.
To illustrate how this statement is used, suppose that we have a table created as follows:
USE test; CREATE TABLE person ( person_id INT NOT NULL PRIMARY KEY, fname VARCHAR(40) NULL, lname VARCHAR(40) NULL, created TIMESTAMP );
Suppose further that this table is initially empty.
Now suppose that we have a simple XML file
person.xml
, whose contents are as shown here:
<?xml version="1.0"?> <list> <person person_id="1" fname="Pekka" lname="Nousiainen"/> <person person_id="2" fname="Jonas" lname="Oreland"/> <person person_id="3"><fname>Mikael</fname><lname>Ronström</lname></person> <person person_id="4"><fname>Lars</fname><lname>Thalmann</lname></person> <person><field name="person_id">5</field><field name="fname">Tomas</field><field name="lname">Ulin</field></person> <person><field name="person_id">6</field><field name="fname">Martin</field><field name="lname">Sköld</field></person> </list>
Each of the permissible XML formats discussed previously is represented in this example file.
To import the data in person.xml
into the
person
table, you can use this statement:
mysql>LOAD XML LOCAL INFILE 'person.xml'
->INTO TABLE person
->ROWS IDENTIFIED BY '<person>';
Query OK, 6 rows affected (0.00 sec) Records: 6 Deleted: 0 Skipped: 0 Warnings: 0
Here, we assume that person.xml
is located in
the MySQL data directory. If the file cannot be found, the
following error results:
ERROR 2 (HY000): File '/person.xml' not found (Errcode: 2)
The ROWS IDENTIFIED BY '<person>'
clause
means that each <person>
element in the
XML file is considered equivalent to a row in the table into which
the data is to be imported. In this case, this is the
person
table in the test
database.
As can be seen by the response from the server, 6 rows were
imported into the test.person
table. This can
be verified by a simple SELECT
statement:
mysql> SELECT * FROM person;
+-----------+--------+------------+---------------------+
| person_id | fname | lname | created |
+-----------+--------+------------+---------------------+
| 1 | Pekka | Nousiainen | 2007-07-13 16:18:47 |
| 2 | Jonas | Oreland | 2007-07-13 16:18:47 |
| 3 | Mikael | Ronström | 2007-07-13 16:18:47 |
| 4 | Lars | Thalmann | 2007-07-13 16:18:47 |
| 5 | Tomas | Ulin | 2007-07-13 16:18:47 |
| 6 | Martin | Sköld | 2007-07-13 16:18:47 |
+-----------+--------+------------+---------------------+
6 rows in set (0.00 sec)
This shows, as stated earlier in this section, that any or all of
the 3 permitted XML formats may appear in a single file and be
read in using LOAD XML
.
The inverse of the above operation—that is, dumping MySQL table data into an XML file—can be accomplished using the mysql client from the system shell, as shown here:
The --xml
option causes the
mysql client to use XML formatting for its
output; the -e
option causes the client to
execute the SQL statement immediately following the option.
shell>mysql --xml -e "SELECT * FROM test.person" > person-dump.xml
shell>cat person-dump.xml
<?xml version="1.0"?> <resultset statement="SELECT * FROM test.person" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <row> <field name="person_id">1</field> <field name="fname">Pekka</field> <field name="lname">Nousiainen</field> <field name="created">2007-07-13 16:18:47</field> </row> <row> <field name="person_id">2</field> <field name="fname">Jonas</field> <field name="lname">Oreland</field> <field name="created">2007-07-13 16:18:47</field> </row> <row> <field name="person_id">3</field> <field name="fname">Mikael</field> <field name="lname">Ronström</field> <field name="created">2007-07-13 16:18:47</field> </row> <row> <field name="person_id">4</field> <field name="fname">Lars</field> <field name="lname">Thalmann</field> <field name="created">2007-07-13 16:18:47</field> </row> <row> <field name="person_id">5</field> <field name="fname">Tomas</field> <field name="lname">Ulin</field> <field name="created">2007-07-13 16:18:47</field> </row> <row> <field name="person_id">6</field> <field name="fname">Martin</field> <field name="lname">Sköld</field> <field name="created">2007-07-13 16:18:47</field> </row> </resultset>
You can verify that the dump is valid by creating a copy of the
person
and then importing the dump file into
the new table, like this:
mysql>USE test;
mysql>CREATE TABLE person2 LIKE person;
Query OK, 0 rows affected (0.00 sec) mysql>LOAD XML LOCAL INFILE 'person-dump.xml'
->INTO TABLE person2;
Query OK, 6 rows affected (0.01 sec) Records: 6 Deleted: 0 Skipped: 0 Warnings: 0 mysql>SELECT * FROM person2;
+-----------+--------+------------+---------------------+ | person_id | fname | lname | created | +-----------+--------+------------+---------------------+ | 1 | Pekka | Nousiainen | 2007-07-13 16:18:47 | | 2 | Jonas | Oreland | 2007-07-13 16:18:47 | | 3 | Mikael | Ronström | 2007-07-13 16:18:47 | | 4 | Lars | Thalmann | 2007-07-13 16:18:47 | | 5 | Tomas | Ulin | 2007-07-13 16:18:47 | | 6 | Martin | Sköld | 2007-07-13 16:18:47 | +-----------+--------+------------+---------------------+ 6 rows in set (0.00 sec)
Using a ROWS IDENTIFIED BY
'<
clause, it
is possible to import data from the same XML file into database
tables with different definitions. For this example, suppose that
you have a file named tagname
>'address.xml
which
contains the following XML:
<?xml version="1.0"?> <list> <person person_id="1"> <fname>Robert</fname> <lname>Jones</lname> <address address_id="1" street="Mill Creek Road" zip="45365" city="Sidney"/> <address address_id="2" street="Main Street" zip="28681" city="Taylorsville"/> </person> <person person_id="2"> <fname>Mary</fname> <lname>Smith</lname> <address address_id="3" street="River Road" zip="80239" city="Denver"/> <!-- <address address_id="4" street="North Street" zip="37920" city="Knoxville"/> --> </person> </list>
You can again use the test.person
table as
defined previously in this section, after clearing all the
existing records from the table and then showing its structure as
shown here:
mysql<TRUNCATE person;
Query OK, 0 rows affected (0.04 sec) mysql<SHOW CREATE TABLE person\G
*************************** 1. row *************************** Table: person Create Table: CREATE TABLE `person` ( `person_id` int(11) NOT NULL, `fname` varchar(40) DEFAULT NULL, `lname` varchar(40) DEFAULT NULL, `created` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`person_id`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 1 row in set (0.00 sec)
Now create an address
table in the
test
database using the following
CREATE TABLE
statement:
CREATE TABLE address ( address_id INT NOT NULL PRIMARY KEY, person_id INT NULL, street VARCHAR(40) NULL, zip INT NULL, city VARCHAR(40) NULL, created TIMESTAMP );
To import the data from the XML file into the
person
table, execute the following
LOAD XML
statement, which specifies
that rows are to be specified by the
<person>
element, as shown here;
mysql>LOAD XML LOCAL INFILE 'address.xml'
->INTO TABLE person
->ROWS IDENTIFIED BY '<person>';
Query OK, 2 rows affected (0.00 sec) Records: 2 Deleted: 0 Skipped: 0 Warnings: 0
You can verify that the records were imported using a
SELECT
statement:
mysql> SELECT * FROM person;
+-----------+--------+-------+---------------------+
| person_id | fname | lname | created |
+-----------+--------+-------+---------------------+
| 1 | Robert | Jones | 2007-07-24 17:37:06 |
| 2 | Mary | Smith | 2007-07-24 17:37:06 |
+-----------+--------+-------+---------------------+
2 rows in set (0.00 sec)
Since the <address>
elements in the XML
file have no corresponding columns in the
person
table, they are skipped.
To import the data from the <address>
elements into the address
table, use the
LOAD XML
statement shown here:
mysql>LOAD XML LOCAL INFILE 'address.xml'
->INTO TABLE address
->ROWS IDENTIFIED BY '<address>';
Query OK, 3 rows affected (0.00 sec) Records: 3 Deleted: 0 Skipped: 0 Warnings: 0
You can see that the data was imported using a
SELECT
statement such as this one:
mysql> SELECT * FROM address;
+------------+-----------+-----------------+-------+--------------+---------------------+
| address_id | person_id | street | zip | city | created |
+------------+-----------+-----------------+-------+--------------+---------------------+
| 1 | 1 | Mill Creek Road | 45365 | Sidney | 2007-07-24 17:37:37 |
| 2 | 1 | Main Street | 28681 | Taylorsville | 2007-07-24 17:37:37 |
| 3 | 2 | River Road | 80239 | Denver | 2007-07-24 17:37:37 |
+------------+-----------+-----------------+-------+--------------+---------------------+
3 rows in set (0.00 sec)
The data from the <address>
element that
is enclosed in XML comments is not imported. However, since there
is a person_id
column in the
address
table, the value of the
person_id
attribute from the parent
<person>
element for each
<address>
is
imported into the address
table.
Security Considerations.
As with the LOAD DATA
statement,
the transfer of the XML file from the client host to the server
host is initiated by the MySQL server. In theory, a patched
server could be built that would tell the client program to
transfer a file of the server's choosing rather than the file
named by the client in the LOAD
XML
statement. Such a server could access any file on
the client host to which the client user has read access.
In a Web environment, clients usually connect to MySQL from a Web
server. A user that can run any command against the MySQL server
can use LOAD XML
LOCAL
to read any files to which the Web server process
has read access. In this environment, the client with respect to
the MySQL server is actually the Web server, not the remote
program being run by the user who connects to the Web server.
You can disable loading of XML files from clients by starting the
server with --local-infile=0
or
--local-infile=OFF
. This option can
also be used when starting the mysql client to
disable LOAD XML
for the duration
of the client session.
To prevent a client from loading XML files from the server, do not
grant the FILE
privilege to the
corresponding MySQL user account, or revoke this privilege if the
client user account already has it.
Revoking the FILE
privilege (or
not granting it in the first place) keeps the user only from
executing the LOAD XML
INFILE
statement (as well as the
LOAD_FILE()
function; it does
not prevent the user from executing
LOAD XML LOCAL
INFILE
. To disallow this statement, you must start the
server or the client with --local-infile=OFF
.
In other words, the FILE
privilege affects only whether the client can read files on the
server; it has no bearing on whether the client can read files
on the local file system.
REPLACE [LOW_PRIORITY | DELAYED] [INTO]tbl_name
[(col_name
,...)] {VALUES | VALUE} ({expr
| DEFAULT},...),(...),...
Or:
REPLACE [LOW_PRIORITY | DELAYED] [INTO]tbl_name
SETcol_name
={expr
| DEFAULT}, ...
Or:
REPLACE [LOW_PRIORITY | DELAYED] [INTO]tbl_name
[(col_name
,...)] SELECT ...
REPLACE
works exactly like
INSERT
, except that if an old row
in the table has the same value as a new row for a
PRIMARY KEY
or a UNIQUE
index, the old row is deleted before the new row is inserted. See
Section 12.2.5, “INSERT
Синтаксис”.
REPLACE
is a MySQL extension to the
SQL standard. It either inserts, or deletes
and inserts. For another MySQL extension to standard
SQL—that either inserts or
updates—see
Section 12.2.5.3, “INSERT ... ON
DUPLICATE KEY UPDATE
Синтаксис”.
Note that unless the table has a PRIMARY KEY
or
UNIQUE
index, using a
REPLACE
statement makes no sense.
It becomes equivalent to INSERT
,
because there is no index to be used to determine whether a new
row duplicates another.
Values for all columns are taken from the values specified in the
REPLACE
statement. Any missing
columns are set to their default values, just as happens for
INSERT
. You cannot refer to values
from the current row and use them in the new row. If you use an
assignment such as SET
, the reference
to the column name on the right hand side is treated as
col_name
=
col_name
+ 1DEFAULT(
,
so the assignment is equivalent to col_name
)SET
.
col_name
=
DEFAULT(col_name
) + 1
To use REPLACE
, you must have both
the INSERT
and
DELETE
privileges for the table.
The REPLACE
statement returns a
count to indicate the number of rows affected. This is the sum of
the rows deleted and inserted. If the count is 1 for a single-row
REPLACE
, a row was inserted and no
rows were deleted. If the count is greater than 1, one or more old
rows were deleted before the new row was inserted. It is possible
for a single row to replace more than one old row if the table
contains multiple unique indexes and the new row duplicates values
for different old rows in different unique indexes.
The affected-rows count makes it easy to determine whether
REPLACE
only added a row or whether
it also replaced any rows: Check whether the count is 1 (added) or
greater (replaced).
If you are using the C API, the affected-rows count can be
obtained using the
mysql_affected_rows()
function.
Currently, you cannot replace into a table and select from the same table in a subquery.
MySQL uses the following algorithm for
REPLACE
(and LOAD DATA ...
REPLACE
):
Try to insert the new row into the table
While the insertion fails because a duplicate-key error occurs for a primary key or unique index:
Delete from the table the conflicting row that has the duplicate key value
Try again to insert the new row into the table
It is possible that in the case of a duplicate-key error, a
storage engine may perform the REPLACE
as an
update rather than a delete plus insert, but the semantics are the
same. There are no user-visible effects other than a possible
difference in how the storage engine increments
Handler_
status
variables.
xxx
Because the results of REPLACE ... SELECT
statements depend on the ordering of rows from the
SELECT
and this order cannot always
be guaranteed, it is possible when logging these statements for
the master and the slave to diverge. For this reason, in MySQL
5.5.18 and later, REPLACE ... SELECT
statements
are flagged as unsafe for statement-based replication. With this
change, such statements produce a warning in the log when using
the STATEMENT
binary logging mode, and are
logged using the row-based format when using
MIXED
mode. See also
Section 15.1.2.1, “Advantages and Disadvantages of Statement-Based and Row-Based
Replication”.
SELECT [ALL | DISTINCT | DISTINCTROW ] [HIGH_PRIORITY] [STRAIGHT_JOIN] [SQL_SMALL_RESULT] [SQL_BIG_RESULT] [SQL_BUFFER_RESULT] [SQL_CACHE | SQL_NO_CACHE] [SQL_CALC_FOUND_ROWS]select_expr
[,select_expr
...] [FROMtable_references
[WHEREwhere_condition
] [GROUP BY {col_name
|expr
|position
} [ASC | DESC], ... [WITH ROLLUP]] [HAVINGwhere_condition
] [ORDER BY {col_name
|expr
|position
} [ASC | DESC], ...] [LIMIT {[offset
,]row_count
|row_count
OFFSEToffset
}] [PROCEDUREprocedure_name
(argument_list
)] [INTO OUTFILE 'file_name
' [CHARACTER SETcharset_name
]export_options
| INTO DUMPFILE 'file_name
' | INTOvar_name
[,var_name
]] [FOR UPDATE | LOCK IN SHARE MODE]]
SELECT
is used to retrieve rows
selected from one or more tables, and can include
UNION
statements and subqueries.
See Section 12.2.9.4, “UNION
Синтаксис”, and Section 12.2.10, “Subquery Синтаксис”.
The most commonly used clauses of
SELECT
statements are these:
Each
select_expr
indicates a column that you want to retrieve. There must be at least oneselect_expr
.table_references
indicates the table or tables from which to retrieve rows. Its syntax is described in Section 12.2.9.2, “JOIN
Синтаксис”.The
WHERE
clause, if given, indicates the condition or conditions that rows must satisfy to be selected.where_condition
is an expression that evaluates to true for each row to be selected. The statement selects all rows if there is noWHERE
clause.In the
WHERE
expression, you can use any of the functions and operators that MySQL supports, except for aggregate (summary) functions. See Section 8.5, “Expression Синтаксис”, and Глава 11, Functions and Operators.
SELECT
can also be used to retrieve
rows computed without reference to any table.
For example:
mysql> SELECT 1 + 1;
-> 2
You are permitted to specify DUAL
as a dummy
table name in situations where no tables are referenced:
mysql> SELECT 1 + 1 FROM DUAL;
-> 2
DUAL
is purely for the convenience of people
who require that all SELECT
statements should have FROM
and possibly other
clauses. MySQL may ignore the clauses. MySQL does not require
FROM DUAL
if no tables are referenced.
In general, clauses used must be given in exactly the order shown
in the syntax description. For example, a
HAVING
clause must come after any
GROUP BY
clause and before any ORDER
BY
clause. The exception is that the
INTO
clause can appear either as shown in the
syntax description or immediately following the
select_expr
list. For more information
about INTO
, see Section 12.2.9.1, “SELECT ... INTO
Синтаксис”.
The list of select_expr
terms comprises
the select list that indicates which columns to retrieve. Terms
specify a column or expression or can use
*
-shorthand:
A select list consisting only of a single unqualified
*
can be used as shorthand to select all columns from all tables:SELECT * FROM t1 INNER JOIN t2 ...
can be used as a qualified shorthand to select all columns from the named table:tbl_name
.*SELECT t1.*, t2.* FROM t1 INNER JOIN t2 ...
Use of an unqualified
*
with other items in the select list may produce a parse error. To avoid this problem, use a qualified
referencetbl_name
.*SELECT AVG(score), t1.* FROM t1 ...
The following list provides additional information about other
SELECT
clauses:
A
select_expr
can be given an alias usingAS
. The alias is used as the expression's column name and can be used inalias_name
GROUP BY
,ORDER BY
, orHAVING
clauses. For example:SELECT CONCAT(last_name,', ',first_name) AS full_name FROM mytable ORDER BY full_name;
The
AS
keyword is optional when aliasing aselect_expr
with an identifier. The preceding example could have been written like this:SELECT CONCAT(last_name,', ',first_name) full_name FROM mytable ORDER BY full_name;
However, because the
AS
is optional, a subtle problem can occur if you forget the comma between twoselect_expr
expressions: MySQL interprets the second as an alias name. For example, in the following statement,columnb
is treated as an alias name:SELECT columna columnb FROM mytable;
For this reason, it is good practice to be in the habit of using
AS
explicitly when specifying column aliases.It is not permissible to refer to a column alias in a
WHERE
clause, because the column value might not yet be determined when theWHERE
clause is executed. See Section C.5.5.4, “Problems with Column Aliases”.The
FROM
clause indicates the table or tables from which to retrieve rows. If you name more than one table, you are performing a join. For information on join syntax, see Section 12.2.9.2, “table_references
JOIN
Синтаксис”. For each table specified, you can optionally specify an alias.tbl_name
[[AS]alias
] [index_hint
]The use of index hints provides the optimizer with information about how to choose indexes during query processing. For a description of the syntax for specifying these hints, see Section 12.2.9.3, “Index Hint Синтаксис”.
You can use
SET max_seeks_for_key=
as an alternative way to force MySQL to prefer key scans instead of table scans. See Section 5.1.3, “Server System Variables”.value
You can refer to a table within the default database as
tbl_name
, or asdb_name
.tbl_name
to specify a database explicitly. You can refer to a column ascol_name
,tbl_name
.col_name
, ordb_name
.tbl_name
.col_name
. You need not specify atbl_name
ordb_name
.tbl_name
prefix for a column reference unless the reference would be ambiguous. See Section 8.2.1, “Identifier Qualifiers”, for examples of ambiguity that require the more explicit column reference forms.A table reference can be aliased using
ortbl_name
ASalias_name
tbl_name alias_name
:SELECT t1.name, t2.salary FROM employee AS t1, info AS t2 WHERE t1.name = t2.name; SELECT t1.name, t2.salary FROM employee t1, info t2 WHERE t1.name = t2.name;
Columns selected for output can be referred to in
ORDER BY
andGROUP BY
clauses using column names, column aliases, or column positions. Column positions are integers and begin with 1:SELECT college, region, seed FROM tournament ORDER BY region, seed; SELECT college, region AS r, seed AS s FROM tournament ORDER BY r, s; SELECT college, region, seed FROM tournament ORDER BY 2, 3;
To sort in reverse order, add the
DESC
(descending) keyword to the name of the column in theORDER BY
clause that you are sorting by. The default is ascending order; this can be specified explicitly using theASC
keyword.If
ORDER BY
occurs within a subquery and also is applied in the outer query, the outermostORDER BY
takes precedence. For example, results for the following statement are sorted in descending order, not ascending order:(SELECT ... ORDER BY a) ORDER BY a DESC;
Use of column positions is deprecated because the syntax has been removed from the SQL standard.
If you use
GROUP BY
, output rows are sorted according to theGROUP BY
columns as if you had anORDER BY
for the same columns. To avoid the overhead of sorting thatGROUP BY
produces, addORDER BY NULL
:SELECT a, COUNT(b) FROM test_table GROUP BY a ORDER BY NULL;
MySQL extends the
GROUP BY
clause so that you can also specifyASC
andDESC
after columns named in the clause:SELECT a, COUNT(b) FROM test_table GROUP BY a DESC;
MySQL extends the use of
GROUP BY
to permit selecting fields that are not mentioned in theGROUP BY
clause. If you are not getting the results that you expect from your query, please read the description ofGROUP BY
found in Section 11.16, “Functions and Modifiers for Use withGROUP BY
Clauses”.GROUP BY
permits aWITH ROLLUP
modifier. See Section 11.16.2, “GROUP BY
Modifiers”.The
HAVING
clause is applied nearly last, just before items are sent to the client, with no optimization. (LIMIT
is applied afterHAVING
.)The SQL standard requires that
HAVING
must reference only columns in theGROUP BY
clause or columns used in aggregate functions. However, MySQL supports an extension to this behavior, and permitsHAVING
to refer to columns in theSELECT
list and columns in outer subqueries as well.If the
HAVING
clause refers to a column that is ambiguous, a warning occurs. In the following statement,col2
is ambiguous because it is used as both an alias and a column name:SELECT COUNT(col1) AS col2 FROM t GROUP BY col2 HAVING col2 = 2;
Preference is given to standard SQL behavior, so if a
HAVING
column name is used both inGROUP BY
and as an aliased column in the output column list, preference is given to the column in theGROUP BY
column.Do not use
HAVING
for items that should be in theWHERE
clause. For example, do not write the following:SELECT
col_name
FROMtbl_name
HAVINGcol_name
> 0;Write this instead:
SELECT
col_name
FROMtbl_name
WHEREcol_name
> 0;The
HAVING
clause can refer to aggregate functions, which theWHERE
clause cannot:SELECT user, MAX(salary) FROM users GROUP BY user HAVING MAX(salary) > 10;
(This did not work in some older versions of MySQL.)
MySQL permits duplicate column names. That is, there can be more than one
select_expr
with the same name. This is an extension to standard SQL. Because MySQL also permitsGROUP BY
andHAVING
to refer toselect_expr
values, this can result in an ambiguity:SELECT 12 AS a, a FROM t GROUP BY a;
In that statement, both columns have the name
a
. To ensure that the correct column is used for grouping, use different names for eachselect_expr
.MySQL resolves unqualified column or alias references in
ORDER BY
clauses by searching in theselect_expr
values, then in the columns of the tables in theFROM
clause. ForGROUP BY
orHAVING
clauses, it searches theFROM
clause before searching in theselect_expr
values. (ForGROUP BY
andHAVING
, this differs from the pre-MySQL 5.0 behavior that used the same rules as forORDER BY
.)The
LIMIT
clause can be used to constrain the number of rows returned by theSELECT
statement.LIMIT
takes one or two numeric arguments, which must both be nonnegative integer constants, with these exceptions:Within prepared statements,
LIMIT
parameters can be specified using?
placeholder markers.Within stored programs,
LIMIT
parameters can be specified using integer-valued routine parameters or local variables as of MySQL 5.5.6.
With two arguments, the first argument specifies the offset of the first row to return, and the second specifies the maximum number of rows to return. The offset of the initial row is 0 (not 1):
SELECT * FROM tbl LIMIT 5,10; # Retrieve rows 6-15
To retrieve all rows from a certain offset up to the end of the result set, you can use some large number for the second parameter. This statement retrieves all rows from the 96th row to the last:
SELECT * FROM tbl LIMIT 95,18446744073709551615;
With one argument, the value specifies the number of rows to return from the beginning of the result set:
SELECT * FROM tbl LIMIT 5; # Retrieve first 5 rows
In other words,
LIMIT
is equivalent torow_count
LIMIT 0,
.row_count
For prepared statements, you can use placeholders. The following statements will return one row from the
tbl
table:SET @a=1; PREPARE STMT FROM 'SELECT * FROM tbl LIMIT ?'; EXECUTE STMT USING @a;
The following statements will return the second to sixth row from the
tbl
table:SET @skip=1; SET @numrows=5; PREPARE STMT FROM 'SELECT * FROM tbl LIMIT ?, ?'; EXECUTE STMT USING @skip, @numrows;
For compatibility with PostgreSQL, MySQL also supports the
LIMIT
syntax.row_count
OFFSEToffset
If
LIMIT
occurs within a subquery and also is applied in the outer query, the outermostLIMIT
takes precedence. For example, the following statement produces two rows, not one:(SELECT ... LIMIT 1) LIMIT 2;
A
PROCEDURE
clause names a procedure that should process the data in the result set. For an example, see Section 22.4.1, “PROCEDURE ANALYSE
”, which describesANALYSE
, a procedure that can be used to obtain suggestions for optimal column data types that may help reduce table sizes.The
SELECT ... INTO
form ofSELECT
enables the query result to be written to a file or stored in variables. For more information, see Section 12.2.9.1, “SELECT ... INTO
Синтаксис”.If you use
FOR UPDATE
with a storage engine that uses page or row locks, rows examined by the query are write-locked until the end of the current transaction. UsingLOCK IN SHARE MODE
sets a shared lock that permits other transactions to read the examined rows but not to update or delete them. See Section 13.3.9.3, “SELECT ... FOR UPDATE
andSELECT ... LOCK IN SHARE MODE
Locking Reads”.
Following the SELECT
keyword, you
can use a number of options that affect the operation of the
statement. HIGH_PRIORITY
,
STRAIGHT_JOIN
, and options beginning with
SQL_
are MySQL extensions to standard SQL.
The
ALL
andDISTINCT
options specify whether duplicate rows should be returned.ALL
(the default) specifies that all matching rows should be returned, including duplicates.DISTINCT
specifies removal of duplicate rows from the result set. It is an error to specify both options.DISTINCTROW
is a synonym forDISTINCT
.HIGH_PRIORITY
gives theSELECT
higher priority than a statement that updates a table. You should use this only for queries that are very fast and must be done at once. ASELECT HIGH_PRIORITY
query that is issued while the table is locked for reading runs even if there is an update statement waiting for the table to be free. This affects only storage engines that use only table-level locking (such asMyISAM
,MEMORY
, andMERGE
).HIGH_PRIORITY
cannot be used withSELECT
statements that are part of aUNION
.STRAIGHT_JOIN
forces the optimizer to join the tables in the order in which they are listed in theFROM
clause. You can use this to speed up a query if the optimizer joins the tables in nonoptimal order.STRAIGHT_JOIN
also can be used in thetable_references
list. See Section 12.2.9.2, “JOIN
Синтаксис”.STRAIGHT_JOIN
does not apply to any table that the optimizer treats as aconst
orsystem
table. Such a table produces a single row, is read during the optimization phase of query execution, and references to its columns are replaced with the appropriate column values before query execution proceeds. These tables will appear first in the query plan displayed byEXPLAIN
. See Section 7.8.1, “Optimizing Queries withEXPLAIN
”. This exception may not apply toconst
orsystem
tables that are used on theNULL
-complemented side of an outer join (that is, the right-side table of aLEFT JOIN
or the left-side table of aRIGHT JOIN
.SQL_BIG_RESULT
orSQL_SMALL_RESULT
can be used withGROUP BY
orDISTINCT
to tell the optimizer that the result set has many rows or is small, respectively. ForSQL_BIG_RESULT
, MySQL directly uses disk-based temporary tables if needed, and prefers sorting to using a temporary table with a key on theGROUP BY
elements. ForSQL_SMALL_RESULT
, MySQL uses fast temporary tables to store the resulting table instead of using sorting. This should not normally be needed.SQL_BUFFER_RESULT
forces the result to be put into a temporary table. This helps MySQL free the table locks early and helps in cases where it takes a long time to send the result set to the client. This option can be used only for top-levelSELECT
statements, not for subqueries or followingUNION
.SQL_CALC_FOUND_ROWS
tells MySQL to calculate how many rows there would be in the result set, disregarding anyLIMIT
clause. The number of rows can then be retrieved withSELECT FOUND_ROWS()
. See Section 11.14, “Information Functions”.The
SQL_CACHE
andSQL_NO_CACHE
options affect caching of query results in the query cache (see Section 7.9.3, “The MySQL Query Cache”).SQL_CACHE
tells MySQL to store the result in the query cache if it is cacheable and the value of thequery_cache_type
system variable is2
orDEMAND
.SQL_NO_CACHE
tells MySQL not to store the result in the query cache.For views,
SQL_NO_CACHE
applies if it appears in anySELECT
in the query. For a cacheable query,SQL_CACHE
applies if it appears in the firstSELECT
of a view referred to by the query.As of MySQL 5.5.3, these two options are mutually exclusive and an error occurs if they are both specified. Also, these options are not permitted in subqueries (including subqueries in the
FROM
clause), andSELECT
statements in unions other than the firstSELECT
.Before MySQL 5.5.3, for a query that uses
UNION
or subqueries, the following rules apply:
The SELECT ...
INTO
form of SELECT
enables a query result to be written to a file or stored in
variables:
SELECT ... INTO OUTFILE
writes the selected rows to a file. Column and line terminators can be specified to produce a specific output format.SELECT ... INTO DUMPFILE
writes a single row to a file without any formatting.SELECT ... INTO
selects column values and into variables.var_list
The SELECT
syntax description
(see Section 12.2.9, “SELECT
Синтаксис”) shows the INTO
clause near the end of the statement. It is also possible to use
INTO
immediately following the
select_expr
list.
The SELECT ... INTO
OUTFILE '
form of
file_name
'SELECT
writes the selected rows
to a file. The file is created on the server host, so you must
have the FILE
privilege to use
this syntax. file_name
cannot be an
existing file, which among other things prevents files such as
/etc/passwd
and database tables from being
destroyed. The
character_set_filesystem
system
variable controls the interpretation of the file name.
The SELECT ... INTO
OUTFILE
statement is intended primarily to let you
very quickly dump a table to a text file on the server machine.
If you want to create the resulting file on some other host than
the server host, you normally cannot use
SELECT ... INTO
OUTFILE
since there is no way to write a path to the
file relative to the server host's file system.
However, if the MySQL client software is installed on the remote
machine, you can instead use a client command such as
mysql -e "SELECT ..." >
to generate the
file on the client host.
file_name
It is also possible to create the resulting file on a different host other than the server host, if the location of the file on the remote host can be accessed using a network-mapped path on the server's file system. In this case, the presence of mysql (or some other MySQL client program) is not required on the target host.
SELECT ... INTO
OUTFILE
is the complement of
LOAD DATA
INFILE
. Column values are written converted to the
character set specified in the CHARACTER SET
clause. If no such clause is present, values are dumped using
the binary
character set. In effect, there is
no character set conversion. If a table contains columns in
several character sets, the output data file will as well and
you may not be able to reload the file correctly.
The syntax for the export_options
part of the statement consists of the same
FIELDS
and LINES
clauses
that are used with the
LOAD DATA
INFILE
statement. See Section 12.2.6, “LOAD DATA INFILE
Синтаксис”, for
information about the FIELDS
and
LINES
clauses, including their default values
and permissible values.
FIELDS ESCAPED BY
controls how to write
special characters. If the FIELDS ESCAPED BY
character is not empty, it is used as a prefix that precedes
following characters on output:
The
FIELDS ESCAPED BY
characterThe
FIELDS [OPTIONALLY] ENCLOSED BY
characterThe first character of the
FIELDS TERMINATED BY
andLINES TERMINATED BY
valuesASCII
NUL
(the zero-valued byte; what is actually written following the escape character is ASCII “0
”, not a zero-valued byte)
The FIELDS TERMINATED BY
, ENCLOSED
BY
, ESCAPED BY
, or LINES
TERMINATED BY
characters must be
escaped so that you can read the file back in reliably. ASCII
NUL
is escaped to make it easier to view with
some pagers.
The resulting file does not have to conform to SQL syntax, so nothing else need be escaped.
If the FIELDS ESCAPED BY
character is empty,
no characters are escaped and NULL
is output
as NULL
, not \N
. It is
probably not a good idea to specify an empty escape character,
particularly if field values in your data contain any of the
characters in the list just given.
Here is an example that produces a file in the comma-separated values (CSV) format used by many programs:
SELECT a,b,a+b INTO OUTFILE '/tmp/result.txt' FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\n' FROM test_table;
If you use INTO DUMPFILE
instead of
INTO OUTFILE
, MySQL writes only one row into
the file, without any column or line termination and without
performing any escape processing. This is useful if you want to
store a BLOB
value in a file.
Any file created by INTO OUTFILE
or
INTO DUMPFILE
is writable by all users on
the server host. The reason for this is that the MySQL server
cannot create a file that is owned by anyone other than the
user under whose account it is running. (You should
never run mysqld as
root
for this and other reasons.) The file
thus must be world-writable so that you can manipulate its
contents.
If the secure_file_priv
system variable is set to a nonempty directory name, the file
to be written must be located in that directory.
The INTO
clause can name a list of one or
more variables, which can be user-defined variables, stored
procedure or function parameters, or stored program local
variables (see Section 12.6.4, “Variables in Stored Programs”). The
selected values are assigned to the variables. The number of
variables must match the number of columns. The query should
return a single row. If the query returns no rows, a warning
with error code 1329 occurs (No data
), and
the variable values remain unchanged. If the query returns
multiple rows, error 1172 occurs (Result consisted of
more than one row
). If it is possible that the
statement may retrieve multiple rows, you can use LIMIT
1
to limit the result set to a single row.
SELECT id, data INTO @x, @y FROM test.t1 LIMIT 1;
User variable names are not case sensitive. See Section 8.4, “User-Defined Variables”.
In the context of such statements that occur as part of events executed by the Event Scheduler, diagnostics messages (not only errors, but also warnings) are written to the error log, and, on Windows, to the application event log. For additional information, see Section 18.4.5, “Event Scheduler Status”.
An INTO
clause should not be used in a nested
SELECT
because such a
SELECT
must return its result to
the outer context.
MySQL supports the following JOIN
syntaxes
for the table_references
part of
SELECT
statements and
multiple-table DELETE
and
UPDATE
statements:
table_references:
table_reference
[,table_reference
] ...table_reference
:table_factor
|join_table
table_factor
:tbl_name
[[AS]alias
] [index_hint_list
] |table_subquery
[AS]alias
| (table_references
) | { OJtable_reference
LEFT OUTER JOINtable_reference
ONconditional_expr
}join_table
:table_reference
[INNER | CROSS] JOINtable_factor
[join_condition
] |table_reference
STRAIGHT_JOINtable_factor
|table_reference
STRAIGHT_JOINtable_factor
ONconditional_expr
|table_reference
{LEFT|RIGHT} [OUTER] JOINtable_reference
join_condition
|table_reference
NATURAL [{LEFT|RIGHT} [OUTER]] JOINtable_factor
join_condition
: ONconditional_expr
| USING (column_list
)index_hint_list
:index_hint
[,index_hint
] ...index_hint
: USE {INDEX|KEY} [{FOR {JOIN|ORDER BY|GROUP BY}] ([index_list
]) | IGNORE {INDEX|KEY} [{FOR {JOIN|ORDER BY|GROUP BY}] (index_list
) | FORCE {INDEX|KEY} [{FOR {JOIN|ORDER BY|GROUP BY}] (index_list
)index_list
:index_name
[,index_name
] ...
A table reference is also known as a join expression.
The syntax of table_factor
is
extended in comparison with the SQL Standard. The latter accepts
only table_reference
, not a list of
them inside a pair of parentheses.
This is a conservative extension if we consider each comma in a
list of table_reference
items as
equivalent to an inner join. For example:
SELECT * FROM t1 LEFT JOIN (t2, t3, t4) ON (t2.a=t1.a AND t3.b=t1.b AND t4.c=t1.c)
is equivalent to:
SELECT * FROM t1 LEFT JOIN (t2 CROSS JOIN t3 CROSS JOIN t4) ON (t2.a=t1.a AND t3.b=t1.b AND t4.c=t1.c)
In MySQL, CROSS JOIN
is a syntactic
equivalent to INNER JOIN
(they can replace
each other). In standard SQL, they are not equivalent.
INNER JOIN
is used with an
ON
clause, CROSS JOIN
is
used otherwise.
In general, parentheses can be ignored in join expressions containing only inner join operations. MySQL also supports nested joins (see Section 7.13.7, “Nested Join Optimization”).
Index hints can be specified to affect how the MySQL optimizer makes use of indexes. For more information, see Section 12.2.9.3, “Index Hint Синтаксис”.
The following list describes general factors to take into account when writing joins.
A table reference can be aliased using
ortbl_name
ASalias_name
tbl_name alias_name
:SELECT t1.name, t2.salary FROM employee AS t1 INNER JOIN info AS t2 ON t1.name = t2.name; SELECT t1.name, t2.salary FROM employee t1 INNER JOIN info t2 ON t1.name = t2.name;
A
table_subquery
is also known as a subquery in theFROM
clause. Such subqueries must include an alias to give the subquery result a table name. A trivial example follows; see also Section 12.2.10.8, “Subqueries in theFROM
Clause”.SELECT * FROM (SELECT 1, 2, 3) AS t1;
INNER JOIN
and,
(comma) are semantically equivalent in the absence of a join condition: both produce a Cartesian product between the specified tables (that is, each and every row in the first table is joined to each and every row in the second table).However, the precedence of the comma operator is less than of
INNER JOIN
,CROSS JOIN
,LEFT JOIN
, and so on. If you mix comma joins with the other join types when there is a join condition, an error of the formUnknown column '
may occur. Information about dealing with this problem is given later in this section.col_name
' in 'on clause'The
conditional_expr
used withON
is any conditional expression of the form that can be used in aWHERE
clause. Generally, you should use theON
clause for conditions that specify how to join tables, and theWHERE
clause to restrict which rows you want in the result set.If there is no matching row for the right table in the
ON
orUSING
part in aLEFT JOIN
, a row with all columns set toNULL
is used for the right table. You can use this fact to find rows in a table that have no counterpart in another table:SELECT left_tbl.* FROM left_tbl LEFT JOIN right_tbl ON left_tbl.id = right_tbl.id WHERE right_tbl.id IS NULL;
This example finds all rows in
left_tbl
with anid
value that is not present inright_tbl
(that is, all rows inleft_tbl
with no corresponding row inright_tbl
). This assumes thatright_tbl.id
is declaredNOT NULL
. See Section 7.13.5, “LEFT JOIN
andRIGHT JOIN
Optimization”.The
USING(
clause names a list of columns that must exist in both tables. If tablescolumn_list
)a
andb
both contain columnsc1
,c2
, andc3
, the following join compares corresponding columns from the two tables:a LEFT JOIN b USING (c1,c2,c3)
The
NATURAL [LEFT] JOIN
of two tables is defined to be semantically equivalent to anINNER JOIN
or aLEFT JOIN
with aUSING
clause that names all columns that exist in both tables.RIGHT JOIN
works analogously toLEFT JOIN
. To keep code portable across databases, it is recommended that you useLEFT JOIN
instead ofRIGHT JOIN
.The
{ OJ ... LEFT OUTER JOIN ...}
syntax shown in the join syntax description exists only for compatibility with ODBC. The curly braces in the syntax should be written literally; they are not metasyntax as used elsewhere in syntax descriptions.SELECT left_tbl.* FROM { OJ left_tbl LEFT OUTER JOIN right_tbl ON left_tbl.id = right_tbl.id } WHERE right_tbl.id IS NULL;
You can use other types of joins within
{ OJ ... }
, such asINNER JOIN
orRIGHT OUTER JOIN
. This helps with compatibility with some third-party applications, but is not official ODBC syntax.The parser does not permit nested
{ OJ ... }
constructs (which are not legal ODBC syntax, anyway). Queries that use such constructs should be rewritten. For an example, seeJOIN
Синтаксис.STRAIGHT_JOIN
is similar toJOIN
, except that the left table is always read before the right table. This can be used for those (few) cases for which the join optimizer puts the tables in the wrong order.
Some join examples:
SELECT * FROM table1, table2; SELECT * FROM table1 INNER JOIN table2 ON table1.id=table2.id; SELECT * FROM table1 LEFT JOIN table2 ON table1.id=table2.id; SELECT * FROM table1 LEFT JOIN table2 USING (id); SELECT * FROM table1 LEFT JOIN table2 ON table1.id=table2.id LEFT JOIN table3 ON table2.id=table3.id;
Join Processing Changes in MySQL 5.0.12
Natural joins and joins with USING
,
including outer join variants, are processed according to the
SQL:2003 standard. The goal was to align the syntax and
semantics of MySQL with respect to NATURAL
JOIN
and JOIN ... USING
according
to SQL:2003. However, these changes in join processing can
result in different output columns for some joins. Also, some
queries that appeared to work correctly in older versions
(prior to 5.0.12) must be rewritten to comply with the
standard.
These changes have five main aspects:
The way that MySQL determines the result columns of
NATURAL
orUSING
join operations (and thus the result of the entireFROM
clause).Expansion of
SELECT *
andSELECT
into a list of selected columns.tbl_name
.*Resolution of column names in
NATURAL
orUSING
joins.Transformation of
NATURAL
orUSING
joins intoJOIN ... ON
.Resolution of column names in the
ON
condition of aJOIN ... ON
.
The following list provides more detail about several effects of current join processing versus join processing in older versions. The term “previously” means “prior to MySQL 5.0.12.”
The columns of a
NATURAL
join or aUSING
join may be different from previously. Specifically, redundant output columns no longer appear, and the order of columns forSELECT *
expansion may be different from before.Consider this set of statements:
CREATE TABLE t1 (i INT, j INT); CREATE TABLE t2 (k INT, j INT); INSERT INTO t1 VALUES(1,1); INSERT INTO t2 VALUES(1,1); SELECT * FROM t1 NATURAL JOIN t2; SELECT * FROM t1 JOIN t2 USING (j);
Previously, the statements produced this output:
+------+------+------+------+ | i | j | k | j | +------+------+------+------+ | 1 | 1 | 1 | 1 | +------+------+------+------+ +------+------+------+------+ | i | j | k | j | +------+------+------+------+ | 1 | 1 | 1 | 1 | +------+------+------+------+
In the first
SELECT
statement, columnj
appears in both tables and thus becomes a join column, so, according to standard SQL, it should appear only once in the output, not twice. Similarly, in the second SELECT statement, columnj
is named in theUSING
clause and should appear only once in the output, not twice. But in both cases, the redundant column is not eliminated. Also, the order of the columns is not correct according to standard SQL.Now the statements produce this output:
+------+------+------+ | j | i | k | +------+------+------+ | 1 | 1 | 1 | +------+------+------+ +------+------+------+ | j | i | k | +------+------+------+ | 1 | 1 | 1 | +------+------+------+
The redundant column is eliminated and the column order is correct according to standard SQL:
First, coalesced common columns of the two joined tables, in the order in which they occur in the first table
Second, columns unique to the first table, in order in which they occur in that table
Third, columns unique to the second table, in order in which they occur in that table
The single result column that replaces two common columns is defined using the coalesce operation. That is, for two
t1.a
andt2.a
the resulting single join columna
is defined asa = COALESCE(t1.a, t2.a)
, where:COALESCE(x, y) = (CASE WHEN V1 IS NOT NULL THEN V1 ELSE V2 END)
If the join operation is any other join, the result columns of the join consists of the concatenation of all columns of the joined tables. This is the same as previously.
A consequence of the definition of coalesced columns is that, for outer joins, the coalesced column contains the value of the non-
NULL
column if one of the two columns is alwaysNULL
. If neither or both columns areNULL
, both common columns have the same value, so it doesn't matter which one is chosen as the value of the coalesced column. A simple way to interpret this is to consider that a coalesced column of an outer join is represented by the common column of the inner table of aJOIN
. Suppose that the tablest1(a,b)
andt2(a,c)
have the following contents:t1 t2 ---- ---- 1 x 2 z 2 y 3 w
Then:
mysql>
SELECT * FROM t1 NATURAL LEFT JOIN t2;
+------+------+------+ | a | b | c | +------+------+------+ | 1 | x | NULL | | 2 | y | z | +------+------+------+Here column
a
contains the values oft1.a
.mysql>
SELECT * FROM t1 NATURAL RIGHT JOIN t2;
+------+------+------+ | a | c | b | +------+------+------+ | 2 | z | y | | 3 | w | NULL | +------+------+------+Here column
a
contains the values oft2.a
.Compare these results to the otherwise equivalent queries with
JOIN ... ON
:mysql>
SELECT * FROM t1 LEFT JOIN t2 ON (t1.a = t2.a);
+------+------+------+------+ | a | b | a | c | +------+------+------+------+ | 1 | x | NULL | NULL | | 2 | y | 2 | z | +------+------+------+------+mysql>
SELECT * FROM t1 RIGHT JOIN t2 ON (t1.a = t2.a);
+------+------+------+------+ | a | b | a | c | +------+------+------+------+ | 2 | y | 2 | z | | NULL | NULL | 3 | w | +------+------+------+------+Previously, a
USING
clause could be rewritten as anON
clause that compares corresponding columns. For example, the following two clauses were semantically identical:a LEFT JOIN b USING (c1,c2,c3) a LEFT JOIN b ON a.c1=b.c1 AND a.c2=b.c2 AND a.c3=b.c3
Now the two clauses no longer are quite the same:
With respect to determining which rows satisfy the join condition, both joins remain semantically identical.
With respect to determining which columns to display for
SELECT *
expansion, the two joins are not semantically identical. TheUSING
join selects the coalesced value of corresponding columns, whereas theON
join selects all columns from all tables. For the precedingUSING
join,SELECT *
selects these values:COALESCE(a.c1,b.c1), COALESCE(a.c2,b.c2), COALESCE(a.c3,b.c3)
For the
ON
join,SELECT *
selects these values:a.c1, a.c2, a.c3, b.c1, b.c2, b.c3
With an inner join,
COALESCE(a.c1,b.c1)
is the same as eithera.c1
orb.c1
because both columns will have the same value. With an outer join (such asLEFT JOIN
), one of the two columns can beNULL
. That column will be omitted from the result.
The evaluation of multi-way natural joins differs in a very important way that affects the result of
NATURAL
orUSING
joins and that can require query rewriting. Suppose that you have three tablest1(a,b)
,t2(c,b)
, andt3(a,c)
that each have one row:t1(1,2)
,t2(10,2)
, andt3(7,10)
. Suppose also that you have thisNATURAL JOIN
on the three tables:SELECT ... FROM t1 NATURAL JOIN t2 NATURAL JOIN t3;
Previously, the left operand of the second join was considered to be
t2
, whereas it should be the nested join(t1 NATURAL JOIN t2)
. As a result, the columns oft3
are checked for common columns only int2
, and, ift3
has common columns witht1
, these columns are not used as equi-join columns. Thus, previously, the preceding query was transformed to the following equi-join:SELECT ... FROM t1, t2, t3 WHERE t1.b = t2.b AND t2.c = t3.c;
That join is missing one more equi-join predicate
(t1.a = t3.a)
. As a result, it produces one row, not the empty result that it should. The correct equivalent query is this:SELECT ... FROM t1, t2, t3 WHERE t1.b = t2.b AND t2.c = t3.c AND t1.a = t3.a;
If you require the same query result in current versions of MySQL as in older versions, rewrite the natural join as the first equi-join.
Previously, the comma operator (
,
) andJOIN
both had the same precedence, so the join expressiont1, t2 JOIN t3
was interpreted as((t1, t2) JOIN t3)
. NowJOIN
has higher precedence, so the expression is interpreted as(t1, (t2 JOIN t3))
. This change affects statements that use anON
clause, because that clause can refer only to columns in the operands of the join, and the change in precedence changes interpretation of what those operands are.Пример:
CREATE TABLE t1 (i1 INT, j1 INT); CREATE TABLE t2 (i2 INT, j2 INT); CREATE TABLE t3 (i3 INT, j3 INT); INSERT INTO t1 VALUES(1,1); INSERT INTO t2 VALUES(1,1); INSERT INTO t3 VALUES(1,1); SELECT * FROM t1, t2 JOIN t3 ON (t1.i1 = t3.i3);
Previously, the
SELECT
was legal due to the implicit grouping oft1,t2
as(t1,t2)
. Now theJOIN
takes precedence, so the operands for theON
clause aret2
andt3
. Becauset1.i1
is not a column in either of the operands, the result is anUnknown column 't1.i1' in 'on clause'
error. To allow the join to be processed, group the first two tables explicitly with parentheses so that the operands for theON
clause are(t1,t2)
andt3
:SELECT * FROM (t1, t2) JOIN t3 ON (t1.i1 = t3.i3);
Alternatively, avoid the use of the comma operator and use
JOIN
instead:SELECT * FROM t1 JOIN t2 JOIN t3 ON (t1.i1 = t3.i3);
This change also applies to statements that mix the comma operator with
INNER JOIN
,CROSS JOIN
,LEFT JOIN
, andRIGHT JOIN
, all of which now have higher precedence than the comma operator.Previously, the
ON
clause could refer to columns in tables named to its right. Now anON
clause can refer only to its operands.Пример:
CREATE TABLE t1 (i1 INT); CREATE TABLE t2 (i2 INT); CREATE TABLE t3 (i3 INT); SELECT * FROM t1 JOIN t2 ON (i1 = i3) JOIN t3;
Previously, the
SELECT
statement was legal. Now the statement fails with anUnknown column 'i3' in 'on clause'
error becausei3
is a column int3
, which is not an operand of theON
clause. The statement should be rewritten as follows:SELECT * FROM t1 JOIN t2 JOIN t3 ON (i1 = i3);
Resolution of column names in
NATURAL
orUSING
joins is different than previously. For column names that are outside theFROM
clause, MySQL now handles a superset of the queries compared to previously. That is, in cases when MySQL formerly issued an error that some column is ambiguous, the query now is handled correctly. This is due to the fact that MySQL now treats the common columns ofNATURAL
orUSING
joins as a single column, so when a query refers to such columns, the query compiler does not consider them as ambiguous.Пример:
SELECT * FROM t1 NATURAL JOIN t2 WHERE b > 1;
Previously, this query would produce an error
ERROR 1052 (23000): Column 'b' in where clause is ambiguous
. Now the query produces the correct result:+------+------+------+ | b | c | y | +------+------+------+ | 4 | 2 | 3 | +------+------+------+
One extension of MySQL compared to the SQL:2003 standard is that MySQL enables you to qualify the common (coalesced) columns of
NATURAL
orUSING
joins (just as previously), while the standard disallows that.
You can provide hints to give the optimizer information about
how to choose indexes during query processing.
Section 12.2.9.2, “JOIN
Синтаксис”, describes the general syntax for
specifying tables in a SELECT
statement. The syntax for an individual table, including that
for index hints, looks like this:
tbl_name
[[AS]alias
] [index_hint_list
]index_hint_list
:index_hint
[,index_hint
] ...index_hint
: USE {INDEX|KEY} [{FOR {JOIN|ORDER BY|GROUP BY}] ([index_list
]) | IGNORE {INDEX|KEY} [{FOR {JOIN|ORDER BY|GROUP BY}] (index_list
) | FORCE {INDEX|KEY} [{FOR {JOIN|ORDER BY|GROUP BY}] (index_list
)index_list
:index_name
[,index_name
] ...
By specifying USE INDEX
(
, you can tell
MySQL to use only one of the named indexes to find rows in the
table. The alternative syntax index_list
)IGNORE INDEX
(
can be used to
tell MySQL to not use some particular index or indexes. These
hints are useful if index_list
)EXPLAIN
shows
that MySQL is using the wrong index from the list of possible
indexes.
You can also use FORCE INDEX
, which acts like
USE INDEX
(
but with the
addition that a table scan is assumed to be
very expensive. In other words, a table
scan is used only if there is no way to use one of the given
indexes to find rows in the table.
index_list
)
Each hint requires the names of indexes,
not the names of columns. The name of a PRIMARY
KEY
is PRIMARY
. To see the index
names for a table, use SHOW
INDEX
.
An index_name
value need not be a
full index name. It can be an unambiguous prefix of an index
name. If a prefix is ambiguous, an error occurs.
Examples:
SELECT * FROM table1 USE INDEX (col1_index,col2_index) WHERE col1=1 AND col2=2 AND col3=3; SELECT * FROM table1 IGNORE INDEX (col3_index) WHERE col1=1 AND col2=2 AND col3=3;
The syntax for index hints has the following characteristics:
It is syntactically valid to specify an empty
index_list
forUSE INDEX
, which means “use no indexes.” Specifying an emptyindex_list
forFORCE INDEX
orIGNORE INDEX
is a syntax error.You can specify the scope of a index hint by adding a
FOR
clause to the hint. This provides more fine-grained control over the optimizer's selection of an execution plan for various phases of query processing. To affect only the indexes used when MySQL decides how to find rows in the table and how to process joins, useFOR JOIN
. To influence index usage for sorting or grouping rows, useFOR ORDER BY
orFOR GROUP BY
. (However, if there is a covering index for the table and it is used to access the table, the optimizer will ignoreIGNORE INDEX FOR {ORDER BY|GROUP BY}
hints that disable that index.)You can specify multiple index hints:
SELECT * FROM t1 USE INDEX (i1) IGNORE INDEX FOR ORDER BY (i2) ORDER BY a;
It is not a error to name the same index in several hints (even within the same hint):
SELECT * FROM t1 USE INDEX (i1) USE INDEX (i1,i1);
However, it is an error to mix
USE INDEX
andFORCE INDEX
for the same table:SELECT * FROM t1 USE INDEX FOR JOIN (i1) FORCE INDEX FOR JOIN (i2);
if you specify no FOR
clause for an index
hint, the hint by default applies to all parts of the statement.
For example, this hint:
IGNORE INDEX (i1)
is equivalent to this combination of hints:
IGNORE INDEX FOR JOIN (i1) IGNORE INDEX FOR ORDER BY (i1) IGNORE INDEX FOR GROUP BY (i1)
To cause the server to use the older behavior for hint scope
when no FOR
clause is present (so that hints
apply only to row retrieval), enable the
old
system variable at server
startup. Take care about enabling this variable in a replication
setup. With statement-based binary logging, having different
modes for the master and slaves might lead to replication
errors.
When index hints are processed, they are collected in a single
list by type (USE
,
FORCE
, IGNORE
) and by
scope (FOR JOIN
, FOR ORDER
BY
, FOR GROUP BY
). For example:
SELECT * FROM t1 USE INDEX () IGNORE INDEX (i2) USE INDEX (i1) USE INDEX (i2);
is equivalent to:
SELECT * FROM t1 USE INDEX (i1,i2) IGNORE INDEX (i2);
The index hints then are applied for each scope in the following order:
{USE|FORCE} INDEX
is applied if present. (If not, the optimizer-determined set of indexes is used.)IGNORE INDEX
is applied over the result of the previous step. For example, the following two queries are equivalent:SELECT * FROM t1 USE INDEX (i1) IGNORE INDEX (i2) USE INDEX (i2); SELECT * FROM t1 USE INDEX (i1);
For FULLTEXT
searches, index hints work as
follows:
For natural language mode searches, index hints are silently ignored. For example,
IGNORE INDEX(i)
is ignored with no warning and the index is still used.For boolean mode searches, index hints with
FOR ORDER BY
orFOR GROUP BY
are silently ignored. Index hints withFOR JOIN
or noFOR
modifier are honored. In contrast to how hints apply for non-FULLTEXT
searches, the hint is used for all phases of query execution (finding rows and retrieval, grouping, and ordering). This is true even if the hint is given for a non-FULLTEXT
index.
For example, the following two queries are equivalent:
SELECT * FROM t USE INDEX (index1) IGNORE INDEX (index1) FOR ORDER BY IGNORE INDEX (index1) FOR GROUP BY WHERE ... IN BOOLEAN MODE ... ; SELECT * FROM t USE INDEX (index1) WHERE ... IN BOOLEAN MODE ... ;
SELECT ... UNION [ALL | DISTINCT] SELECT ... [UNION [ALL | DISTINCT] SELECT ...]
UNION
is used to combine the
result from multiple SELECT
statements into a single result set.
The column names from the first
SELECT
statement are used as the
column names for the results returned. Selected columns listed
in corresponding positions of each
SELECT
statement should have the
same data type. (For example, the first column selected by the
first statement should have the same type as the first column
selected by the other statements.)
If the data types of corresponding
SELECT
columns do not match, the
types and lengths of the columns in the
UNION
result take into account
the values retrieved by all of the
SELECT
statements. For example,
consider the following:
mysql> SELECT REPEAT('a',1) UNION SELECT REPEAT('b',10);
+---------------+
| REPEAT('a',1) |
+---------------+
| a |
| bbbbbbbbbb |
+---------------+
The SELECT
statements are normal
select statements, but with the following restrictions:
Only the last
SELECT
statement can useINTO OUTFILE
. (However, the entireUNION
result is written to the file.)HIGH_PRIORITY
cannot be used withSELECT
statements that are part of aUNION
. If you specify it for the firstSELECT
, it has no effect. If you specify it for any subsequentSELECT
statements, a syntax error results.
The default behavior for UNION
is
that duplicate rows are removed from the result. The optional
DISTINCT
keyword has no effect other than the
default because it also specifies duplicate-row removal. With
the optional ALL
keyword, duplicate-row
removal does not occur and the result includes all matching rows
from all the SELECT
statements.
You can mix UNION
ALL
and UNION
DISTINCT
in the same query. Mixed
UNION
types are treated such that
a DISTINCT
union overrides any
ALL
union to its left. A
DISTINCT
union can be produced explicitly by
using UNION
DISTINCT
or implicitly by using
UNION
with no following
DISTINCT
or ALL
keyword.
To apply ORDER BY
or LIMIT
to an individual SELECT
, place
the clause inside the parentheses that enclose the
SELECT
:
(SELECT a FROM t1 WHERE a=10 AND B=1 ORDER BY a LIMIT 10) UNION (SELECT a FROM t2 WHERE a=11 AND B=2 ORDER BY a LIMIT 10);
However, use of ORDER BY
for individual
SELECT
statements implies nothing
about the order in which the rows appear in the final result
because UNION
by default produces
an unordered set of rows. Therefore, the use of ORDER
BY
in this context is typically in conjunction with
LIMIT
, so that it is used to determine the
subset of the selected rows to retrieve for the
SELECT
, even though it does not
necessarily affect the order of those rows in the final
UNION
result. If ORDER
BY
appears without LIMIT
in a
SELECT
, it is optimized away
because it will have no effect anyway.
To use an ORDER BY
or
LIMIT
clause to sort or limit the entire
UNION
result, parenthesize the
individual SELECT
statements and
place the ORDER BY
or
LIMIT
after the last one. The following
example uses both clauses:
(SELECT a FROM t1 WHERE a=10 AND B=1) UNION (SELECT a FROM t2 WHERE a=11 AND B=2) ORDER BY a LIMIT 10;
A statement without parentheses is equivalent to one parenthesized as just shown.
This kind of ORDER BY
cannot use column
references that include a table name (that is, names in
tbl_name
.col_name
format). Instead, provide a column alias in the first
SELECT
statement and refer to the
alias in the ORDER BY
. (Alternatively, refer
to the column in the ORDER BY
using its
column position. However, use of column positions is
deprecated.)
Also, if a column to be sorted is aliased, the ORDER
BY
clause must refer to the
alias, not the column name. The first of the following
statements will work, but the second will fail with an
Unknown column 'a' in 'order clause'
error:
(SELECT a AS b FROM t) UNION (SELECT ...) ORDER BY b; (SELECT a AS b FROM t) UNION (SELECT ...) ORDER BY a;
To cause rows in a UNION
result
to consist of the sets of rows retrieved by each
SELECT
one after the other,
select an additional column in each
SELECT
to use as a sort column
and add an ORDER BY
following the last
SELECT
:
(SELECT 1 AS sort_col, col1a, col1b, ... FROM t1) UNION (SELECT 2, col2a, col2b, ... FROM t2) ORDER BY sort_col;
To additionally maintain sort order within individual
SELECT
results, add a secondary
column to the ORDER BY
clause:
(SELECT 1 AS sort_col, col1a, col1b, ... FROM t1) UNION (SELECT 2, col2a, col2b, ... FROM t2) ORDER BY sort_col, col1a;
Use of an additional column also enables you to determine which
SELECT
each row comes from. Extra
columns can provide other identifying information as well, such
as a string that indicates a table name.
- 12.2.10.1. The Subquery as Scalar Operand
- 12.2.10.2. Comparisons Using Subqueries
- 12.2.10.3. Subqueries with
ANY
,IN
, orSOME
- 12.2.10.4. Subqueries with
ALL
- 12.2.10.5. Row Subqueries
- 12.2.10.6. Subqueries with
EXISTS
orNOT EXISTS
- 12.2.10.7. Correlated Subqueries
- 12.2.10.8. Subqueries in the
FROM
Clause - 12.2.10.9. Subquery Ошибки
- 12.2.10.10. Optimizing Subqueries
- 12.2.10.11. Rewriting Subqueries as Joins
A subquery is a SELECT
statement
within another statement.
Starting with MySQL 4.1, all subquery forms and operations that the SQL standard requires are supported, as well as a few features that are MySQL-specific.
Here is an example of a subquery:
SELECT * FROM t1 WHERE column1 = (SELECT column1 FROM t2);
In this example, SELECT * FROM t1 ...
is the
outer query (or outer
statement), and (SELECT column1 FROM
t2)
is the subquery. We say that
the subquery is nested within the outer
query, and in fact it is possible to nest subqueries within other
subqueries, to a considerable depth. A subquery must always appear
within parentheses.
The main advantages of subqueries are:
They allow queries that are structured so that it is possible to isolate each part of a statement.
They provide alternative ways to perform operations that would otherwise require complex joins and unions.
Many people find subqueries more readable than complex joins or unions. Indeed, it was the innovation of subqueries that gave people the original idea of calling the early SQL “Structured Query Language.”
Here is an example statement that shows the major points about subquery syntax as specified by the SQL standard and supported in MySQL:
DELETE FROM t1 WHERE s11 > ANY (SELECT COUNT(*) /* no hint */ FROM t2 WHERE NOT EXISTS (SELECT * FROM t3 WHERE ROW(5*t2.s1,77)= (SELECT 50,11*s1 FROM t4 UNION SELECT 50,77 FROM (SELECT * FROM t5) AS t5)));
A subquery can return a scalar (a single value), a single row, a single column, or a table (one or more rows of one or more columns). These are called scalar, column, row, and table subqueries. Subqueries that return a particular kind of result often can be used only in certain contexts, as described in the following sections.
There are few restrictions on the type of statements in which
subqueries can be used. A subquery can contain many of the
keywords or clauses that an ordinary
SELECT
can contain:
DISTINCT
, GROUP BY
,
ORDER BY
, LIMIT
, joins,
index hints, UNION
constructs,
comments, functions, and so on.
One restriction is that a subquery's outer statement must be one
of: SELECT
,
INSERT
,
UPDATE
,
DELETE
,
SET
, or
DO
. Another restriction is that
currently you cannot modify a table and select from the same table
in a subquery. This applies to statements such as
DELETE
,
INSERT
,
REPLACE
,
UPDATE
, and (because subqueries can
be used in the SET
clause)
LOAD DATA
INFILE
.
A more comprehensive discussion of restrictions on subquery use, including performance issues for certain forms of subquery syntax, is given in Section E.4, “Restrictions on Subqueries”.
In its simplest form, a subquery is a scalar subquery that
returns a single value. A scalar subquery is a simple operand,
and you can use it almost anywhere a single column value or
literal is legal, and you can expect it to have those
characteristics that all operands have: a data type, a length,
an indication that it can be NULL
, and so on.
For example:
CREATE TABLE t1 (s1 INT, s2 CHAR(5) NOT NULL); INSERT INTO t1 VALUES(100, 'abcde'); SELECT (SELECT s2 FROM t1);
The subquery in this SELECT
returns a single value ('abcde'
) that has a
data type of CHAR
, a length of 5,
a character set and collation equal to the defaults in effect at
CREATE TABLE
time, and an
indication that the value in the column can be
NULL
. Nullability of the value selected by a
scalar subquery is not copied because if the subquery result is
empty, the result is NULL
. For the subquery
just shown, if t1
were empty, the result
would be NULL
even though
s2
is NOT NULL
.
There are a few contexts in which a scalar subquery cannot be
used. If a statement permits only a literal value, you cannot
use a subquery. For example, LIMIT
requires
literal integer arguments, and
LOAD DATA
INFILE
requires a literal string file name. You cannot
use subqueries to supply these values.
When you see examples in the following sections that contain the
rather spartan construct (SELECT column1 FROM
t1)
, imagine that your own code contains much more
diverse and complex constructions.
Suppose that we make two tables:
CREATE TABLE t1 (s1 INT); INSERT INTO t1 VALUES (1); CREATE TABLE t2 (s1 INT); INSERT INTO t2 VALUES (2);
Then perform a SELECT
:
SELECT (SELECT s1 FROM t2) FROM t1;
The result is 2
because there is a row in
t2
containing a column s1
that has a value of 2
.
A scalar subquery can be part of an expression, but remember the parentheses, even if the subquery is an operand that provides an argument for a function. For example:
SELECT UPPER((SELECT s1 FROM t1)) FROM t2;
The most common use of a subquery is in the form:
non_subquery_operand
comparison_operator
(subquery
)
Where comparison_operator
is one of
these operators:
= > < >= <= <> != <=>
For example:
... WHERE 'a' = (SELECT column1 FROM t1)
MySQL also permits this construct:
non_subquery_operand
LIKE (subquery
)
At one time the only legal place for a subquery was on the right side of a comparison, and you might still find some old DBMSs that insist on this.
Here is an example of a common-form subquery comparison that you
cannot do with a join. It finds all the rows in table
t1
for which the column1
value is equal to a maximum value in table
t2
:
SELECT * FROM t1 WHERE column1 = (SELECT MAX(column2) FROM t2);
Here is another example, which again is impossible with a join
because it involves aggregating for one of the tables. It finds
all rows in table t1
containing a value that
occurs twice in a given column:
SELECT * FROM t1 AS t WHERE 2 = (SELECT COUNT(*) FROM t1 WHERE t1.id = t.id);
For a comparison of the subquery to a scalar, the subquery must return a scalar. For a comparison of the subquery to a row constructor, the subquery must be a row subquery that returns a row with the same number of values as the row constructor. See Section 12.2.10.5, “Row Subqueries”.
Синтаксис:
operand
comparison_operator
ANY (subquery
)operand
IN (subquery
)operand
comparison_operator
SOME (subquery
)
Where comparison_operator
is one of
these operators:
= > < >= <= <> !=
The ANY
keyword, which must follow a
comparison operator, means “return TRUE
if the comparison is TRUE
for
ANY
of the values in the column that the
subquery returns.” For example:
SELECT s1 FROM t1 WHERE s1 > ANY (SELECT s1 FROM t2);
Suppose that there is a row in table t1
containing (10)
. The expression is
TRUE
if table t2
contains
(21,14,7)
because there is a value
7
in t2
that is less than
10
. The expression is
FALSE
if table t2
contains
(20,10)
, or if table t2
is
empty. The expression is unknown (that is,
NULL
) if table t2
contains
(NULL,NULL,NULL)
.
When used with a subquery, the word IN
is an
alias for = ANY
. Thus, these two statements
are the same:
SELECT s1 FROM t1 WHERE s1 = ANY (SELECT s1 FROM t2); SELECT s1 FROM t1 WHERE s1 IN (SELECT s1 FROM t2);
IN
and = ANY
are not
synonyms when used with an expression list.
IN
can take an expression list, but
= ANY
cannot. See
Section 11.3.2, “Comparison Functions and Operators”.
NOT IN
is not an alias for <>
ANY
, but for <> ALL
. See
Section 12.2.10.4, “Subqueries with ALL
”.
The word SOME
is an alias for
ANY
. Thus, these two statements are the same:
SELECT s1 FROM t1 WHERE s1 <> ANY (SELECT s1 FROM t2); SELECT s1 FROM t1 WHERE s1 <> SOME (SELECT s1 FROM t2);
Use of the word SOME
is rare, but this
example shows why it might be useful. To most people, the
English phrase “a is not equal to any b” means
“there is no b which is equal to a,” but that is
not what is meant by the SQL syntax. The syntax means
“there is some b to which a is not equal.” Using
<> SOME
instead helps ensure that
everyone understands the true meaning of the query.
Синтаксис:
operand
comparison_operator
ALL (subquery
)
The word ALL
, which must follow a comparison
operator, means “return TRUE
if the
comparison is TRUE
for ALL
of the values in the column that the subquery returns.”
For example:
SELECT s1 FROM t1 WHERE s1 > ALL (SELECT s1 FROM t2);
Suppose that there is a row in table t1
containing (10)
. The expression is
TRUE
if table t2
contains
(-5,0,+5)
because 10
is
greater than all three values in t2
. The
expression is FALSE
if table
t2
contains
(12,6,NULL,-100)
because there is a single
value 12
in table t2
that
is greater than 10
. The expression is
unknown (that is, NULL
)
if table t2
contains
(0,NULL,1)
.
Finally, the expression is TRUE
if table
t2
is empty. So, the following expression is
TRUE
when table t2
is
empty:
SELECT * FROM t1 WHERE 1 > ALL (SELECT s1 FROM t2);
But this expression is NULL
when table
t2
is empty:
SELECT * FROM t1 WHERE 1 > (SELECT s1 FROM t2);
In addition, the following expression is NULL
when table t2
is empty:
SELECT * FROM t1 WHERE 1 > ALL (SELECT MAX(s1) FROM t2);
In general, tables containing NULL
values and empty tables are
“edge cases.” When writing subqueries, always
consider whether you have taken those two possibilities into
account.
NOT IN
is an alias for <>
ALL
. Thus, these two statements are the same:
SELECT s1 FROM t1 WHERE s1 <> ALL (SELECT s1 FROM t2); SELECT s1 FROM t1 WHERE s1 NOT IN (SELECT s1 FROM t2);
The discussion to this point has been of scalar or column subqueries; that is, subqueries that return a single value or a column of values. A row subquery is a subquery variant that returns a single row and can thus return more than one column value. Legal operators for row subquery comparisons are:
= > < >= <= <> != <=>
Here are two examples:
SELECT * FROM t1 WHERE (col1,col2) = (SELECT col3, col4 FROM t2 WHERE id = 10); SELECT * FROM t1 WHERE ROW(col1,col2) = (SELECT col3, col4 FROM t2 WHERE id = 10);
For both queries, if the table t2
contains a
single row with id = 10
, the subquery returns
a single row. If this row has col3
and
col4
values equal to the
col1
and col2
values of
any rows in t1
, the WHERE
expression is TRUE
and each query returns
those t1
rows. If the t2
row col3
and col4
values
are not equal the col1
and
col2
values of any t1
row,
the expression is FALSE
and the query returns
an empty result set. The expression is
unknown (that is, NULL
)
if the subquery produces no rows. An error occurs if the
subquery produces multiple rows because a row subquery can
return at most one row.
The expressions (1,2)
and
ROW(1,2)
are sometimes called row
constructors. The two are equivalent. The row
constructor and the row returned by the subquery must contain
the same number of values.
A row constructor is used for comparisons with subqueries that return two or more columns. When a subquery returns a single column, this is regarded as a scalar value and not as a row, so a row constructor cannot be used with a subquery that does not return at least two columns. Thus, the following query fails with a syntax error:
SELECT * FROM t1 WHERE ROW(1) = (SELECT column1 FROM t2)
Row constructors are legal in other contexts. For example, the following two statements are semantically equivalent (and are handled in the same way by the optimizer):
SELECT * FROM t1 WHERE (column1,column2) = (1,1); SELECT * FROM t1 WHERE column1 = 1 AND column2 = 1;
The following query answers the request, “find all rows in
table t1
that also exist in table
t2
”:
SELECT column1,column2,column3 FROM t1 WHERE (column1,column2,column3) IN (SELECT column1,column2,column3 FROM t2);
If a subquery returns any rows at all, EXISTS
is
subquery
TRUE
, and NOT EXISTS
is
subquery
FALSE
. For example:
SELECT column1 FROM t1 WHERE EXISTS (SELECT * FROM t2);
Traditionally, an EXISTS
subquery starts with
SELECT *
, but it could begin with
SELECT 5
or SELECT column1
or anything at all. MySQL ignores the
SELECT
list in such a subquery,
so it makes no difference.
For the preceding example, if t2
contains any
rows, even rows with nothing but NULL
values,
the EXISTS
condition is
TRUE
. This is actually an unlikely example
because a [NOT] EXISTS
subquery almost always
contains correlations. Here are some more realistic examples:
What kind of store is present in one or more cities?
SELECT DISTINCT store_type FROM stores WHERE EXISTS (SELECT * FROM cities_stores WHERE cities_stores.store_type = stores.store_type);
What kind of store is present in no cities?
SELECT DISTINCT store_type FROM stores WHERE NOT EXISTS (SELECT * FROM cities_stores WHERE cities_stores.store_type = stores.store_type);
What kind of store is present in all cities?
SELECT DISTINCT store_type FROM stores s1 WHERE NOT EXISTS ( SELECT * FROM cities WHERE NOT EXISTS ( SELECT * FROM cities_stores WHERE cities_stores.city = cities.city AND cities_stores.store_type = stores.store_type));
The last example is a double-nested NOT
EXISTS
query. That is, it has a NOT
EXISTS
clause within a NOT EXISTS
clause. Formally, it answers the question “does a city
exist with a store that is not in
Stores
”? But it is easier to say that
a nested NOT EXISTS
answers the question
“is x
TRUE
for all y
?”
A correlated subquery is a subquery that contains a reference to a table that also appears in the outer query. For example:
SELECT * FROM t1 WHERE column1 = ANY (SELECT column1 FROM t2 WHERE t2.column2 = t1.column2);
Notice that the subquery contains a reference to a column of
t1
, even though the subquery's
FROM
clause does not mention a table
t1
. So, MySQL looks outside the subquery, and
finds t1
in the outer query.
Suppose that table t1
contains a row where
column1 = 5
and column2 =
6
; meanwhile, table t2
contains a
row where column1 = 5
and column2 =
7
. The simple expression ... WHERE column1 =
ANY (SELECT column1 FROM t2)
would be
TRUE
, but in this example, the
WHERE
clause within the subquery is
FALSE
(because (5,6)
is
not equal to (5,7)
), so the expression as a
whole is FALSE
.
Scoping rule: MySQL evaluates from inside to outside. For example:
SELECT column1 FROM t1 AS x WHERE x.column1 = (SELECT column1 FROM t2 AS x WHERE x.column1 = (SELECT column1 FROM t3 WHERE x.column2 = t3.column1));
In this statement, x.column2
must be a column
in table t2
because SELECT column1
FROM t2 AS x ...
renames t2
. It is
not a column in table t1
because
SELECT column1 FROM t1 ...
is an outer query
that is farther out.
For subqueries in HAVING
or ORDER
BY
clauses, MySQL also looks for column names in the
outer select list.
For certain cases, a correlated subquery is optimized. For example:
val
IN (SELECTkey_val
FROMtbl_name
WHEREcorrelated_condition
)
Otherwise, they are inefficient and likely to be slow. Rewriting the query as a join might improve performance.
Aggregate functions in correlated subqueries may contain outer references, provided the function contains nothing but outer references, and provided the function is not contained in another function or expression.
Subqueries are legal in a SELECT
statement's FROM
clause. The actual syntax
is:
SELECT ... FROM (subquery
) [AS]name
...
The [AS]
clause is mandatory, because every table in a
name
FROM
clause must have a name. Any columns in
the subquery
select list must have
unique names.
For the sake of illustration, assume that you have this table:
CREATE TABLE t1 (s1 INT, s2 CHAR(5), s3 FLOAT);
Here is how to use a subquery in the FROM
clause, using the example table:
INSERT INTO t1 VALUES (1,'1',1.0); INSERT INTO t1 VALUES (2,'2',2.0); SELECT sb1,sb2,sb3 FROM (SELECT s1 AS sb1, s2 AS sb2, s3*2 AS sb3 FROM t1) AS sb WHERE sb1 > 1;
Result: 2, '2', 4.0
.
Here is another example: Suppose that you want to know the average of a set of sums for a grouped table. This does not work:
SELECT AVG(SUM(column1)) FROM t1 GROUP BY column1;
However, this query provides the desired information:
SELECT AVG(sum_column1) FROM (SELECT SUM(column1) AS sum_column1 FROM t1 GROUP BY column1) AS t1;
Notice that the column name used within the subquery
(sum_column1
) is recognized in the outer
query.
Subqueries in the FROM
clause can return a
scalar, column, row, or table. Subqueries in the
FROM
clause cannot be correlated subqueries,
unless used within the ON
clause of a
JOIN
operation.
Subqueries in the FROM
clause are executed
even for the EXPLAIN
statement
(that is, derived temporary tables are materialized). This
occurs because upper-level queries need information about all
tables during the optimization phase, and the table represented
by a subquery in the FROM
clause is
unavailable unless the subquery is executed.
It is possible under certain circumstances to modify table data
using EXPLAIN
SELECT
. This can occur if the outer query accesses any
tables and an inner query invokes a stored function that changes
one or more rows of a table. Suppose that there are two tables
t1
and t2
in database
d1
, created as shown here:
mysql>CREATE DATABASE d1;
Query OK, 1 row affected (0.00 sec) mysql>USE d1;
Database changed mysql>CREATE TABLE t1 (c1 INT);
Query OK, 0 rows affected (0.15 sec) mysql>CREATE TABLE t2 (c1 INT);
Query OK, 0 rows affected (0.08 sec)
Now we create a stored function f1
which
modifies t2
:
mysql>DELIMITER //
mysql>CREATE FUNCTION f1(p1 INT) RETURNS INT
mysql>BEGIN
mysql>INSERT INTO t2 VALUES (p1);
mysql>RETURN p1;
mysql>END //
Query OK, 0 rows affected (0.01 sec) mysql>DELIMITER ;
Referencing the function directly in an
EXPLAIN
SELECT
does not have any effect on
t2
, as shown here:
mysql>SELECT * FROM t2;
Empty set (0.00 sec) mysql>EXPLAIN SELECT f1(5);
+----+-------------+-------+------+---------------+------+---------+------+------+----------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+------+---------------+------+---------+------+------+----------------+ | 1 | SIMPLE | NULL | NULL | NULL | NULL | NULL | NULL | NULL | No tables used | +----+-------------+-------+------+---------------+------+---------+------+------+----------------+ 1 row in set (0.00 sec) mysql>SELECT * FROM t2;
Empty set (0.00 sec)
This is because the SELECT
statement did not reference any tables, as can be seen in the
table
and Extra
columns of
the output. This is also true of the following nested
SELECT
:
mysql>EXPLAIN SELECT NOW() AS a1, (SELECT f1(5)) AS a2;
+----+-------------+-------+------+---------------+------+---------+------+------+----------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+------+---------------+------+---------+------+------+----------------+ | 1 | PRIMARY | NULL | NULL | NULL | NULL | NULL | NULL | NULL | No tables used | +----+-------------+-------+------+---------------+------+---------+------+------+----------------+ 1 row in set, 1 warning (0.00 sec) mysql>SHOW WARNINGS;
+-------+------+------------------------------------------+ | Level | Code | Message | +-------+------+------------------------------------------+ | Note | 1249 | Select 2 was reduced during optimization | +-------+------+------------------------------------------+ 1 row in set (0.00 sec) mysql>SELECT * FROM t2;
Empty set (0.00 sec)
However, if the outer SELECT
references any tables, the optimizer executes the statement in
the subquery as well:
mysql>EXPLAIN SELECT * FROM t1 AS a1, (SELECT f1(5)) AS a2;
+----+-------------+------------+--------+---------------+------+---------+------+------+---------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+------------+--------+---------------+------+---------+------+------+---------------------+ | 1 | PRIMARY | a1 | system | NULL | NULL | NULL | NULL | 0 | const row not found | | 1 | PRIMARY | <derived2> | system | NULL | NULL | NULL | NULL | 1 | | | 2 | DERIVED | NULL | NULL | NULL | NULL | NULL | NULL | NULL | No tables used | +----+-------------+------------+--------+---------------+------+---------+------+------+---------------------+ 3 rows in set (0.00 sec) mysql>SELECT * FROM t2;
+------+ | c1 | +------+ | 5 | +------+ 1 row in set (0.00 sec)
This also means that an
EXPLAIN
SELECT
statement such as the one shown here may take a
long time to execute because the
BENCHMARK()
function is executed
once for each row in t1
:
EXPLAIN SELECT * FROM t1 AS a1, (SELECT BENCHMARK(1000000, MD5(NOW())));
There are some errors that apply only to subqueries. This section describes them.
Unsupported subquery syntax:
ERROR 1235 (ER_NOT_SUPPORTED_YET) SQLSTATE = 42000 Message = "This version of MySQL doesn't yet support 'LIMIT & IN/ALL/ANY/SOME subquery'"
This means that MySQL does not support statements of the following form:
SELECT * FROM t1 WHERE s1 IN (SELECT s2 FROM t2 ORDER BY s1 LIMIT 1)
Incorrect number of columns from subquery:
ERROR 1241 (ER_OPERAND_COL) SQLSTATE = 21000 Message = "Operand should contain 1 column(s)"
This error occurs in cases like this:
SELECT (SELECT column1, column2 FROM t2) FROM t1;
You may use a subquery that returns multiple columns, if the purpose is row comparison. In other contexts, the subquery must be a scalar operand. See Section 12.2.10.5, “Row Subqueries”.
Incorrect number of rows from subquery:
ERROR 1242 (ER_SUBSELECT_NO_1_ROW) SQLSTATE = 21000 Message = "Subquery returns more than 1 row"
This error occurs for statements where the subquery must return at most one row but returns multiple rows. Consider the following example:
SELECT * FROM t1 WHERE column1 = (SELECT column1 FROM t2);
If
SELECT column1 FROM t2
returns just one row, the previous query will work. If the subquery returns more than one row, error 1242 will occur. In that case, the query should be rewritten as:SELECT * FROM t1 WHERE column1 = ANY (SELECT column1 FROM t2);
Incorrectly used table in subquery:
Error 1093 (ER_UPDATE_TABLE_USED) SQLSTATE = HY000 Message = "You can't specify target table 'x' for update in FROM clause"
This error occurs in cases such as the following, which attempts to modify a table and select from the same table in the subquery:
UPDATE t1 SET column2 = (SELECT MAX(column1) FROM t1);
You can use a subquery for assignment within an
UPDATE
statement because subqueries are legal inUPDATE
andDELETE
statements as well as inSELECT
statements. However, you cannot use the same table (in this case, tablet1
) for both the subqueryFROM
clause and the update target.
For transactional storage engines, the failure of a subquery causes the entire statement to fail. For nontransactional storage engines, data modifications made before the error was encountered are preserved.
Development is ongoing, so no optimization tip is reliable for the long term. The following list provides some interesting tricks that you might want to play with:
Use subquery clauses that affect the number or order of the rows in the subquery. For example:
SELECT * FROM t1 WHERE t1.column1 IN (SELECT column1 FROM t2 ORDER BY column1); SELECT * FROM t1 WHERE t1.column1 IN (SELECT DISTINCT column1 FROM t2); SELECT * FROM t1 WHERE EXISTS (SELECT * FROM t2 LIMIT 1);
Replace a join with a subquery. For example, try this:
SELECT DISTINCT column1 FROM t1 WHERE t1.column1 IN ( SELECT column1 FROM t2);
Instead of this:
SELECT DISTINCT t1.column1 FROM t1, t2 WHERE t1.column1 = t2.column1;
Some subqueries can be transformed to joins for compatibility with older versions of MySQL that do not support subqueries. However, in some cases, converting a subquery to a join may improve performance. See Section 12.2.10.11, “Rewriting Subqueries as Joins”.
Move clauses from outside to inside the subquery. For example, use this query:
SELECT * FROM t1 WHERE s1 IN (SELECT s1 FROM t1 UNION ALL SELECT s1 FROM t2);
Instead of this query:
SELECT * FROM t1 WHERE s1 IN (SELECT s1 FROM t1) OR s1 IN (SELECT s1 FROM t2);
For another example, use this query:
SELECT (SELECT column1 + 5 FROM t1) FROM t2;
Instead of this query:
SELECT (SELECT column1 FROM t1) + 5 FROM t2;
Use a row subquery instead of a correlated subquery. For example, use this query:
SELECT * FROM t1 WHERE (column1,column2) IN (SELECT column1,column2 FROM t2);
Instead of this query:
SELECT * FROM t1 WHERE EXISTS (SELECT * FROM t2 WHERE t2.column1=t1.column1 AND t2.column2=t1.column2);
Use
NOT (a = ANY (...))
rather thana <> ALL (...)
.Use
x = ANY (
rather thantable containing (1,2)
)x=1 OR x=2
.Use
= ANY
rather thanEXISTS
.For uncorrelated subqueries that always return one row,
IN
is always slower than=
. For example, use this query:SELECT * FROM t1 WHERE t1.
col_name
= (SELECT a FROM t2 WHERE b =some_const
);Instead of this query:
SELECT * FROM t1 WHERE t1.
col_name
IN (SELECT a FROM t2 WHERE b =some_const
);
These tricks might cause programs to go faster or slower. Using
MySQL facilities like the
BENCHMARK()
function, you can get
an idea about what helps in your own situation. See
Section 11.14, “Information Functions”.
Some optimizations that MySQL itself makes are:
MySQL executes uncorrelated subqueries only once. Use
EXPLAIN
to make sure that a given subquery really is uncorrelated.MySQL rewrites
IN
,ALL
,ANY
, andSOME
subqueries in an attempt to take advantage of the possibility that the select-list columns in the subquery are indexed.MySQL replaces subqueries of the following form with an index-lookup function, which
EXPLAIN
describes as a special join type (unique_subquery
orindex_subquery
):... IN (SELECT
indexed_column
FROMsingle_table
...)MySQL enhances expressions of the following form with an expression involving
MIN()
orMAX()
, unlessNULL
values or empty sets are involved:value
{ALL|ANY|SOME} {> | < | >= | <=} (uncorrelated subquery
)For example, this
WHERE
clause:WHERE 5 > ALL (SELECT x FROM t)
might be treated by the optimizer like this:
WHERE 5 > (SELECT MAX(x) FROM t)
See also the MySQL Internals Manual chapter How MySQL Transforms Subqueries.
Sometimes there are other ways to test membership in a set of
values than by using a subquery. Also, on some occasions, it is
not only possible to rewrite a query without a subquery, but it
can be more efficient to make use of some of these techniques
rather than to use subqueries. One of these is the
IN()
construct:
For example, this query:
SELECT * FROM t1 WHERE id IN (SELECT id FROM t2);
Can be rewritten as:
SELECT DISTINCT t1.* FROM t1, t2 WHERE t1.id=t2.id;
The queries:
SELECT * FROM t1 WHERE id NOT IN (SELECT id FROM t2); SELECT * FROM t1 WHERE NOT EXISTS (SELECT id FROM t2 WHERE t1.id=t2.id);
Can be rewritten as:
SELECT table1.* FROM table1 LEFT JOIN table2 ON table1.id=table2.id WHERE table2.id IS NULL;
A LEFT [OUTER] JOIN
can be faster than an
equivalent subquery because the server might be able to optimize
it better—a fact that is not specific to MySQL Server
alone. Prior to SQL-92, outer joins did not exist, so subqueries
were the only way to do certain things. Today, MySQL Server and
many other modern database systems offer a wide range of outer
join types.
MySQL Server supports multiple-table
DELETE
statements that can be
used to efficiently delete rows based on information from one
table or even from many tables at the same time. Multiple-table
UPDATE
statements are also
supported. See Section 12.2.2, “DELETE
Синтаксис”, and
Section 12.2.11, “UPDATE
Синтаксис”.
Single-table syntax:
UPDATE [LOW_PRIORITY] [IGNORE]table_reference
SETcol_name1
={expr1
|DEFAULT} [,col_name2
={expr2
|DEFAULT}] ... [WHEREwhere_condition
] [ORDER BY ...] [LIMITrow_count
]
Multiple-table syntax:
UPDATE [LOW_PRIORITY] [IGNORE]table_references
SETcol_name1
={expr1
|DEFAULT} [,col_name2
={expr2
|DEFAULT}] ... [WHEREwhere_condition
]
For the single-table syntax, the
UPDATE
statement updates columns of
existing rows in the named table with new values. The
SET
clause indicates which columns to modify
and the values they should be given. Each value can be given as an
expression, or the keyword DEFAULT
to set a
column explicitly to its default value. The
WHERE
clause, if given, specifies the
conditions that identify which rows to update. With no
WHERE
clause, all rows are updated. If the
ORDER BY
clause is specified, the rows are
updated in the order that is specified. The
LIMIT
clause places a limit on the number of
rows that can be updated.
For the multiple-table syntax,
UPDATE
updates rows in each table
named in table_references
that satisfy
the conditions. In this case, ORDER BY
and
LIMIT
cannot be used.
where_condition
is an expression that
evaluates to true for each row to be updated. For expression
syntax, see Section 8.5, “Expression Синтаксис”.
table_references
and
where_condition
are is specified as
described in Section 12.2.9, “SELECT
Синтаксис”.
You need the UPDATE
privilege only
for columns referenced in an UPDATE
that are actually updated. You need only the
SELECT
privilege for any columns
that are read but not modified.
The UPDATE
statement supports the
following modifiers:
With the
LOW_PRIORITY
keyword, execution of theUPDATE
is delayed until no other clients are reading from the table. This affects only storage engines that use only table-level locking (such asMyISAM
,MEMORY
, andMERGE
).With the
IGNORE
keyword, the update statement does not abort even if errors occur during the update. Rows for which duplicate-key conflicts occur are not updated. Rows for which columns are updated to values that would cause data conversion errors are updated to the closest valid values instead.
In MySQL 5.5.18 and later,
UPDATE IGNORE
statements, including those having an ORDER BY
clause, are flagged as unsafe for statement-based replication.
(This is because the order in which the rows are updated
determines which rows are ignored.) With this change, such
statements produce a warning in the log when using statement-based
mode and are logged using the row-based format when using
MIXED
mode. (Bug #11758262, Bug #50439) See
Section 15.1.2.3, “Determination of Safe and Unsafe Statements in Binary Logging”, for more
information.
If you access a column from the table to be updated in an
expression, UPDATE
uses the current
value of the column. For example, the following statement sets
col1
to one more than its current value:
UPDATE t1 SET col1 = col1 + 1;
The second assignment in the following statement sets
col2
to the current (updated)
col1
value, not the original
col1
value. The result is that
col1
and col2
have the same
value. This behavior differs from standard SQL.
UPDATE t1 SET col1 = col1 + 1, col2 = col1;
Single-table UPDATE
assignments are
generally evaluated from left to right. For multiple-table
updates, there is no guarantee that assignments are carried out in
any particular order.
If you set a column to the value it currently has, MySQL notices this and does not update it.
If you update a column that has been declared NOT
NULL
by setting to NULL
, an error
occurs if strict SQL mode is enabled; otherwise, the column is set
to the implicit default value for the column data type and the
warning count is incremented. The implicit default value is
0
for numeric types, the empty string
(''
) for string types, and the
“zero” value for date and time types. See
Section 10.1.4, “Data Type Default Values”.
UPDATE
returns the number of rows
that were actually changed. The
mysql_info()
C API function
returns the number of rows that were matched and updated and the
number of warnings that occurred during the
UPDATE
.
You can use LIMIT
to restrict the
scope of the row_count
UPDATE
. A
LIMIT
clause is a rows-matched restriction. The
statement stops as soon as it has found
row_count
rows that satisfy the
WHERE
clause, whether or not they actually were
changed.
If an UPDATE
statement includes an
ORDER BY
clause, the rows are updated in the
order specified by the clause. This can be useful in certain
situations that might otherwise result in an error. Suppose that a
table t
contains a column id
that has a unique index. The following statement could fail with a
duplicate-key error, depending on the order in which rows are
updated:
UPDATE t SET id = id + 1;
For example, if the table contains 1 and 2 in the
id
column and 1 is updated to 2 before 2 is
updated to 3, an error occurs. To avoid this problem, add an
ORDER BY
clause to cause the rows with larger
id
values to be updated before those with
smaller values:
UPDATE t SET id = id + 1 ORDER BY id DESC;
You can also perform UPDATE
operations covering multiple tables. However, you cannot use
ORDER BY
or LIMIT
with a
multiple-table UPDATE
. The
table_references
clause lists the
tables involved in the join. Its syntax is described in
Section 12.2.9.2, “JOIN
Синтаксис”. Here is an example:
UPDATE items,month SET items.price=month.price WHERE items.id=month.id;
The preceding example shows an inner join that uses the comma
operator, but multiple-table UPDATE
statements can use any type of join permitted in
SELECT
statements, such as
LEFT JOIN
.
If you use a multiple-table UPDATE
statement involving InnoDB
tables for which
there are foreign key constraints, the MySQL optimizer might
process tables in an order that differs from that of their
parent/child relationship. In this case, the statement fails and
rolls back. Instead, update a single table and rely on the
ON UPDATE
capabilities that
InnoDB
provides to cause the other tables to be
modified accordingly. See
Section 13.3.5.4, “FOREIGN KEY
Constraints”.
Currently, you cannot update a table and select from the same table in a subquery.
Index hints (see Section 12.2.9.3, “Index Hint Синтаксис”) are accepted but
ignored for UPDATE
statements.
- 12.3.1.
START TRANSACTION
,COMMIT
, andROLLBACK
Синтаксис - 12.3.2. Statements That Cannot Be Rolled Back
- 12.3.3. Statements That Cause an Implicit Commit
- 12.3.4.
SAVEPOINT
andROLLBACK TO SAVEPOINT
Синтаксис - 12.3.5.
LOCK TABLES
andUNLOCK TABLES
Синтаксис - 12.3.6.
SET TRANSACTION
Синтаксис - 12.3.7. XA Transactions
MySQL supports local transactions (within a given client session)
through statements such as
SET autocommit
,
START TRANSACTION
,
COMMIT
, and
ROLLBACK
. See
Section 12.3.1, “START TRANSACTION
,
COMMIT
, and
ROLLBACK
Синтаксис”. XA transaction support enables MySQL to
participate in distributed transactions as well. See
Section 12.3.7, “XA Transactions”.
START TRANSACTION [WITH CONSISTENT SNAPSHOT] | BEGIN [WORK] COMMIT [WORK] [AND [NO] CHAIN | [NO] RELEASE] ROLLBACK [WORK] [AND [NO] CHAIN | [NO] RELEASE] SET autocommit = {0 | 1}
The START
TRANSACTION
or
BEGIN
statement
begins a new transaction. COMMIT
commits the current transaction, making its changes permanent.
ROLLBACK
rolls
back the current transaction, canceling its changes. The
SET autocommit
statement disables or enables the default autocommit mode for the
current session.
The optional WORK
keyword is supported for
COMMIT
and
ROLLBACK
, as are
the CHAIN
and RELEASE
clauses. CHAIN
and RELEASE
can be used for additional control over transaction completion.
The value of the completion_type
system variable determines the default completion behavior. See
Section 5.1.3, “Server System Variables”.
Within all stored programs (stored procedures and functions,
triggers, and events), the parser treats
BEGIN [WORK]
as the beginning of a
BEGIN ...
END
block. Begin a transaction in this context with
START
TRANSACTION
instead.
The AND CHAIN
clause causes a new transaction
to begin as soon as the current one ends, and the new transaction
has the same isolation level as the just-terminated transaction.
The RELEASE
clause causes the server to
disconnect the current client session after terminating the
current transaction. Including the NO
keyword
suppresses CHAIN
or RELEASE
completion, which can be useful if the
completion_type
system variable
is set to cause chaining or release completion by default.
By default, MySQL runs with autocommit mode enabled. This means that as soon as you execute a statement that updates (modifies) a table, MySQL stores the update on disk to make it permanent. To disable autocommit mode, use the following statement:
SET autocommit=0;
After disabling autocommit mode by setting the
autocommit
variable to zero,
changes to transaction-safe tables (such as those for
InnoDB
or
NDBCLUSTER
) are not made permanent
immediately. You must use COMMIT
to
store your changes to disk or
ROLLBACK
to
ignore the changes.
autocommit
is a session variable
and must be set for each session. If you want to disable
autocommit mode for each new connection, see the description of
the autocommit
system variable at
Section 5.1.3, “Server System Variables”.
To disable autocommit mode for a single series of statements, use
the START
TRANSACTION
statement:
START TRANSACTION; SELECT @A:=SUM(salary) FROM table1 WHERE type=1; UPDATE table2 SET summary=@A WHERE type=1; COMMIT;
With START
TRANSACTION
, autocommit remains disabled until you end
the transaction with COMMIT
or
ROLLBACK
. The
autocommit mode then reverts to its previous state.
BEGIN
and
BEGIN WORK
are
supported as aliases of
START
TRANSACTION
for initiating a transaction.
START
TRANSACTION
is standard SQL syntax and is the
recommended way to start an ad-hoc transaction.
Many APIs used for writing MySQL client applications (such as
JDBC) provide their own methods for starting transactions that
can (and sometimes should) be used instead of sending a
START
TRANSACTION
statement from the client. See
Глава 21, Connectors and APIs, or the documentation for your
API, for more information.
The BEGIN
statement differs from the use of the BEGIN
keyword that starts a
BEGIN ... END
compound statement. The latter does not begin a transaction. See
Section 12.6.1, “BEGIN ... END
Compound-Statement Синтаксис”.
You can also begin a transaction like this:
START TRANSACTION WITH CONSISTENT SNAPSHOT;
The WITH CONSISTENT SNAPSHOT
clause starts a
consistent read for storage engines that are capable of it. This
applies only to InnoDB
. The effect is the same
as issuing a START
TRANSACTION
followed by a
SELECT
from any
InnoDB
table. See
Section 13.3.9.2, “Consistent Nonlocking Reads”. The WITH
CONSISTENT SNAPSHOT
clause does not change the current
transaction isolation level, so it provides a consistent snapshot
only if the current isolation level is one that permits consistent
read (REPEATABLE READ
or
SERIALIZABLE
).
Beginning a transaction causes any pending transaction to be committed. See Section 12.3.3, “Statements That Cause an Implicit Commit”, for more information.
Beginning a transaction also causes table locks acquired with
LOCK TABLES
to be released, as
though you had executed
UNLOCK
TABLES
. Beginning a transaction does not release a
global read lock acquired with
FLUSH TABLES WITH READ
LOCK
.
For best results, transactions should be performed using only tables managed by a single transaction-safe storage engine. Otherwise, the following problems can occur:
If you use tables from more than one transaction-safe storage engine (such as
InnoDB
), and the transaction isolation level is notSERIALIZABLE
, it is possible that when one transaction commits, another ongoing transaction that uses the same tables will see only some of the changes made by the first transaction. That is, the atomicity of transactions is not guaranteed with mixed engines and inconsistencies can result. (If mixed-engine transactions are infrequent, you can useSET TRANSACTION ISOLATION LEVEL
to set the isolation level toSERIALIZABLE
on a per-transaction basis as necessary.)If you use tables that are not transaction-safe within a transaction, changes to those tables are stored at once, regardless of the status of autocommit mode.
If you issue a
ROLLBACK
statement after updating a nontransactional table within a transaction, anER_WARNING_NOT_COMPLETE_ROLLBACK
warning occurs. Changes to transaction-safe tables are rolled back, but not changes to nontransaction-safe tables.
Each transaction is stored in the binary log in one chunk, upon
COMMIT
. Transactions that are
rolled back are not logged.
(Exception: Modifications to
nontransactional tables cannot be rolled back. If a transaction
that is rolled back includes modifications to nontransactional
tables, the entire transaction is logged with a
ROLLBACK
statement at the end to ensure that modifications to the
nontransactional tables are replicated.) See
Section 5.2.4, “The Binary Log”.
You can change the isolation level for transactions with
SET TRANSACTION
ISOLATION LEVEL
. See Section 12.3.6, “SET TRANSACTION
Синтаксис”.
Rolling back can be a slow operation that may occur implicitly
without the user having explicitly asked for it (for example, when
an error occurs). Because of this, SHOW
PROCESSLIST
displays Rolling back
in
the State
column for the session, not only for
explicit rollbacks performed with the
ROLLBACK
statement but also for implicit rollbacks.
In MySQL 5.5, BEGIN
,
COMMIT
, and ROLLBACK
are
not affected by --replicate-do-db
or --replicate-ignore-db
rules.
Some statements cannot be rolled back. In general, these include data definition language (DDL) statements, such as those that create or drop databases, those that create, drop, or alter tables or stored routines.
You should design your transactions not to include such
statements. If you issue a statement early in a transaction that
cannot be rolled back, and then another statement later fails, the
full effect of the transaction cannot be rolled back in such cases
by issuing a
ROLLBACK
statement.
The statements listed in this section (and any synonyms for them)
implicitly end a transaction, as if you had done a
COMMIT
before executing the
statement. As of MySQL 5.5.3, most of these statements also cause
an implicit commit after executing; for additional details, see
the end of this section.
Data definition language (DDL) statements that define or modify database objects.
ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME
,ALTER EVENT
,ALTER PROCEDURE
,ALTER TABLE
,ALTER VIEW
,CREATE DATABASE
,CREATE EVENT
,CREATE INDEX
,CREATE PROCEDURE
,CREATE TABLE
,CREATE TRIGGER
,CREATE VIEW
,DROP DATABASE
,DROP EVENT
,DROP INDEX
,DROP PROCEDURE
,DROP TABLE
,DROP TRIGGER
,DROP VIEW
,RENAME TABLE
,TRUNCATE TABLE
.ALTER FUNCTION
,CREATE FUNCTION
andDROP FUNCTION
also cause an implicit commit when used with stored functions, but not with UDFs. (ALTER FUNCTION
can only be used with stored functions.)ALTER TABLE
,CREATE TABLE
, andDROP TABLE
do not commit a transaction if theTEMPORARY
keyword is used. (This does not apply to other operations on temporary tables such asCREATE INDEX
, which do cause a commit.) However, although no implicit commit occurs, neither can the statement be rolled back. Therefore, use of such statements will violate transaction atomicity: For example, if you useCREATE TEMPORARY TABLE
and then roll back the transaction, the table remains in existence.The
CREATE TABLE
statement inInnoDB
is processed as a single transaction. This means that aROLLBACK
from the user does not undoCREATE TABLE
statements the user made during that transaction.CREATE TABLE ... SELECT
causes an implicit commit before and after the statement is executed when you are creating nontemporary tables. (No commit occurs forCREATE TEMPORARY TABLE ... SELECT
.) This is to prevent an issue during replication where the table could be created on the master after a rollback, but fail to be recorded in the binary log, and therefore not replicated to the slave. For more information, see Bug #22865.Statements that implicitly use or modify tables in the
mysql
database.CREATE USER
,DROP USER
,GRANT
,RENAME USER
,REVOKE
,SET PASSWORD
.Transaction-control and locking statements.
BEGIN
,LOCK TABLES
,SET autocommit = 1
(if the value is not already 1),START TRANSACTION
,UNLOCK TABLES
.UNLOCK TABLES
commits a transaction only if any tables currently have been locked withLOCK TABLES
to acquire nontransactional table locks. A commit does not occur forUNLOCK TABLES
followingFLUSH TABLES WITH READ LOCK
because the latter statement does not acquire table-level locks.Transactions cannot be nested. This is a consequence of the implicit commit performed for any current transaction when you issue a
START TRANSACTION
statement or one of its synonyms.Statements that cause an implicit commit cannot be used in an XA transaction while the transaction is in an
ACTIVE
state.The
BEGIN
statement differs from the use of theBEGIN
keyword that starts aBEGIN ... END
compound statement. The latter does not cause an implicit commit. See Section 12.6.1, “BEGIN ... END
Compound-Statement Синтаксис”.Data loading statements.
LOAD DATA INFILE
.LOAD DATA INFILE
causes an implicit commit only for tables using theNDB
storage engine. For more information, see Bug #11151.Administrative statements.
ANALYZE TABLE
,CACHE INDEX
,CHECK TABLE
,LOAD INDEX INTO CACHE
,OPTIMIZE TABLE
,REPAIR TABLE
.
As of MySQL 5.5.3, most statements that previously caused an implicit commit before executing also do so after executing. The intent is to handle each such statement in its own special transaction because it cannot be rolled back anyway. The following list provides additional details pertaining to this change:
The
CREATE TABLE
variants (CREATE TABLE
forInnoDB
tables andCREATE TABLE ... SELECT
) that previously were special cases no longer are so becauseCREATE TABLE
uniformly causes an implicit commit before and after executing.Transaction-control and locking statements behave as before.
SAVEPOINTidentifier
ROLLBACK [WORK] TO [SAVEPOINT]identifier
RELEASE SAVEPOINTidentifier
InnoDB
supports the SQL statements
SAVEPOINT
,
ROLLBACK TO
SAVEPOINT
,
RELEASE
SAVEPOINT
and the optional WORK
keyword for
ROLLBACK
.
The SAVEPOINT
statement sets a
named transaction savepoint with a name of
identifier
. If the current transaction
has a savepoint with the same name, the old savepoint is deleted
and a new one is set.
The ROLLBACK TO
SAVEPOINT
statement rolls back a transaction to the
named savepoint without terminating the transaction. Modifications
that the current transaction made to rows after the savepoint was
set are undone in the rollback, but InnoDB
does
not release the row locks that were stored in
memory after the savepoint. (For a new inserted row, the lock
information is carried by the transaction ID stored in the row;
the lock is not separately stored in memory. In this case, the row
lock is released in the undo.) Savepoints that were set at a later
time than the named savepoint are deleted.
If the ROLLBACK TO
SAVEPOINT
statement returns the following error, it
means that no savepoint with the specified name exists:
ERROR 1305 (42000): SAVEPOINT identifier
does not exist
The RELEASE
SAVEPOINT
statement removes the named savepoint from the
set of savepoints of the current transaction. No commit or
rollback occurs. It is an error if the savepoint does not exist.
All savepoints of the current transaction are deleted if you
execute a COMMIT
, or a
ROLLBACK
that
does not name a savepoint.
A new savepoint level is created when a stored function is invoked or a trigger is activated. The savepoints on previous levels become unavailable and thus do not conflict with savepoints on the new level. When the function or trigger terminates, any savepoints it created are released and the previous savepoint level is restored.
LOCK TABLEStbl_name
[[AS]alias
]lock_type
[,tbl_name
[[AS]alias
]lock_type
] ...lock_type
: READ [LOCAL] | [LOW_PRIORITY] WRITE UNLOCK TABLES
MySQL enables client sessions to acquire table locks explicitly for the purpose of cooperating with other sessions for access to tables, or to prevent other sessions from modifying tables during periods when a session requires exclusive access to them. A session can acquire or release locks only for itself. One session cannot acquire locks for another session or release locks held by another session.
Locks may be used to emulate transactions or to get more speed when updating tables. This is explained in more detail later in this section.
LOCK TABLES
explicitly acquires
table locks for the current client session. Table locks can be
acquired for base tables or views. You must have the
LOCK TABLES
privilege, and the
SELECT
privilege for each object to
be locked.
For view locking, LOCK TABLES
adds
all base tables used in the view to the set of tables to be locked
and locks them automatically. If you lock a table explicitly with
LOCK TABLES
, any tables used in
triggers are also locked implicitly, as described in
Section 12.3.5.2, “LOCK TABLES
and Triggers”.
UNLOCK
TABLES
explicitly releases any table locks held by the
current session.
Another use for
UNLOCK
TABLES
is to release the global read lock acquired with
the FLUSH TABLES WITH READ
LOCK
statement, which enables you to lock all tables in
all databases. See Section 12.7.6.3, “FLUSH
Синтаксис”. (This is a very
convenient way to get backups if you have a file system such as
Veritas that can take snapshots in time.)
A table lock protects only against inappropriate reads or writes
by other sessions. The session holding the lock, even a read lock,
can perform table-level operations such as
DROP TABLE
. Truncate operations are
not transaction-safe, so an error occurs if the session attempts
one during an active transaction or while holding a table lock.
The following discussion applies only to
non-TEMPORARY
tables. LOCK
TABLES
is permitted (but ignored) for a
TEMPORARY
table. The table can be accessed
freely by the session within which it was created, regardless of
what other locking may be in effect. No lock is necessary because
no other session can see the table.
For information about other conditions on the use of
LOCK TABLES
and statements that
cannot be used while LOCK TABLES
is
in effect, see Section 12.3.5.3, “Table-Locking Restrictions and Conditions”
Rules for Lock Acquisition
To acquire table locks within the current session, use the
LOCK TABLES
statement. The
following lock types are available:
READ [LOCAL]
lock:
The session that holds the lock can read the table (but not write it).
Multiple sessions can acquire a
READ
lock for the table at the same time.Other sessions can read the table without explicitly acquiring a
READ
lock.The
LOCAL
modifier enables nonconflictingINSERT
statements (concurrent inserts) by other sessions to execute while the lock is held. (See Section 7.10.3, “Concurrent Inserts”.) However,READ LOCAL
cannot be used if you are going to manipulate the database using processes external to the server while you hold the lock. ForInnoDB
tables,READ LOCAL
is the same asREAD
.
[LOW_PRIORITY] WRITE
lock:
The session that holds the lock can read and write the table.
Only the session that holds the lock can access the table. No other session can access it until the lock is released.
Lock requests for the table by other sessions block while the
WRITE
lock is held.The
LOW_PRIORITY
modifier has no effect as of MySQL 5.5.3. Before 5.5.3, it affects lock scheduling if theWRITE
lock request must wait, as described later.
If the LOCK TABLES
statement must
wait due to locks held by other sessions on any of the tables, it
blocks until all locks can be acquired.
A session that requires locks must acquire all the locks that it
needs in a single LOCK TABLES
statement. While the locks thus obtained are held, the session can
access only the locked tables. For example, in the following
sequence of statements, an error occurs for the attempt to access
t2
because it was not locked in the
LOCK TABLES
statement:
mysql>LOCK TABLES t1 READ;
mysql>SELECT COUNT(*) FROM t1;
+----------+ | COUNT(*) | +----------+ | 3 | +----------+ mysql>SELECT COUNT(*) FROM t2;
ERROR 1100 (HY000): Table 't2' was not locked with LOCK TABLES
Tables in the INFORMATION_SCHEMA
database are
an exception. They can be accessed without being locked explicitly
even while a session holds table locks obtained with
LOCK TABLES
.
You cannot refer to a locked table multiple times in a single query using the same name. Use aliases instead, and obtain a separate lock for the table and each alias:
mysql>LOCK TABLE t WRITE, t AS t1 READ;
mysql>INSERT INTO t SELECT * FROM t;
ERROR 1100: Table 't' was not locked with LOCK TABLES mysql>INSERT INTO t SELECT * FROM t AS t1;
The error occurs for the first
INSERT
because there are two
references to the same name for a locked table. The second
INSERT
succeeds because the
references to the table use different names.
If your statements refer to a table by means of an alias, you must lock the table using that same alias. It does not work to lock the table without specifying the alias:
mysql>LOCK TABLE t READ;
mysql>SELECT * FROM t AS myalias;
ERROR 1100: Table 'myalias' was not locked with LOCK TABLES
Conversely, if you lock a table using an alias, you must refer to it in your statements using that alias:
mysql>LOCK TABLE t AS myalias READ;
mysql>SELECT * FROM t;
ERROR 1100: Table 't' was not locked with LOCK TABLES mysql>SELECT * FROM t AS myalias;
WRITE
locks normally have higher priority than
READ
locks to ensure that updates are processed
as soon as possible. This means that if one session obtains a
READ
lock and then another session requests a
WRITE
lock, subsequent READ
lock requests wait until the session that requested the
WRITE
lock has obtained the lock and released
it. Before MySQL 5.5.3, the LOW_PRIORITY
modifier can be given to affect locking behavior as follows (as of
5.5.3, it has no effect): A request for a LOW_PRIORITY
WRITE
lock permits subsequent READ
lock requests by other sessions to be satisfied first if they
occur while the LOW_PRIORITY WRITE
request is
waiting. You should use LOW_PRIORITY WRITE
locks only if you are sure that eventually there will be a time
when no sessions have a READ
lock. For
InnoDB
tables in transactional mode (autocommit
= 0), a waiting LOW_PRIORITY WRITE
lock acts
like a regular WRITE
lock and causes subsequent
READ
lock requests to wait.
LOCK TABLES
acquires locks as
follows:
Sort all tables to be locked in an internally defined order. From the user standpoint, this order is undefined.
If a table is to be locked with a read and a write lock, put the write lock request before the read lock request.
Lock one table at a time until the session gets all locks.
This policy ensures that table locking is deadlock free. There
are, however, other things you need to be aware of about this
policy: If you are using a LOW_PRIORITY WRITE
lock for a table, it means only that MySQL waits for this
particular lock until there are no other sessions that want a
READ
lock. When the session has gotten the
WRITE
lock and is waiting to get the lock for
the next table in the lock table list, all other sessions wait for
the WRITE
lock to be released. If this becomes
a serious problem with your application, you should consider
converting some of your tables to transaction-safe tables.
Rules for Lock Release
When the table locks held by a session are released, they are all released at the same time. A session can release its locks explicitly, or locks may be released implicitly under certain conditions.
A session can release its locks explicitly with
UNLOCK TABLES
.If a session issues a
LOCK TABLES
statement to acquire a lock while already holding locks, its existing locks are released implicitly before the new locks are granted.If a session begins a transaction (for example, with
START TRANSACTION
), an implicitUNLOCK TABLES
is performed, which causes existing locks to be released. (For additional information about the interaction between table locking and transactions, see Section 12.3.5.1, “Interaction of Table Locking and Transactions”.)
If the connection for a client session terminates, whether normally or abnormally, the server implicitly releases all table locks held by the session (transactional and nontransactional). If the client reconnects, the locks will no longer be in effect. In addition, if the client had an active transaction, the server rolls back the transaction upon disconnect, and if reconnect occurs, the new session begins with autocommit enabled. For this reason, clients may wish to disable auto-reconnect. With auto-reconnect in effect, the client is not notified if reconnect occurs but any table locks or current transaction will have been lost. With auto-reconnect disabled, if the connection drops, an error occurs for the next statement issued. The client can detect the error and take appropriate action such as reacquiring the locks or redoing the transaction. See Section 21.9.12, “Controlling Automatic Reconnection Behavior”.
If you use ALTER TABLE
on a
locked table, it may become unlocked. For example, if you
attempt a second ALTER TABLE
operation, the result may be an error Table
'
. To handle this, lock the table again prior to
the second alteration. See also
Section C.5.7.1, “Problems with tbl_name
' was not locked with LOCK
TABLESALTER TABLE
”.
LOCK TABLES
and
UNLOCK
TABLES
interact with the use of transactions as
follows:
LOCK TABLES
is not transaction-safe and implicitly commits any active transaction before attempting to lock the tables.UNLOCK TABLES
implicitly commits any active transaction, but only ifLOCK TABLES
has been used to acquire table locks. For example, in the following set of statements,UNLOCK TABLES
releases the global read lock but does not commit the transaction because no table locks are in effect:FLUSH TABLES WITH READ LOCK; START TRANSACTION; SELECT ... ; UNLOCK TABLES;
Beginning a transaction (for example, with
START TRANSACTION
) implicitly commits any current transaction and releases existing locks.Other statements that implicitly cause transactions to be committed do not release existing locks. For a list of such statements, see Section 12.3.3, “Statements That Cause an Implicit Commit”.
The correct way to use
LOCK TABLES
andUNLOCK TABLES
with transactional tables, such asInnoDB
tables, is to begin a transaction withSET autocommit = 0
(notSTART TRANSACTION
) followed byLOCK TABLES
, and to not callUNLOCK TABLES
until you commit the transaction explicitly. For example, if you need to write to tablet1
and read from tablet2
, you can do this:SET autocommit=0; LOCK TABLES t1 WRITE, t2 READ, ...;
... do something with tables t1 and t2 here ...
COMMIT; UNLOCK TABLES;When you call
LOCK TABLES
,InnoDB
internally takes its own table lock, and MySQL takes its own table lock.InnoDB
releases its internal table lock at the next commit, but for MySQL to release its table lock, you have to callUNLOCK TABLES
. You should not haveautocommit = 1
, because thenInnoDB
releases its internal table lock immediately after the call ofLOCK TABLES
, and deadlocks can very easily happen.InnoDB
does not acquire the internal table lock at all ifautocommit = 1
, to help old applications avoid unnecessary deadlocks.ROLLBACK
does not release table locks.FLUSH TABLES WITH READ LOCK
acquires a global read lock and not table locks, so it is not subject to the same behavior asLOCK TABLES
andUNLOCK TABLES
with respect to table locking and implicit commits. See Section 12.7.6.3, “FLUSH
Синтаксис”.
If you lock a table explicitly with LOCK
TABLES
, any tables used in triggers are also locked
implicitly:
The locks are taken as the same time as those acquired explicitly with the
LOCK TABLES
statement.The lock on a table used in a trigger depends on whether the table is used only for reading. If so, a read lock suffices. Otherwise, a write lock is used.
If a table is locked explicitly for reading with
LOCK TABLES
, but needs to be locked for writing because it might be modified within a trigger, a write lock is taken rather than a read lock. (That is, an implicit write lock needed due to the table's appearance within a trigger causes an explicit read lock request for the table to be converted to a write lock request.)
Suppose that you lock two tables, t1
and
t2
, using this statement:
LOCK TABLES t1 WRITE, t2 READ;
If t1
or t2
have any
triggers, tables used within the triggers will also be locked.
Suppose that t1
has a trigger defined like
this:
CREATE TRIGGER t1_a_ins AFTER INSERT ON t1 FOR EACH ROW BEGIN UPDATE t4 SET count = count+1 WHERE id = NEW.id AND EXISTS (SELECT a FROM t3); INSERT INTO t2 VALUES(1, 2); END;
The result of the LOCK TABLES
statement is that t1
and
t2
are locked because they appear in the
statement, and t3
and t4
are locked because they are used within the trigger:
t1
is locked for writing per theWRITE
lock request.t2
is locked for writing, even though the request is for aREAD
lock. This occurs becauset2
is inserted into within the trigger, so theREAD
request is converted to aWRITE
request.t3
is locked for reading because it is only read from within the trigger.t4
is locked for writing because it might be updated within the trigger.
You can safely use KILL
to
terminate a session that is waiting for a table lock. See
Section 12.7.6.4, “KILL
Синтаксис”.
You should not lock any tables that you are
using with INSERT DELAYED
. An
INSERT DELAYED
in this case
results in an error because the insert must be handled by a
separate thread, not by the session which holds the lock.
LOCK TABLES
and
UNLOCK
TABLES
cannot be used within stored programs.
Tables in the performance_schema
database
cannot be locked with LOCK TABLES
, except the
SETUP_
tables.
xxx
The following statements are prohibited while a
LOCK TABLES
statement is in
effect:
As of MySQL 5.5.3,
CREATE TABLE
,CREATE TABLE ... LIKE
,CREATE VIEW
,DROP VIEW
, and DDL statements on stored procedures and functions.As of MySQL 5.5.8, DDL statements on events
For some operations, system tables in the
mysql
database must be accessed. For example,
the HELP
statement requires the
contents of the server-side help tables, and
CONVERT_TZ()
might need to read
the time zone tables. The server implicitly locks the system
tables for reading as necessary so that you need not lock them
explicitly. These tables are treated as just described:
mysql.help_category mysql.help_keyword mysql.help_relation mysql.help_topic mysql.proc mysql.time_zone mysql.time_zone_leap_second mysql.time_zone_name mysql.time_zone_transition mysql.time_zone_transition_type
If you want to explicitly place a WRITE
lock
on any of those tables with a LOCK
TABLES
statement, the table must be the only one
locked; no other table can be locked with the same statement.
Normally, you do not need to lock tables, because all single
UPDATE
statements are atomic; no
other session can interfere with any other currently executing
SQL statement. However, there are a few cases when locking
tables may provide an advantage:
If you are going to run many operations on a set of
MyISAM
tables, it is much faster to lock the tables you are going to use. LockingMyISAM
tables speeds up inserting, updating, or deleting on them because MySQL does not flush the key cache for the locked tables untilUNLOCK TABLES
is called. Normally, the key cache is flushed after each SQL statement.The downside to locking the tables is that no session can update a
READ
-locked table (including the one holding the lock) and no session can access aWRITE
-locked table other than the one holding the lock.If you are using tables for a nontransactional storage engine, you must use
LOCK TABLES
if you want to ensure that no other session modifies the tables between aSELECT
and anUPDATE
. The example shown here requiresLOCK TABLES
to execute safely:LOCK TABLES trans READ, customer WRITE; SELECT SUM(value) FROM trans WHERE customer_id=
some_id
; UPDATE customer SET total_value=sum_from_previous_statement
WHERE customer_id=some_id
; UNLOCK TABLES;Without
LOCK TABLES
, it is possible that another session might insert a new row in thetrans
table between execution of theSELECT
andUPDATE
statements.
You can avoid using LOCK TABLES
in many cases by using relative updates (UPDATE
customer SET
)
or the value
=value
+new_value
LAST_INSERT_ID()
function.
See Section 1.8.5.3, “Transaction and Atomic Operation Differences”.
You can also avoid locking tables in some cases by using the
user-level advisory lock functions
GET_LOCK()
and
RELEASE_LOCK()
. These locks are
saved in a hash table in the server and implemented with
pthread_mutex_lock()
and
pthread_mutex_unlock()
for high speed. See
Section 11.15, “Miscellaneous Functions”.
See Section 7.10.1, “Internal Locking Methods”, for more information on locking policy.
SET [GLOBAL | SESSION] TRANSACTION ISOLATION LEVEL { READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE }
This statement sets the transaction isolation level globally, for the current session, or for the next transaction:
With the
GLOBAL
keyword, the statement sets the default transaction level globally for all subsequent sessions. Existing sessions are unaffected.With the
SESSION
keyword, the statement sets the default transaction level for all subsequent transactions performed within the current session.Without any
SESSION
orGLOBAL
keyword, the statement sets the isolation level for the next (not started) transaction performed within the current session.
A change to the global default isolation level requires the
SUPER
privilege. Any session is
free to change its session isolation level (even in the middle of
a transaction), or the isolation level for its next transaction.
SET TRANSACTION
ISOLATION LEVEL
without GLOBAL
or
SESSION
is not permitted while there is an
active transaction:
mysql>START TRANSACTION;
Query OK, 0 rows affected (0.02 sec) mysql>SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
ERROR 1568 (25001): Transaction isolation level can't be changed while a transaction is in progress
To set the global default isolation level at server startup, use
the
--transaction-isolation=
option to mysqld on the command line or in an
option file. Values of level
level
for this
option use dashes rather than spaces, so the permissible values
are READ-UNCOMMITTED
,
READ-COMMITTED
,
REPEATABLE-READ
, or
SERIALIZABLE
. For example, to
set the default isolation level to
REPEATABLE READ
, use these
lines in the [mysqld]
section of an option
file:
[mysqld] transaction-isolation = REPEATABLE-READ
To determine the global and session transaction isolation levels
at runtime, check the value of the
tx_isolation
system variable:
SELECT @@GLOBAL.tx_isolation, @@tx_isolation;
InnoDB
supports each of the transaction
isolation levels described here using different locking
strategies. The default level is
REPEATABLE READ
. For additional
information about InnoDB
record-level locks and
how it uses them to execute various types of statements, see
Section 13.3.9.4, “InnoDB
Record, Gap, and Next-Key Locks”, and
Section 13.3.9.6, “Locks Set by Different SQL Statements in InnoDB
”.
The following list describes how MySQL supports the different transaction levels:
SELECT
statements are performed in a nonlocking fashion, but a possible earlier version of a row might be used. Thus, using this isolation level, such reads are not consistent. This is also called a “dirty read.” Otherwise, this isolation level works likeREAD COMMITTED
.A somewhat Oracle-like isolation level with respect to consistent (nonlocking) reads: Each consistent read, even within the same transaction, sets and reads its own fresh snapshot. See Section 13.3.9.2, “Consistent Nonlocking Reads”.
For locking reads (
SELECT
withFOR UPDATE
orLOCK IN SHARE MODE
),InnoDB
locks only index records, not the gaps before them, and thus permits the free insertion of new records next to locked records. ForUPDATE
andDELETE
statements, locking depends on whether the statement uses a unique index with a unique search condition (such asWHERE id = 100
), or a range-type search condition (such asWHERE id > 100
). For a unique index with a unique search condition,InnoDB
locks only the index record found, not the gap before it. For range-type searches,InnoDB
locks the index range scanned, using gap locks or next-key (gap plus index-record) locks to block insertions by other sessions into the gaps covered by the range. This is necessary because “phantom rows” must be blocked for MySQL replication and recovery to work.ЗамечаниеIn MySQL 5.5, if the
READ COMMITTED
isolation level is used or theinnodb_locks_unsafe_for_binlog
system variable is enabled, there is noInnoDB
gap locking except for foreign-key constraint checking and duplicate-key checking. Also, record locks for nonmatching rows are released after MySQL has evaluated theWHERE
condition.If you use
READ COMMITTED
or enableinnodb_locks_unsafe_for_binlog
, you must use row-based binary logging.This is the default isolation level for
InnoDB
. For consistent reads, there is an important difference from theREAD COMMITTED
isolation level: All consistent reads within the same transaction read the snapshot established by the first read. This convention means that if you issue several plain (nonlocking)SELECT
statements within the same transaction, theseSELECT
statements are consistent also with respect to each other. See Section 13.3.9.2, “Consistent Nonlocking Reads”.For locking reads (
SELECT
withFOR UPDATE
orLOCK IN SHARE MODE
),UPDATE
, andDELETE
statements, locking depends on whether the statement uses a unique index with a unique search condition, or a range-type search condition. For a unique index with a unique search condition,InnoDB
locks only the index record found, not the gap before it. For other search conditions,InnoDB
locks the index range scanned, using gap locks or next-key (gap plus index-record) locks to block insertions by other sessions into the gaps covered by the range.This level is like
REPEATABLE READ
, butInnoDB
implicitly converts all plainSELECT
statements toSELECT ... LOCK IN SHARE MODE
if autocommit is disabled. If autocommit is enabled, theSELECT
is its own transaction. It therefore is known to be read only and can be serialized if performed as a consistent (nonlocking) read and need not block for other transactions. (This means that to force a plainSELECT
to block if other transactions have modified the selected rows, you should disable autocommit.)
Support for XA transactions is available for the
InnoDB
storage engine. The MySQL XA
implementation is based on the X/Open CAE document
Distributed Transaction Processing: The XA
Specification. This document is published by The Open
Group and available at
http://www.opengroup.org/public/pubs/catalog/c193.htm.
Limitations of the current XA implementation are described in
Section E.6, “Restrictions on XA Transactions”.
On the client side, there are no special requirements. The XA
interface to a MySQL server consists of SQL statements that begin
with the XA
keyword. MySQL client programs must
be able to send SQL statements and to understand the semantics of
the XA statement interface. They do not need be linked against a
recent client library. Older client libraries also will work.
Currently, among the MySQL Connectors, MySQL Connector/J 5.0.0 supports XA directly (by means of a class interface that handles the Xan SQL statement interface for you).
XA supports distributed transactions; that is, the ability to permit multiple separate transactional resources to participate in a global transaction. Transactional resources often are RDBMSs but may be other kinds of resources.
A global transaction involves several actions that are
transactional in themselves, but that all must either complete
successfully as a group, or all be rolled back as a group. In
essence, this extends ACID properties “up a level” so
that multiple ACID transactions can be executed in concert as
components of a global operation that also has ACID properties.
(However, for a distributed transaction, you must use the
SERIALIZABLE
isolation level to
achieve ACID properties. It is enough to use
REPEATABLE READ
for a
nondistributed transaction, but not for a distributed
transaction.)
Some examples of distributed transactions:
An application may act as an integration tool that combines a messaging service with an RDBMS. The application makes sure that transactions dealing with message sending, retrieval, and processing that also involve a transactional database all happen in a global transaction. You can think of this as “transactional email.”
An application performs actions that involve different database servers, such as a MySQL server and an Oracle server (or multiple MySQL servers), where actions that involve multiple servers must happen as part of a global transaction, rather than as separate transactions local to each server.
A bank keeps account information in an RDBMS and distributes and receives money through automated teller machines (ATMs). It is necessary to ensure that ATM actions are correctly reflected in the accounts, but this cannot be done with the RDBMS alone. A global transaction manager integrates the ATM and database resources to ensure overall consistency of financial transactions.
Applications that use global transactions involve one or more Resource Managers and a Transaction Manager:
A Resource Manager (RM) provides access to transactional resources. A database server is one kind of resource manager. It must be possible to either commit or roll back transactions managed by the RM.
A Transaction Manager (TM) coordinates the transactions that are part of a global transaction. It communicates with the RMs that handle each of these transactions. The individual transactions within a global transaction are “branches” of the global transaction. Global transactions and their branches are identified by a naming scheme described later.
The MySQL implementation of XA MySQL enables a MySQL server to act as a Resource Manager that handles XA transactions within a global transaction. A client program that connects to the MySQL server acts as the Transaction Manager.
To carry out a global transaction, it is necessary to know which components are involved, and bring each component to a point when it can be committed or rolled back. Depending on what each component reports about its ability to succeed, they must all commit or roll back as an atomic group. That is, either all components must commit, or all components must roll back. To manage a global transaction, it is necessary to take into account that any component or the connecting network might fail.
The process for executing a global transaction uses two-phase commit (2PC). This takes place after the actions performed by the branches of the global transaction have been executed.
In the first phase, all branches are prepared. That is, they are told by the TM to get ready to commit. Typically, this means each RM that manages a branch records the actions for the branch in stable storage. The branches indicate whether they are able to do this, and these results are used for the second phase.
In the second phase, the TM tells the RMs whether to commit or roll back. If all branches indicated when they were prepared that they will be able to commit, all branches are told to commit. If any branch indicated when it was prepared that it will not be able to commit, all branches are told to roll back.
In some cases, a global transaction might use one-phase commit (1PC). For example, when a Transaction Manager finds that a global transaction consists of only one transactional resource (that is, a single branch), that resource can be told to prepare and commit at the same time.
To perform XA transactions in MySQL, use the following statements:
XA {START|BEGIN}xid
[JOIN|RESUME] XA ENDxid
[SUSPEND [FOR MIGRATE]] XA PREPARExid
XA COMMITxid
[ONE PHASE] XA ROLLBACKxid
XA RECOVER
For XA
START
, the JOIN
and
RESUME
clauses are not supported.
For XA
END
the SUSPEND [FOR MIGRATE]
clause is not supported.
Each XA statement begins with the XA
keyword,
and most of them require an xid
value. An xid
is an XA transaction
identifier. It indicates which transaction the statement applies
to. xid
values are supplied by the
client, or generated by the MySQL server. An
xid
value has from one to three
parts:
xid
:gtrid
[,bqual
[,formatID
]]
gtrid
is a global transaction
identifier, bqual
is a branch
qualifier, and formatID
is a number
that identifies the format used by the
gtrid
and
bqual
values. As indicated by the
syntax, bqual
and
formatID
are optional. The default
bqual
value is ''
if not given. The default formatID
value is 1 if not given.
gtrid
and
bqual
must be string literals, each
up to 64 bytes (not characters) long.
gtrid
and
bqual
can be specified in several
ways. You can use a quoted string ('ab'
), hex
string (0x6162
, X'ab'
), or
bit value
(b'
).
nnnn
'
formatID
is an unsigned integer.
The gtrid
and
bqual
values are interpreted in bytes
by the MySQL server's underlying XA support routines. However,
while an SQL statement containing an XA statement is being
parsed, the server works with some specific character set. To be
safe, write gtrid
and
bqual
as hex strings.
xid
values typically are generated by
the Transaction Manager. Values generated by one TM must be
different from values generated by other TMs. A given TM must be
able to recognize its own xid
values
in a list of values returned by the
XA
RECOVER
statement.
XA START
starts an XA transaction with the given
xid
xid
value. Each XA transaction must
have a unique xid
value, so the value
must not currently be used by another XA transaction. Uniqueness
is assessed using the gtrid
and
bqual
values. All following XA
statements for the XA transaction must be specified using the
same xid
value as that given in the
XA
START
statement. If you use any of those statements
but specify an xid
value that does
not correspond to some existing XA transaction, an error occurs.
One or more XA transactions can be part of the same global
transaction. All XA transactions within a given global
transaction must use the same gtrid
value in the xid
value. For this
reason, gtrid
values must be globally
unique so that there is no ambiguity about which global
transaction a given XA transaction is part of. The
bqual
part of the
xid
value must be different for each
XA transaction within a global transaction. (The requirement
that bqual
values be different is a
limitation of the current MySQL XA implementation. It is not
part of the XA specification.)
The XA
RECOVER
statement returns information for those XA
transactions on the MySQL server that are in the
PREPARED
state. (See
Section 12.3.7.2, “XA Transaction States”.) The output includes a row for each
such XA transaction on the server, regardless of which client
started it.
XA
RECOVER
output rows look like this (for an example
xid
value consisting of the parts
'abc'
, 'def'
, and
7
):
mysql> XA RECOVER;
+----------+--------------+--------------+--------+
| formatID | gtrid_length | bqual_length | data |
+----------+--------------+--------------+--------+
| 7 | 3 | 3 | abcdef |
+----------+--------------+--------------+--------+
The output columns have the following meanings:
formatID
is theformatID
part of the transactionxid
gtrid_length
is the length in bytes of thegtrid
part of thexid
bqual_length
is the length in bytes of thebqual
part of thexid
data
is the concatenation of thegtrid
andbqual
parts of thexid
An XA transaction progresses through the following states:
Use
XA START
to start an XA transaction and put it in theACTIVE
state.For an
ACTIVE
XA transaction, issue the SQL statements that make up the transaction, and then issue anXA END
statement.XA END
puts the transaction in theIDLE
state.For an
IDLE
XA transaction, you can issue either anXA PREPARE
statement or anXA COMMIT ... ONE PHASE
statement:XA PREPARE
puts the transaction in thePREPARED
state. AnXA RECOVER
statement at this point will include the transaction'sxid
value in its output, becauseXA RECOVER
lists all XA transactions that are in thePREPARED
state.XA COMMIT ... ONE PHASE
prepares and commits the transaction. Thexid
value will not be listed byXA RECOVER
because the transaction terminates.
For a
PREPARED
XA transaction, you can issue anXA COMMIT
statement to commit and terminate the transaction, orXA ROLLBACK
to roll back and terminate the transaction.
Here is a simple XA transaction that inserts a row into a table as part of a global transaction:
mysql>XA START 'xatest';
Query OK, 0 rows affected (0.00 sec) mysql>INSERT INTO mytable (i) VALUES(10);
Query OK, 1 row affected (0.04 sec) mysql>XA END 'xatest';
Query OK, 0 rows affected (0.00 sec) mysql>XA PREPARE 'xatest';
Query OK, 0 rows affected (0.00 sec) mysql>XA COMMIT 'xatest';
Query OK, 0 rows affected (0.00 sec)
Within the context of a given client connection, XA transactions
and local (non-XA) transactions are mutually exclusive. For
example, if XA
START
has been issued to begin an XA transaction, a
local transaction cannot be started until the XA transaction has
been committed or rolled back. Conversely, if a local
transaction has been started with
START
TRANSACTION
, no XA statements can be used until the
transaction has been committed or rolled back.
Note that if an XA transaction is in the
ACTIVE
state, you cannot issue any statements
that cause an implicit commit. That would violate the XA
contract because you could not roll back the XA transaction. You
will receive the following error if you try to execute such a
statement:
ERROR 1399 (XAE07): XAER_RMFAIL: The command cannot be executed when global transaction is in the ACTIVE state
Statements to which the preceding remark applies are listed at Section 12.3.3, “Statements That Cause an Implicit Commit”.
Replication can be controlled through the SQL interface using the statements described in this section. One group of statements controls master servers, the other controls slave servers.
This section discusses statements for managing master replication servers. Section 12.4.2, “SQL Statements for Controlling Slave Servers”, discusses statements for managing slave servers.
In addition to the statements described here, the following
SHOW
statements are used with
master servers in replication. For information about these
statements, see Section 12.7.5, “SHOW
Синтаксис”.
PURGE { BINARY | MASTER } LOGS { TO 'log_name
' | BEFOREdatetime_expr
}
The binary log is a set of files that contain information about data modifications made by the MySQL server. The log consists of a set of binary log files, plus an index file (see Section 5.2.4, “The Binary Log”).
The PURGE BINARY LOGS
statement
deletes all the binary log files listed in the log index file
prior to the specified log file name or date.
BINARY
and MASTER
are
synonyms. Deleted log files also are removed from the list
recorded in the index file, so that the given log file becomes
the first in the list.
This statement has no effect if the server was not started with
the --log-bin
option to enable
binary logging.
Examples:
PURGE BINARY LOGS TO 'mysql-bin.010'; PURGE BINARY LOGS BEFORE '2008-04-02 22:46:26';
The BEFORE
variant's
datetime_expr
argument should
evaluate to a DATETIME
value (a
value in 'YYYY-MM-DD hh:mm:ss'
format).
This statement is safe to run while slaves are replicating. You need not stop them. If you have an active slave that currently is reading one of the log files you are trying to delete, this statement does nothing and fails with an error. However, if a slave is not connected and you happen to purge one of the log files it has yet to read, the slave will be unable to replicate after it reconnects.
To safely purge binary log files, follow this procedure:
On each slave server, use
SHOW SLAVE STATUS
to check which log file it is reading.Obtain a listing of the binary log files on the master server with
SHOW BINARY LOGS
.Determine the earliest log file among all the slaves. This is the target file. If all the slaves are up to date, this is the last log file on the list.
Make a backup of all the log files you are about to delete. (This step is optional, but always advisable.)
Purge all log files up to but not including the target file.
You can also set the
expire_logs_days
system
variable to expire binary log files automatically after a given
number of days (see Section 5.1.3, “Server System Variables”).
If you are using replication, you should set the variable no
lower than the maximum number of days your slaves might lag
behind the master.
PURGE BINARY LOGS TO
and PURGE
BINARY LOGS BEFORE
both fail with an error when binary
log files listed in the .index
file had
been removed from the system by some other means (such as using
rm on Linux). (Bug #18199, Bug #18453) To
handle such errors, edit the .index
file
(which is a simple text file) manually to ensure that it lists
only the binary log files that are actually present, then run
again the PURGE BINARY LOGS
statement that failed.
RESET MASTER
Deletes all binary log files listed in the index file, resets the binary log index file to be empty, and creates a new binary log file. This statement is intended to be used only when the master is started for the first time.
The effects of RESET MASTER
differ from those of PURGE BINARY
LOGS
in 2 key ways:
RESET MASTER
removes all binary log files that are listed in the index file, leaving only a single, empty binary log file with a numeric suffix of.000001
, whereas the numbering is not reset byPURGE BINARY LOGS
.RESET MASTER
is not intended to be used while any replication slaves are running. The behavior ofRESET MASTER
when used while slaves are running is undefined (and thus unsupported), whereasPURGE BINARY LOGS
may be safely used while replication slaves are running.
RESET MASTER
can prove useful
when you first set up the master and the slave, so that you can
verify the setup as follows:
Start the master and slave, and start replication (see Section 15.1.1, “How to Set Up Replication”).
Execute a few test queries on the master.
Check that the queries were replicated to the slave.
When replication is running correctly, issue
STOP SLAVE
followed byRESET SLAVE
on the slave, then verify that any unwanted data no longer exists on the slave.Issue
RESET MASTER
on the master to clean up the test queries.
After verifying the setup and getting rid of any unwanted and log files generated by testing, you can start the slave and begin replicating.
SET sql_log_bin = {0|1}
Disables or enables binary logging for the current session
(sql_log_bin
is a session
variable) if the client has the
SUPER
privilege. The statement
fails with an error if the client does not have that privilege.
This section discusses statements for managing slave replication servers. Section 12.4.1, “SQL Statements for Controlling Master Servers”, discusses statements for managing master servers.
In addition to the statements described here,
SHOW SLAVE STATUS
is also used with
replication slaves. For information about this statement, see
Section 12.7.5.35, “SHOW SLAVE STATUS
Синтаксис”.
CHANGE MASTER TOoption
[,option
] ...option
: MASTER_BIND = 'interface_name
' | MASTER_HOST = 'host_name
' | MASTER_USER = 'user_name
' | MASTER_PASSWORD = 'password
' | MASTER_PORT =port_num
| MASTER_CONNECT_RETRY =interval
| MASTER_HEARTBEAT_PERIOD =interval
| MASTER_LOG_FILE = 'master_log_name
' | MASTER_LOG_POS =master_log_pos
| RELAY_LOG_FILE = 'relay_log_name
' | RELAY_LOG_POS =relay_log_pos
| MASTER_SSL = {0|1} | MASTER_SSL_CA = 'ca_file_name
' | MASTER_SSL_CAPATH = 'ca_directory_name
' | MASTER_SSL_CERT = 'cert_file_name
' | MASTER_SSL_KEY = 'key_file_name
' | MASTER_SSL_CIPHER = 'cipher_list
' | MASTER_SSL_VERIFY_SERVER_CERT = {0|1} | IGNORE_SERVER_IDS = (server_id_list
)server_id_list
: [server_id
[,server_id
] ... ]
CHANGE MASTER TO
changes the
parameters that the slave server uses for connecting to the
master server, for reading the master binary log, and reading
the slave relay log. It also updates the contents of the
master.info
and
relay-log.info
files. To use
CHANGE MASTER TO
, the slave
replication threads must be stopped (use
STOP SLAVE
if necessary).
Options not specified retain their value, except as indicated in the following discussion. Thus, in most cases, there is no need to specify options that do not change. For example, if the password to connect to your MySQL master has changed, you just need to issue these statements to tell the slave about the new password:
STOP SLAVE; -- if replication was running CHANGE MASTER TO MASTER_PASSWORD='new3cret'; START SLAVE; -- if you want to restart replication
MASTER_HOST
, MASTER_USER
,
MASTER_PASSWORD
, and
MASTER_PORT
provide information to the slave
about how to connect to its master:
MASTER_HOST
andMASTER_PORT
are the host name (or IP address) of the master host and its TCP/IP port.ЗамечаниеReplication cannot use Unix socket files. You must be able to connect to the master MySQL server using TCP/IP.
If you specify the
MASTER_HOST
orMASTER_PORT
option, the slave assumes that the master server is different from before (even if the option value is the same as its current value.) In this case, the old values for the master binary log file name and position are considered no longer applicable, so if you do not specifyMASTER_LOG_FILE
andMASTER_LOG_POS
in the statement,MASTER_LOG_FILE=''
andMASTER_LOG_POS=4
are silently appended to it.Setting
MASTER_HOST=''
(that is, setting its value explicitly to an empty string) is not the same as not settingMASTER_HOST
at all. Beginning with MySQL 5.5, trying to setMASTER_HOST
to an empty string fails with an error. Previously, settingMASTER_HOST
to an empty string causedSTART SLAVE
subsequently to fail. (Bug #28796)MASTER_USER
andMASTER_PASSWORD
are the user name and password of the account to use for connecting to the master.In MySQL 5.5.20 and later,
MASTER_USER
cannot be made empty; settingMASTER_USER = ''
or leaving it unset when setting a value for forMASTER_PASSWORD
causes an error (Bug #13427949).Currently, a password used for a replication slave account can exceed 32 characters, but any characters in excess of this number are truncated. This is not due to any limit imposed by the MySQL Server but rather one that is specific to MySQL Replication. (See Bug #43439, for more information.)
The text of a running
CHANGE MASTER TO
statement, including values forMASTER_USER
andMASTER_PASSWORD
, can be seen in the output of a concurrentSHOW PROCESSLIST
statement.
The MASTER_SSL_
options provide information about using SSL for the connection.
They correspond to the
xxx
--ssl-
options
described in Section 5.5.8.3, “SSL Command Options”, and
Section 15.3.7, “Setting Up Replication Using SSL”. These options can
be changed even on slaves that are compiled without SSL support.
They are saved to the xxx
master.info
file, but
are ignored if the slave does not have SSL support enabled.
MASTER_CONNECT_RETRY
specifies how many
seconds to wait between connect retries. The default is 60. The
number of reconnection attempts is limited
by the --master-retry-count
server option; for more information, see
Section 15.1.3, “Replication and Binary Logging Options and Variables”.
The MASTER_BIND
option is available in MySQL
Cluster NDB 7.2 and later, but is not supported in mainline
MySQL 5.5.
MASTER_BIND
is for use on replication slaves
having multiple network interfaces, and determines which of the
slave's network interfaces is chosen for connecting to the
master.
MASTER_HEARTBEAT_PERIOD
sets the interval in
seconds between replication heartbeats. Whenever the master's
binary log is updated with an event, the waiting period for the
next heartbeat is reset. interval
is
a decimal value having the range 0 to 4294967 seconds and a
resolution in milliseconds; the smallest nonzero value is 0.001.
Heartbeats are sent by the master only if there are no unsent
events in the binary log file for a period longer than
interval
.
Setting interval
to 0 disables
heartbeats altogether. The default value for
interval
is equal to the value of
slave_net_timeout
divided by 2.
Setting @@global.slave_net_timeout
to a value
less than that of the current heartbeat interval results in a
warning being issued. The effect of issuing
RESET SLAVE
on the heartbeat
interval is to reset it to the default value.
MASTER_LOG_FILE
and
MASTER_LOG_POS
are the coordinates at which
the slave I/O thread should begin reading from the master the
next time the thread starts. RELAY_LOG_FILE
and RELAY_LOG_POS
are the coordinates at
which the slave SQL thread should begin reading from the relay
log the next time the thread starts. If you specify either of
MASTER_LOG_FILE
or
MASTER_LOG_POS
, you cannot specify
RELAY_LOG_FILE
or
RELAY_LOG_POS
. If neither of
MASTER_LOG_FILE
or
MASTER_LOG_POS
is specified, the slave uses
the last coordinates of the slave SQL
thread before CHANGE MASTER
TO
was issued. This ensures that there is no
discontinuity in replication, even if the slave SQL thread was
late compared to the slave I/O thread, when you merely want to
change, say, the password to use.
CHANGE MASTER TO
deletes all relay log files and starts a
new one, unless you specify RELAY_LOG_FILE
or
RELAY_LOG_POS
. In that case, relay log files
are kept; the relay_log_purge
global variable is set silently to 0.
Prior to MySQL 5.5, RELAY_LOG_FILE
required
an absolute path. In MySQL 5.5, the path can be
relative, and uses the same basename as
MASTER_LOG_FILE
. (Bug #12190)
IGNORE_SERVER_IDS
was added in MySQL 5.5.
This option takes a comma-separated list of 0 or more server
IDs. Events originating from the corresponding servers are
ignored, with the exception of log rotation and deletion events,
which are still recorded in the relay log.
In circular replication, the originating server normally acts as
the terminator of its own events, so that they are not applied
more than once. Thus, this option is useful in circular
replication when one of the servers in the circle is removed.
Suppose that you have a circular replication setup with 4
servers, having server IDs 1, 2, 3, and 4, and server 3 fails.
When bridging the gap by starting replication from server 2 to
server 4, you can include IGNORE_SERVER_IDS =
(3)
in the CHANGE MASTER TO
statement that you issue on server 4 to tell it to use server 2
as its master instead of server 3. Doing so causes it to ignore
and not to propagate any statements that originated with the
server that is no longer in use.
If a CHANGE MASTER TO
statement is issued
without any IGNORE_SERVER_IDS
option, any
existing list is preserved; RESET
SLAVE
also has no effect on the server ID list. To
clear the list of ignored servers, it is necessary to use the
option with an empty list:
CHANGE MASTER TO IGNORE_SERVER_IDS = ();
If IGNORE_SERVER_IDS
contains the
server's own ID and the server was started with the
--replicate-same-server-id
option
enabled, an error results.
Also beginning with MySQL 5.5, the
master.info
file and the output of
SHOW SLAVE STATUS
are extended to
provide the list of servers that are currently ignored. For more
information, see Section 15.2.2.2, “Slave Status Logs”, and
Section 12.7.5.35, “SHOW SLAVE STATUS
Синтаксис”.
Beginning with MySQL 5.5.5, invoking CHANGE
MASTER TO
causes the previous values for
MASTER_HOST
, MASTER_PORT
,
MASTER_LOG_FILE
, and
MASTER_LOG_POS
to be written to the error
log, along with other information about the slave's state
prior to execution.
CHANGE MASTER TO
is useful for
setting up a slave when you have the snapshot of the master and
have recorded the master binary log coordinates corresponding to
the time of the snapshot. After loading the snapshot into the
slave to synchronize it to the slave, you can run
CHANGE MASTER TO
MASTER_LOG_FILE='
on
the slave to specify the coordinates at which the slave should
begin reading the master binary log.
log_name
',
MASTER_LOG_POS=log_pos
The following example changes the master server the slave uses and establishes the master binary log coordinates from which the slave begins reading. This is used when you want to set up the slave to replicate the master:
CHANGE MASTER TO MASTER_HOST='master2.mycompany.com', MASTER_USER='replication', MASTER_PASSWORD='bigs3cret', MASTER_PORT=3306, MASTER_LOG_FILE='master2-bin.001', MASTER_LOG_POS=4, MASTER_CONNECT_RETRY=10;
The next example shows an operation that is less frequently
employed. It is used when the slave has relay log files that you
want it to execute again for some reason. To do this, the master
need not be reachable. You need only use
CHANGE MASTER TO
and start the
SQL thread (START SLAVE SQL_THREAD
):
CHANGE MASTER TO RELAY_LOG_FILE='slave-relay-bin.006', RELAY_LOG_POS=4025;
You can even use the second operation in a nonreplication setup
with a standalone, nonslave server for recovery following a
crash. Suppose that your server has crashed and you have
restored it from a backup. You want to replay the server's own
binary log files (not relay log files, but regular binary log
files), named (for example) myhost-bin.*
.
First, make a backup copy of these binary log files in some safe
place, in case you don't exactly follow the procedure below and
accidentally have the server purge the binary log. Use
SET GLOBAL relay_log_purge=0
for additional
safety. Then start the server without the
--log-bin
option, Instead, use
the --replicate-same-server-id
,
--relay-log=myhost-bin
(to make
the server believe that these regular binary log files are relay
log files) and --skip-slave-start
options. After the server starts, issue these statements:
CHANGE MASTER TO RELAY_LOG_FILE='myhost-bin.153', RELAY_LOG_POS=410, MASTER_HOST='some_dummy_string'; START SLAVE SQL_THREAD;
The server reads and executes its own binary log files, thus
achieving crash recovery. Once the recovery is finished, run
STOP SLAVE
, shut down the server,
delete the master.info
and
relay-log.info
files, and restart the
server with its original options.
Specifying the MASTER_HOST
option (even with
a dummy value) is required to make the server think it is a
slave.
The following table shows the maximum permissible length for the string-valued options.
Option | Maximum Length |
---|---|
MASTER_HOST | 60 |
MASTER_USER | 16 |
MASTER_PASSWORD | 32 |
MASTER_LOG_FILE | 255 |
RELAY_LOG_FILE | 255 |
MASTER_SSL_CA | 255 |
MASTER_SSL_CAPATH | 255 |
MASTER_SSL_CERT | 255 |
MASTER_SSL_KEY | 255 |
MASTER_SSL_CIPHER | 511 |
SELECT MASTER_POS_WAIT('master_log_file
',master_log_pos
[,timeout
])
This is actually a function, not a statement. It is used to ensure that the slave has read and executed events up to a given position in the master's binary log. See Section 11.15, “Miscellaneous Functions”, for a full description.
RESET SLAVE [ALL]
RESET SLAVE
makes the slave
forget its replication position in the master's binary log. This
statement is meant to be used for a clean start: It deletes the
master.info
and
relay-log.info
files, all the relay log
files, and starts a new relay log file. To use
RESET SLAVE
, the slave
replication threads must be stopped (use
STOP SLAVE
if necessary).
All relay log files are deleted, even if they have not been
completely executed by the slave SQL thread. (This is a
condition likely to exist on a replication slave if you have
issued a STOP SLAVE
statement
or if the slave is highly loaded.)
In MySQL 5.5 (unlike the case in MySQL 5.1 and
earlier), RESET SLAVE
does not
change any replication connection parameters such as master
host, master port, master user, or master password, which are
retained in memory. This means that START
SLAVE
can be issued without requiring a
CHANGE MASTER TO
statement
following RESET SLAVE
.
In MySQL 5.5.16 and later, you can use RESET SLAVE
ALL
to reset these connection parameters (Bug
#11809016). Connection parameters are also reset if the slave
mysqld is shut down.
If the slave SQL thread was in the middle of replicating
temporary tables when it was stopped, and
RESET SLAVE
is issued, these
replicated temporary tables are deleted on the slave.
SET GLOBAL sql_slave_skip_counter = N
This statement skips the next N
events from the master. This is useful for recovering from
replication stops caused by a statement.
This statement is valid only when the slave threads are not running. Otherwise, it produces an error.
When using this statement, it is important to understand that the binary log is actually organized as a sequence of groups known as event groups. Each event group consists of a sequence of events.
For transactional tables, an event group corresponds to a transaction.
For nontransactional tables, an event group corresponds to a single SQL statement.
A single transaction can contain changes to both transactional and nontransactional tables.
When you use SET GLOBAL
sql_slave_skip_counter
to skip events and the result
is in the middle of a group, the slave continues to skip events
until it reaches the end of the group. Execution then starts
with the next event group.
Beginning with MySQL 5.5.5, issuing this statement causes the
previous values of RELAY_LOG_FILE
,
RELAY_LOG_POS
, and
sql_slave_skip_counter
to be
written to the error log.
START SLAVE [thread_type
[,thread_type
] ... ] START SLAVE [SQL_THREAD] UNTIL MASTER_LOG_FILE = 'log_name
', MASTER_LOG_POS =log_pos
START SLAVE [SQL_THREAD] UNTIL RELAY_LOG_FILE = 'log_name
', RELAY_LOG_POS =log_pos
thread_type
: IO_THREAD | SQL_THREAD
START SLAVE
with no
thread_type
options starts both of
the slave threads. The I/O thread reads events from the master
server and stores them in the relay log. The SQL thread reads
events from the relay log and executes them.
START SLAVE
requires the
SUPER
privilege.
If START SLAVE
succeeds in
starting the slave threads, it returns without any error.
However, even in that case, it might be that the slave threads
start and then later stop (for example, because they do not
manage to connect to the master or read its binary log, or some
other problem). START SLAVE
does
not warn you about this. You must check the slave's error log
for error messages generated by the slave threads, or check that
they are running satisfactorily with SHOW
SLAVE STATUS
.
START SLAVE
sends an
acknowledgment to the user after both the I/O thread and the SQL
thread have started. However, the I/O thread may not yet have
connected. For this reason, a successful
START SLAVE
causes
SHOW SLAVE STATUS
to show
Slave_SQL_Running=Yes
, but this does not
guarantee that Slave_IO_Running=Yes
(because
Slave_IO_Running=Yes
only if the I/O thread
is running and connected). For more
information, see Section 12.7.5.35, “SHOW SLAVE STATUS
Синтаксис”, and
Section 15.1.4.1, “Checking Replication Status”.
You can add IO_THREAD
and
SQL_THREAD
options to the statement to name
which of the threads to start.
An UNTIL
clause may be added to specify that
the slave should start and run until the SQL thread reaches a
given point in the master binary log or in the slave relay log.
When the SQL thread reaches that point, it stops. If the
SQL_THREAD
option is specified in the
statement, it starts only the SQL thread. Otherwise, it starts
both slave threads. If the SQL thread is running, the
UNTIL
clause is ignored and a warning is
issued.
For an UNTIL
clause, you must specify both a
log file name and position. Do not mix master and relay log
options.
Any UNTIL
condition is reset by a subsequent
STOP SLAVE
statement, a
START SLAVE
statement that
includes no UNTIL
clause, or a server
restart.
The UNTIL
clause can be useful for debugging
replication, or to cause replication to proceed until just
before the point where you want to avoid having the slave
replicate an event. For example, if an unwise
DROP TABLE
statement was executed
on the master, you can use UNTIL
to tell the
slave to execute up to that point but no farther. To find what
the event is, use mysqlbinlog with the master
binary log or slave relay log, or by using a
SHOW BINLOG EVENTS
statement.
If you are using UNTIL
to have the slave
process replicated queries in sections, it is recommended that
you start the slave with the
--skip-slave-start
option to
prevent the SQL thread from running when the slave server
starts. It is probably best to use this option in an option file
rather than on the command line, so that an unexpected server
restart does not cause it to be forgotten.
The SHOW SLAVE STATUS
statement
includes output fields that display the current values of the
UNTIL
condition.
In old versions of MySQL (before 4.0.5), this statement was
called SLAVE START
. This usage is still
accepted in MySQL 5.5 for backward compatibility,
but is deprecated and is removed in MySQL 5.6.
STOP SLAVE [thread_type
[,thread_type
] ... ]thread_type
: IO_THREAD | SQL_THREAD
Stops the slave threads. STOP
SLAVE
requires the
SUPER
privilege.
Like START SLAVE
, this statement
may be used with the IO_THREAD
and
SQL_THREAD
options to name the thread or
threads to be stopped.
In MySQL 5.5, STOP SLAVE
waits
until the current replication event group affecting one or
more non-transactional tables has finished executing (if there
is any such replication group), or until the user issues a
KILL QUERY
or
KILL
CONNECTION
statement. (Bug #319, Bug #38205)
In old versions of MySQL (before 4.0.5), this statement was
called SLAVE STOP
. This usage is still
accepted in MySQL 5.5 for backward compatibility,
but is deprecated and is removed in MySQL 5.6.
MySQL 5.5 provides support for server-side prepared
statements. This support takes advantage of the efficient
client/server binary protocol implemented in MySQL 4.1, provided
that you use an appropriate client programming interface. Candidate
interfaces include the MySQL C API client library (for C programs),
MySQL Connector/J (for Java programs), and MySQL Connector/Net. For
example, the C API provides a set of function calls that make up its
prepared statement API. See
Section 21.9.4, “C API Prepared Statements”. Other language
interfaces can provide support for prepared statements that use the
binary protocol by linking in the C client library, one example
being the
mysqli
extension, available in PHP 5.0 and later.
An alternative SQL interface to prepared statements is available. This interface is not as efficient as using the binary protocol through a prepared statement API, but requires no programming because it is available directly at the SQL level:
You can use it when no programming interface is available to you.
You can use it from any program that enables you to send SQL statements to the server to be executed, such as the mysql client program.
You can use it even if the client is using an old version of the client library. The only requirement is that you be able to connect to a server that is recent enough to support SQL syntax for prepared statements.
SQL syntax for prepared statements is intended to be used for situations such as these:
You want to test how prep