mysql的字符集設(shè)置有多個層級，在mysql中存儲中文，如果不能正確設(shè)置字符集，很容易出現(xiàn)數(shù)據(jù)亂碼。今天就有一個用戶反饋他數(shù)據(jù)庫中的數(shù)據(jù)下午1點(diǎn)多開始出現(xiàn)了亂碼。在這里，我分享下具體問題的排查過程，以及解決的辦法。

（1）  排除客戶端設(shè)置導(dǎo)致的顯示亂碼

如果用戶設(shè)置的mysql character_set_client跟客戶端顯示的字符集不一致，很容易導(dǎo)致中文數(shù)據(jù)亂碼。

設(shè)置session字符集為utf8：set names utf8，設(shè)置客戶端顯示字符集為utf8，然后從表中select出有亂碼的數(shù)據(jù)。

上面顯示，在character_set_client跟客戶端的字符集一致的情況下，還是出現(xiàn)了亂碼，這個排除是用戶顯示字符集設(shè)置不對的可能。下面通過hex(item_title)列來查看這個列在底層的存儲字符集是否正確。

通過上面的查詢，可以確認(rèn)這個數(shù)據(jù)亂碼不是顯示問題，而是存儲的數(shù)據(jù)內(nèi)容本身就是錯誤的。

（2）  定位存儲亂碼原因

1>     用戶確認(rèn)這個記錄插入時能夠正常顯示，但是后來update之后，數(shù)據(jù)就亂碼了。根據(jù)這個信息到binlog中查找更改正確內(nèi)容對應(yīng)的update語句。

上面的binlog日志顯示這個sql將原來數(shù)據(jù)庫中正確的內(nèi)容，更新成一堆亂碼。所以導(dǎo)致數(shù)據(jù)庫中的存儲數(shù)據(jù)亂碼。

從binlog日志可以看出在更新時，是用latin1的方式寫入到數(shù)據(jù)庫中。Update后面的set語句中item_title字段的內(nèi)容是亂碼的，所以確認(rèn)是導(dǎo)入數(shù)據(jù)源本身內(nèi)容有問題，從而導(dǎo)致更新后的數(shù)據(jù)亂碼。跟用戶確認(rèn)這個update語句的更新內(nèi)容，是先從庫中l(wèi)oad 出來，后拼接成的update sql，所以懷疑load出來的數(shù)據(jù)就已經(jīng)是亂碼了，然后直接用這個錯誤的數(shù)據(jù)更新原來正確的數(shù)據(jù)，導(dǎo)致所有的正確的數(shù)據(jù)亂碼。所以，需要確認(rèn)這個update導(dǎo)入的數(shù)據(jù)源是否正確，即load出來的數(shù)據(jù)是否是正確的。

2>     導(dǎo)入數(shù)據(jù)源確認(rèn)

開啟實(shí)例的全日志開關(guān)，然后比對日志，從上面update語句對應(yīng)的連接運(yùn)行的sql中查找數(shù)據(jù)導(dǎo)出語句，以及對應(yīng)的字符集設(shè)置。

從上面的日志內(nèi)容可以看出，這個連接建立后沒有進(jìn)行任何字符集的設(shè)置，直接從數(shù)據(jù)庫中將內(nèi)容select出來。在mysql中，如果沒有設(shè)置session級別的字符集，那么使用默認(rèn)的配置，配置如下：

即輸出會按照latin1的格式顯示。在默認(rèn)字符集的配置下，手動運(yùn)行SELECT `main_table`.* FROM `promo_item` AS `main_table` WHERE  promo_item_id ='500186324' 命令，可以發(fā)現(xiàn)，在character_set_results 設(shè)置為latin1的情況下，輸出結(jié)果中的item_title確實(shí)為一堆問號。

由于latin1不能正確表示中文字符，所以顯示為一堆問號，用戶直接將這個內(nèi)容update 原來正確的內(nèi)容，所以導(dǎo)致存儲內(nèi)容亂碼。

（3）小結(jié)

在使用mysql存儲中文字符時，需要注意以下幾點(diǎn)：

1>     確認(rèn)更新的數(shù)據(jù)源同mysql 的session級別的字符集保持一致，Session級別的字符集可以用set names charset_name來設(shè)置。

2>     如果要正確顯示中文，需要將character_set_results設(shè)置為GBK或是utf8。同時，客戶端的顯示字符集需要跟character_set_results的配置一致。

最新評論