Navicat数据同步乱码主因是源库、目标库及连接层字符集（如utf8mb4与utf8）或排序规则不匹配，需分别核查表级CHARACTER SET、COLLATION、Navicat连接高级设置中Initial charset是否为utf8mb4，并在同步前手动执行ALTER TABLE CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci确保目标表编码一致。
navicat 数据同步时出现乱码，大概率是源库和目标库的字符集（如 utf8mb4 与 utf8）或排序规则（collation）不匹配，而非 navicat 本身“自动修复”了编码问题——它默认按数据库声明的字符集读写，不会做隐式转码。
确认两端数据库实际字符集和连接层设置
乱码往往不是同步过程出错，而是建表时字符集没对齐，或客户端连接未指定正确 charset。必须分别检查：
- 源库表的
CHARACTER SET和COLLATION（用SHOW CREATE TABLE t1查） - 目标库对应表的字符集是否一致（尤其注意 MySQL 5.7 默认
utf8是阉割版，不支持 emoji；而utf8mb4才是完整 UTF-8） - Navicat 连接属性里的「高级」页签中，
Initial charset是否设为utf8mb4（不是utf8） - 若用 SSH 隧道或代理，中间链路（如跳板机 MySQL 客户端配置）也可能覆盖字符集
同步前手动修正目标表字符集
Navicat 的「数据同步」功能不会自动 ALTER 表修改字符集，它只同步数据行。如果目标表仍是 utf8，即使源是 utf8mb4，插入四字节字符（如 ?）就会被截断或转成问号。
务必在同步前执行：
ALTER TABLE `t1` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
注意：CONVERT TO 会重写整张表，大表需评估锁表现；若只要改列，用 MODIFY COLUMN 更精准。
同步任务中避开隐式转换陷阱
Navicat 同步向导里有「字段映射」步骤，但默认勾选「同步结构」时，它只比对字段类型、长度、是否为空，完全忽略字符集和 collation 差异。这意味着：
- 即使你勾了「同步结构」，
CHARACTER SET不同也不会报错或提醒 - 若源字段是
VARCHAR(255) CHARACTER SET utf8mb4，目标同名字段是VARCHAR(255) CHARACTER SET utf8，同步仍会强行写入，导致乱码 - 解决办法：取消勾选「同步结构」，先手工确保表结构一致；或在「高级」选项里启用「Compare character set and collation」（部分 Navicat 版本支持，v16+ 更可靠）
验证乱码是否真发生在同步环节
最常被忽略的一点：乱码可能根本不是同步导致的，而是查询时客户端解码错了。比如：
- 用 Navicat 查目标库，但连接设置仍是
utf8→ 显示 ???? - 用命令行
mysql -u -p --default-character-set=utf8连，查出来也是乱码（应改用--default-character-set=utf8mb4） - 应用代码里 JDBC URL 缺少
characterEncoding=utf8mb4参数
真正要定位问题，得在目标库执行：SELECT HEX(col), col FROM t1 LIMIT 1; —— 如果 HEX() 返回的是 C3A9（é 的 UTF-8 编码），说明存进去了；如果是 3F3F（两个问号的 ASCII 码），说明写入时就被替换了。
