MySQL如何解决备份文件导入乱码问题

结论是乱码并非数据损坏，而是字符集在某一层被错解，必须定位client/connection/results三层中具体哪层错位并针对性修复；需用命令行执行SHOW VARIABLES LIKE 'character%'确认三者全为utf8mb4，导入命令须显式加--default-character-set=utf8mb4，配置文件需在[mysqld]段启用skip-character-set-client-handshake=ON并重启服务。

直接说结论：乱码不是数据坏了，是字符集在某一层被错解了——必须定位到具体哪一层错位，再针对性修复。光改表结构、只设数据库默认字符集，90%的情况都白忙。

检查导入前的三件套：character_set_client、character_set_connection、character_set_results

图形工具（如 Navicat、DBeaver）会自动协商字符集，掩盖真实问题；命令行才是唯一可信入口。登录 MySQL 后立即执行：

SHOW VARIABLES LIKE 'character%';

只看这三项：

1. character_set_client：客户端声称自己发的是什么编码
2. character_set_connection：服务端按什么编码解析传来的字节
3. character_set_results：服务端返回结果时用什么编码编码

只要其中任意一项不是 utf8mb4（比如是 latin1、utf8 或 gbk），导入时中文就会在连接层被截断或误转，后续改表也无效。

导入命令本身必须带 --default-character-set=utf8mb4

别依赖配置文件或环境变量，临时参数最可靠。正确写法是：

mysql --default-character-set=utf8mb4 -u root -p database_name 
注意三点：

这个参数必须放在 mysql 命令后、-u 之前，顺序错就失效
它只影响本次连接的 character_set_client 和 character_set_connection，不改 character_set_results，所以仍需配合 SET NAMES utf8mb4 或确保服务端已对齐
如果报错 Unknown character set: 'utf8mb4'，说明 MySQL 版本 
确认 data.sql 文件实际编码是 UTF-8 without BOM
编辑器声明的编码 ≠ 文件真实编码。Linux 下用 file -i data.sql 查看真实类型，常见陷阱：

Windows 记事本导出的 SQL 文件，默认是 ISO-8859-1 或 GBK，哪怕右下角显示“UTF-8”也可能是假的
含 BOM 的 UTF-8 文件（U+FEFF 开头）会导致第一行执行失败，或让 SET NAMES 等语句被跳过
混合编码（如部分 GBK、部分 UTF-8）无法靠参数修复，必须先清洗
安全做法：
sed -i '1s/^xefxbbxbf//' data.sql# 清除 BOM
iconv -f gbk -t utf-8//ignore data_gbk.sql > data.sql# 转换遗留 GBK 文件
永久生效要改配置 + 重启，且必须加 skip-character-set-client-handshake
只在 [mysqld] 段写 character-set-server = utf8mb4 不够。旧版客户端可能硬编码发 latin1，服务端默认照单全收。必须加：
[mysqld]
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci
skip-character-set-client-handshake = ON
同时在 [client] 段补上：
[client]
default-character-set = utf8mb4
关键点：


skip-character-set-client-handshake = ON 强制忽略客户端声明的字符集，所有连接统一按服务端设定走
Linux 下改完必须 sudo systemctl restart mysql，kill 进程不加载新配置
Windows 下必须通过服务管理器重启，命令行 net stop/start mysql 有时不生效
最常被忽略的是：即使配置全对，终端本身不是 UTF-8 编码（如 Windows CMD 代码页是 936），character_set_client 设成 utf8mb4 也无效——得先改终端编码，再跑 mysql 命令。