需统一连接层、服务层、表层字符集为utf8mb4：修改my.cnf的character_set_server，Navicat连接中勾选Use Unicode UTF-8并设初始化命令SET NAMES utf8mb4，SQL文件头加注释/!40101 SET NAMES utf8mb4/，替换utf8mb4_0900_ai_ci为utf8mb4_unicode_ci，保存为UTF-8无BOM格式。
还原时提示 Incorrect string value 怎么办
这是 mysql 字符集不匹配最典型的报错，navicat 执行 sql 文件还原时，如果源库用的是 utf8mb4（比如存了 emoji 或生僻中文），而目标库或连接默认字符集是 utf8（mysql 旧版伪 utf8，实际只支持 3 字节），就会卡在这一步。
关键不是改 Navicat 界面选项，而是得让「连接层 + 服务层 + 表层」三者一致：
- 目标 MySQL 实例的
character_set_server必须设为utf8mb4（改my.cnf或my.ini，重启生效） - Navicat 连接该库时，在连接属性 → 「高级」页里勾选
Use Unicode UTF-8，并手动在「初始化命令」框里填：SET NAMES utf8mb4; - 还原前确认 SQL 文件头没有硬编码
SET NAMES utf8—— 如果有，得全局替换成utf8mb4，否则会覆盖连接层设置
Navicat 导入 SQL 文件时如何指定字符集
Navicat 的「运行 SQL 文件」功能本身不提供字符集下拉菜单，它完全依赖当前连接的字符集上下文。所以所谓「指定」，其实是靠连接配置和 SQL 文件内容协同完成的。
实操中容易漏掉两个点：
- SQL 文件第一行加上
/*!40101 SET NAMES utf8mb4 */;（注意是注释写法，兼容性更好） - 如果文件是 Windows 记事本保存的，可能带 BOM 头，Navicat 读取时会误判编码 —— 用 VS Code 或 Notepad++ 保存为「UTF-8 无 BOM」格式再导入
- 不要依赖 Navicat 的「编码」下拉框（位于导入弹窗右下角），那个只影响文件读取阶段的解码，不影响 MySQL 执行时的字符集行为
从高版本 MySQL 备份还原到低版本时的 COLLATE 冲突
MySQL 8.0 默认排序规则是 utf8mb4_0900_ai_ci，而 5.7 只认 utf8mb4_unicode_ci 或 utf8mb4_general_ci。Navicat 还原时若直接执行含新排序规则的 CREATE TABLE 语句，会报错 Unknown collation: 'utf8mb4_0900_ai_ci'。
解决方式不是升级低版本库，而是预处理 SQL 文件：
- 用
sed或 VS Code 正则批量替换：utf8mb4_0900_ai_ci→utf8mb4_unicode_ci - 或者导出时就在源库用
mysqldump --skip-set-charset --default-character-set=utf8mb4，避免写死排序规则 - Navicat 自带的「数据传输」功能比「运行 SQL 文件」更智能，能自动适配目标库能力，优先考虑用它做跨版本迁移
还原后中文显示问号或乱码的排查顺序
不是所有乱码都出在还原环节，得按链路一层层确认：
- 查目标库当前连接的字符集：
SHOW VARIABLES LIKE 'character\_set%';和SHOW VARIABLES LIKE 'collation%';—— 重点看character_set_client、character_set_connection、character_set_results是否全为utf8mb4 - 查具体表的字符集：
SHOW CREATE TABLE `your_table`;—— 确保DEFAULT CHARSET=utf8mb4且字段定义没写死CHARACTER SET utf8 - Navicat 查询窗口右下角状态栏显示的编码（如
UTF-8）只是界面渲染用，不影响数据存储，别被它误导
字符集问题从来不是单点故障，而是连接、服务、表、客户端四层叠加的结果。少调一个 SET NAMES，或者少改一行配置，就可能让前面所有操作白费。
