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

在MySQL上寫了一個存儲過程，但是我發現用#寫完中文注釋后，在保存時這些注釋會消失。在覺得可能是編碼問題導致識別不了中文語句，于是就直接將數據庫的編碼修改成為了gbk，但是并沒有能夠修復這個問題。

相反，在運行原本正常的存儲過程時，出現了詭異的報錯：Illegal mix of collations (gbk_bin,IMPLICIT) and (latin1_swedish_ci,COERCIBL...

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

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

表達式會使用系統默認的collation_connection字符比較設定，而表內的值則會采取最初建表時給每個列設定的設定。

接下來，我使用“show VARIABLES”命令查看了系統對應的變量，找到collation_connection，發現取值為latin1_swedish_ci，猜測應該是之前寫存儲過程時，默認使用的latin編碼，但是后面我將數據庫編碼整體修改為了gbk_bin，導致了不同步。

本來準備查一下是否有辦法可以修改“collation_connection”，但是發現并沒有特別便利的解決方案。

于是，我就把數據庫的編碼模式回退到了“latin1”，并且將“collation_connection”設置為“latin1_swedish_ci”，于是問題解決了。

二、MySQL客戶端中的超時連接時間設置

當用MySQL查詢比較大的表時，如果使用客戶端，會出現連接超時的報錯情況，這種情況下，可以修改客戶端上的超時時間。MySQL Workbench和Navicat不同。

MySQL Workbench：

Navicat：

在需要修改的數據庫上“右鍵->編輯連接”

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