逻辑还原后字符集乱码说明SQL文件本身已损坏或还原参数不匹配；须先用file -i、hexdump等命令确认文件真实编码与UTF-8字节合法性，再确保mysql命令带--default-character-set=utf8mb4且SQL文件首行含SET NAMES utf8mb4，同时核查表及字段级实际字符集是否一致。
逻辑还原后字符集乱码，说明数据在 SQL 文件里已经损坏——不是还原命令写错了，而是备份那一刻就编码错位了。必须先判断是“文件已损”还是“还原参数没对”，否则盲目改配置、转编码只会让问题更难回溯。
确认 backup.sql 里的中文是否已损坏
别急着执行 mysql 命令。先用二进制视角看文件本身是否还存有合法 UTF-8 字节：
- 运行
file -i backup.sql：如果输出charset=us-ascii或charset=iso-8859-1，基本可断定中文已被错误解码成 Latin1 字节流，原始 UTF-8 已丢失 - 运行
head -n 50 backup.sql | grep -E "INSERT.*VALUES" | head -1 | hexdump -C | head -3：找中文字段值（如'张三'），看对应十六进制是不是合法 UTF-8 编码（如e5xbc9 e4b889）；如果是c3a6 c2b1 c28d这类，就是双重编码残留，文件已坏 - 打开文件用 VS Code 或 Sublime，右下角查看编码标识：若显示 “UTF-8 with BOM” 或 “GBK”，而你预期是 UTF-8，说明编辑器或生成环节已二次污染
还原命令必须带 --default-character-set 且值要匹配表真实字符集
这个参数控制的是 mysql 客户端如何解析 SQL 文本本身（比如 INSERT 语句里的字符串字面量），不加它就默认用 latin1 解整个文件，哪怕目标库是 utf8mb4，汉字也会被截断或错映射。
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 正确写法：
mysql --default-character-set=utf8mb4 -u root -p db_name - 如果报
Unknown character set: 'utf8mb4'，说明本地mysql客户端太老（常见于 macOS 自带或旧版 XAMPP），必须升级 MySQL client，或临时降级为--default-character-set=utf8（但 emoji 和部分生僻字会丢） - Windows 下禁用 cmd：它的代码页默认是 GBK，会把 UTF-8 字节流再错解一次；改用 PowerShell（执行
$OutputEncoding = [System.Text.Encoding]::UTF8后再跑命令）或 Git Bash
SQL 文件开头必须有 SET NAMES utf8mb4，且位置不能错
--default-character-set 管客户端本地解码，SET NAMES 管连接层三变量（character_set_client/connection/results）。两者作用阶段不同，缺一不可。
- 手动在
backup.sql第一行插入：SET NAMES utf8mb4;—— 必须在任何CREATE DATABASE、USE、CREATE TABLE之前 - 如果文件里已有
SET NAMES latin1;或类似语句，必须全局替换成utf8mb4，否则它会在执行时覆盖命令行参数 - 注意：有些 mysqldump 输出会自带
/*!40101 SET NAMES utf8 */;，这种条件注释在 MySQL 5.7+ 默认不生效，得改成无条件的SET NAMES utf8mb4;
还原后 SELECT 还是乱码？立刻查存储层三处定义
命令执行成功 ≠ 数据正确。乱码可能藏在表结构里，而不是传输链路上。
- 查表真实字符集：
SHOW CREATE TABLE table_name;看DEFAULT CHARSET=xxx和每个VARCHAR字段后有没有显式声明CHARACTER SET latin1 - 查字段级定义：
SELECT COLUMN_NAME, CHARACTER_SET_NAME FROM information_schema.COLUMNS WHERE TABLE_SCHEMA='db_name' AND TABLE_NAME='table_name' AND DATA_TYPE IN ('varchar','text','char'); - 如果发现某字段是
CHARACTER SET latin1，即使整库设了 utf8mb4，它也按 latin1 存——此时还原进去的就是错的字节，后续只能靠ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4强制重编码（有风险，需先备份）
最容易被忽略的是：同一库中不同表可能混用 utf8mb4、latin1、gbk，甚至同一张表里字段字符集都不一致。不能只看 SHOW VARIABLES LIKE 'character_set%' 就以为万事大吉——那只是会话变量，不是数据实际存储的编码。
