Navicat结构比对报“字符集不一致”实为排序规则（collation）差异所致，即使字段类型相同也会标红；需在“对象比较设置”中勾选Compare collations和Compare column character sets，并通过ALTER TABLE CONVERT TO或MODIFY COLUMN统一目标表collation，避免同步失败。
Navicat结构比对报“字符集不一致”但实际字段类型相同
navicat默认不比对collate和character set，所以报告里不会直接写“排序规则不同”，而是表现为字段被标红、显示“结构不一致”——尤其当源表用utf8mb4_0900_ai_ci、目标表是utf8mb4_unicode_ci时，即使类型都是varchar(255)也会触发差异。这不是误报，是navicat把collation差异归类到“整体结构不一致”里了。
真正要解决，得先确认它到底比了没：右键比对任务 → 选项 → 对象比较设置 → 必须勾选Compare collations和Compare column character sets。否则你改了collation，报告仍可能“无差异”，同步脚本却失败。
修改目标表的排序规则让结构比对通过
比对前手动统一目标库的表级collation，是最稳妥的前置动作。注意不是改连接或会话层，而是直接更新元数据：
- 连上目标库，执行：
ALTER TABLE `table_name` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 如果只要改某几列（比如只改
name和desc），用：ALTER TABLE `table_name` MODIFY `name` VARCHAR(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci, MODIFY `desc` TEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 批量处理多张表？别手敲，用
SELECT CONCAT('ALTER TABLE `', table_name, '` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;') FROM information_schema.tables WHERE table_schema = 'your_db';生成语句再执行
Navicat同步时自动修正collation失败的常见原因
即使你勾选了Compare collations，同步仍可能卡在“无法修改collation”——这不是Navicat bug，是MySQL权限或语法限制导致的：
- 目标库用户缺少
ALTER权限，或没有CREATE权限（某些collation变更需重建表） - 目标MySQL版本低于8.0，不支持
utf8mb4_0900_ai_ci，但Navicat同步脚本仍试图写入该collation（此时必须预处理源库导出文件） - 表含全文索引或生成列时，
CONVERT TO会失败，得拆成MODIFY COLUMN逐列处理 - Navicat生成的同步SQL里带
ENGINE=InnoDB ROW_FORMAT=DYNAMIC等附加子句，和collation混在一起，导致语法错误；建议在同步预览窗口里手动删掉无关子句
为什么不能只靠Navicat“自动同步”解决collation差异
Navicat的结构同步本质是生成DDL并执行，它不会主动降级或转换collation值。比如源库是utf8mb4_0900_as_cs，目标库只认utf8mb4_unicode_ci，它不会帮你替换，而是原样写进ALTER TABLE ... COLLATE = utf8mb4_0900_as_cs，然后MySQL直接报错Unknown collation。
真正可控的做法是：先用mysqldump --skip-set-charset --default-character-set=utf8mb4从源库导出（避免硬编码collation），再用文本编辑器全局替换残留的8.0专属collation，最后用Navicat导入或结构同步。这比依赖工具“智能适配”更可靠——毕竟collation不是可协商的参数，是MySQL服务端硬校验的。
