淺談MySQL的sql_mode

  • 2022 年 8 月 14 日
  • 筆記

SQL mode

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

image

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官網的原文描述：「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進行詳細的講解，其他的哪些大家可以去官網參考。

//docs.oracle.com/cd/E17952_01/mysql-5.7-en/sql-mode.html

默認的SQL mode

ONLY_FULL_GROUP_BY

設置了這個值，如果使用GROUP BY，在SELECT後面出現的欄位，在GROUP BY後面必須出現，不然報錯如下

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如何處理數據更改語句中的無效或缺失值，如INSERT或UPDATE。一個值可能因多種原因無效。例如，它可能具有列的錯誤數據類型，或者它可能超出了範圍。如果要插入的新行不包含定義中沒有顯式DEFAULT子句的非null列的值，則該值缺失。

比如我們的某個欄位設置不能為NULL，而我們插入的數據這個欄位為NULL，那麼就不能通過，就會報錯如下：

1364 – Field ‘dealer’ doesn’t have a default value

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

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中，如果被除數為0，那麼就會產生錯誤，數據無法插入，MOD(N,M)也是一樣

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

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

SELECT price / 0  FROM shop

報錯資訊： 1365 – Division by 0

NO_AUTO_CREATE_USER

不能使用grant命令創建密碼為空的用戶。

NO_ENGINE_SUBSTITUTION

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

如下我們創建表，將存儲引擎設置為一個不存在的InnoDBTest，因為我們去除了NO_ENGINE_SUBSTITUTION，所以不會報錯，並且會替換成默認的InnoDB

創建sql

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

查看創建過程

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默認的幾種並對其進行講解，有興趣的話可以去了解其他的選項。感謝你的觀看，我們下期見！

VirMach 便宜 VPS

QNews

QNews