服务器上mysql编码配置文件怎么改，乱码怎么解决

MySQL编码问题十有八九不是数据库单方面的事，而是配置文件、连接串、表结构三者没对齐导致的；把服务器上的my.cnf按本文步骤设置成utf8mb4，再配合编码工具统一客户端连接，乱码基本能连根拔起。

服务器上MySQL编码配置文件到底改哪里

很多朋友登录服务器第一件事就是打开my.cnf，但改完重启发现乱码依旧，行业共识认为，MySQL编码配置文件通常不止一个生效位置，得先确认你改对了文件。

加载中

查看、修改、踩坑字符集

编程小龙

8659874

原视频地址

查找服务器上MySQL读取的配置文件路径

执行以下命令可以看到MySQL启动时依次读取了哪些配置文件：

mysqld --verbose --help | grep -A 1 "Default options"

输出结果中列出的路径顺序就是加载顺序,比如/etc/my.cnf、/etc/mysql/my.cnf、~/.my.cnf等。后读取的文件会覆盖先读取的同名参数，所以检查时一定要看最终生效的是哪一份，实际运维中，Debian/Ubuntu系统习惯把配置拆到/etc/mysql/mysql.conf.d/和/etc/mysql/conf.d/两个目录下，而CentOS/RHEL系统则集中在/etc/my.cnf，如果你在多个地方都改了，就等着看哪边覆盖哪边吧。

my.cnf中必改的四项编码参数

在[mysqld]段下，需要确保这四个参数全部指向utf8mb4：

[mysqld]
character_set_server = utf8mb4
collation_server = utf8mb4_unicode_ci
character_set_filesystem = utf8mb4
skip-character-set-client-handshake

其中skip-character-set-client-handshake这一项很关键，它让服务器忽略客户端传来的字符集信息，强制使用服务端统一设置，不过这个参数比较霸道，如果你有老程序还在用latin1连接，加了它反而会出问题，稳妥做法是不加这一项，转而让客户端主动指定编码。

改完配置后,重启MySQL服务并执行SHOW VARIABLES LIKE 'character_set%';验证，注意，此时已存在的库和表不会自动转换，还需要手动处理存量数据。

MySQL乱码问题往往出在连接层而不是服务器配置

我处理过不少线上乱码案例,发现一个规律：服务端配置得很规矩，但程序连上去还是乱码，这里有个高频坑，就是连接字符串里没有指定编码。

JDBC和PHP连接串的统一编码写法

Java应用在JDBC连接串上必须加上characterEncoding参数：

jdbc:mysql://localhost:3306/dbname?useUnicode=true&characterEncoding=utf8mb4&connectionCollation=utf8mb4_unicode_ci

PHP的PDO连接则这样写：

$pdo = new PDO('mysql:host=localhost;dbname=dbname;charset=utf8mb4', 'user', 'pass');

Python的pymysql则在connect时传charset='utf8mb4'参数。

命令行登录后立即执行set names utf8mb4

数据库连接建立后,服务器会根据客户端发送的握手包判断字符集，如果客户端没有明确指定，就可能回退到latin1，登录MySQL后马上执行：

SET NAMES utf8mb4;

这个命令同时设置了character_set_client、character_set_connection、character_set_results三个变量，在MySQL 8.0中，默认字符集已是utf8mb4，但在MySQL 5.7及更早版本中这个步骤能避免大多数乱码现象，为了一劳永逸，可以在my.cnf的[client]段和[mysql]段都加上default-character-set = utf8mb4，这样命令行连接时就不用手动敲set names了。

编码工具在排查MySQL字符集问题时的三个关键作用

做编码排查的时候,光靠眼睛看是不够的，得用工具把每个环节的字符集数据量化出来，这里说的编码工具不只是图形化客户端，还包括命令行里的小工具链。

用system variables和metadata排查编码不一致

查询服务器当前所有字符集相关变量：

SHOW VARIABLES LIKE 'character_set_%';
SHOW VARIABLES LIKE 'collation_%';

查看某个数据库的默认字符集：

SELECT SCHEMA_NAME, DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME 
FROM information_schema.SCHEMATA;

查看某张表的结构：

SHOW CREATE TABLE table_nameG

把这三层结果放在一起对比,就能快速定位是服务器层、库层还是表层的字符集设置不一致。

用hex函数定位乱码源头

乱码分两种：一种是存储时编码就错了，另一种是存储正确但读取时解码错了，用HEX()

函数可以把字符串转成十六进制，直接看存储层面的字节：

SELECT HEX(content) FROM articles WHERE id = 123;

如果十六进制结果是以E4B8AD等符合UTF-8编码规则的字节序列开头，说明存储没问题，问题出在读取连接层，如果十六进制是D6D0这样的GBK字节，说明写入时就用了GBK编码，这就需要先转码再存储，这个方法在排查“问号乱码”和“方块乱码”时有奇效。

编码转换工具处理存量乱码数据

对于已经乱掉的存量数据,可以用MySQL自带的CONVERT()函数处理：

UPDATE articles SET content = CONVERT(CAST(CONVERT(content USING latin1) AS BINARY) USING utf8mb4);

这个操作的原理是：先把utf8mb4字节流按latin1解码（还原成原始字节），再把这批字节按utf8mb4重新解码，这是处理“UTF-8被latin1读取导致乱码”的经典恢复手法，执行前务必先备份数据，并先用SELECT语句预览转换结果，确认无误后再执行UPDATE。

MySQL 5.7和8.0在编码配置文件上的差异对比

MySQL 8.0中，utf8mb4_0900_ai_ci排序规则在性能和准确性上优于5.7时代的utf8mb4_general_ci，但在MySQL 5.7中如果强行指定这个排序规则会报错，跨版本迁移时，要特别注意排序规则的兼容性问题。

如果从5.7升级到8.0，建议在升级前把库和表的排序规则统一转换为utf8mb4_0900_ai_ci，避免升级过程中自动转换带来的锁表时间。

服务器上MySQL编码配置文件常见的三个坑

只改配置文件不重建表结构

之前讲过,character_set_server只影响新建的表，已有的表必须手动转换，批量转换工具可以这样生成SQL语句：

SELECT CONCAT("ALTER TABLE `", TABLE_SCHEMA, "`.`", TABLE_NAME, "` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;")
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'your_database';

把输出结果复制出来,一条条执行，注意大表执行时会锁表，建议在业务低峰期操作。

配置文件权限不对导致MySQL无法读取

my.cnf文件权限如果设置成777，MySQL会拒绝读取并报World-writable config file is ignored错误，正确权限是644，属主为root：

chown root:root /etc/my.cnf
chmod 644 /etc/my.cnf

这个坑很隐蔽,因为MySQL启动不报错，只是默默忽略配置文件，导致所有修改都无效。

连接池缓存了旧连接

修改完配置文件、重启完服务，应用层连接池里的长连接可能还持有旧的字符集设置，跑Java应用的同学尤其要注意，Druid、HikariCP这些连接池都有连接存活时间配置，改完配置后，让连接池把旧连接全部淘汰，或者直接重启应用服务，否则排查了半天发现测试连接正常、线上连接还是乱码。

Q&A：MySQL编码配置的高频问题

服务器上MySQL编码配置文件修改后需要重启吗？

需要。character_set_server和collation_server是只读参数，不能用SET GLOBAL在线修改，执行SHOW VARIABLES LIKE 'character_set_server';确认修改结果，重启前检查[mysqld]段配置语法，可用mysqld --validate-config做语法校验。

设置utf8mb4后表结构还是latin1怎么处理？

需要手动转换存量表,用ALTER TABLE CONVERT TO CHARACTER SET utf8mb4逐表转换，或先修改库默认字符集再处理表，转换前备份全部数据，转换期间关注表锁定和空间占用情况。

编码转换工具能修复所有类型的乱码吗？

不能,编码转换工具能处理因字符集误读导致的乱码，比如UTF-8字节被按latin1显示、GBK内容混入UTF-8表等情况，但如果数据在存储时就已经被截断或丢弃了无法映射的字节，造成的损坏是不可逆的，任何工具都无法还原，服务器上MySQL编码配置文件和编码工具的共同目标，就是从根本上阻止乱码的产生，而不是事后修复。