1. 背景
很多MySQL DBA搞不清楚MySQL中utf8字符集与utf8mb4的区别，部分人有模糊认识，认为现在应该使用utf8mb4，而不应该使用utf8字符集，但是具体是为什么，说不清楚，本文把这个问题解释清楚。
2. MySQL中的utf8字符集核utf8mb4字符集
MySQL在5.5版本之前，虽然实现了utf8字符集，但是此utf8字符集并不是完整的utf8字符集，而是只能存储UNICODE中基本多文种平面(BMP)中的字符，即65536个字符，即早些UNICODE中用2字节编码的字符。而不在这个范围内字符则不能存储。UNICODE中用2字节编码的字符用UTF-8来编码，则需要1~3个字符。utf8是一种变长编码，理论上是1~6个字节来表示4字节的UNICODE编码的字符。我们知道英文在UTF-8中是用1个字节来表示，欧洲的一些字符用2个字节来表示，而在UTF-8中绝大多数汉字是用3个字节来表示，但一些生僻汉字或表情符号是使用4个字节来表示的。
所以在MySQL中的utf8字符集只能表示1~3字节长的utf8字符，而不能表示4字节长的utf8字符。
这里解释一下基本多文种平面，BMP(Basic Multilingual Plane)，或称第零平面(Plane 0)，是Unicode中的一个编码区段。编码从U+0000至U+FFFF。
除了基本多文种平面，还有其它平面：
Plane | 范围 | 名称 |
Plane 0 | U+0000 ~ U+FFFF | 基本多文种平面（Basic Multilingual Plane, BMP） |
Plane 1 | U+10000 ~ U+1FFFF | 多文种补充平面（Supplementary Multilingual Plane, SMP） |
Plane 2 | U+20000 ~ U+2FFFF | 表意文字补充平面（Supplementary Ideographic Plane, SIP） |
Plane 3 | U+30000 ~ U+3FFFF | 表意文字第三平面（Tertiary Ideographic Plane, TIP） |
Plane 4 ~ 13 | U+40000 ~ U+4FFFF | 未使用（unassigned） |
Plane 14 | U+E0000 ~ U+EFFFF | 特别用途补充平面（Supplementary Special-purpose Plane, SSP） |
Plane 15 ~ 16 | U+F0000 ~ U+10FFFF | 保留作为私人使用区（Private Use Area, PUA） |
所以在MySQL中utf8字符集时，发现一些需要用4个字节表示的utf-8的字符，如一些生僻字无法插入到MySQL中，为了解决这个问题，MySQL在5.5.3之后增加了utf8mb4 字符编码，mb4即 most bytes 4，简单说MySQL中utf8mb4是utf8的超集并完全兼容utf8，能够用四个字节存储更多的字符。所以从这里可以知道原先 MySQL中的utf8字符集实际上是utf8mb3，即只能存最多3个字节的utf8字符。了解的utf8编码的同学可能知道utf8编码理论的长度是1~6字节，那么来一个5字节的utf8字符怎么办？从目前的情况看，全世界当前的的字符用4个字节的utf-8编码都可以容纳，还没有5个字节的utf8字符。当然未来，如果有5个字节的utf8字符出现时，MySQL的编码从utf8mb4再扩展成utf8mb5，这看着有点傻。还不如象Oracle、PostgreSQL等数据库一样，自动适应1~6个字节的utf8编码，多好？但没有办法，MySQL目前的实现就是这样。
3. 生僻字的例子：
如宋末元初官员、书法家、画家、诗人赵孟，字念“俯”，这个字就是生僻字：
我们在utf8字符集的表执行下面的SQL语句：
CREATE TABLE `test01` ( `id` int(11) DEFAULT NULL, `t` varchar(30) COLLATE utf8_bin DEFAULT NULL) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;insert into test01 values(1, '赵孟');
在MySQL的命令行中，这个字转换成一个UNICODE的值了，并报错了：
root@localhost : db01 03:35:39> insert into test01 values(1, '赵孟\U+2B5AF');ERROR 1366 (HY000): Incorrect string value: '\xF0\xAB\x96\xAF' for column 't' at row 1Warning (Code 1300): Invalid utf8 character string: 'F0AB96'Error (Code 1366): Incorrect string value: '\xF0\xAB\x96\xAF' for column 't' at row 1
如果把表的字符集改成utf8mb4，排序规则为COLLATE=utf8mb4_unicode_ci：
CREATE TABLE `test01` ( `id` int(11) DEFAULT NULL, `t` varchar(30) COLLATE utf8_bin DEFAULT NULL) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
这时再插入就没有问题了：
root@localhost : db01 04:07:36> insert into test01 values(1, '赵孟\U+2B5AF');Query OK, 1 row affected (0.02 sec)root@localhost : db01 04:08:00> select * from test01;+------+------------+| id | t |+------+------------+| 1 | 赵孟 |+------+------------+1 row in set (0.00 sec)
4. 一些注意事项
可以看：
- mysql使用utf8mb4经验吐血总结
datax使用中的一些问题，需要在jdbc的url中添加：jdbc:mysql://ip:3306/testabc?
com.mysql.jdbc.faultInjection.serverCharsetIndex=45
具体见：
DataX:导入4字节UTF8编码（生僻字）到Mysql数据库的utf8mb4数据表
5. 总结
为了避免后续插入不了一些生僻字，在建库时就应该把默认字符集设置为utf8mb4，my.cnf的配置应该为：
[client]loose_default-character-set = utf8mb4......[mysqldump]default-character-set = utf8mb4......[mysql]default-character-set = utf8mb4......[mysqld]character-set-server=utf8mb4collation_server = utf8mb4_unicode_ci......
注意MySQL中的默认的utf8字符集实际上是utf8mb3，而不是完整的utf8，这个问题目前只在MySQL数据库中存在，PostgreSQL和Oracle是没有这个问题的，PostgreSQL数据库默认就是utf8字符集，是可以插入这些生僻字的，是没有问题的。这个问题主要是MySQL在设计之初不够严谨导致的。