SQL mode

今天我們來分享一下MySQL的SQL mode , 這也是我們比較容易忽略的一點，我們在一開始安裝數(shù)據(jù)庫的時候其實就要先考慮要保留哪些SQL mode，去除哪些，合理的配置能夠減少很多不必要的麻煩。

MySQL 5.7默認的SQL mode包含ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER, and NO_ENGINE_SUBSTITUTION。

這是MySQL官網(wǎng)的原文描述：“These modes were added to the default SQL mode in MySQL 5.7: The ONLY_FULL_GROUP_BY and STRICT_TRANS_TABLES modes were added in MySQL 5.7.5. The NO_AUTO_CREATE_USER mode was added in MySQL 5.7.7. The ERROR_FOR_DIVISION_BY_ZERO, NO_ZERO_DATE, and NO_ZERO_IN_DATE modes were added in MySQL 5.7.8. For additional discussion regarding these changes to the default SQL mode value, see SQL Mode Changes in MySQL 5.7.”

show sql mode

SELECT @@GLOBAL.sql_mode;

SELECT @@SESSION.sql_mode;

set sql mode

設置為GLOBAL，那么所有的客戶端都會受到影響，不過要擁有SUPER權限才能進行設置，也就是root用戶，設置SESSION，那么受影響的只是當前的連接會話。

SET GLOBAL sql_mode ='ONLY_FULL_GROUP_BY'

SET SESSION sql_mode ='ONLY_FULL_GROUP_BY'

下面我們就針對默認設置的這幾種SQL mode進行詳細的講解，其他的哪些大家可以去官網(wǎng)參考。

docs.oracle.com/cd/E17952_0…

默認的SQL mode

ONLY_FULL_GROUP_BY

設置了這個值，如果使用GROUP BY，在SELECT后面出現(xiàn)的字段，在GROUP BY后面必須出現(xiàn)，不然報錯如下

Expression #3 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'blue.shop.price' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by

如下使用的是MySQL默認的sql_mode

ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION

那么下面的語句就會報錯，因為GROUP BY后面只有一個字段，而SELECT * 是查出所有字段，所以就報錯。

SELECT * FROM shop GROUP BY article 

這樣寫就不會報錯

SELECT * FROM shop GROUP BY article , dealer , price

不過我們不可能使用一個GROUP BY，后面還要跟著所有字段，顯然不合理，那么就應該將其關閉，只需要將其去掉就行

STRICT_TRANS_TABLES

嚴格模式控制MySQL如何處理數(shù)據(jù)更改語句中的無效或缺失值，如INSERT或UPDATE。一個值可能因多種原因無效。例如，它可能具有列的錯誤數(shù)據(jù)類型，或者它可能超出了范圍。如果要插入的新行不包含定義中沒有顯式DEFAULT子句的非null列的值，則該值缺失。

比如我們的某個字段設置不能為NULL，而我們插入的數(shù)據(jù)這個字段為NULL，那么就不能通過，就會報錯如下：

1364 - Field 'dealer' doesn't have a default value

那么這個問題要怎么解決呢？我相信這個問題大家經(jīng)常遇到，一般是我們在插入數(shù)據(jù)的時候?qū)嶓w的屬性沒有賦值，所以導致這個問題，所以我們會去檢查代碼，然后給屬性賦值，另外一種做法就是去除STRICT_TRANS_TABLES,這樣就不會進行校驗，不過是極其不推薦這樣做的，因為要我們要保證數(shù)據(jù)的完整性，所以必須在代碼層面做好工作。

NO_ZERO_IN_DATE

NO_ZERO_IN_DATE模式會影響服務器是否允許年部分不為零但月或日部分為0的日期。(該模式影響日期，如“2010-00-01”或“2010-01-00”，但不影響“0000-00-00”。要控制服務器是否允許'0000-00-00'，請使用NO_ZERO_DATE模式。)NO_ZERO_IN_DATE的效果還取決于是否啟用嚴格SQL模式，如果沒有啟用嚴格SQL模式STRICT_TRANS_TABLES，那么啟用了NO_ZERO_IN_DATE也沒用。

如下SQL的日期月和日為0，啟用了嚴格模式STRICT_TRANS_TABLES和NO_ZERO_IN_DATE，那么就會報錯。

INSERT INTO `blue`.`shop` (`article`, `dealer` ,`price`,`date`) VALUES ('商品5', '5', 5.00, '2022-00-00');

1292 - Incorrect datetime value: '2022-00-00' for column 'date' at row 1

去除嚴格模式STRICT_TRANS_TABLES和NO_ZERO_IN_DATE就不會報錯。

NO_ZERO_DATE

上面的NO_ZERO_IN_DATE可以插入'0000-00-00'，如果使用了嚴格模式STRICT_TRANS_TABLES和NO_ZERO_DATE，那么就不可以插入'0000-00-00'。

ERROR_FOR_DIVISION_BY_ZERO

對于INSERT或者UPDATE中，如果被除數(shù)為0，那么就會產(chǎn)生錯誤，數(shù)據(jù)無法插入，MOD(N,M)也是一樣

INSERT INTO `blue`.`shop` (`article`,dealer ,`price`,`date`) VALUES ('商品5', '5', MOD(10,0), '0000-00-00');

對于SELECT，如果被除數(shù)為0，那么就會返回NULL，MOD(N,M)也一樣。

SELECT price / 0  FROM shop

報錯信息： 1365 - Division by 0

NO_AUTO_CREATE_USER

不能使用grant命令創(chuàng)建密碼為空的用戶。

NO_ENGINE_SUBSTITUTION

如果指定了NO_ENGINE_SUBSTITUTION，我們在創(chuàng)建表或者修改表的時候，如果去指定了不存在或者不支持的存儲引擎，那么就會報錯，無法創(chuàng)建和修改，如果沒有配置NO_ENGINE_SUBSTITUTION，那么就會將我們指定的存儲引擎（不支持或者不存在）的存儲引擎替換為默認的存儲引擎，MySQL5.7后的默認存儲引擎為InnoDB，所以就會自動設置為InnoDB。

如下我們創(chuàng)建表，將存儲引擎設置為一個不存在的InnoDBTest，因為我們?nèi)コ薔O_ENGINE_SUBSTITUTION，所以不會報錯，并且會替換成默認的InnoDB

創(chuàng)建sql

CREATE TABLE store ( `name` VARCHAR ( 255 ) DEFAULT NULL ) ENGINE = InnoDBTest

查看創(chuàng)建過程

SHOW CREATE TABLE store

結果

CREATE TABLE `store` (
  `name` varchar(255) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

MySQL存儲引擎

SHOW ENGINES;

關于MySQL的SQL mode，就說到這里，我只列舉了MySQL5.7默認的幾種并對其進行講解，有興趣的話可以去了解其他的選項

以上就是MySQL默認sql_mode淺析的詳細內(nèi)容，更多關于MySQL默認sql_mode的資料請關注腳本之家其它相關文章！