Navicat 还原多库时 SET NAMES 不生效，因其忽略 SQL 文件中的字符集设置；需在连接属性中配置“初始命令”SET NAMES utf8mb4，并检查 server/database/table 三层字符集一致性，导出时用 mysqldump --default-character-set=utf8mb4 --compatible=mysql57 避免兼容性问题。
Navicat 还原多库时 SET NAMES 不生效？字符集冲突的根源在这里
navicat 默认用客户端连接参数控制字符集，但还原 sql 文件时它会跳过文件里的 set names utf8mb4 或 set character set 语句——不是 navicat bug，是它按 mysql 官方协议把这类语句当“非执行上下文”直接忽略。结果就是：你明明写了 set names utf8mb4，还原后表结构或数据还是乱码。
- 必须在 Navicat 连接属性里手动指定「初始命令」（Initial Command），填入
SET NAMES utf8mb4 - 这个设置对当前连接下的所有操作（含导入 SQL）生效，比 SQL 文件里的
SET更早、更可靠 - 如果目标库已存在且字符集不一致，仅靠
SET NAMES不够，还需确保库/表级字符集匹配，否则插入时仍报Incorrect string value
还原前必须检查的三个字符集层级
MySQL 字符集有 server、database、table、column 四层，默认继承上层，但还原时只保证 SQL 文件里声明的那层生效。Navicat 导入不校验下层兼容性，容易漏掉关键冲突点。
-
SHOW VARIABLES LIKE 'character_set_server'—— 看服务器默认值，决定新库默认字符集 -
SHOW CREATE DATABASE `db_name`—— 确认目标库是否真用了DEFAULT CHARACTER SET utf8mb4 -
SHOW CREATE TABLE `t_name`—— 单表可能被单独设成latin1，即使库是utf8mb4，导入含 emoji 的数据也会失败
用 mysqldump 加参数导出，比 Navicat 自带备份更可控
Navicat 的「备份数据库」功能不暴露字符集导出选项，导出的 SQL 可能缺 CHARACTER SET 声明，导致还原到不同环境时隐性失败。
- 导出时显式加
--default-character-set=utf8mb4，并用--skip-set-charset避免重复SET NAMES - 加上
--hex-blob，防止二进制字段（如加密字段）因字符集转换被破坏 - 还原时别双击 SQL 文件用 Navicat 打开执行，改用「运行 SQL 文件」功能，并勾选「使用当前连接的字符集」——这个选项实际读的是连接属性里的初始命令，不是文件内容
ERROR 1273 (HY000): Unknown collation: 'utf8mb4_0900_ai_ci' 怎么办
这是 MySQL 8.0+ 默认排序规则，低版本（如 5.7）不识别，Navicat 还原时直接报错中断。不能靠替换字符串硬改，因为 collation 和 charset 绑定，改错一个会导致索引失效或查询乱序。
- 导出时加
--compatible=mysql57，自动降级 collation 为utf8mb4_general_ci - 若已拿到含
utf8mb4_0900_ai_ci的 SQL，可用 sed 或 VS Code 多行替换：utf8mb4_0900_ai_ci→utf8mb4_unicode_ci（比_general_ci更准，兼容性也够） - 千万别只替换 collation 不改对应 column 的
CHARACTER SET，否则ALTER TABLE ... CONVERT TO时会静默失败
SET NAMES，以及还原时主动勾选字符集继承开关。其余全是 MySQL 字符集模型本身的约束，绕不开，也藏不住。 
