一、導讀
我們新建mysql數據庫的時候，需要指定數據庫的字符集，一般我們都是選擇utf8這個字符集，但是還會又一個utf8mb4這個字符集，好像和utf8有聯系，今天就來解析一下這兩者的區別。
二、起源
MySQL在5.5.3之后增加了這個utf8mb4的編碼，mb4就是most bytes 4的意思，專門用來兼容四字節的unicode。好在utf8mb4是utf8的超集，除了將編碼改為utf8mb4外不需要做其他轉換。當然，為了節省空間，一般情況下使用utf8也就夠了。
可以簡單的理解 utf8mb4 是目前最大的一個字符編碼,支持任意文字。
三、為什么mysql有utf8和utf8mb4兩種幾乎差不多的字符集
utf8 是 Mysql 中的一種字符集，只支持最長三個字節的 UTF-8字符，也就是 Unicode 中的基本多文本平面。
Mysql 中的 utf8 為什么只支持持最長三個字節的 UTF-8字符呢？我想了一下，可能是因為 Mysql 剛開始開發那會，Unicode 還沒有輔助平面這一說呢。那時候，Unicode 委員會還做着 “65535 個字符足夠全世界用了”的美夢。Mysql 中的字符串長度算的是字符數而非字節數，對於 CHAR 數據類型來說，需要為字符串保留足夠的長。當使用 utf8 字符集時，需要保留的長度就是 utf8 最長字符長度乘以字符串長度，所以這里理所當然的限制了 utf8 最大長度為 3，比如 CHAR(100) Mysql 會保留 300字節長度。至於后續的版本為什么不對 4 字節長度的 UTF-8 字符提供支持，我想一個是為了向后兼容性的考慮，還有就是基本多文種平面之外的字符確實很少用到。
要在 Mysql 中保存 4 字節長度的 UTF-8 字符，需要使用 utf8mb4 字符集，但只有 5.5.3 版本以后的才支持。我覺得，為了獲取更好的兼容性，應該總是使用 utf8mb4 而非 utf8. 對於 CHAR 類型數據，utf8mb4 會多消耗一些空間，根據 Mysql 官方建議，使用 VARCHAR 替代 CHAR。
四、為什么要使用utf8mb4字符集
既然utf8應付日常使用完全沒有問題，那為什么還要使用utf8mb4呢? 低版本的MySQL支持的utf8編碼，最大字符長度為 3 字節，如果遇到 4 字節的字符就會出現錯誤了。三個字節的 UTF-8 最大能編碼的 Unicode 字符是 0xFFFF，也就是 Unicode 中的基本多文平面（BMP）。也就是說，任何不在基本多文平面的 Unicode字符，都無法使用MySQL原有的 utf8 字符集存儲。這些不在BMP中的字符包括哪些呢？最常見的就是Emoji 表情（Emoji 是一種特殊的 Unicode 編碼，常見於 ios 和 android 手機上），和一些不常用的漢字，以及任何新增的 Unicode 字符等等。
那么utf8mb4比utf8多了什么的呢?
多了emoji編碼支持.
如果實際用途上來看,可以給要用到emoji的庫或者說表,設置utf8mb4.
比如評論要支持emoji可以用到。
五、新建mysql庫的排序規則
utf8_unicode_ci比較准確，utf8_general_ci速度比較快。通常情況下 utf8_general_ci的准確性就夠我們用的了，在我看過很多程序源碼后，發現它們大多數也用的是utf8_general_ci，所以新建數據 庫時一般選用utf8_general_ci就可以了
如果是utf8mb4那么對應的就是 utf8mb4_general_ci utf8mb4_unicode_ci
————————————————
版權聲明：本文為CSDN博主「fds++」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/qq_37054881/article/details/90023611