应将 Navicat 连接字符集设为 utf8mb4，并在初始化命令中执行 SET NAMES utf8mb4；若目标库不支持 utf8mb4，需全局替换备份文件中的 utf8mb4 为 utf8 并删除 COLLATE 子句。
还原时提示
怎么办
这是 mysql 字符集不匹配的典型表现：备份文件里有 utf8mb4 编码的 emoji 或生僻字，但目标库表用的是
（实际是 utf8mb3），或连接层没设对。navicat 默认用客户端字符集发起还原，不自动适配源备份的编码声明。
先查备份 SQL 文件头几行，找类似
或
的语句，确认源字符集
在 Navicat 还原界面点击「高级」→ 勾选「使用自定义连接参数」→ 在「初始化命令」栏填：
如果目标库本身是
且不能改，得提前把备份 SQL 里的
全局替换成
，并删掉所有
子句（否则建表会失败）
Navicat 高级特权还原不生效，
仍是 latin1
Navicat 的「高级特权」不是开关式功能，它只影响是否允许执行
类语句；而还原过程中的会话级字符集由连接参数控制，和全局变量无关。真正起作用的是连接字符串里的
参数，不是权限等级。
右键连接 →「编辑连接」→「高级」页签 → 找到「初始化命令」，必须手动加
不要依赖「使用高级特权」复选框来解决字符集问题，它对还原时的会话编码无直接影响
若用 SSH 隧道或代理连接，还要确认中间层（如跳板机 MySQL 客户端）没强制覆盖
还原后中文变问号或乱码，但建表语句里明明写了
表定义里的
只管存储，不控制导入时的解析。Navicat 还原本质是把 SQL 文本发给服务端执行，如果客户端连接用的是
，MySQL 就会把整段 SQL 当作 latin1 解析——哪怕里面写着
，也会先错解再存，导致双乱码。
检查 Navicat 底部状态栏，看「字符集」显示的是什么（常见错误是显示
）
必须在连接设置里显式指定字符集：编辑连接 →「常规」页签 →「字符集」下拉选
（不是「自动」）
如果数据库版本 utf8mb4 可能不被连接器识别，降级用
并确保数据不含四字节字符
企业环境多实例还原，如何批量统一字符集处理
靠 Navicat 界面逐个改不现实。关键点在于：还原动作本身不可编程，但连接配置和 SQL 预处理可以脚本化。企业级做法是绕过图形界面，用命令行工具做标准化入口。
导出备份时就加参数：
写个轻量 wrapper 脚本，用
如果必须用 Navicat，可通过其「计划任务」调用外部命令行脚本，把字符集控制权交还给 shell 层
字符集问题从来不在「有没有高级特权」，而在「连接建立那一刻，MySQL 认为你发来的每个字节是什么编码」。这个决定点极早，一旦错，后面全错，且很难事后修正。
Incorrect string valueutf8SET NAMES utf8mb4DEFAULT CHARSET=utf8mb4SET NAMES utf8mb4 COLLATE utf8mb4_unicode_ci;utf8utf8mb4utf8COLLATEcharacter_set_clientSET GLOBALcharsetSET NAMES utf8mb4;charsetCHARSET=utf8mb4CHARSETlatin1utf8mb4latin1utf8mb4utf8mysqldump --default-character-set=utf8mb4 -h ... > backup.sqlmysql --default-character-set=utf8mb4 -h ... 替代 Navicat 还原