可以簡單的理解 utf8mb4 是目前最大的一個字元編碼, 支援任意文字.
為什麼會有 UTF8MB4？
既然 utf8 應付日常使用完全沒有問題，那為什麼還要使用 utf8mb4 呢? 低版本的 MySQL 支援的 utf8 編碼，最大字元長度為 3 位元組，如果遇到 4 位元組的字元就會出現錯誤了。三個位元組的 UTF-8 最大能編碼的 Unicode 字元是 0xFFFF，也就是 Unicode 中的基本多文平面（BMP）。也就是説，任何不在基本多文平面的 Unicode 字元，都無法使用 MySQL 原有的 utf8 字符集儲存。這些不在 BMP 中的字元包括哪些呢？最常見的就是 Emoji 表情（Emoji 是一種特殊的 Unicode 編碼，常見於 ios 和 android 手機上），和一些不常用的漢字，以及任何新增的 Unicode 字元等等。
UTF-8 編碼
理論上將， UTF-8 格式使用一至六個位元組，最大能編碼 31 位字元。最新的 UTF-8 規範只使用一到四個位元組，最大能編碼 21 位，正好能夠表示所有的 17 個 Unicode 平面。關於 UTF 編碼，請閲讀《常見編碼總結》一文。
而 utf8 則是 Mysql 早期版本中支援的一種字符集，只支援最長三個位元組的 UTF-8 字元，也就是 Unicode 中的基本多文字平面。這可能是因為在 MySQL 釋出初期，基本多文種平面之外的字元確實很少用到。而在 MySQL5.5.3 版本後，要在 Mysql 中儲存 4 位元組長度的 UTF-8 字元，就可以使用 utf8mb4 字符集了。例如可以用 utf8mb4 字元編碼直接儲存 emoj 表情，而不是存表情的替換字元。
為了獲取更好的相容性，應該總是使用 utf8mb4 而非 utf8，事實上，最新版的 phpmyadmin 預設字符集就是 utf8mb4 。誠然，對於 CHAR 型別資料，使用 utf8mb4 儲存會多消耗一些空間。
那麼 utf8mb4 比 utf8 多了什麼的呢?
多了 emoji 編碼支援.
如果實際用途上來看, 可以給要用到 emoji 的庫或者説表, 設定 utf8mb4.
比如評論, 文章什麼的要支援 emoji 可以用到.
建議普通表使用 utf8 如果這個表需要支援 emoji 就使用 utf8mb4
新建 mysql 庫或者表的時候還有一個排序規則
utf8_unicode_ci 比較準確，utf8_general_ci 速度比較快。通常情況下 utf8_general_ci 的準確性就夠我們用的了，在我看過很多程式原始碼後，發現它們大多數也用的是 utf8_general_ci，所以新建資料 庫時一般選用 utf8_general_ci 就可以了
如果是 utf8mb4 那麼對應的就是 utf8mb4_general_ci utf8mb4_unicode_ci
