可以简单的理解 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
