要在 Mysql 中保存 4 字节长度的 UTF-8 字符，需要使用 utf8mb4 字符集（mb4就是most bytes 4的意思，专门用来兼容四字节的unicode），但只有 5.5.3 版本以后的才支持。
为了获取更好的兼容性，应该总是使用 utf8mb4 而非 utf8. 对于 CHAR 类型数据，utf8mb4 会多消耗一些空间，根据 Mysql 官方建议，使用 VARCHAR 替代 CHAR。其实，utf8mb4是utf8的超集，理论上原来使用utf8，然后将字符集修改为utf8mb4，也会不会对已有的utf8编码读取产生任何问题。当然，为了节省空间一般情况下使用utf8也就够了！转换是否有影响
MySQL 可以设置数据库级别，表级别，列级别 字符集编码
优先级顺序为：
数据库字符集<表字符集<列字符集
也就是 上面三个级别 字符集不一致时，以 更小范围的配置 为准；
例如：数据库字符集为utf8，表字符集不设置的情况下会默认utf8。如果表主动设置了编码 utf8mb4，那么表的字符集编码就为utf8mb4。
MySQL数据库的"utf8"并不是真正概念里的UTF-8
转载链接
MySQL中的“utf8”编码只支持最大3字节每字符。真正的大家正在使用的UTF-8编码是应该能支持4字节每个字符。
MySQL的开发者没有修复这个bug。他们在2010年增加了一个变通的方法：一个新的字符集“utf8mb4”
当然，他们并没有对外公布(可能因为这个bug有点尴尬)。现在很多指南推荐用户使用“utf8”其实都错了！
简单的说:
MySQL中的 “utf8mb4” 才是 真正意义上的“UTF-8”。
MySQL的utf8是个“特殊的字符编码”。这种编码很多Unicode字符保存不了。
建议MySQL和MariaDB用户使用“utf8mb4”而不是“utf8”。
编码是什么？什么是UTF-8？
计算机使用0和1存储文字。比如第一段第一个字符存储为“01000011”表示“C”，计算机通过以下两个步骤选择用“C”表示：
计算机读取到“01000011”后计算出这是数字67。
计算机通过查找Unicode字符集来确认67代表的“C”。
同样的事情发生在我打字输入C的时候。
计算机通过Unicode字符集将“C” 映射为67。
计算机把67编码为“01000011”发送给web服务器。
几乎所有的程序和互联网应用使用Unicode字符集。
Unicode字符集里有超过100万个字符(“C” 和 “?” 是两种不同的字符)。UTF-32是最简单的编码方式，它在表示每个字符的时候使用32个bits。这样编码简单，但是并不实用，明显浪费了太多的空间。
UTF-8相比UTF-32更加节约空间。在UTF-8中，像“C”这样的字符占用8bits，“?”这样的占用32 bits。其他字符占用16或者24 bits。用UTF-8存储比用UTF-32节省4倍左右的空间。更小的空间占用也意味着加载速度会快上4倍。
而MySQL中的 “utf8”字符集则和其他应用行为不一样。比如根本没法表示“?”。
MySQL从4.1版开始支持UTF-8。那是在比今天UTF-8 RFC 3629标准更早的2003年。
在此之前的UTF-8标准,RFC 2279中规定6个bytes表示一个字符。MySQL的开发者在2002.3.28编码实现了RFC 2279 。并发布了pre-pre-release 的 MySQL 4.1，然后在9月出现了一个神秘的字节调整。“UTF8 now works with up to3 byte sequences only.”
回到2002年，如果用户可以保证表中的每一行具有相同的字节数，MySQL就可以提高用户的速度。为了得到这个提升，用户就需要定义保存文字的列为“CHAR”。一个“CHAR”列总是拥有相同的字符数。如果存入的字符较少则会在最后补齐空白。如果存入的数据过多则会被抛弃多余的字符。
当MySQL的开发者第一次尝试以6字节每字符实现UTF-8时，他们意识到CHAR(1)的列会占用6字节，CHAR(2)会占用12字节，以此类推。
显而易见的是，这个没有被使用的实现方式是正确的，任何一个理解UTF-8的开发者将会认同这一点。
我的猜测是：MySQL的开发者违背了“utf8”编码去帮助那些1)试图去优化空间和速度的人，2)尝试优化空间和速度失败的人。
这是个无人获益的改动。那些想要更快性能，更小空间的得到的依然是比他们曾经使用版本更大更慢的实现，而那些想要正确的“utf8”的人得到的是个“?”都存储不了的实现。
MySQL发布了这个错误的版本后，在也没有修复它：因为那样很多使用者将被迫重建他们的数据库。MySQL最终在2010年更新了一个以“utf8mb4”命名的UTF-8实现。
如果你使用MySQL或者 MariaDB,不要使用“utf8”，应该总是使用“utf8mb4”，否则总有一天会遇到头疼的事情。
字节和字符
varchar(255)所表示的单位是字符，而一个汉字一个字母都是一字符。所以这里可以存储255个汉字或者255个字母。
utf-8下 1字符=3字节。 （uft-8也称之为utf-8mb3）
utf-8mb4下 1字符=4字节。
存储上限
varchar的存储上限是65535字节
utf-8 varchar(21845)是上限(65535/3)
utf-8mb4 varchar(16383)是上限(65535/4)
表情??
一个表情是占用4个字节，所以utf-8下，表情会乱码，1字符装不下，需要额外的空间。
utf-8mb4下，一个表情正好是一字符，能够完美显示。
varchar(255) 即表示能存放255个汉字，或255个字母，或255个表情。
为什么要使用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的准确性就够我们用的了。
如果是utf8mb4那么对应的就是 utf8mb4_general_ci utf8mb4_unicode_ci
索引长度限制
1、对于 myisam 引擎, utf8mb4字符的字段, 允许单索引字段的最大字节为1000, 即最大允许 1000/4=250 个字符, varchar(255)。
2、对于 innodb 引擎, utf8mb4字符的字段, 允许单索引字段的最大字节为765, 即最大允许 765/4=191 个字符, varchar(191)。
如果有启用 innodb_large_prefix 选项，设置 mysql innodb_large_prefix=on, 可将允许索引字段的最大字节约束项扩展至 3072 字节, 即最大允许 3072/4=768个字符, varchar(768)。具体可查阅《mysql 索引长度限制》
You must be more handsome when you work hard!