1. 乱码与报错背后：两个“utf8”的真相
先讲一个我实际踩过的坑。某次上线一个带用户昵称功能的模块，开发环境一切正常，上了生产环境没几天，运营那边就反馈说有人注册时直接报错，错误信息大致是Incorrect string value: '\xF0\x9F\x98\x80' for column 'nickname'。当时第一反应是校验没做好，传了非法字符，后来查了才知道，用户只是输入了一个emoji表情。这个表情本身合法，问题出在数据库。
那个项目用的数据库连接串、建表语句里写的都是“utf8”，看着没毛病，但MySQL里有个历史包袱：它自己定义的“utf8”根本不是完整的UTF-8，最多只支持3个字节的字符。而像emoji这种绝大多数是4字节编码，比如\xF0\x9F\x98\x80对应的就是😀，一旦落到utf8字段里，必然报错。
所以这个标题说的“为什么必须用utf8mb4”，本质上是说：如果你在MySQL里写“utf8”，你用的其实是“utf8mb3”，一个残缺的字符集。只有utf8mb4才是完整支持Unicode的版本，能覆盖所有字符，包括emoji、生僻字、特殊符号。
这个知识点适合谁？适合所有用MySQL做存储的开发者，不管是刚入门写CRUD的新手，还是负责老系统维护的工程师。理解它不需要很深的基础，但不知道它，早晚会在某个奇怪的字符上报错。这篇就把原理、参数选择、迁移步骤和排查技巧一次说清楚。
2. 从utf8到utf8mb4：到底改了什么
2.1 历史包袱：为什么MySQL的utf8不完整
早期的MySQL版本在定义字符集时，utf8对应的实现是utf8mb3，它最大支持3字节。而Unicode标准的UTF-8编码实际是变长的，从1字节到4字节都有，4字节部分恰好覆盖了emoji（U+1F000到U+1FAFF区域）以及一些CJK扩展B区生僻字。MySQL官方后来意识到这个命名有歧义，但为了兼容性，不能把既有utf8的行为直接改掉，于是补充了utf8mb4。
这带来的直接后果就是：很多老项目在初始建库时顺手写了“utf8”，建表时也默认继承了这个设置，直到某天有用户输入了一个特殊字符，整个SQL报错，才会注意到问题。更麻烦的是，有些问题不是报错，而是数据被截断，写入静默丢失，排查起来更隐蔽。
另外要注意，utf8mb3其实在日常使用中覆盖了绝大多数常用中文字符，因为常用汉字都在三字节以内，所以很长一段时间“没毛病”。但“没毛病”不等于“没问题”，emoji流行、用户输入越来越多样化之后，这个隐患就集中爆发了。
2.2 三个关键概念：字符集、排序规则、连接层
搞清楚这个问题需要拆解三层。
字符集定义了一套编码规则，比如“a”对应哪个字节，“中”对应哪个字节。utf8mb4和utf8的区别就是允不允许4字节字符存在。
排序规则定义的是比较和排序的逻辑，同一个字符集可以搭配多个排序规则。对应到utf8mb4，常见的有两个：
utf8mb4_general_ci：老的默认规则，比较速度稍快，但对某些语言的处理不够精确。utf8mb4_0900_ai_ci：MySQL 8.0里的新默认规则，基于Unicode 9.0标准，对多语言排序更准确，也支持一些新的特性。0900指的是Unicode版本号。
连接层是最容易被忽略的。客户端连接MySQL时，也有自己的字符集设置。如果你的数据库是utf8mb4，但连接层指定成了latin1或者utf8mb3，那传输过程中照样可能乱码。所以规范操作是建库用utf8mb4，同时连接串里也要显式指定charset=utf8mb4，两条腿缺一不可。
这三个层面任何一环没对齐，都可能出现乱码。改字符集不是只改一个建表语句就行，要从库、表、连接、应用侧全链路排查。
2.3 为什么不是latin1，也不是别的编码
有一种常见的历史遗留场景：老系统用了latin1，数据存进去的是乱码但“看起来没丢”。这是因为latin1是单字节编码，任何字节都能映射成某个字符，所以写入不会报错，读出来就五花八门。这种转utf8mb4最痛苦，往往需要做字节层面的转换，不能简单ALTER TABLE完事。
相比之下，从utf8迁移到utf8mb4就平滑得多，因为utf8是utf8mb4的子集，新字符集覆盖了旧字符集的所有字符。所以检查一下排序规则的兼容性，直接改就行，数据基本不会损坏。
另外也有一些团队会考虑gbk或gb18030，但站在2025年的视角，没有必要再造轮子。utf8mb4是MySQL生态最通用的选择，所有工具、驱动、ORM对它的支持最完善，遇到问题也最容易搜到解决方案。字符集这种基础设施，越标准越好，不要搞特殊化。
3. 实操之前必看：两个让新手最容易懵的细节
3.1 连接串为什么要显式写utf8mb4
有位读者的老项目环境是MySQL 5.7，数据库和表都已经是utf8mb4，但通过一个老版本驱动连接之后，插入中文偶尔变成问号。查了所有表设置都没问题，最后定位到连接参数。
很多连接池或者JDBC URL默认使用的charset是继承服务端配置的，如果服务端的character_set_server没有显式指定，可能沿用默认的utf8mb3，结果就是应用认为自己在用utf8，实际上传过去的是不完整的编码。
更隐蔽的是，某些中间件或者代理层可能会把连接字符集强制重置。最典型的是早期版本的ProxySQL，它对字符集做了自己的管理，导致应用层、MySQL层都设置对了，中间层还是会兜底改掉。这种问题用普通手段查不出来，必须看实际会话的character_set_client、character_set_connection、character_set_results三个变量。
我的习惯是每次排查乱码问题，先执行这条SQL看当前会话状态：
SHOW VARIABLES LIKE 'character_set_%';重点是看三行：
- character_set_client
- character_set_connection
- character_set_results
这三个值应当都是utf8mb4。如果client和connection不一致，说明连接参数没生效；如果connection和results不一致，说明程序内部可能执行过SET NAMES或者类似操作。
3.2 排序规则的版本差异：8.0和5.7不一样
MySQL 5.7时代，utf8mb4的默认排序规则是utf8mb4_general_ci。MySQL 8.0开始，默认变成了utf8mb4_0900_ai_ci。这个差异直接影响升级之后的老表。
假如你从5.7迁移到8.0，跑的又是自动迁移工具，工具通常会保留原有的排序规则，这本身没问题。问题在于新建的表可能会用8.0的新默认规则，于是同一套库里出现两种排序规则，join的时候偶尔会报Illegal mix of collations错误。
这个错误很折磨人，因为从数据上看什么都没变，就是某些SQL语句会报错。解决办法也简单，要么统一改成utf8mb4_0900_ai_ci，要么统一保留utf8mb4_general_ci，关键是表之间要一致。
如果你的应用对大小写敏感，比如用户名登录时要严格区分大小写，可以用utf8mb4_bin。这个排序规则直接按二进制比较，不会做任何折叠，但要注意，它跟utf8mb4_general_ci在对某些字符的比较结果上不一样，改之前要评估是否影响现有查询逻辑。
实测下来，普通业务用默认的就行，操作上建议遵守一个原则：整个实例尽量只用一种排序规则。混合使用就是给自己埋坑。
4. 从建库到迁移：一份可以直接抄的实操指南
4.1 新库新表：一开始就用对
如果是全新项目，事情最简单。建库时直接指定：
CREATE DATABASE `app_db` CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;建表时也显式写上：
CREATE TABLE `user` ( `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, `nickname` VARCHAR(64) NOT NULL DEFAULT '', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;有些开发者图省事，建库时不指定，建表时也不指定，完全依赖实例默认值。这样不是不能用，但隐患在于：DBA有时会调整实例参数，或者不同环境配置不一致，生产库是utf8mb4，测试库却是utf8mb3，某些字符在测试库测试时就会漏过，一到生产才炸。显式声明在建表语句里，每个环境行为一致，成本极低，收益极大。
关于字段长度，这里有个很容易踩的坑。VARCHAR(64)这里的64是字符数而不是字节数，utf8mb4下每个字符最多占4字节，所以最大能到256字节，仍然在InnoDB的VARCHAR长度限制内。如果某个字段原来设计成VARCHAR(255)并且在utf8下用了前缀索引，改成utf8mb4后索引长度限制可能触发最大767字节的限制，旧的InnoDB版本下会报错，这种情况可以把字段缩短，或者把索引改成前缀索引idx_nick(nickname(191))。191是MySQL在旧版限制下保证utf8mb4前缀索引进索引的最大安全字符数。
4.2 存量系统迁移：三步走，不乱改
老项目改造要稳，不要一键执行。
第一步：先备份，再做一次全量字符集扫描，找出存量数据里有没有4字节字符。可以这样查：
SELECT COUNT(*) FROM `user` WHERE LENGTH(`nickname`) <> CHAR_LENGTH(`nickname`);CHAR_LENGTH返回的是字符数，LENGTH返回的是字节数。如果两者相等，说明这个字段里全是单字节字符；如果不相等，差值就是多字节字符占的额外字节数。如果字段本身存的是纯中文和字母，这个值通常不为0，因为中文本身就是3字节，但你不能用这个直接判断是否存在4字节字符。
更准确的判断方法是检查是否有4字节字符占用：
SELECT `id`, `nickname` FROM `user` WHERE `nickname` REGEXP '[\\x{10000}-\\x{10FFFF}]';用正则直接匹配Supplementary Characters区域，如果有匹配的，说明存量数据里已经有emoji或生僻字。这种字符在utf8mb3下要么存不进、要么变成了乱码，如果查出来是乱码，迁移时不要直接转换，需要先做数据清洗。
第二步：逐表执行ALTER。以用户表为例，标准写法是：
ALTER TABLE `user` DEFAULT CHARACTER SET utf8mb4, MODIFY `nickname` VARCHAR(64) CHARACTER SET utf8mb4;注意，ALTER TABLE ... DEFAULT CHARACTER SET只会改变表的默认字符集，不会自动转换已有列的字符集。必须显式MODIFY每个需要转换的字段。有些DB工具生成的ALTER语句会自动帮你补齐，但如果手动写SQL，这一步最容易漏。漏掉之后表显示是utf8mb4，实际字段还是utf8mb3，排查时极具迷惑性。
也可以用一条语句直接转表内全部字段：
ALTER TABLE `user` CONVERT TO CHARACTER SET utf8mb4;这条会同时转换表默认字符集和所有字符型字段，比手动MODIFY更安全。但要注意，它会把所有字符串类型字段全转过去，如果某些字段是二进制场景，比如存了加密串的VARBINARY，那不在影响范围内，因为它本来就不是字符集。
第三步：改连接配置。应用侧连接串加参数：
jdbc:mysql://127.0.0.1:3306/app_db?useUnicode=true&characterEncoding=utf8mb4&connectionCollation=utf8mb4_0900_ai_ci注意，Java驱动的characterEncoding有些旧版本不认“utf8mb4”这个名字，可以写characterEncoding=UTF-8。这个细节有点反直觉，但确实存在，如果你的驱动确认支持，直接写utf8mb4最准确。
4.3 迁移后的验证：怎么确认改成功了
迁移完不要只看几行数据就完事。我的验证套路是：
第一步，执行前面的SHOW VARIABLES LIKE 'character_set_%';确认三个核心变量。
第二步，抽查几列的系统表信息：
SELECT TABLE_NAME, TABLE_COLLATION, CHARACTER_SET_NAME FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = 'app_db' AND CHARACTER_SET_NAME IS NOT NULL LIMIT 100;重点看TABLE_COLLATION是不是统一了。
第三步，插入测试数据。把最有代表性的字符挨个试一遍：中文字符串、emoji、全角符号、带声调的拉丁字母。
INSERT INTO `user` (`nickname`) VALUES ('中文测试'), ('😀😃😄'), ('ＡＢＣ１２３'), -- 全角 ('ñáéíóú');这样验证比直接相信文档靠谱得多。只要你插入emoji不报错，基本就成功了一大半。
5. 连接层与服务器的排查技巧
5.1 乱码现象太多，先分清是哪一类
乱码问题看起来五花八门，其实只有三类：
第一类是插入时报错Incorrect string value。这个最直接，说明字节无法被目标字符集解码，一般是字段或表还是utf8mb3，或者连接层用了更狭窄的字符集。
第二类是插入不报错，查询出来变成???。这是数据在写入时被转成了其他字符集，某个环节把多字节字符吃掉了，查询时只能看到问号。这种情况要么是连接层latin1，要么是客户端charset设置不对，要么是中间件强制转换。
第三类是数据本身没坏，但展示乱码。SQL客户端显示乱码，应用页面显示正常或者反过来。这种通常是结果集和客户端的显示编码不匹配，比如MySQL Workbench的字体设置或者终端编码不对，数据库本身没问题。
所以排查的第一步不是改配置，而是先判断题干属于哪一类。判断方法很有效：把同一个查询放到不同客户端跑一遍，比如命令行、图形客户端、应用页面各跑一次。如果只有某一个环境乱码，那数据库大概率没问题；如果所有环境都乱码，再从数据库层开始查。
5.2 常用排查SQL速查
排查时我经常用这几条SQL，按顺序执行，基本能定住问题：
-- 看全局字符集配置 SHOW VARIABLES LIKE 'character_set_%'; SHOW VARIABLES LIKE 'collation_%'; -- 看当前连接实际使用的字符集 SELECT @@character_set_client, @@character_set_connection, @@character_set_results; -- 看某张表实际使用的情况 SHOW TABLE STATUS LIKE 'user'; -- 看某个字段实际使用的字符集 SHOW FULL COLUMNS FROM `user`;SHOW FULL COLUMNS输出的Collation列会展示每个字段的排序规则，如果看到有些字段是utf8mb4，有些是latin1，就说明建表时没有统一，需要挨个改。
5.3 那些不是字符集问题的真乱码
有一种情况特别容易误导人：字符集全部都是utf8mb4，表也建对了，连接也正常，但数据查出来还是乱码。这种往往是程序内部处理的问题。
比如后端代码里拿到了请求参数，框架层做过一次编码转换，如果框架配置的是ISO-8859-1或者GBK，即使数据库是utf8mb4，传给数据库的字节已经是坏的。这种问题靠调数据库参数没用，要在应用层检查请求编码和响应编码。
再比如跨语言协作时，Java侧字符串内部本身就是UTF-16，序列化到JSON后变成了UTF-8字节，如果另一个服务消费时误按GBK解码，再入库就是乱码。这种链条上的问题，数据库永远只是背锅侠，真正要查的是各服务之间传输时用的编码是否一致。
我自己排查这类问题的顺序是：客户端显示 → 应用代码 → 框架配置 → 数据库连接 → 表结构 → 库配置。从用户能感知的层面往前倒推，比一开始就扎进数据库效率高得多。
6. 字符集迁移时的几个隐藏雷区
6.1 大表执行ALTER很危险
如果表有几千万行，执行ALTER TABLE CONVERT TO CHARACTER SET utf8mb4会重建整张表，期间会锁表（取决于MySQL版本和在线DDL支持程度），线上业务可能会受到明显影响。
实测下来，在MySQL 5.7里，InnoDB对字符集转换的操作支持有限，表数据量一大，执行期间会对读写造成阻塞。8.0部分场景可以走在线DDL，但也不是完全无感，最好在低峰期操作。
靠谱一点的做法是：
- 先扩容实例或磁盘，避免空间不够。因为转换过程中需要一份临时表的空间。
- 分批处理或使用工具。大表不建议一条ALTER硬跑，可以借助gh-ost这类工具做在线迁移，也可以按主键范围分批做。
- 操作前把binlog格式设成ROW，方便误操作后做闪回。
如果数据量不大，直接ALTER没问题；如果超过几百万行，建议先评估一下停机窗口。
6.2 存储过程和函数里的字符串也要关注
有一次我帮人排查一个接口，字段都是utf8mb4了，但某个存储过程里拼接了字符串，执行后返回的结果出现乱码。查了半天，发现那个存储过程定义时没指定字符集，默认继承了创建时刻的库配置，库当时还是utf8，后来库改了utf8mb4，但存储过程还是老编码。
这种情况下光是表改对了不管用。需要把存储过程重新定义一次，或者显式在CREATE PROCEDURE时指定：
CREATE PROCEDURE `test_proc`() CHARACTER SET utf8mb4 READS SQL DATA BEGIN -- 过程体 END;触发器、视图也有同样的问题。迁移后记得把所有视图、存储过程、触发器重建一遍。这里没有一步到位的命令，我的做法是把它们全部导出为SQL文件，然后把文件里的字符集声明全局替换掉，再重新导入。
6.3 两个库之间的数据迁移也会翻车
业务里经常要做库到库的数据同步，比如从旧库同步到新库。如果源库的字符集和目标库的字符集不一样，同步工具可能在中间环节发生字节转换，数据就会坏。
我自己用DataX或Canal这类工具时，会特别留意任务配置里的编码参数。源端如果声明了utf8，目标端声明了utf8mb4，工具默认会做一次编码转换。看起来合理，但如果源端实际数据由于历史原因已经是混编码，再转一次就容易出问题。更安全的做法是，先确认源端数据在当前字符集下能被正确解码，再设置目标端的字符集参数，同时保留一份源数据快照做对比。
7. 排序规则选错带来的性能隐患
这一段可能有人觉得不重要，但排序规则不只是排序效果问题，也影响性能。这里说两个典型的真实场景。
第一个是关于utf8mb4_general_ci和utf8mb4_0900_ai_ci的索引选择问题。MySQL 8.0里，如果两张表join的字段排序规则不同，优化器有概率无法直接用索引，只能做全表扫描。这就是前面说的Illegal mix of collations报错之外的另一种表现——不报错，但慢。
查慢SQL日志时，看到某个join执行时间从毫秒级变成秒级，先检查两边字段的Collation是否一致。
第二个场景是LIKE模糊查询。utf8mb4_0900_ai_ci支持更精确的Unicode比较，但某些场景下它的排序规则比较复杂，导致LIKE 'a%'这种行为在语义上比general_ci更慢。不过对于普通业务来说，这个差异微乎其微，不用过度追求性能上的细微差别，只要不出现全表扫描级别的退化就行。
建议是：统一用MySQL 8.0的默认规则utf8mb4_0900_ai_ci，别搞混搭，出了问题好定位，性能也足够。
8. 什么时候可以不用utf8mb4
标题说“为什么必须用utf8mb4”，但技术选型不能成为教条。下面这几种场景，用utf8mb4反而不合适。
存储纯ASCII的业务标识符，比如订单号、设备ID、身份证号之类的，用ascii或latin1可以省空间，因为排序规则简单、比较速度快。不过省的空间其实很有限，除非真的到了抠空间的地步，否则还是统一utf8mb4更省事。
如果做的是极端的全文检索场景，并且处理的是固定语种，比如只存简体中文和英文，gbk也不是不能用。但问题在于，业务需求是变化的，你不敢保证未来不会有人往里面存emoji或者日文假名。普通项目承受不起这种不可预见的坑，宁可多花一点存储，换取兼容性和心智负担的降低。
还有一种是数据直接存二进制，比如把图片的base64编码存到TEXT字段，字符集设在latin1反而不会产生编码转换。但这种场景建表时用BLOB或者VARBINARY更合适，压根不需要字符集参与。
所以准确的说法是：没有特殊理由时，一律选utf8mb4；有特殊理由时，先确认自己真的理解那个理由。
9. 一套完整自查表：照做就行
开发新功能、排查乱码、迁移系统时，我都按一套固定清单检查。直接贴出来，照着走能省很多时间：
- 实例层：
character_set_server是否为utf8mb4。 - 库层：所有库的
DEFAULT CHARACTER SET是否为utf8mb4。 - 表层：所有表的
DEFAULT CHARACTER SET是否为utf8mb4。 - 字段层：所有字符型字段的字符集是否为utf8mb4。
- 连接层：连接串是否显式设置了charset=utf8mb4。
- 排序规则层：全部统一，不混搭。
- 客户端层：命令行客户端地址是否加了
--default-character-set=utf8mb4。 - 视图和存储过程：重建时是否保留了utf8mb4声明。
我自己在命令行连MySQL时，一直习惯加一句：
mysql -h127.0.0.1 -uxxx -p --default-character-set=utf8mb4不然的话，命令行客户端默认字符集会跟随系统locale，某些Linux服务器默认是UTF-8跟MySQL默认不一致，看着界面正常，实际操作时就会出乱码。
还有一个加分项：在应用启动时执行一次SET NAMES utf8mb4。即使连接串已经配置了，再执行一次也不会有副作用，反而能防止某些数据库驱动覆盖连接参数。对于老项目改造，这是最低成本的兜底方案。
整套自查下来如果全部通过，乱码问题基本不会再找上门。最后再提醒一次：字符集改完之后，一定重启连接池里的连接，因为已存在的连接会保留旧参数，不重启的话，代码改了但行为不变，排查时最容易怀疑人生。
