MySQL安裝程序可能會(huì)在安裝過程中配置SQL模式。如果 SQL 模式與默認(rèn)值或您期望的不同，請(qǐng)檢查服務(wù)器在啟動(dòng)時(shí)讀取的選項(xiàng)文件中的設(shè)置。

SET GLOBAL sql_mode = 'modes';
SET SESSION sql_mode = 'modes';

SELECT @@GLOBAL.sql_mode;
SELECT @@SESSION.sql_mode;

SQL模式和用戶定義的分區(qū)。??創(chuàng)建數(shù)據(jù)并將其插入分區(qū)表后更改服務(wù)器 SQL 模式可能會(huì)導(dǎo)致此類表的行為發(fā)生重大變化，并可能導(dǎo)致數(shù)據(jù)丟失或損壞。強(qiáng)烈建議您在創(chuàng)建使用用戶定義分區(qū)的表后不要更改 SQL 模式。

復(fù)制分區(qū)表時(shí)，源和副本上不同的 SQL 模式也可能導(dǎo)致問題。為了獲得最佳結(jié)果，您應(yīng)該始終在源和副本上使用相同的服務(wù)器 SQL 模式。

有關(guān)更多信息，請(qǐng)參閱?第 22.6 節(jié)“分區(qū)的約束和限制”。

• ANSI

  此模式更改語法和行為以更符合標(biāo)準(zhǔn) SQL。?它是本節(jié)末尾列出的 特殊組合模式之一 。

• STRICT_TRANS_TABLES

  如果無法按照給定值將值插入到事務(wù)表中，則中止該語句。對(duì)于非事務(wù)性表，如果該值出現(xiàn)在單行語句或多行語句的第一行中，則中止該語句。本節(jié)稍后將提供更多詳細(xì)信息。

  從 MySQL 5.7.5 開始，默認(rèn)的 SQL 模式包括?STRICT_TRANS_TABLES.

• TRADITIONAL

  使 MySQL 表現(xiàn)得像一個(gè)“傳統(tǒng)”?SQL 數(shù)據(jù)庫系統(tǒng)。這種模式的簡單描述是?當(dāng)向列中插入不正確的值時(shí)“給出錯(cuò)誤而不是警告” 。它是本節(jié)末尾列出的 特殊組合模式之一。

  筆記

  TRADITIONAL啟用模式?后，一旦發(fā)生錯(cuò)誤，INSERT或 就會(huì) 中止。UPDATE如果您使用的是非事務(wù)性存儲(chǔ)引擎，這可能不是您想要的，因?yàn)殄e(cuò)誤之前所做的數(shù)據(jù)更改可能不會(huì)回滾，從而導(dǎo)致“部分完成”更新。

• ALLOW_INVALID_DATES

  不要對(duì)日期進(jìn)行全面檢查。僅檢查月份是否在 1 到 12 的范圍內(nèi)以及日期是否在 1 到 31 的范圍內(nèi)。這對(duì)于在三個(gè)不同字段中獲取年、月和日并準(zhǔn)確存儲(chǔ)用戶信息的 Web 應(yīng)用程序可能很有用插入，沒有日期驗(yàn)證。該模式適用于?DATE和?DATETIME列。它不適用于TIMESTAMP始終需要有效日期的列。

  禁用后ALLOW_INVALID_DATES?，服務(wù)器要求月份和日期值合法，而不僅僅是分別在 1 到 12 和 1 到 31 的范圍內(nèi)。禁用嚴(yán)格模式后，無效日期（例如）'2004-04-31'將被轉(zhuǎn)換為?'0000-00-00'并生成警告。啟用嚴(yán)格模式后，無效日期會(huì)生成錯(cuò)誤。要允許此類日期，請(qǐng)啟用?ALLOW_INVALID_DATES.

• ANSI_QUOTES

  將其"視為標(biāo)識(shí)符引號(hào)字符（如`引號(hào)字符），而不是字符串引號(hào)字符。啟用此模式后，您仍然可以使用?`引用標(biāo)識(shí)符。啟用后ANSI_QUOTES?，您不能使用雙引號(hào)來引用文字字符串，因?yàn)樗鼈儽唤忉尀闃?biāo)識(shí)符。

• ERROR_FOR_DIVISION_BY_ZERO

  該?ERROR_FOR_DIVISION_BY_ZERO?模式影響除以零的處理，其中包括?.?對(duì)于數(shù)據(jù)更改操作（、?），其效果還取決于是否啟用嚴(yán)格 SQL 模式。?MOD(N,0)INSERTUPDATE

  • 如果未啟用此模式，則除以零會(huì)插入?NULL并且不會(huì)產(chǎn)生警告。

  • 如果啟用此模式，則除以零會(huì)插入?NULL并產(chǎn)生警告。

  • 如果啟用此模式和嚴(yán)格模式，除以零會(huì)產(chǎn)生錯(cuò)誤，除非IGNORE?同時(shí)給出。對(duì)于INSERT IGNORE?和UPDATE IGNORE，除以零會(huì)插入NULL并產(chǎn)生警告。

  對(duì)于SELECT，除以零返回NULL。ERROR_FOR_DIVISION_BY_ZERO?無論是否啟用嚴(yán)格模式，?啟用 都會(huì)導(dǎo)致生成警告。

  ERROR_FOR_DIVISION_BY_ZERO?已棄用。?ERROR_FOR_DIVISION_BY_ZERO?不是嚴(yán)格模式的一部分，但應(yīng)與嚴(yán)格模式結(jié)合使用，并且默認(rèn)啟用。如果啟用但未同時(shí)啟用嚴(yán)格模式，則會(huì)出現(xiàn)警告?ERROR_FOR_DIVISION_BY_ZERO?，反之亦然。有關(guān)更多討論，請(qǐng)參閱?MySQL 5.7 中的 SQL 模式更改。

  因?yàn)?ERROR_FOR_DIVISION_BY_ZERO?已被棄用；預(yù)計(jì)它會(huì)在 MySQL 的未來版本中作為單獨(dú)的模式名稱被刪除，并且其效果包含在嚴(yán)格 SQL 模式的效果中。

• HIGH_NOT_PRECEDENCE

  運(yùn)算符的優(yōu)先級(jí)NOT?使得諸如 之類的表達(dá)式NOT a BETWEEN b AND c被解析為NOT (a BETWEEN b AND c)。在某些舊版本的 MySQL 中，表達(dá)式被解析為(NOT a) BETWEEN b AND c.?舊的更高優(yōu)先級(jí)行為可以通過啟用 SQL 模式來獲得?HIGH_NOT_PRECEDENCE。

  mysql> SET sql_mode = '';
  mysql> SELECT NOT 1 BETWEEN -5 AND 5;
          -> 0
  mysql> SET sql_mode = 'HIGH_NOT_PRECEDENCE';
  mysql> SELECT NOT 1 BETWEEN -5 AND 5;
          -> 1

• IGNORE_SPACE

  函數(shù)名稱和?(字符之間允許有空格。這會(huì)導(dǎo)致內(nèi)置函數(shù)名稱被視為保留字。因此，與函數(shù)名稱相同的標(biāo)識(shí)符必須按照第9.2 節(jié)“模式對(duì)象名稱”中所述加引號(hào)。例如，因?yàn)橛幸粋€(gè)?COUNT()函數(shù)，所以在以下語句中使用?count作為表名會(huì)導(dǎo)致錯(cuò)誤：

  mysql> CREATE TABLE count (i INT);
  ERROR 1064 (42000): You have an error in your SQL syntax

  表名應(yīng)該加引號(hào)：

  mysql> CREATE TABLE `count` (i INT);
  Query OK, 0 rows affected (0.00 sec)

  SQLIGNORE_SPACE模式適用于內(nèi)置函數(shù)，不適用于可加載函數(shù)或存儲(chǔ)函數(shù)。IGNORE_SPACE無論是否啟用?，始終允許在可加載函數(shù)或存儲(chǔ)函數(shù)名稱后有空格 。

  有關(guān) 的進(jìn)一步討論?IGNORE_SPACE，請(qǐng)參見?第 9.2.5 節(jié)“函數(shù)名稱解析和解析”。

• NO_AUTO_CREATE_USER

  除非指定了身份驗(yàn)證信息，否則阻止該GRANT語句自動(dòng)創(chuàng)建新用戶帳戶（否則會(huì)這樣做）。該語句必須使用 指定非空密碼IDENTIFIED BY或使用 的身份驗(yàn)證插件IDENTIFIED WITH。

  最好使用?CREATE USER而不是 創(chuàng)建 MySQL 帳戶GRANT。?NO_AUTO_CREATE_USER已棄用，默認(rèn) SQL 模式包括?NO_AUTO_CREATE_USER.?sql_mode?更改 模式狀態(tài)的賦值NO_AUTO_CREATE_USER會(huì)產(chǎn)生警告，設(shè)置為 的賦值?sql_mode除外?DEFAULT。預(yù)計(jì)?NO_AUTO_CREATE_USER將在 MySQL 的未來版本中刪除，并且其效果將始終啟用（并且?GRANT不再創(chuàng)建帳戶）。

  以前，before?NO_AUTO_CREATE_USER已被棄用，不啟用它的原因之一是它不是復(fù)制安全的。CREATE USER IF NOT EXISTS現(xiàn)在可以使用、DROP USER IF EXISTS和ALTER USER IF EXISTS而不是 來?啟用它并執(zhí)行復(fù)制安全的用戶管理GRANT。當(dāng)副本可能具有與源上的授權(quán)不同的授權(quán)時(shí)，這些語句可以實(shí)現(xiàn)安全復(fù)制。請(qǐng)參見第 13.7.1.2 節(jié)“CREATE USER 語句”、?第 13.7.1.3 節(jié)“DROP USER 語句”和?第 13.7.1.1 節(jié)“ALTER USER 語句”。

• NO_AUTO_VALUE_ON_ZERO

  NO_AUTO_VALUE_ON_ZERO?影響AUTO_INCREMENT?列的處理。通常，您可以通過在其中 插入NULL或 來?生成該列的下一個(gè)序列號(hào)。?抑制此行為，以便僅生成下一個(gè)序列號(hào)。?0NO_AUTO_VALUE_ON_ZERO0NULL

  0如果已存儲(chǔ)在表的列中?，則此模式會(huì)很有用AUTO_INCREMENT?。（順便說一句，存儲(chǔ)0不是推薦的做法。）例如，如果使用mysqldump轉(zhuǎn)儲(chǔ)表，然后重新加載它，MySQL 通常會(huì)在遇到這些0值時(shí)生成新的序列號(hào)，從而導(dǎo)致表的內(nèi)容與之前的表不同那被拋棄了。NO_AUTO_VALUE_ON_ZERO?在重新加載轉(zhuǎn)儲(chǔ)文件之前啟用 可以解決此問題。因此，mysqldump自動(dòng)在其輸出中包含一條啟用?NO_AUTO_VALUE_ON_ZERO.

• NO_BACKSLASH_ESCAPES

  啟用此模式將禁用反斜杠字符 (?\) 作為字符串和標(biāo)識(shí)符中的轉(zhuǎn)義字符。啟用此模式后，反斜杠將成為像其他字符一樣的普通字符，并且?LIKE表達(dá)式的默認(rèn)轉(zhuǎn)義序列將更改，以便不使用轉(zhuǎn)義字符。

• NO_DIR_IN_CREATE

  創(chuàng)建表時(shí)，忽略 allINDEX DIRECTORY和DATA DIRECTORY?指令。此選項(xiàng)在副本復(fù)制服務(wù)器上很有用。

• NO_ENGINE_SUBSTITUTION

  當(dāng)諸如CREATE TABLE或 之類的語句ALTER TABLE指定禁用或未編譯的存儲(chǔ)引擎時(shí)，控制默認(rèn)存儲(chǔ)引擎的自動(dòng)替換。

  默認(rèn)情況下，?NO_ENGINE_SUBSTITUTION已啟用。

  由于存儲(chǔ)引擎可以在運(yùn)行時(shí)插入，因此不可用的引擎將以相同的方式處理：

  禁用后?NO_ENGINE_SUBSTITUTION?，將CREATE TABLE?使用默認(rèn)引擎，如果所需的引擎不可用，則會(huì)出現(xiàn)警告。對(duì)于?ALTER TABLE，會(huì)出現(xiàn)警告并且表不會(huì)更改。

  啟用后?NO_ENGINE_SUBSTITUTION?，如果所需的引擎不可用，則會(huì)發(fā)生錯(cuò)誤，并且不會(huì)創(chuàng)建或更改表。

• NO_FIELD_OPTIONS

  不要在 的輸出中打印 MySQL 特定的列選項(xiàng)?SHOW CREATE TABLE。該模式由mysqldump在可移植模式下使用。

  筆記

  從 MySQL 5.7.22 開始，?NO_FIELD_OPTIONS已棄用。它在 MySQL 8.0 中被刪除。

• NO_KEY_OPTIONS

  不要在 的輸出中打印 MySQL 特定的索引選項(xiàng)?SHOW CREATE TABLE。該模式由mysqldump在可移植模式下使用。

  筆記

  從 MySQL 5.7.22 開始，?NO_KEY_OPTIONS已棄用。它在 MySQL 8.0 中被刪除。

• NO_TABLE_OPTIONS

  ENGINE不要在 的輸出中?打印 MySQL 特定的表選項(xiàng)（例如 ）?SHOW CREATE TABLE。該模式由mysqldump在可移植模式下使用。

  筆記

  從 MySQL 5.7.22 開始，?NO_TABLE_OPTIONS已棄用。它在 MySQL 8.0 中被刪除。

• NO_UNSIGNED_SUBTRACTION

  默認(rèn)情況下，整數(shù)值之間的減法（其中 1 的類型為?UNSIGNED）會(huì)產(chǎn)生無符號(hào)結(jié)果。如果結(jié)果為負(fù)，則會(huì)出現(xiàn)錯(cuò)誤：

  mysql> SET sql_mode = '';
  Query OK, 0 rows affected (0.00 sec)
  
  mysql> SELECT CAST(0 AS UNSIGNED) - 1;
  ERROR 1690 (22003): BIGINT UNSIGNED value is out of range in '(cast(0 as unsigned) - 1)'

  如果?NO_UNSIGNED_SUBTRACTION?啟用 SQL 模式，則結(jié)果為負(fù)：

  mysql> SET sql_mode = 'NO_UNSIGNED_SUBTRACTION';
  mysql> SELECT CAST(0 AS UNSIGNED) - 1;
  +-------------------------+
  | CAST(0 AS UNSIGNED) - 1 |
  +-------------------------+
  |                      -1 |
  +-------------------------+

  如果此類操作的結(jié)果用于更新?UNSIGNED整數(shù)列，則結(jié)果將被截?cái)酁樵摿蓄愋偷淖畲笾?，或者如?NO_UNSIGNED_SUBTRACTION啟用，則被截?cái)酁?0。啟用嚴(yán)格 SQL 模式后，會(huì)發(fā)生錯(cuò)誤并且列保持不變。

  當(dāng)?NO_UNSIGNED_SUBTRACTION啟用時(shí)，減法結(jié)果是有符號(hào)的，即使任何操作數(shù)是 unsigned。c2例如，比較table 中的?列類型與table 中的t1列類型?：?c2t2

  mysql> SET sql_mode='';
  mysql> 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 | NO   |     | 0       |       |
  +-------+---------------------+------+-----+---------+-------+
  
  mysql> SET sql_mode='NO_UNSIGNED_SUBTRACTION';
  mysql> CREATE TABLE t2 SELECT c1 - 1 AS c2 FROM test;
  mysql> DESCRIBE t2;
  +-------+------------+------+-----+---------+-------+
  | Field | Type       | Null | Key | Default | Extra |
  +-------+------------+------+-----+---------+-------+
  | c2    | bigint(21) | NO   |     | 0       |       |
  +-------+------------+------+-----+---------+-------+

  這意味著它BIGINT UNSIGNED并非在所有情況下 100% 可用。請(qǐng)參見?第 12.10 節(jié)“強(qiáng)制轉(zhuǎn)換函數(shù)和運(yùn)算符”。

• NO_ZERO_DATE

  該NO_ZERO_DATE模式影響服務(wù)器是否允許?'0000-00-00'作為有效日期。其效果還取決于是否啟用嚴(yán)格SQL模式。

  • 如果未啟用此模式，?'0000-00-00'則允許并且插入不會(huì)產(chǎn)生警告。

  • 如果啟用此模式，'0000-00-00'?則允許并且插入會(huì)產(chǎn)生警告。

  • 如果啟用此模式和嚴(yán)格模式，?'0000-00-00'則不允許并且插入會(huì)產(chǎn)生錯(cuò)誤，除非?IGNORE同時(shí)給出。對(duì)于?INSERT IGNORE和UPDATE IGNORE,'0000-00-00'是允許的并且插入會(huì)產(chǎn)生警告。

  NO_ZERO_DATE已棄用。NO_ZERO_DATE?不是嚴(yán)格模式的一部分，但應(yīng)與嚴(yán)格模式結(jié)合使用，并且默認(rèn)啟用。如果啟用但未同時(shí)啟用嚴(yán)格模式，則會(huì)出現(xiàn)警告?NO_ZERO_DATE，反之亦然。有關(guān)更多討論，請(qǐng)參閱?MySQL 5.7 中的 SQL 模式更改。

  因?yàn)镹O_ZERO_DATE已被棄用；預(yù)計(jì)它會(huì)在 MySQL 的未來版本中作為單獨(dú)的模式名稱被刪除，并且其效果包含在嚴(yán)格 SQL 模式的效果中。

• NO_ZERO_IN_DATE

  該NO_ZERO_IN_DATE模式影響服務(wù)器是否允許年部分非零但月或日部分為 0 的日期。（此模式影響 或 等日期'2010-00-01'，?'2010-01-00'但不影響?'0000-00-00'。要控制服務(wù)器是否允許'0000-00-00'，請(qǐng)使用該?NO_ZERO_DATE模式。）還NO_ZERO_IN_DATE?取決于是否啟用嚴(yán)格 SQL 模式。

  • 如果未啟用此模式，則允許包含零部分的日期并且插入不會(huì)產(chǎn)生警告。

  • 如果啟用此模式，則插入零部分的日期'0000-00-00'并產(chǎn)生警告。

  • 如果啟用此模式和嚴(yán)格模式，則不允許包含零部分的日期，并且插入會(huì)產(chǎn)生錯(cuò)誤，除非IGNORE同時(shí)給出。對(duì)于INSERT IGNORE和?UPDATE IGNORE，帶有零部分的日期將被插入'0000-00-00'并產(chǎn)生警告。

  NO_ZERO_IN_DATE已棄用。?NO_ZERO_IN_DATE不是嚴(yán)格模式的一部分，但應(yīng)與嚴(yán)格模式結(jié)合使用，并且默認(rèn)啟用。如果啟用但未同時(shí)啟用嚴(yán)格模式，則會(huì)出現(xiàn)警告?NO_ZERO_IN_DATE，反之亦然。有關(guān)更多討論，請(qǐng)參閱?MySQL 5.7 中的 SQL 模式更改。

  因?yàn)镹O_ZERO_IN_DATE已被棄用；預(yù)計(jì)它會(huì)在 MySQL 的未來版本中作為單獨(dú)的模式名稱被刪除，并且其效果包含在嚴(yán)格 SQL 模式的效果中。

• ONLY_FULL_GROUP_BY

  拒絕選擇列表、?HAVING條件或ORDER BY列表引用既未在GROUP BY子句中命名也不在功能上依賴于列（由列唯一確定）的非 聚合GROUP BY列的查詢。

  從 MySQL 5.7.5 開始，默認(rèn)的 SQL 模式包括?ONLY_FULL_GROUP_BY.?（5.7.5之前，MySQL不檢測函數(shù)依賴，ONLY_FULL_GROUP_BY默認(rèn)不啟用。）

  MySQL 對(duì)標(biāo)準(zhǔn) SQL 的擴(kuò)展允許在?HAVING子句中引用選擇列表中的別名表達(dá)式。在 MySQL 5.7.5 之前，啟用會(huì)?ONLY_FULL_GROUP_BY?禁用此擴(kuò)展，因此要求?HAVING使用非別名表達(dá)式編寫該子句。從 MySQL 5.7.5 開始，此限制被取消，以便HAVING無論是否?ONLY_FULL_GROUP_BY啟用該子句都可以引用別名。

  有關(guān)其他討論和示例，請(qǐng)參閱?第 12.19.3 節(jié)，“MySQL 處理 GROUP BY”。

• PAD_CHAR_TO_FULL_LENGTH

  CHAR默認(rèn)情況下，檢索時(shí)會(huì)從列值中?刪除尾隨空格 。如果?PAD_CHAR_TO_FULL_LENGTH啟用，則不會(huì)進(jìn)行修剪，并且檢索到的?CHAR值將填充到其完整長度。此模式不適用于?VARCHAR在檢索時(shí)保留尾隨空格的列。

  mysql> 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)

• PIPES_AS_CONCAT

  將||其視為字符串連接運(yùn)算符（與 相同?CONCAT()），而不是視為 的同義詞OR。

• REAL_AS_FLOAT

  視為REAL的同義詞?FLOAT。默認(rèn)情況下，MySQL 將REAL其視為?DOUBLE.

• STRICT_ALL_TABLES

  為所有存儲(chǔ)引擎啟用嚴(yán)格的 SQL 模式。無效數(shù)據(jù)值將被拒絕。詳細(xì)信息請(qǐng)參見?嚴(yán)格SQL模式。

  從 MySQL 5.7.4 到 5.7.7， 包括、?、 和 模式STRICT_ALL_TABLES的效果?。有關(guān)更多討論，請(qǐng)參閱?MySQL 5.7 中的 SQL 模式更改。?ERROR_FOR_DIVISION_BY_ZERONO_ZERO_DATENO_ZERO_IN_DATE

• STRICT_TRANS_TABLES

  為事務(wù)性存儲(chǔ)引擎啟用嚴(yán)格的 SQL 模式，并在可能的情況下為非事務(wù)性存儲(chǔ)引擎啟用嚴(yán)格的 SQL 模式。詳細(xì)信息請(qǐng)參見嚴(yán)格SQL模式。

  從 MySQL 5.7.4 到 5.7.7， 包括、?、 和 模式STRICT_TRANS_TABLES?的效果?。有關(guān)更多討論，請(qǐng)參閱?MySQL 5.7 中的 SQL 模式更改。?ERROR_FOR_DIVISION_BY_ZERONO_ZERO_DATENO_ZERO_IN_DATE

• ANSI

  相當(dāng)于?REAL_AS_FLOAT,?PIPES_AS_CONCAT,?ANSI_QUOTES,?IGNORE_SPACE, 和 （從 MySQL 5.7.5 開始）?ONLY_FULL_GROUP_BY。

  ANSIS如果具有外部引用的 集合函數(shù)?無法在已解析外部引用的外部查詢中聚合，模式還會(huì)導(dǎo)致服務(wù)器返回查詢錯(cuò)誤 。這是這樣一個(gè)查詢：?S(outer_ref)

  SELECT * FROM t1 WHERE t1.a IN (SELECT MAX(t1.b) FROM t2 WHERE ...);

  此處，MAX(t1.b)無法在外部查詢中聚合，因?yàn)樗霈F(xiàn)在?WHERE該查詢的子句中。標(biāo)準(zhǔn) SQL 在這種情況下需要出錯(cuò)。如果?ANSI未啟用模式，服務(wù)器會(huì)?以與解釋 相同的方式處理此類查詢?。?S(outer_ref)S(const)

  請(qǐng)參閱第 1.6 節(jié)“MySQL 標(biāo)準(zhǔn)合規(guī)性”。

• DB2

  相當(dāng)于?PIPES_AS_CONCAT，?ANSI_QUOTES，?IGNORE_SPACE，?NO_KEY_OPTIONS，?NO_TABLE_OPTIONS，?NO_FIELD_OPTIONS。

  筆記

  從 MySQL 5.7.22 開始，DB2?已棄用。它在 MySQL 8.0 中被刪除。

• MAXDB

  相當(dāng)于?PIPES_AS_CONCAT，?ANSI_QUOTES，?IGNORE_SPACE，?NO_KEY_OPTIONS，?NO_TABLE_OPTIONS，?NO_FIELD_OPTIONS，?NO_AUTO_CREATE_USER。

  筆記

  從 MySQL 5.7.22 開始，?MAXDB已棄用。它在 MySQL 8.0 中被刪除。

• MSSQL

  相當(dāng)于?PIPES_AS_CONCAT，?ANSI_QUOTES，?IGNORE_SPACE，?NO_KEY_OPTIONS，?NO_TABLE_OPTIONS，?NO_FIELD_OPTIONS。

  筆記

  從 MySQL 5.7.22 開始，?MSSQL已棄用。它在 MySQL 8.0 中被刪除。

• MYSQL323

  相當(dāng)于MYSQL323，?HIGH_NOT_PRECEDENCE。這意味著HIGH_NOT_PRECEDENCE?加上一些SHOW CREATE TABLE?特定于的行為?MYSQL323：

  • TIMESTAMP列顯示不包含DEFAULT或?ON UPDATE屬性。

  • 字符串列顯示不包括字符集和排序規(guī)則屬性。對(duì)于?CHAR和?VARCHAR列，如果排序規(guī)則是二進(jìn)制，BINARY則附加到列類型。

  • 表選項(xiàng)?顯示為?。?ENGINE=engine_nameTYPE=engine_name

  • 對(duì)于MEMORY表，存儲(chǔ)引擎顯示為HEAP。

  筆記

  從 MySQL 5.7.22 開始，?MYSQL323已棄用。它在 MySQL 8.0 中被刪除。

• MYSQL40

  相當(dāng)于MYSQL40，?HIGH_NOT_PRECEDENCE。這意味著HIGH_NOT_PRECEDENCE?加上一些特定于 的行為?MYSQL40。這些與 for 相同MYSQL323，只是SHOW CREATE TABLE?不顯示HEAP為MEMORY表的存儲(chǔ)引擎。

  筆記

  從 MySQL 5.7.22 開始，?MYSQL40已棄用。它在 MySQL 8.0 中被刪除。

• ORACLE

  相當(dāng)于?PIPES_AS_CONCAT，?ANSI_QUOTES，?IGNORE_SPACE，?NO_KEY_OPTIONS，?NO_TABLE_OPTIONS，?NO_FIELD_OPTIONS，?NO_AUTO_CREATE_USER。

  筆記

  從 MySQL 5.7.22 開始，?ORACLE已棄用。它在 MySQL 8.0 中被刪除。

• POSTGRESQL

  相當(dāng)于?PIPES_AS_CONCAT，?ANSI_QUOTES，?IGNORE_SPACE，?NO_KEY_OPTIONS，?NO_TABLE_OPTIONS，?NO_FIELD_OPTIONS。

  筆記

  從 MySQL 5.7.22 開始，?POSTGRESQL已棄用。它在 MySQL 8.0 中被刪除。

• TRADITIONAL

  在 MySQL 5.7.4 之前以及在 MySQL 5.7.8 及更高版本中，?TRADITIONAL相當(dāng)于STRICT_TRANS_TABLES,?STRICT_ALL_TABLES,?NO_ZERO_IN_DATE,?NO_ZERO_DATE,?ERROR_FOR_DIVISION_BY_ZERO,?NO_AUTO_CREATE_USER, 和?NO_ENGINE_SUBSTITUTION。

  從 MySQL 5.7.4 到 5.7.7，?TRADITIONAL相當(dāng)于STRICT_TRANS_TABLES,?STRICT_ALL_TABLES,?NO_AUTO_CREATE_USER, 和?NO_ENGINE_SUBSTITUTION。、和 模式未命名，因?yàn)樵谶@些NO_ZERO_IN_DATE版本?中，它們的效果包含在嚴(yán)格 SQL 模式（或?）的效果中。因此，在所有 MySQL 5.7 版本中的效果?都是相同的（與 MySQL 5.6 中相同）。有關(guān)更多討論，請(qǐng)參閱?MySQL 5.7 中的 SQL 模式更改。?NO_ZERO_DATEERROR_FOR_DIVISION_BY_ZEROSTRICT_ALL_TABLESSTRICT_TRANS_TABLESTRADITIONAL

• 對(duì)于事務(wù)表，當(dāng)啟用STRICT_ALL_TABLES或 時(shí)?，數(shù)據(jù)更改語句中的值無效或缺失會(huì)發(fā)生錯(cuò)誤 。STRICT_TRANS_TABLES該語句被中止并回滾。

• 對(duì)于非事務(wù)表，如果在要插入或更新的第一行中出現(xiàn)錯(cuò)誤值，則任一模式的行為都是相同的：語句將中止并且表保持不變。如果語句插入或修改多行，并且錯(cuò)誤值出現(xiàn)在第二行或后面的行中，則結(jié)果取決于啟用了哪種嚴(yán)格模式：

  • 對(duì)于STRICT_ALL_TABLES，MySQL 返回錯(cuò)誤并忽略其余行。但是，由于已插入或更新了較早的行，因此結(jié)果是部分更新。為了避免這種情況，請(qǐng)使用單行語句，該語句可以在不更改表的情況下中止。

  • 對(duì)于?STRICT_TRANS_TABLES，MySQL 會(huì)將無效值轉(zhuǎn)換為該列最接近的有效值，并插入調(diào)整后的值。如果缺少值，MySQL 會(huì)插入列數(shù)據(jù)類型的隱式默認(rèn)值。無論哪種情況，MySQL 都會(huì)生成警告而不是錯(cuò)誤，并繼續(xù)處理該語句。第 11.6 節(jié)“數(shù)據(jù)類型默認(rèn)值”中描述了隱式默認(rèn)值。

• 嚴(yán)格模式影響除以零的處理，其中包括?：?MOD(N,0)

  對(duì)于數(shù)據(jù)更改操作 (?INSERT,?UPDATE)：

  • 如果未啟用嚴(yán)格模式，則除以零插入?NULL并且不會(huì)產(chǎn)生警告。

  • 如果啟用了嚴(yán)格模式，除以零會(huì)產(chǎn)生錯(cuò)誤，除非IGNORE也給出了。對(duì)于INSERT IGNORE和?UPDATE IGNORE，除以零會(huì)插入NULL并產(chǎn)生警告。

  對(duì)于SELECT，除以零返回NULL。啟用嚴(yán)格模式也會(huì)導(dǎo)致生成警告。

• 嚴(yán)格模式會(huì)影響服務(wù)器是否允許?'0000-00-00'作為有效日期：

  • 如果未啟用嚴(yán)格模式，?'0000-00-00'則允許并且插入不會(huì)產(chǎn)生警告。

  • 如果啟用了嚴(yán)格模式，則?'0000-00-00'不允許并且插入會(huì)產(chǎn)生錯(cuò)誤，除非?IGNORE也給出了。對(duì)于?INSERT IGNORE和UPDATE IGNORE,'0000-00-00'是允許的并且插入會(huì)產(chǎn)生警告。

• 嚴(yán)格模式會(huì)影響服務(wù)器是否允許年部分非零但月或日部分為 0 的日期（例如'2010-00-01'或?'2010-01-00'）：

  • 如果未啟用嚴(yán)格模式，則允許包含零部分的日期并且插入不會(huì)產(chǎn)生警告。

  • 如果啟用嚴(yán)格模式，則不允許包含零部分的日期，并且插入會(huì)產(chǎn)生錯(cuò)誤，除非?IGNORE也給出了。對(duì)于?INSERT IGNORE和UPDATE IGNORE，零部分的日期將被插入為?'0000-00-00'（對(duì)于 被認(rèn)為有效IGNORE）并產(chǎn)生警告。

• IGNORE 對(duì)語句執(zhí)行的影響

• 嚴(yán)格SQL模式對(duì)語句執(zhí)行的影響

mysql> CREATE TABLE t (i INT NOT NULL PRIMARY KEY);
mysql> INSERT INTO t (i) VALUES(1),(1);
ERROR 1062 (23000): Duplicate entry '1' for key 'PRIMARY'

mysql> INSERT IGNORE INTO t (i) VALUES(1),(1);
Query OK, 1 row affected, 1 warning (0.01 sec)
Records: 2  Duplicates: 1  Warnings: 1

mysql> SHOW WARNINGS;
+---------+------+---------------------------------------+
| Level   | Code | Message                               |
+---------+------+---------------------------------------+
| Warning | 1062 | Duplicate entry '1' for key 'PRIMARY' |
+---------+------+---------------------------------------+
1 row in set (0.00 sec)

mysql> CREATE TABLE t2 (id INT NOT NULL);
mysql> INSERT INTO t2 (id) VALUES(1),(NULL),(3);
ERROR 1048 (23000): Column 'id' cannot be null
mysql> SELECT * FROM t2;
Empty set (0.00 sec)

mysql> INSERT INTO t2 (id) VALUES(1),(NULL),(3);
mysql> SELECT * FROM t2;
+----+
| id |
+----+
|  1 |
|  0 |
|  3 |
+----+

• CREATE TABLE ... SELECT：IGNORE不適用于語句的CREATE TABLE或?SELECT部分，但適用于插入到由 生成的行表中?SELECT。與唯一鍵值重復(fù)現(xiàn)有行的行將被丟棄。

• DELETE：?IGNORE導(dǎo)致MySQL在刪除行的過程中忽略錯(cuò)誤。

• INSERT：使用 時(shí)?IGNORE，在唯一鍵值上重復(fù)現(xiàn)有行的行將被丟棄。設(shè)置為會(huì)導(dǎo)致數(shù)據(jù)轉(zhuǎn)換錯(cuò)誤的值的行將設(shè)置為最接近的有效值。

  對(duì)于未找到與給定值匹配的分區(qū)的分區(qū)表，IGNORE會(huì)導(dǎo)致包含不匹配值的行的插入操作靜默失敗。

• LOAD DATA,?LOAD XML：使用 時(shí)?IGNORE，在唯一鍵值上重復(fù)現(xiàn)有行的行將被丟棄。

• UPDATE：使用 時(shí)?IGNORE，不會(huì)更新唯一鍵值上發(fā)生重復(fù)鍵沖突的行。更新為會(huì)導(dǎo)致數(shù)據(jù)轉(zhuǎn)換錯(cuò)誤的值的行將更新為最接近的有效值。

ER_BAD_NULL_ERROR
ER_DUP_ENTRY
ER_DUP_ENTRY_WITH_KEY_NAME
ER_DUP_KEY
ER_NO_PARTITION_FOR_GIVEN_VALUE
ER_NO_PARTITION_FOR_GIVEN_VALUE_SILENT
ER_NO_REFERENCED_ROW_2
ER_ROW_DOES_NOT_MATCH_GIVEN_PARTITION_SET
ER_ROW_IS_REFERENCED_2
ER_SUBQUERY_NO_1_ROW
ER_VIEW_CHECK_FAILED

mysql> SET sql_mode = '';
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO t (i) VALUES('abc');
Query OK, 1 row affected, 1 warning (0.01 sec)

mysql> SHOW WARNINGS;
+---------+------+--------------------------------------------------------+
| Level   | Code | Message                                                |
+---------+------+--------------------------------------------------------+
| Warning | 1366 | Incorrect integer value: 'abc' for column 'i' at row 1 |
+---------+------+--------------------------------------------------------+
1 row in set (0.00 sec)

mysql> SET sql_mode = 'STRICT_ALL_TABLES';
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO t (i) VALUES('abc');
ERROR 1366 (HY000): Incorrect integer value: 'abc' for column 'i' at row 1

• ALTER TABLE

• CREATE TABLE

• CREATE TABLE ... SELECT

• DELETE（單表和多表均可）

• INSERT

• LOAD DATA

• LOAD XML

• SELECT SLEEP()

• UPDATE（單表和多表均可）

ER_BAD_NULL_ERROR
ER_CUT_VALUE_GROUP_CONCAT
ER_DATA_TOO_LONG
ER_DATETIME_FUNCTION_OVERFLOW
ER_DIVISION_BY_ZERO
ER_INVALID_ARGUMENT_FOR_LOGARITHM
ER_NO_DEFAULT_FOR_FIELD
ER_NO_DEFAULT_FOR_VIEW_FIELD
ER_TOO_LONG_KEY
ER_TRUNCATED_WRONG_VALUE
ER_TRUNCATED_WRONG_VALUE_FOR_FIELD
ER_WARN_DATA_OUT_OF_RANGE
ER_WARN_NULL_TO_NOTNULL
ER_WARN_TOO_FEW_RECORDS
ER_WRONG_ARGUMENTS
ER_WRONG_VALUE_FOR_TYPE
WARN_DATA_TRUNCATED

由于 MySQL 的持續(xù)開發(fā)定義了新的錯(cuò)誤，因此可能存在不屬于上述嚴(yán)格 SQL 模式適用的錯(cuò)誤。

• 如果可以修改有問題的查詢，請(qǐng)這樣做，以便非聚合列在功能上依賴于GROUP BY列，或者通過使用 引用非聚合列?ANY_VALUE()。

• 如果無法修改有問題的查詢（例如，如果它是由第三方應(yīng)用程序生成的），請(qǐng)sql_mode在服務(wù)器啟動(dòng)時(shí)將系統(tǒng)變量設(shè)置為 not enable?ONLY_FULL_GROUP_BY。

• ERROR_FOR_DIVISION_BY_ZERO、?NO_ZERO_DATE、 和?NO_ZERO_IN_DATE不是嚴(yán)格 SQL 模式的一部分，但它們旨在與嚴(yán)格模式一起使用。提醒一下，如果在未啟用嚴(yán)格模式的情況下啟用它們，則會(huì)出現(xiàn)警告，反之亦然。

• ERROR_FOR_DIVISION_BY_ZERO、?NO_ZERO_DATE、 和?NO_ZERO_IN_DATE默認(rèn)情況下啟用。