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