mysql中文亂碼問題一直每次遷移一次數據庫就要從頭解決一遍，因為數據庫建好以后就不會怎么動了，一直沒當回事兒，反正就麻煩一次嗎。最近服務器遇到了點問題，重裝了幾次，結果每次都要重新配置這個問題，索性就總結一下。
首先中文亂碼的根本問題就是編碼問題：我們把中文輸入到數據庫中再從數據庫中取出來顯式在瀏覽器上分為幾個過程，這些過程中要求每一個處理過程的編碼都是要支持中文的，而且如果前后兩個過程如果編碼方式不一樣的話，必須要有轉碼的手段。比如說你用gbk的編碼方式在本地寫好了一段中文，或者說是.sql腳本，上傳服務器后執行，如果你的mysql默認以utf8的編碼讀取你的sql語句的話，那么中文就是亂碼了。（沒有測試過，說不准gbk和utf8是兼容的或者是mysql默認會通過unicode轉碼。不過大致就是這個意思）。可以想象如果所有的過程之間都要檢查編碼問題是非常繁瑣的，所以最好的解決方案，就是選擇一種編碼，然后在所有的過程中都使用這種編碼，這樣就不用擔心編碼轉換問題了。
然后說一下mysql中關於編碼的規則，mysql中對每個數據庫，每個數據庫中的每個表，每個表中的每個字段都有關於編碼的設置變量，（記得好像是可以在mysql中用sql語句：show variables like “%char%”）查到。這些變量的優先級是從小到大排列的。也就是說如果你設置一個testdb數據庫的默認編碼是latin的，那么在你新建一個表（不聲明編碼方式）以后，這個表的所有字段的編碼都是latin的，但是你可以新建一個其他編碼方式（比如說utf8）的表，做法就是在建表的時候顯式的聲明用的是什么編碼。這樣就可以再一個數據庫中同時存在latin編碼的和utf8編碼方式的表了。同樣的規則也可以應用在表和表中的字段上。
最開始就是這里耽誤了很長時間，因為自己明明已經把數據庫的編碼方式改為utf8的了，但還是顯示亂碼，一直以為是哪里編碼不統一，檢查了好幾遍。問題是因為這個表是在修改數據庫默認編碼之前建立的，所以這個表的默認編碼還是latin的，同樣這個表中的字段也是默認為latin的。所以除了需要修改數據庫的默認編碼以外還需要修改表的默認編碼，然后還需要修改字段的默認編碼。當然如果你的數據庫中只有一個表是需要中文的，那么你只要在建立表的時候修改它的默認編碼就好了。但是如果你先建立的這個表再去修改表的默認編碼是沒有用的，因為表中的字段的編碼是根據表建立的時候所確定的。所以說對於已經建立好的表，想要修改其中字段的編碼不僅需要修改表的默認編碼，還需要修改具體字段的編碼。
這里我用phpmyadmin作為例子來說明一下對於已經建立好的表怎么讓其支持中文：
在phpmyadmin中，“默認排序方式”就是默認編碼的意思，我也不知道為什么這么說。。。
首先我們看到mysql的默認編碼是什么，關於編碼有好幾個變量，每個變量負責的功能不一樣，具體的介紹點擊那個問號就可以有mysql的官方解釋了，或者自己去查一下mysql的手冊就好了
在這種默認編碼的情況下我們新建一個數據庫test：
我們這里不選擇編碼方式也就是“排序規則”
然后新建一個表：
同樣也不選擇編碼方式
然后插入一條有中文的記錄：
就會出現亂碼了：
原因是默認情況下name字段的編碼是這種：
我也不清楚為什么從latin1變成了cp1250_bin可能是mysql中其他的設置里有規定吧。。。。。。
我們改掉這個編碼：
再插入一條中文的記錄：
可以看到解決了。
現在我們換個思路：改掉test數據庫的默認編碼：
重新建立一個表testtable2：
可以看到這個testtable2的編碼已經變成utf8的了。
同樣插入一條中文記錄，可以看到問題也解決了：
總結一下吧：雖然現在很多數據庫管理工具都可以支持邊開發，邊修改數據庫。但是在新建數據庫的時候還是應該大致思考一下數據庫的性質，表之間的依賴關系等等。否則以調試程序的方式來調試數據庫效率太低。