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字符等等。

如果要在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 會有區分；

比如下面這個查詢：

# 假設數據庫中SC_Teacher表存在一條數據，其中TeacherName字段的值為 "A"

select * from SC_Teacher where TeacherName = 'a'

-- 如果數據庫使用的是utf8_general_ci排序規則, 下面的查詢是可以查詢到這條數據

-- 如果數據庫使用的是utf8_general_cs排序規則, 下面的查詢是查詢不到這條數據

正因為這個性質，導致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，因為它比較準確。

簡短總結

utf8_unicode_ci和utf8_general_ci對中、英文來說沒有實質的差別。

utf8_general_ci校對速度快，但準確度稍差。

utf8_unicode_ci準確度高，但校對速度稍慢。

如果你的應用有德語、法語或者俄語，請一定使用utf8_unicode_ci。一般用utf8_general_ci就夠了，到現在也沒發現問題。

總結

以上是生活随笔為你收集整理的mysql默认字符集和排序_MySQL字符集和排序规则的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。