The MySQL server can operate in different SQL modes, and can apply these modes differently for different clients. This capability enables each application to tailor the server's operating mode to its own requirements.
For answers to some questions that are often asked about server SQL modes in MySQL, see Section B.3, "MySQL 5.7 FAQ: Server SQL Mode".
Modes define what SQL syntax MySQL should support and what kind of data validation checks it should perform. This makes it easier to use MySQL in different environments and to use MySQL together with other database servers.
You can set the default SQL mode by starting mysqld with the
--sql-mode=" option, or by using
operating systems) or
is a list of different modes separated by comma ("
characters. The default SQL mode in MySQL 5.7 is
NO_ENGINE_SUBSTITUTION. To clear
the mode explicitly, set it to an empty string using
--sql-mode="" on the command line, or with
my.cnf on Unix systems or in
my.ini on Windows.
You can change the SQL mode at runtime by using a
SET [GLOBAL|SESSION] sql_mode=' statement to set the
sql_mode system value. Setting the
and affects the operation of all clients that connect from that time on. Setting the
variable affects only the current client. Any client can change its own session
sql_mode value at any time.
SQL mode and user-defined partitioning. Changing the server SQL mode after creating and inserting data into partitioned tables can cause major changes in the behavior of such tables, and could lead to loss or corruption of data. It is strongly recommended that you never change the SQL mode once you have created tables employing user-defined partitioning.
When replicating partitioned tables, differing SQL modes on master and slave can also lead to problems. For best results, you should always use the same server SQL mode on the master and on the slave.
See Section 17.6, "Restrictions and Limitations on Partitioning", for more information.
You can retrieve the current global or session
sql_mode value with the following statements:
SELECT @@GLOBAL.sql_mode;SELECT @@SESSION.sql_mode;
The most important
values are probably these:
This mode changes syntax and behavior to conform more closely to standard SQL. It is one of the special combination modes listed at the end of this section.
If a value could not be inserted as given into a transactional table, abort the statement. For a nontransactional table, abort the statement if the value occurs in a single-row statement or the first row of a multiple-row statement. More detail is given later in this section.
Make MySQL behave like a "traditional" SQL database system. A simple description of this mode is "give an error instead of a warning" when inserting an incorrect value into a column. It is one of the special combination modes listed at the end of this section.
The following list describes all supported modes:
Do not perform full checking of dates. Check only that the month is in the range from 1 to 12 and
the day is in the range from 1 to 31. This is very convenient for Web applications where you obtain
year, month, and day in three different fields and you want to store exactly what the user inserted
(without date validation). This mode applies to
DATETIME columns. It does not apply
TIMESTAMP columns, which always require a valid date.
The server requires that month and day values be legal, and not merely in the range 1 to 12 and 1 to
31, respectively. With strict mode disabled, invalid dates such as
are converted to
'0000-00-00' and a warning is generated. With strict
mode enabled, invalid dates generate an error. To permit such dates, enable
"" as an
identifier quote character (like the "
quote character) and not as a string quote character. You can still use "
`" to quote identifiers with this
mode enabled. With
ANSI_QUOTES enabled, you cannot use double quotation marks to
quote literal strings, because it is interpreted as an identifier.
Produce an error in strict mode (otherwise a warning) when a division by zero (or
MOD(X,0)) occurs during an
If this mode is not enabled, MySQL instead returns
NULL for divisions
by zero. For
INSERT IGNORE or
MySQL generates a warning for divisions by zero, but the result of the operation is
The precedence of the
NOT operator is such that expressions such as
a BETWEEN b AND c are parsed as
NOT (a BETWEEN b AND c). In some
older versions of MySQL, the expression was parsed as
(NOT a) BETWEEN b AND
c. The old higher-precedence behavior can be obtained by enabling the
HIGH_NOT_PRECEDENCE SQL mode.
SET sql_mode = '';mysql>
SELECT NOT 1 BETWEEN -5 AND 5;-> 0mysql>
SET sql_mode = 'HIGH_NOT_PRECEDENCE';mysql>
SELECT NOT 1 BETWEEN -5 AND 5;-> 1
Permit spaces between a function name and the "
(" character. This causes built-in function names to be
treated as reserved words. As a result, identifiers that are the same as function names must be
quoted as described in Section 9.2, "Schema Object Names".
For example, because there is a
COUNT() function, the use of
as a table name in the following statement causes an error:
CREATE TABLE count (i INT);ERROR 1064 (42000): You have an error in your SQL syntax
The table name should be quoted:
CREATE TABLE `count` (i INT);Query OK, 0 rows affected (0.00 sec)
SQL mode applies to built-in functions, not to user-defined functions or stored functions. It is
always permissible to have spaces after a UDF or stored function name, regardless of whether
For further discussion of
IGNORE_SPACE, see Section
9.2.4, "Function Name Parsing and Resolution".
GRANT statement from automatically creating new users if it would
otherwise do so, unless authentication information is specified. The statement must specify a
nonempty password using
IDENTIFIED BY or an authentication plugin using
NO_AUTO_VALUE_ON_ZERO affects handling of
columns. Normally, you generate the next sequence number for the column by inserting either
0 into it.
NO_AUTO_VALUE_ON_ZERO suppresses this behavior for
0 so that only
NULL generates the next
This mode can be useful if
0 has been stored in a table's
AUTO_INCREMENT column. (Storing
0 is not a
recommended practice, by the way.) For example, if you dump the table with mysqldump and then reload it, MySQL normally
generates new sequence numbers when it encounters the
resulting in a table with contents different from the one that was dumped. Enabling
NO_AUTO_VALUE_ON_ZERO before reloading the dump file solves this
now automatically includes in its output a statement that enables
NO_AUTO_VALUE_ON_ZERO, to avoid this problem.
Disable the use of the backslash character ("
\") as an escape character within strings. With this mode
enabled, backslash becomes an ordinary character like any other.
When creating a table, ignore all
INDEX DIRECTORY and
DATA DIRECTORY directives. This option is useful on slave replication
Because storage engines can be pluggable at runtime, unavailable engines are treated the same way:
NO_ENGINE_SUBSTITUTION disabled, for
CREATE TABLE the default engine is used and a warning occurs if the
desired engine is unavailable. For
TABLE, a warning occurs and the table is not altered.
NO_ENGINE_SUBSTITUTION enabled, an error occurs and the table is not
created or altered if the desired engine is unavailable.
By default, subtraction between integer operands produces an
result if any operand is
NO_UNSIGNED_SUBTRACTION is enabled, the subtraction result is
signed, even if any operand is unsigned. For example, compare
the type of column
c2 in table
that of column
c2 in table
CREATE TABLE test (c1 BIGINT UNSIGNED NOT NULL);mysql>
CREATE TABLE t1 SELECT c1 - 1 AS c2 FROM test;mysql>
DESCRIBE t1;+-------+---------------------+------+-----+---------+-------+| Field | Type | Null | Key | Default | Extra |+-------+---------------------+------+-----+---------+-------+| c2 | bigint(21) unsigned | | | 0 | |+-------+---------------------+------+-----+---------+-------+mysql>
CREATE TABLE t2 SELECT c1 - 1 AS c2 FROM test;mysql>
DESCRIBE t2;+-------+------------+------+-----+---------+-------+| Field | Type | Null | Key | Default | Extra |+-------+------------+------+-----+---------+-------+| c2 | bigint(21) | | | 0 | |+-------+------------+------+-----+---------+-------+
Note that this means that
BIGINT UNSIGNED is not 100% usable in all
contexts. See Section 12.10, "Cast Functions and
SET sql_mode = '';mysql>
SELECT CAST(0 AS UNSIGNED) - 1;+-------------------------+| CAST(0 AS UNSIGNED) - 1 |+-------------------------+| 18446744073709551615 |+-------------------------+mysql>
SET sql_mode = 'NO_UNSIGNED_SUBTRACTION';mysql>
SELECT CAST(0 AS UNSIGNED) - 1;+-------------------------+| CAST(0 AS UNSIGNED) - 1 |+-------------------------+| -1 |+-------------------------+
In strict mode, do not permit
'0000-00-00' as a valid date. You can
still insert zero dates with the
IGNORE option. When not in strict
mode, the date is accepted but a warning is generated.
In strict mode, do not accept dates where the year part is nonzero but the month or day part is 0
'0000-00-00' is legal but
'2010-01-00' are not). If used with the
option, MySQL inserts a
'0000-00-00' date for any such date. When not
in strict mode, the date is accepted but a warning is generated.
Do not permit queries for which the select list or
HAVING list or
ORDER BY list refers to nonaggregated columns that are not named in the
GROUP BY clause.
The following queries are invalid with
ONLY_FULL_GROUP_BY enabled. The first is invalid because
address in the select list is not named in the
BY clause, and the second because
max_age in the
HAVING clause is not named in the
SELECT name, address, MAX(age) FROM t GROUP BY name;ERROR 1055 (42000): 't.address' isn't in GROUP BY
SELECT name, MAX(age) AS max_age FROM t GROUP BY name->
HAVING max_age < 30;Empty set (0.00 sec)ERROR 1463 (42000): Non-grouping field 'max_age' is used in HAVING clause
In the second example, the query could be rewritten to use
MAX(age) instead, so that the reference is to a column named in an aggregate function. (
max_age fails because it is an
In addition, if a query has aggregate functions and no
GROUP BY clause,
it cannot have nonaggregated columns in the select list or
SELECT name, MAX(age) FROM t;ERROR 1140 (42000): Mixing of GROUP columns (MIN(),MAX(),COUNT(),...)with no GROUP columns is illegal if there is no GROUP BY clause
For more information, see Section 12.17.3, "MySQL
By default, trailing spaces are trimmed from
CHAR column values on retrieval. If
PAD_CHAR_TO_FULL_LENGTH is enabled, trimming does not occur and
are padded to their full length. This mode does not apply to
VARCHAR columns, for which trailing spaces are retained on
CREATE TABLE t1 (c1 CHAR(10));Query OK, 0 rows affected (0.37 sec)mysql>
INSERT INTO t1 (c1) VALUES('xy');Query OK, 1 row affected (0.01 sec)mysql>
SET sql_mode = '';Query OK, 0 rows affected (0.00 sec)mysql>
SELECT c1, CHAR_LENGTH(c1) FROM t1;+------+-----------------+| c1 | CHAR_LENGTH(c1) |+------+-----------------+| xy | 2 |+------+-----------------+1 row in set (0.00 sec)mysql>
SET sql_mode = 'PAD_CHAR_TO_FULL_LENGTH';Query OK, 0 rows affected (0.00 sec)mysql>
SELECT c1, CHAR_LENGTH(c1) FROM t1;+------------+-----------------+| c1 | CHAR_LENGTH(c1) |+------------+-----------------+| xy | 10 |+------------+-----------------+1 row in set (0.00 sec)
Enable strict mode for all storage engines. Invalid data values are rejected. Additional detail follows.
Enable strict mode for transactional storage engines, and when possible for nontransactional storage engines. Additional details follow.
Strict mode controls how MySQL handles input values that are invalid or missing. A value can be invalid for
several reasons. For example, it might have the wrong data type for the column, or it might be out of range. A
value is missing when a new row to be inserted does not contain a value for a non-
NULL column that has no explicit
DEFAULT clause in
its definition. (For a
NULL is inserted
if the value is missing.)
For transactional tables, an error occurs for invalid or missing values in a statement when either of the
modes are enabled. The statement is aborted and rolled back.
For nontransactional tables, the behavior is the same for either mode, if the bad value occurs in the first row to be inserted or updated. The statement is aborted and the table remains unchanged. If the statement inserts or modifies multiple rows and the bad value occurs in the second or later row, the result depends on which strict option is enabled:
STRICT_ALL_TABLES, MySQL returns an error and ignores the rest of the
rows. However, in this case, the earlier rows still have been inserted or updated. This means that you
might get a partial update, which might not be what you want. To avoid this, it is best to use
single-row statements because these can be aborted without changing the table.
STRICT_TRANS_TABLES, MySQL converts an invalid value to the closest valid
value for the column and insert the adjusted value. If a value is missing, MySQL inserts the implicit
default value for the column data type. In either case, MySQL generates a warning rather than an error
and continues processing the statement. Implicit defaults are described in Section
11.5, "Data Type Default Values".
Strict mode disallows invalid date values such as
'2004-04-31'. It does not
disallow dates with zero month or day parts such as
'2004-04-00' or "zero" dates. To disallow these as well, enable the
NO_ZERO_DATE SQL modes in addition to strict mode.
If you are not using strict mode (that is, neither
STRICT_ALL_TABLES is enabled), MySQL inserts adjusted values for invalid or
missing values and produces warnings. In strict mode, you can produce this behavior by using
INSERT IGNORE or
UPDATE IGNORE. See Section
SHOW WARNINGS Syntax".
The following special modes are provided as shorthand for combinations of mode values from the preceding list.
The descriptions include all mode values that are available in the most recent version of MySQL. For older versions, a combination mode does not include individual mode values that are not available except in newer versions.
mode also causes the server to return an error for queries where a set function
S with an outer reference
cannot be aggregated in the outer query against which the outer reference has been resolved. This is
such a query:
SELECT * FROM t1 WHERE t1.a IN (SELECT MAX(t1.b) FROM t2 WHERE ...);
cannot aggregated in the outer query because it appears in the
clause of that query. Standard SQL requires an error in this situation. If
ANSI mode is not enabled, the server treats
in such queries the same way that it would interpret