故事這樣發生的，那是一個中午。。。。

老板：小a呀，咱測試項目部署在百度雲服務器上，測試數據庫部署在阿裏雲上，為了節省點流量，你把阿裏雲上的測試數據庫遷移到百度雲上吧。

小a : 好的，老板。

小a登陸測試服務器一看，咦？竟然有mysql的服務在跑，試著登陸了一下，密碼不對，於是他仔細想了想，好像並沒有任何項目用到這個數據庫，這。。。是什麽情況，難道是centos自帶的嗎

於是小a去問了度娘，還真的有centos自帶mysql這一說，為了減少數據庫版本不一致可能會導致的麻煩，小a果斷卸載了原本的數據庫，裝上了和要遷移的數據庫版本相同的mysql，數據遷移整體還算順利（除了小a腦子抽筋，不知道看的哪個教程把mysql的data目錄的權限變成了root,導致mysql服務一直啟動不了，當然最後使用chown mysql:mysql /var/lib/msyql 還是順利的解決了問題），

正當小a美滋滋的時候，安卓同事告訴他，mantis不能訪問了，報的錯誤是數據庫連接失敗，當小a確定了mantis是裝在測試服務器上的時候，瞬間小a整個人的上半身都被汗水打濕了，這個bug追蹤系統可是花費了測試人員和老板大量的心血，上面提交記錄了n多bug，自己刪了mantis,開發人員對自己會感激不盡，但是老板絕對會吃了自己的，一想到有可能自己刪的數據庫就是mantis使用的mysql，小a只想說一句 WTFK,沒辦法，庫已經刪了，準備準備跑路吧。。。。。。不過作為一個有道德，有，有，有的四有青年，小a還是沒有輕言放棄，小a心想：我只是卸載了mysql，並沒有刪除相應的數據a,數據庫再高端，你也得存在磁盤上吧，我找到磁盤上mantis對應的數據庫文件，說不定還能恢復，於是在經過了一番努力之後，小a真的在原數據庫的data目錄下找到了一個mantis文件夾，哈哈哈，把他拷貝到當前mysql對用的數據目錄，再把mantis的配置文件中的數據庫userName和password改成當前數據庫對應的,bingo，沒毛病。

問題解決了，終於不用跑路了，但是。。。。

正當小a松了一口氣的時候，老板過來了，小a呀，我們的篩選突然出了點問題，中文篩選怎麽都返回空

小a心裏頓時又緊張起來了，難不成又是數據庫遷移導致的bug，憑借問題的現象以及小a的猜測，應該是編碼的問題，但是小a記得很清楚自己建立數據庫用的是萬能的utf-8啊，這是怎麽回事呢。。

小a按照正常解決bug的思路，本地模擬請求，打印出bug,直接面向數據庫執行sql，天，竟然沒問題，，，，沒跑了，一定是編碼的問題了。。。但是問題出在哪兒呢？？

小a心想，我肯定數據庫的編碼是沒有問題的，難道是mysql也有默認的編碼？

於是小a趕緊看了之前服務器的mysql和新安裝的mysql配置文件的差別，果然，少了一個默認編碼的配置，果斷加上，，，，終於是搞定了，，，

啦啦啦啦啦啦。。。。。

記一次差點刪庫跑路的事故