字符集问题堪称MySQL使用过程中最经典、也最容易踩坑的问题之一。表面上看只是配置文件里的一个参数，实际上它贯穿了客户端连接、数据传输、存储引擎落盘的整个链路。一旦配置不一致，就会出现中文变问号、emoji存储报错、排序结果错乱等各种诡异现象。这篇文章从常见字符集的底层编码讲起，分析utf8和utf8mb4的真实区别，再梳理字符集在不同层级的作用范围，最后给出一套可以直接落地的配置方案。
一、常见字符集有哪些，各自的特点是什么
MySQL支持的字符集种类不少，可以通过SHOW CHARACTER SET;命令查看全部列表。实际生产中使用频率最高的是latin1、gbk、utf8（utf8mb3）和utf8mb4这四种，各有各的适用场景和历史背景。
latin1是MySQL 5.5之前的默认字符集，单字节编码，最多只能表示256个字符，覆盖西欧语言。如果在latin1的表里存中文，数据并不会直接丢失，而是以乱码形式存在，因为一个中文字符会被拆成多个字节存进去，读取时若连接字符集不一致，就会出现经典的“问号”或“烫烫烫”现象。早期很多老项目因为建库时没指定字符集，被latin1坑了很多年。
gbk是双字节编码，一个汉字占2个字节，主要面向中文场景。它的优势是存储空间比utf8小，缺点是无法存储生僻字和emoji，而且在国际化和多语言场景下几乎没有扩展能力，目前新项目已不推荐使用。
utf8在MySQL中是个“名不副实”的角色。标准UTF-8编码最多可以用4个字节表示一个字符，而MySQL的utf8最多只支持3个字节，官方后来也把它重命名为utf8mb3以正视听。这意味着它无法存储emoji表情、一些生僻汉字以及某些特殊符号。utf8mb4才是MySQL中真正的完整UTF-8实现，一个字符最多占4字节，能够覆盖整个Unicode字符集，这也是官方推荐并且从MySQL 8.0开始成为默认值的字符集。
二、utf8和utf8mb4的底层差异与存储代价
很多人知道要用utf8mb4，但不清楚它和utf8在存储上到底差在哪。其实对于绝大多数常用字符来说，两者的存储开销是一样的：英文字母和数字占1字节，常用汉字占3字节。utf8mb4的4字节只在存储emoji、生僻字时才会用到，所以“utf8mb4更占空间”这个说法并不准确，变长编码机制保证了它的向下兼容。
真正需要注意的差异在于索引长度。在MySQL 5.6及更早版本中，InnoDB单列索引最长为767字节，utf8mb4下单列索引的最大长度只有191个字符（767除以4），如果直接用utf8建索引再迁移到utf8mb4，索引可能报错或被截断。解决办法是开启innodb_large_prefix参数并使用DYNAMIC行格式，这样索引长度上限可以提升到3072字节。MySQL 5.7之后的版本默认就支持，无需额外配置。
另外，排序规则（Collation）也要和字符集配套。utf8mb4常见的排序规则有utf8mb4_general_ci和utf8mb4_unicode_ci，前者速度快但对多语言支持较弱，后者基于Unicode标准排序更准确。MySQL 8.0还引入了utf8mb4_0900_ai_ci作为默认排序规则，在准确性和性能上做了进一步优化。需要注意的是，排序规则不兼容也可能导致JOIN时索引失效或报错。
三、字符集在四个层级的作用范围与优先级
MySQL的字符集设置分为服务器级、数据库级、表级、列级四个层级，优先级从低到高。列上明确指定的字符集优先级最高，其次是表级，再是数据库级，最后才是服务器默认值。如果建表时没有显式指定字符集，表会继承数据库的设置；建库时没指定，则继承服务器的设置。
除了这四个存储层级，还有一个非常容易忽视的部分：连接层。客户端与服务器的连接涉及三个参数，character_set_client表示客户端发送的SQL语句用什么编码，character_set_connection表示服务器将语句转换成什么编码处理，character_set_results表示返回给客户端的结果用什么编码。三者不一致时，数据在传输过程中就会被“二次翻译”，乱码多半就出在这里。
排查乱码问题的标准步骤是：先执行SHOW VARIABLES LIKE 'character%';查看所有相关变量的当前值，再执行SHOW CREATE DATABASE 库名;和SHOW CREATE TABLE 表名;确认存储层的实际字符集，最后检查客户端驱动或连接串中是否显式设置了编码。很多人只改了表的字符集却没改连接字符集，结果还是乱码，就是这个原因。
四、一套完整的utf8mb4配置方案
对于新项目，直接全链路使用utf8mb4是最省心的方案。首先修改MySQL配置文件my.cnf或my.ini，在对应节点中加入如下配置：
[mysqld] character-set-server = utf8mb4 collation-server = utf8mb4_unicode_ci [client] default-character-set = utf8mb4 [mysql] default-character-set = utf8mb4
然后重启MySQL服务，使配置生效。对于已有的数据库和表，可以通过ALTER语句转换字符集，注意转换前务必做好备份，并评估索引长度是否超限：
-- 修改数据库默认字符集 ALTER DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; -- 修改表及其所有列的字符集 ALTER TABLE user CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
最后别忘了连接层。在JDBC连接串中指定useUnicode=true&characterEncoding=utf8，驱动会自动映射到utf8mb4（MySQL Connector/J 5.1.47之后的版本支持显式写成utf8mb4）；使用PHP的PDO时设置charset=utf8mb4；命令行客户端可以直接执行SET NAMES utf8mb4;来一次性设置三个连接变量。
总结一下选择原则：新项目无脑选utf8mb4，老项目在迁移前评估索引长度和存储引擎版本，gbk和latin1只作为历史遗留的兼容选项保留。字符集配置的核心思路是“全链路一致”，存储层、连接层、客户端三处对齐，乱码问题基本可以从根源上杜绝。