MySQL的编码体系比很多人想象中更复杂，它并不是只由建库时的一个参数决定，而是分布在客户端连接、服务器、数据库、表和列等多个层面。实际使用中常见的现象是：命令行查询正常，程序读写变乱码；或者数据库里已经改成utf8mb4，但新插入的emoji仍然报错。这些情况通常都是因为各层字符集设置没有保持一致。
一、先理解MySQL编码相关的核心变量
在开始查看和设置之前，需要先理解MySQL中几个关键变量。执行SHOW VARIABLES LIKE 'character_set%'可以看到一组character_set开头的变量，它们控制着不同环节的字符集。
character_set_client表示客户端发送SQL语句所使用的字符集；character_set_connection是服务器接收后用于转换的字符集；character_set_results决定服务器返回结果给客户端时使用的字符集。这三个变量在MySQL中可以通过一条SET NAMES命令同时修改。这也是很多人执行SET NAMES utf8后乱码暂时消失的原因。
除此之外，character_set_server是服务器默认字符集，影响新建数据库时的默认继承值；character_set_database表示当前数据库的默认字符集，但这个变量在切换数据库后可能会变化，更多用于兼容旧版本。真正落实到数据存储层面的是表或列自己声明的字符集，information_schema中可以精确查询。
字符集与排序规则需要一起理解。字符集决定能存储哪些字符，排序规则决定字符如何比较与排序。例如utf8mb4是字符集，utf8mb4_unicode_ci和utf8mb4_0900_ai_ci是它的不同排序规则。名称中的ci表示大小写不敏感，ai表示重音不敏感。同一列使用不同排序规则，可能影响查询结果的顺序和唯一索引行为。
二、查看MySQL数据库编码的常用方法
最常用的查看命令是SHOW VARIABLES LIKE 'character_set%'，它可以一次列出客户端、连接、结果集、服务器等所有相关变量。查看时建议同时关注collation%，因为字符集和排序规则通常要配套检查。下面这段SQL可以直接在MySQL命令行或客户端工具中执行：
-- 查看服务器与连接相关的字符集变量 SHOW VARIABLES LIKE 'character_set%'; SHOW VARIABLES LIKE 'collation%';
如果只想看当前数据库的默认字符集，可以查询information_schema.SCHEMATA，或者使用SHOW CREATE DATABASE your_db。后者会打印建库语句，其中包含CHARACTER SET和COLLATE信息，适合快速确认。
-- 查看指定数据库的默认字符集与排序规则 SELECT DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME = 'your_db';
对于已经存在的表，需要进一步查看表的默认字符集，以及每个文本列是否有单独覆盖。可以使用SHOW TABLE STATUS查看表级信息，使用SHOW FULL COLUMNS FROM your_table查看列级字符集和排序规则。
-- 查看表状态中的字符集信息 SHOW TABLE STATUS FROM your_db LIKE 'your_table'; -- 查看表中所有文本列的字符集 SHOW FULL COLUMNS FROM your_table;
实际排查问题时，如果表显示为utf8mb4，但某列仍然为latin1，写入中文仍然会出错。因此建议从服务器、数据库、表、列四个层级逐步确认，而不是只查一个SHOW VARIABLES就下结论。
三、设置MySQL编码的几种方式
设置编码可以按作用范围分为会话级、全局级和对象级。会话级设置只在当前连接有效，适合临时调试。最快捷的方式是执行：
-- 同时设置客户端、连接和结果集编码 SET NAMES utf8mb4;
这条语句等价于分别设置character_set_client、character_set_connection和character_set_results三个变量。注意它不会修改服务器默认字符集，也不会改变已有库表的存储字符集。程序连接池中若初始化时没有统一执行SET NAMES，可能出现部分连接正常、部分连接乱码的诡异问题。
如果希望长期生效，需要修改MySQL配置文件。Linux下通常是my.cnf，Windows下可能是my.ini。在对应节点下加入：
[mysqld] character-set-server=utf8mb4 collation-server=utf8mb4_unicode_ci [client] default-character-set=utf8mb4
修改配置文件后需要重启MySQL服务才能生效。重启后新建的数据库和表会默认继承utf8mb4，但已经存在的库表不会自动改变。此时需要执行ALTER DATABASE和ALTER TABLE进行转换：
-- 修改数据库默认字符集 ALTER DATABASE your_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; -- 修改单张表的字符集及所有文本列 ALTER TABLE your_table CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
执行ALTER TABLE ... CONVERT TO CHARACTER SET时会读取原始字符集并转换为目标字符集，适合已有数据的表。但有一点需要特别小心：如果旧表本身已经是错误字符集，例如原本用latin1存储中文，直接转换可能让数据损坏。在生产库操作前应先备份，或先在测试环境验证转换结果。
四、utf8与utf8mb4的区别及选型建议
MySQL里的utf8并不是标准意义上的完整UTF-8，它最多只使用三个字节，无法表示一些四字节的Unicode字符，包括大部分emoji表情和部分生僻汉字。当客户端发送一个四字节字符时，如果服务器字符集是utf8，通常会报错Incorrect string value。
utf8mb4才是真正的四字节UTF-8实现，能覆盖完整Unicode。因此现在新建数据库时应尽量直接使用utf8mb4。排序规则方面，MySQL 8.0默认使用utf8mb4_0900_ai_ci，它基于Unicode 9.0，性能与准确性都较好；如果需要兼容旧版或某些工具链，可以选择utf8mb4_unicode_ci或utf8mb4_general_ci。general_ci查询比较快，但对多语言排序的准确度不如unicode_ci。
对于已经上线且数据量较大的库，可以分批转换表字符集，避免长时间锁表。也可以先修改新表的默认字符集，再逐步用ALTER TABLE ... CONVERT TO CHARACTER SET处理历史表。转换完成后，建议重新执行查看命令，确认服务器、数据库、表、列四个层面都已经是utf8mb4。