MySQL在創建數據庫時，需要設置數據庫的字符集和排序規則，如圖所示：
我覺得這裡有必要解釋下字符集和排序規則這兩個概念。
字符集
說到字符集，需要先提下字符、字符集和字符編碼這幾個詞的含義。
- 字符(Character)是各種文字和符號的總稱，包括各國家文字、標點符號、圖形符號、數字等。
- 字符集(Character set)是多個字符的集合，字符集種類較多，每個字符集包含的字符個數不同，常見字符集名稱：ASCII字符集、GB2312字符集、BIG5字符集、 GB18030字符集、Unicode字符集等。
- 字符編碼是把字符集中的字符編碼為特定的二進制數，以便在計算機中存儲。編碼方式一般就是對二維表的橫縱座標進行變換的算法。一般都比較簡單，直接把橫縱座標拼一起就完事了。後來隨著字符集的不斷擴大，為了節省存儲空間，才出現了各種各樣的算法。
字符集和字符編碼一般都是成對出現的，如ASCII、IOS-8859-1、GB2312、GBK，都是即表示了字符集又表示了對應的字符編碼，以後統稱為編碼。Unicode比較特殊，後面細說。
在MySQL中需要注意的utf8和utf8mb4這兩種字符集的區別，utf-8編碼格式我們經常會碰到，但是這裡的utf8卻不是指utf-8這種編碼格式，那麼又為啥會出現utf8mb4這種字符集呢？
據說MySQL一開始沒有utf8mb4這個字符集，因為utf8只支持每個字符最多三個字節，而真正的UTF-8是每個字符最多四個字節，這就造成UTF-8編碼下的一些字符無法保存到數據庫中，為了修復這個bug而出現了utf8mb4這種字符集。
三個字節的UTF-8最大能編碼的Unicode字符是0xFFFF，也就是Unicode中的基本多文平面（BMP）。也就是說，任何不在基本多文平面的Unicode字符，都無法使用MySQL原有的utf8字符集存儲。這些不在BMP中的字符包括哪些呢？最常見的就是Emoji表情（Emoji是一種特殊的Unicode編碼，常見於ios和android手機上），和一些不常用的漢字，以及任何新增的Unicode字符等等。
轉載處:https://www.jianshu.com/p/f90...
如果要在MySQL中保存4字節長度的UTF-8字符，就需要使用utf8mb4編碼，但是要注意只有5.5.3版本以後的MySQL才支持（查看版本命令： select version()）。為了獲取更好的兼容性，建議使用utf8mb4而非utf8. 對於CHAR類型數據，utf8mb4會多消耗一些空間，但根據 MySQL官方建議，可以使用VARCHAR替代CHAR。
擴展：char是一種固定長度的類型，varchar則是一種可變長度的類型（因為char長度固定，方便程序的存儲與查找，所以char類型存取速度優於varchar，即以空間換效率）
排序規則
MySQL中常用的排序規則(這裡以utf8字符集為例)主要有：utf8_general_ci、utf8_general_cs、utf8_unicode_ci等。
這裡需要注意下ci和cs的區別:
- ci的完整英文是'Case Insensitive', 即“大小寫不敏感”，a和A會在字符判斷中會被當做一樣的;
- cs的完整英文是‘Case Sensitive’，即“大小寫敏感”，a 和 A 會有區分；
比如下面這個查詢：
<code># 假設數據庫中SC_Teacher表存在一條數據，其中TeacherName字段的值為 "A"
select * from SC_Teacher where TeacherName = 'a'
-- 如果數據庫使用的是utf8_general_ci排序規則, 下面的查詢是可以查詢到這條數據
-- 如果數據庫使用的是utf8_general_cs排序規則, 下面的查詢是查詢不到這條數據
/<code>
正因為這個性質，導致utf8_general_ci的查詢速度比utf8_general_cs快，(純屬個人推測，沒有實際依據)
- utf8_general_ci： 查詢時不區分大小寫匹配
- utf8_general_cs： 查詢時區分大小寫匹配
- utf8_bin： 字符串每個字符串用二進制數據編譯存儲。 區分大小寫，而且可以存二進制的內容，與utf8_general_cs一樣，區分大小寫
- utf8_unicode_ci ： 和utf8_general_ci一樣，不區分大小寫
當前utf8_general_ci校對規則僅部分支持Unicode校對規則算法。一些字符還是不能支持。並且，不能完全支持組合的記號。這主要影響越南和俄羅斯的一些少數民族語言，如：Udmurt、Tatar、Bashkir和Mari。
utf8_general_ci的最主要的特色是支持擴展，即當把一個字母看作與其它字母組合相等時。例如，在德語和一些其它語言中‘ß’等於‘ss’。
utf8_general_ci是一個遺留的校對規則，不支持擴展。它僅能夠在字符之間進行逐個比較。這意味著utf8_general_ci校對規則進行的比較速度很快，但是與使用utf8_general_ci的校對規則相比，比較正確性較差）。
例如，使用utf8_general_ci和utf8_unicode_ci兩種 校對規則下面的比較相等：
Ä = A Ö = O Ü = U
兩種校對規則之間的區別是，對於utf8_general_ci下面的等式成立：
ß = s
但是，對於utf8_unicode_ci下面等式成立：
ß = ss
對於一種語言僅當使用utf8_unicode_ci排序做的不好時，才執行與具體語言相關的utf8字符集 校對規則。例如，對於德語和法語，utf8_unicode_ci工作的很好，因此不再需要為這兩種語言創建特殊的utf8校對規則。
utf8_general_ci也適用與德語和法語，除了‘ß’等於‘s’，而不是‘ss’之外。如果你的應用能夠接受這些，那麼應該使用utf8_general_ci，因為它速度快。否則，使用utf8_unicode_ci，因為它比較準確。
轉載處:http://www.chinaz.com/program...
簡短總結
utf8_unicode_ci和utf8_general_ci對中、英文來說沒有實質的差別。utf8_general_ci校對速度快，但準確度稍差。utf8_unicode_ci準確度高，但校對速度稍慢。
如果你的應用有德語、法語或者俄語，請一定使用utf8_unicode_ci。一般用utf8_general_ci就夠了，到現在也沒發現問題。
閱讀更多 拖延症晚期 的文章
