结论是乱码并非数据损坏，而是字符集在某一层被错解，必须定位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%';

只看这三项：

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

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

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

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

mysql --default-character-set=utf8mb4 -u root -p database_name <p>注意三点：</p><div class="aritcle_card flexRow artxards">
											<div class="artcardd flexRow">
												<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill4139" title="Pandas 配置文件报告生成器"><img
														src="https://img.php.cn/upload/skill/000/000/081/178991110986426.jpg" alt="Pandas 配置文件报告生成器" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
												<div class="aritcle_card_info flexColumn">
													<a rel="nofollow" href="/xiazai/skill4139" title="Pandas 配置文件报告生成器" class="overflowclass">Pandas 配置文件报告生成器</a>
													<p class="overflowclass">使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。</p>
												</div>
												<a rel="nofollow" href="/xiazai/skill4139" title="Pandas 配置文件报告生成器" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
												</a>
											</div>
										</div>

• 这个参数必须放在 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/^\xef\xbb\xbf//' data.sql  # 清除 BOM<br>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]<br>character-set-server = utf8mb4<br>collation-server = utf8mb4_unicode_ci<br>skip-character-set-client-handshake = ON

同时在 [client] 段补上：

[client]<br>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 命令。