程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> MYSQL數據庫 >> MySQL綜合教程 >> MySQL存儲數據亂碼的問題解析,mysql存儲亂碼解析

MySQL存儲數據亂碼的問題解析,mysql存儲亂碼解析

編輯:MySQL綜合教程

MySQL存儲數據亂碼的問題解析,mysql存儲亂碼解析


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

(1)  排除客戶端設置導致的顯示亂碼

如果用戶設置的mysql character_set_client跟客戶端顯示的字符集不一致,很容易導致中文數據亂碼。

設置session字符集為utf8:set names utf8,設置客戶端顯示字符集為utf8,然後從表中select出有亂碼的數據。

201557105216605.jpg (821×583)

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

201557105249811.jpg (811×149)

通過上面的查詢,可以確認這個數據亂碼不是顯示問題,而是存儲的數據內容本身就是錯誤的。

(2)  定位存儲亂碼原因

1>     用戶確認這個記錄插入時能夠正常顯示,但是後來update之後,數據就亂碼了。根據這個信息到binlog中查找更改正確內容對應的update語句。

201557105315821.jpg (792×244)

201557105339521.jpg (737×771)

上面的binlog日志顯示這個sql將原來數據庫中正確的內容,更新成一堆亂碼。所以導致數據庫中的存儲數據亂碼。

從binlog日志可以看出在更新時,是用latin1的方式寫入到數據庫中。Update後面的set語句中item_title字段的內容是亂碼的,所以確認是導入數據源本身內容有問題,從而導致更新後的數據亂碼。跟用戶確認這個update語句的更新內容,是先從庫中load 出來,後拼接成的update sql,所以懷疑load出來的數據就已經是亂碼了,然後直接用這個錯誤的數據更新原來正確的數據,導致所有的正確的數據亂碼。所以,需要確認這個update導入的數據源是否正確,即load出來的數據是否是正確的。

2>     導入數據源確認

開啟實例的全日志開關,然後比對日志,從上面update語句對應的連接運行的sql中查找數據導出語句,以及對應的字符集設置。

201557105423659.jpg (810×324)

從上面的日志內容可以看出,這個連接建立後沒有進行任何字符集的設置,直接從數據庫中將內容select出來。在mysql中,如果沒有設置session級別的字符集,那麼使用默認的配置,配置如下:

201557105448774.jpg (816×323)

即輸出會按照latin1的格式顯示。在默認字符集的配置下,手動運行SELECT `main_table`.* FROM `promo_item` AS `main_table` WHERE  promo_item_id ='500186324' 命令,可以發現,在character_set_results 設置為latin1的情況下,輸出結果中的item_title確實為一堆問號。

201557105513089.jpg (794×572)

由於latin1不能正確表示中文字符,所以顯示為一堆問號,用戶直接將這個內容update 原來正確的內容,所以導致存儲內容亂碼。

(3)小結

在使用mysql存儲中文字符時,需要注意以下幾點:

1>     確認更新的數據源同mysql 的session級別的字符集保持一致,Session級別的字符集可以用set names charset_name來設置。

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

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved