MySQL存儲數據亂碼的成績解析。本站提示廣大學習愛好者：（MySQL存儲數據亂碼的成績解析）文章只能為提供參考，不一定能成為您想要的結果。以下是MySQL存儲數據亂碼的成績解析正文
mysql的字符集設置有多個層級，在mysql中存儲中文，假如不克不及准確設置字符集，很輕易湧現數據亂碼。明天就有一個用戶反應他數據庫中的數據下晝1點多開端湧現了亂碼。在這裡，我分享下詳細成績的排查進程，和處理的方法。
（1） 消除客戶端設置招致的顯示亂碼
假如用戶設置的mysql character_set_client跟客戶端顯示的字符集紛歧致，很輕易招致中文數據亂碼。
設置session字符集為utf8：set names utf8，設置客戶端顯示字符集為utf8，然後從表中select出有亂碼的數據。
下面顯示，在character_set_client跟客戶真個字符集分歧的情形下，照樣湧現了亂碼，這個消除是用戶顯示字符集設置纰謬的能夠。上面經由過程hex(item_title)列來檢查這個列在底層的存儲字符集能否准確。
經由過程下面的查詢，可以確認這個數據亂碼不是顯示成績，而是存儲的數據內容自己就是毛病的。
（2） 定位存儲亂碼緣由
1> 用戶確認這個記載拔出時可以或許正常顯示，然則後來update以後，數據就亂碼了。依據這個信息到binlog中查找更糾正確內容對應的update語句。
下面的binlog日記顯示這個sql將本來數據庫中准確的內容，更新成一堆亂碼。所以招致數據庫中的存儲數據亂碼。
從binlog日記可以看出在更新時，是用latin1的方法寫入到數據庫中。Update前面的set語句中item_title字段的內容是亂碼的，所以確認是導入數據源自己內容有成績，從而招致更新後的數據亂碼。跟用戶確認這個update語句的更新內容，是先從庫中load 出來，後拼接成的update sql，所以疑惑load出來的數據就曾經是亂碼了，然後直接用這個毛病的數據更新本來准確的數據，招致一切的准確的數據亂碼。所以，須要確認這個update導入的數據源能否准確，即load出來的數據能否是准確的。
2> 導入數據源確認
開啟實例的全日記開關，然後比對日記，從下面update語句對應的銜接運轉的sql中查找數據導出語句，和對應的字符集設置。
從下面的日記內容可以看出，這個銜接樹立後沒有停止任何字符集的設置，直接從數據庫中將內容select出來。在mysql中，假如沒有設置session級其余字符集，那末應用默許的設置裝備擺設，設置裝備擺設以下：
即輸入會依照latin1的格局顯示。在默許字符集的設置裝備擺設下，手動運轉SELECT `main_table`.* FROM `promo_item` AS `main_table` WHERE promo_item_id ='500186324' 敕令，可以發明，在character_set_results 設置為latin1的情形下，輸入成果中的item_title確切為一堆問號。
因為latin1不克不及准確表現中文字符，所以顯示為一堆問號，用戶直接將這個內容update 本來准確的內容，所以招致存儲內容亂碼。
（3）小結
在應用mysql存儲中文字符時，須要留意以下幾點：
1> 確認更新的數據源同mysql 的session級其余字符集堅持分歧，Session級其余字符集可以用set names charset_name來設置。
2> 假如要准確顯示中文，須要將character_set_results設置為GBK或是utf8。同時，客戶真個顯示字符集須要跟character_set_results的設置裝備擺設分歧。
