MySQL导入SQL文件中文乱码需逐层排查：客户端连接须加--default-character-set=utf8mb4参数；SQL文件须用UTF-8无BOM编码保存；CREATE TABLE语句需显式指定DEFAULT CHARSET=utf8mb4；已建表乱码需用ALTER TABLE CONVERT TO CHARACTER SET utf8mb4；GUI工具需单独配置字符集，推荐优先使用带参命令行导入。
MySQL 导入 SQL 文件时中文变问号或方块？先看客户端编码是否真生效
乱码不是文件问题就是连接问题，八成出在 mysql 客户端连接时没带对编码参数。哪怕你用的是 utf-8 保存的文件，如果 mysql 命令行没声明字符集，它默认按 latin1 连接，插入时就自动转码丢数据。
实操建议：
- 导入前必须加
--default-character-set=utf8mb4参数，例如：mysql --default-character-set=utf8mb4 -u root -p db_name - 别信 MySQL 配置文件里
character_set_server设了就万事大吉——客户端连接层不指定，照样走默认 - 用
mysql -V确认客户端版本；5.7.8+ 才推荐用utf8mb4，老版本用utf8（注意：MySQL 的utf8不是真正 UTF-8，最多存 3 字节）
SQL 文件本身编码不对？用命令行工具快速验证并重存
编辑器显示正常 ≠ 文件真是 UTF-8 编码。VS Code、Sublime 默认可能存成 UTF-8 with BOM，而 MySQL 会把 BOM 当作非法字符报错；记事本则更常见存成 GBK 或 ANSI。
实操建议：
- Linux/macOS 下用
file -i dump.sql查真实编码，输出含charset=utf-8才算靠谱 - 确认非 UTF-8 时，用
iconv -f gbk -t utf8mb4 dump.sql > dump_utf8.sql转换（把gbk换成你实际编码） - Windows 用户别依赖记事本“另存为 UTF-8”，改用 VS Code 打开 → 右下角点编码名 → “Save with Encoding” → 选
UTF-8（不是UTF-8 with BOM）
CREATE TABLE 语句里没设 DEFAULT CHARSET？建表就埋下乱码隐患
即使导入时一切正常，如果原 SQL 文件里的 CREATE TABLE 没显式写 DEFAULT CHARSET=utf8mb4，MySQL 会按当前库默认字符集建表——而这个默认值很可能还是 latin1 或 utf8。
实操建议：
- 打开 SQL 文件搜
CREATE TABLE，每张表结尾补上ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 - 如果表已存在且乱码，不能只改表定义，得用
ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci连数据一起转 - 注意：
CONVERT TO会重建表，大数据量要避开业务高峰
Navicat / DBeaver 等图形工具导入失败？它们常绕过命令行编码控制
这类工具底层调用 mysql 命令但未必透传 --default-character-set，或者自己缓存了旧的连接配置，导致你改了配置文件也无效。
实操建议：
- Navicat：右键连接 → “编辑连接” → “高级”页 → 勾选“使用 MySQL 字符集”，并在“初始化命令”里填
SET NAMES utf8mb4 - DBeaver：连接设置 → “驱动属性” → 找
characterEncoding改为utf8mb4，同时确保useSSL=false（某些版本 SSL 会干扰编码协商） - 最稳方案：关掉 GUI，直接用终端跑带参数的
mysql命令，避免中间层干扰
真正卡住人的地方往往不是“怎么设 UTF-8”，而是某一层（客户端参数、文件编码、建表语句、GUI 工具配置）悄悄漏掉了，而且错误不报错，只静默转成问号。逐层验证比反复重存文件更省时间。
