恢复后乱码90%是因导出或导入时--default-character-set未匹配，导致解码错误而非数据丢失；导出须按表真实字符集指定该参数，导入须显式声明编码或在SQL文件首行加SET NAMES。
恢复后乱码，90% 是导出或导入时 --default-character-set 没对上，不是数据丢了，是解码错了。
导出时用错 --default-character-set 就埋了雷
导出命令里不加或加错这个参数，mysqldump 会按当前 session 的 character_set_client 去读数据——而这个值往往不是你表的真实编码。比如表是 latin1，但 session 是 utf8mb4，导出时就会把字节强行当 utf8 解，再写进 SQL 文件，结果就是“双重编码”。
- 原表字符集是
latin1→ 必须加--default-character-set=latin1 - 原表是
utf8mb4→ 必须加--default-character-set=utf8mb4 - 不确定时，先查：
SHOW CREATE TABLE table_name;看CHARACTER SET字段 - 别信
SHOW VARIABLES LIKE 'character_set%'里的client或connection，它们只影响当前连接，不决定 dump 行为
导入时没指定字符集，MySQL 自己瞎猜
导入 SQL 文件时，如果没显式告诉 MySQL “这文件是用什么编码写的”，它就按 character_set_client 解析——而这个值通常是配置文件里设的默认值，跟文件实际编码很可能不一致。
- 导入命令必须带
--default-character-set=utf8mb4（或对应真实编码） - 或者在 SQL 文件开头手动加：
SET NAMES 'utf8mb4'; - 不要依赖
mysql -u root -p db_name 这种裸命令，它不传字符集 - 如果已导入且乱码，别急着删库重来；先确认源文件编码（可用
file -i file.sql或 VS Code 查看右下角编码），再针对性修复
ALTER TABLE ... CONVERT TO 不能救已错的数据
这个命令只改元数据和后续写入行为，不会重解已存的乱码字节。比如 \xE6\x88\x91 在 latin1 下是三个独立字符，在 utf8mb4 下才是“我”，但 CONVERT TO 不会帮你做这种逆向映射。
- 已乱码的数据，得靠“反向转码”修复：例如原是 latin1 写入、误当 utf8 导出，可尝试用 Python 脚本把字符串先 encode('latin1') 再 decode('utf8') 拉回来
-
CONVERT TO只适合迁移前数据干净、只是结构要升级的场景 - 大表执行
CONVERT TO会锁表，线上务必避开高峰；小表也建议先在测试库验证效果
真正容易被忽略的是：同一个数据库里不同表可能用不同字符集，甚至同一张表里不同字段都可能混用。别假设“全库统一”，每个 SHOW CREATE TABLE 都得亲手看一遍。
