还原后中文乱码源于mysqldump未指定--default-character-set导致双重编码，须查表真实字符集、还原时匹配--default-character-set、SQL首行加SET NAMES utf8mb4，并验证四层编码一致。
还原后中文变 æ些æå 或问号，不是还原失败，而是备份那一刻就错了——mysqldump 没指定 --default-character-set，用错字符集读表，导致双重编码。
查清表的真实字符集，别信 SHOW VARIABLES
MySQL 不会按库级默认值覆盖字段定义。同一库中，不同表可能混用 utf8mb4、latin1 甚至 gbk。
- 必须逐个执行
SHOW CREATE TABLE table_name，盯住DEFAULT CHARSET=xxx和每个VARCHAR字段后有没有CHARACTER SET xxx -
SHOW VARIABLES LIKE 'character_set%'里的client或connection只影响当前会话，和mysqldump行为无关 - 不确定时，直接连上数据库，对每个业务表都跑一遍
SHOW CREATE TABLE，不跳过
还原命令必须带 --default-character-set，且值要匹配表真实编码
--default-character-set 控制客户端如何解码整个 SQL 文件的字节流。不加这个参数，mysql 默认用编译时设定的字符集（通常是 latin1）去解析 UTF-8 字节，中文必然被截断或错映射。
- 正确写法：
mysql --default-character-set=utf8mb4 -u root -p db_name < backup.sql - 错误写法：
mysql -u root -p db_name < backup.sql（缺参数） - Windows 下别用
cmd执行——它的代码页常是GBK，会二次污染；改用PowerShell或Git Bash - 如果报
Unknown character set: 'utf8mb4'，说明客户端太老，升级mysql命令行工具，或临时用utf8（但 emoji 会丢）
SQL 文件开头手动补 SET NAMES，且位置不能错
--default-character-set 控制客户端本地解码行为，SET NAMES 是发给服务器的指令，两者作用阶段不同，不能互相替代。旧 dump 脚本常无初始化语句，光靠命令行参数不够。
- 打开
backup.sql，在**第一行**插入：SET NAMES utf8mb4; - 这行必须在任何
CREATE DATABASE、USE或CREATE TABLE之前 - 如果文件里已有
SET NAMES latin1;，必须替换成SET NAMES utf8mb4;，否则它会覆盖命令行参数 - 别指望 JDBC 风格的
charset=utf8mb4URL 参数——mysql命令行根本不认这个
还原后 SELECT 还是乱码？重点检查三处存储层
命令跑成功不代表数据对了。MySQL 有四层编码：客户端、连接、数据库、表/列。任意一层不匹配，SELECT 出来就是乱的。
- 运行：
SELECT @@character_set_client, @@character_set_connection, @@character_set_results;——三个值必须都是utf8mb4 - 再查表结构：
SHOW CREATE TABLE t1;，确认ENGINE=InnoDB DEFAULT CHARSET=utf8mb4和字段定义里有没有CHARACTER SET utf8mb4 - 如果表本身仍是
latin1，ALTER TABLE t1 CONVERT TO CHARACTER SET utf8mb4;必须在还原前做，或还原到新库后再转——老数据已损坏，硬转可能失真
最易被忽略的是：备份时没加 --default-character-set，问题就已经固化在 SQL 文件里了；后续所有还原操作，只是把错误“忠实”地重放一遍。
