一，Illegal mix of collations (gbk_bin,IMPLICIT) and (latin1_swedish_ci,COERCIBL

在MySQL上寫了一個(gè)存儲(chǔ)過程，但是我發(fā)現(xiàn)用#寫完中文注釋后，在保存時(shí)這些注釋會(huì)消失。在覺得可能是編碼問題導(dǎo)致識(shí)別不了中文語句，于是就直接將數(shù)據(jù)庫(kù)的編碼修改成為了gbk，但是并沒有能夠修復(fù)這個(gè)問題。

相反，在運(yùn)行原本正常的存儲(chǔ)過程時(shí)，出現(xiàn)了詭異的報(bào)錯(cuò)：Illegal mix of collations (gbk_bin,IMPLICIT) and (latin1_swedish_ci,COERCIBL...

百度之后并沒有合適的解決辦法，閱讀了stackoverflow上的這篇回答，里面介紹了MySQL本身的編碼和字符比較體系，collation的設(shè)定保證了使用某種編碼體系時(shí)可以正常進(jìn)行字符之間的比較，包括bin/cs/ci幾種，分別代表二進(jìn)制字符比較（可以比較二進(jìn)制字符和正常字符，大小寫敏感）、大小寫敏感、大小寫不敏感三種比較方式。同時(shí)，這個(gè)回答給出了下面的描述：

Literal expressions take the collation specified in the?collation_connection?system variable; values from tables take the collation specified in their column metadata.

表達(dá)式會(huì)使用系統(tǒng)默認(rèn)的collation_connection字符比較設(shè)定，而表內(nèi)的值則會(huì)采取最初建表時(shí)給每個(gè)列設(shè)定的設(shè)定。

接下來，我使用“show VARIABLES”命令查看了系統(tǒng)對(duì)應(yīng)的變量，找到collation_connection，發(fā)現(xiàn)取值為latin1_swedish_ci，猜測(cè)應(yīng)該是之前寫存儲(chǔ)過程時(shí)，默認(rèn)使用的latin編碼，但是后面我將數(shù)據(jù)庫(kù)編碼整體修改為了gbk_bin，導(dǎo)致了不同步。

本來準(zhǔn)備查一下是否有辦法可以修改“collation_connection”，但是發(fā)現(xiàn)并沒有特別便利的解決方案。

于是，我就把數(shù)據(jù)庫(kù)的編碼模式回退到了“l(fā)atin1”，并且將“collation_connection”設(shè)置為“l(fā)atin1_swedish_ci”，于是問題解決了。

二、MySQL客戶端中的超時(shí)連接時(shí)間設(shè)置

當(dāng)用MySQL查詢比較大的表時(shí)，如果使用客戶端，會(huì)出現(xiàn)連接超時(shí)的報(bào)錯(cuò)情況，這種情況下，可以修改客戶端上的超時(shí)時(shí)間。MySQL Workbench和Navicat不同。

MySQL Workbench：

Navicat：

在需要修改的數(shù)據(jù)庫(kù)上“右鍵->編輯連接”

條件判斷中的NULL，如果是某個(gè)字段取值A(chǔ)為NULL，在使用條件“A<>'0' ”之類的格式時(shí)，并不會(huì)返回NULL的行，目前還不清楚原因，猜測(cè)可能NULL和普通的取值不在一個(gè)比較體系里面，這種情況下，如果只是需要返回NULL對(duì)應(yīng)的行，就用is NULL做判斷就好了。