1. MySQL 莫名變成了 Strict SQL Mode
最近測試組那邊反應數據庫部分寫入失敗,app層提示是插入成功,但表裏面裏面沒有產生數據,而兩個寫入操作的另外一個表有數據。因爲 insert 失敗在數據庫層面是看不出來的,於是找php的同事看下錯誤信息:
[Err] 1364 - Field `f_company_id` doesn't have a default value
很明顯2個 insert 操作,第一條成功,第二條失敗了,但因爲沒有控制在一個事務當中,導致app裏面依然提示成功,這是客戶入庫操作,心想如果線上也有這個問題得是多大的代價。
不說開發的問題,好端端的mysql怎麼突然就部分表寫入失敗呢?根據上面的問題很快能猜到是 sql_mode 問題: NOT NULL 列沒有默認值但代碼裏也沒給值,在非嚴格模式下,int列默認爲0,string列默認爲''了,所以不成問題;但在嚴格模式下,是直接返回失敗的。
一看,果然:
mysql> show variables like "sql_mode";
+---------------+--------------------------------------------+
| Variable_name | Value |
+---------------+--------------------------------------------+
| sql_mode | STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION |
+---------------+--------------------------------------------+
但是一直是沒問題的的,就突然出現了,有誰會去改 sql_mode 呢,生產環境產生這個問題的風險有多大?所以必須揪出來。
先 set global sql_mode=''
,讓他們用着先(文後會給解決問題根本的辦法),同時打開general_log看是哪一個用戶有類似設置 sql_mode 命令:
1134456 Query SET autocommit=1
1134456 Query Set sql_mode='NO_ENGINE_SUBSITUTION,STRICT_TRANS_TABLES'
1134457 Connect [email protected] on
1134457 Query /* mysql-connector-java-5.1.35 ...
看出是java組那邊哪個框架建立連接的時候使用設置了sql_mode,但這是session級別的,不影響php那邊用戶的連接。
<!-- more -->
那會是什麼原因在 set global 之後又變回strict模式呢,於是想到 mysqld_safe 啓動實際是一個保護進程,在mysqld異常停止之後會拉起來,會不會中間有異常導致 mysqld 重啓,致使 global 失效?看了mysql錯誤日誌,纔想到前些天斷過電,所以決定直接改 /etc/my.cnf
配置:
[mysqld]
sql_mode=NO_ENGINE_SUBSTITUTION
重啓myqld之後,還是STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION
,很少遇到my.cnf裏面配置不生效的情況。無獨有偶,在 stackoverflow上找到同樣的問題 how-to-make-sql-mode-no-engine-substitution-permanent-in-mysql-my-cnf ,原因很簡單,sql_mode這個選項被其它地方的配置覆蓋了。
瞭解一下mysql配置文件的加載順序:
$ mysqld --help --verbose|grep -A1 -B1 cnf
Default options are read from the following files in the given order:
/etc/my.cnf /etc/mysql/my.cnf /usr/etc/my.cnf ~/.my.cnf
mysql按照上面的順序加載配置文件,後面的配置項會覆蓋前面的。最後終於在 /usr/my.cnf
找到有一條sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
,把這個文件刪掉,/etc/my.cnf 裏面的就生效了。
但是目前沒能整明白的是,mysql運行這麼長時間怎麼突然在/usr
(MYSQL_BASE)下多個my.cnf,也不像人爲創建的。其它實例也沒這樣的問題。
類似還出現過一例:存儲過程裏把 '' 傳給int型的,嚴格模式是不允許,而非嚴格模式只是一個warning。(命令行執行完語句後,show warnings
可看見)
那麼解決這類問題的終極(推薦)辦法其實是,考慮到數據的兼容性和準確性,MySQL就應該運行在嚴格模式下!無論開發環境還是生產環境,否則代碼移植到線上可能產生隱藏的問題。
sql_mode 問題可以很簡單,也可以很複雜。曾經在一個交流羣裏看到有人提到,主從sql_mode設置不一致導致複製異常,這裏自己正好全面瞭解一下幾個常用的值,方便以後排除問題多個方向。
2. sql_mode 常用值說明
官方手冊專門有一節介紹 https://dev.mysql.com/doc/refman/5.6/en/sql-mode.html 。 SQL Mode 定義了兩個方面:MySQL應支持的SQL語法,以及應該在數據上執行何種確認檢查。
1. SQL語法支持類
-
ONLY_FULL_GROUP_BY
對於GROUP BY聚合操作,如果在SELECT中的列、HAVING或者ORDER BY子句的列,沒有在GROUP BY中出現,那麼這個SQL是不合法的。是可以理解的,因爲不在 group by 的列查出來展示會有矛盾。
在5.7中默認啓用,所以在實施5.6升級到5.7的過程需要注意:Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column '1066export.ebay_order_items.TransactionID' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by
-
ANSI_QUOTES
啓用 ANSI_QUOTES 後,不能用雙引號來引用字符串,因爲它被解釋爲識別符,作用與 ` 一樣。設置它以後,update t set f1="" ...
,會報 Unknown column '' in 'field list 這樣的語法錯誤。 -
PIPES_AS_CONCAT
將||
視爲字符串的連接操作符而非 或 運算符,這和Oracle數據庫是一樣的,也和字符串的拼接函數 CONCAT() 相類似。 -
NO_TABLE_OPTIONS
使用SHOW CREATE TABLE
時不會輸出MySQL特有的語法部分,如ENGINE
,這個在使用 mysqldump 跨DB種類遷移的時候需要考慮。 -
NO_AUTO_CREATE_USER
字面意思不自動創建用戶。在給MySQL用戶授權時,我們習慣使用GRANT ... ON ... TO dbuser
順道一起創建用戶。設置該選項後就與oracle操作類似,授權之前必須先建立用戶。5.7.7開始也默認了。
2. 數據檢查類
-
NO_ZERO_DATE
認爲日期 '0000-00-00' 非法,與是否設置後面的嚴格模式有關。-
如果設置了嚴格模式,則 NO_ZERO_DATE 自然滿足。但如果是 INSERT IGNORE 或 UPDATE IGNORE,'0000-00-00'依然允許且只顯示warning
-
如果在非嚴格模式下,設置了
NO_ZERO_DATE
,效果與上面一樣,'0000-00-00'允許但顯示warning;如果沒有設置NO_ZERO_DATE
,no warning,當做完全合法的值。 -
NO_ZERO_IN_DATE
情況與上面類似,不同的是控制日期和天,是否可爲 0 ,即2010-01-00
是否合法。
-
-
NO_ENGINE_SUBSTITUTION
使用ALTER TABLE
或CREATE TABLE
指定 ENGINE 時, 需要的存儲引擎被禁用或未編譯,該如何處理。啓用NO_ENGINE_SUBSTITUTION
時,那麼直接拋出錯誤;不設置此值時,CREATE用默認的存儲引擎替代,ATLER不進行更改,並拋出一個 warning . -
STRICT_TRANS_TABLES
設置它,表示啓用嚴格模式。
注意STRICT_TRANS_TABLES
不是幾種策略的組合,單獨指INSERT
、UPDATE
出現少值或無效值該如何處理:-
前面提到的把 '' 傳給int,嚴格模式下非法,若啓用非嚴格模式則變成0,產生一個warning
-
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
-
上面並沒有囊括所有的 SQL Mode,選了幾個代表性的,詳細還是 看手冊。
sql_mode一般來說很少去關注它,沒有遇到實際問題之前不會去啓停上面的條目。我們常設置的 sql_mode 是 ANSI
、STRICT_TRANS_TABLES
、TRADITIONAL
,ansi和traditional是上面的幾種組合。
-
ANSI
:更改語法和行爲,使其更符合標準SQL
相當於REAL_AS_FLOAT, PIPES_AS_CONCAT, ANSI_QUOTES, IGNORE_SPACE -
TRADITIONAL
:更像傳統SQL數據庫系統,該模式的簡單描述是當在列中插入不正確的值時“給出錯誤而不是警告”。
相當於 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 -
ORACLE
:相當於 PIPES_AS_CONCAT, ANSI_QUOTES, IGNORE_SPACE, NO_KEY_OPTIONS, NO_TABLE_OPTIONS, NO_FIELD_OPTIONS, NO_AUTO_CREATE_USER
無論何種mode,產生error之後就意味着單條sql執行失敗,對於支持事務的表,則導致當前事務回滾;但如果沒有放在事務中執行,或者不支持事務的存儲引擎表,則可能導致數據不一致。MySQL認爲,相比直接報錯終止,數據不一致問題更嚴重。於是 STRICT_TRANS_TABLES
對非事務表依然儘可能的讓寫入繼續,比如給個"最合理"的默認值或截斷。而對於 STRICT_ALL_TABLES
,如果是單條更新,則不影響,但如果更新的是多條,第一條成功,後面失敗則會出現部分更新。
5.6.6 以後版本默認就是NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
,5.5默認爲 '' 。
3. 設置 sql_mode
查看
查看當前連接會話的sql模式:
mysql> select @@session.sql_mode;
或者從環境變量裏取
mysql> show variables like "sql_mode";
查看全局sql_mode設置:
mysql> select @@global.sql_mode;
只設置global,需要重新連接進來纔會生效
設置
形式如
mysql> set sql_mode='';
mysql> set global sql_mode='NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES';
如果是自定義的模式組合,可以像下面這樣
Adding only one mode to sql_mode without removing existing ones:
mysql> SET sql_mode=(SELECT CONCAT(@@sql_mode,',<mode_to_add>'));
Removing only a specific mode from sql_mode without removing others:
mysql> SET sql_mode=(SELECT REPLACE(@@sql_mode,'<mode_to_remove>',''));
配置文件裏面設置 sql-mode=""
。
參考