Navicat 15模型同步前必须手动设置字符集选项：在同步向导中点击「选项」，显式选择utf8mb4字符集与utf8mb4_unicode_ci排序规则，并勾选“将字符集应用到所有文本列”；否则字段级字符集不更新，导致中文乱码或同步失败。
模型同步前必须手动设置目标库字符集
navicat 15 的「模型同步」功能不会自动读取或继承目标数据库的 character_set_server，也不会根据模型中字段定义的字符集去适配目标表。它只比对模型结构与目标库当前状态，若两者字符集声明不一致（比如模型里是 utf8mb4，目标表是 latin1），同步会失败或静默降级——最常见表现是中文字段变问号、emoji 插入报 incorrect string value。
真正起作用的是在同步向导第二步「选择要同步的对象」之后、点击「下一步」前，必须手动点开右下角的「选项」按钮，在弹出窗口中显式指定：
- 「字符集」下拉选
utf8mb4（不是「自动」，也不是留空） - 「排序规则」选
utf8mb4_unicode_ci（避免用utf8mb4_0900_ai_ci，否则同步到 MySQL 5.7 会卡住） - 勾选「将字符集应用到所有文本列」——这个选项默认不勾，但漏掉会导致仅修改表级 CHARSET，字段级仍保持旧值
模型里字段没写字符集，同步后还是 latin1
Navicat 模型编辑器中，如果新建字段时没在「属性」面板里手动填 Collation 或勾选「使用默认字符集」，该字段在模型 XML 中就不会生成 CHARACTER SET 和 COLLATE 声明。同步时 Navicat 会按目标库当前默认值（通常是 latin1_swedish_ci）建表，哪怕你在连接设置里选了 utf8mb4 也无效。
解决办法只有两个：
- 逐个双击模型中的
VARCHAR/TEXT字段 → 左侧「属性」面板 → 手动设Collation为utf8mb4_unicode_ci - 或批量操作：右键模型 →「编辑模型 SQL」→ 在生成的 DDL 里全局搜索
varchar(，补上CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci
注意：ENUM 和 SET 类型字段同样需要单独处理，它们不会继承表级字符集。
同步时报错 Unknown collation: 'utf8mb4_0900_ai_ci'
这是典型跨版本陷阱：你用 MySQL 8.0+ 导出的模型（或从 8.0 库反向工程来的模型），自带 utf8mb4_0900_ai_ci 排序规则，但目标库是 MySQL 5.7 或更早版本，压根不识别这个 collation。
不能靠「选项」里换字符集解决，因为模型里已硬编码了该值。必须预处理模型：
- 导出模型为 SQL 文件（「模型」→「导出模型为 SQL」）
- 用 VS Code 打开，正则替换：
utf8mb4_0900_ai_ci→utf8mb4_unicode_ci；utf8mb4_0900_as_cs→utf8mb4_unicode_ci - 再通过「模型」→「从 SQL 文件导入」重建模型，此时所有 collation 已降级
- 最后执行同步——此时「选项」里选
utf8mb4_unicode_ci才真正生效
为什么改了模型字符集，同步后表结构还是不对
Navicat 15 同步逻辑分两层：先比对 DDL 差异生成 ALTER 语句，再执行。但如果目标表已存在且字段字符集是 latin1，而模型里对应字段没声明字符集，Navicat 默认不会生成 MODIFY COLUMN ... CONVERT TO CHARSET utf8mb4 —— 它认为「没声明 = 不需要改」。
绕过这个限制的实操方式：
- 同步前先手动执行：
ALTER TABLE `table_name` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 或者在模型同步「选项」里勾选「删除并重新创建对象」（慎用，有数据丢失风险）
- 更稳妥的做法：同步完成后，立刻检查
information_schema.columns，对遗漏字段单独跑ALTER TABLE ... MODIFY COLUMN ... VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
模型同步不是魔法，它不保证字符集最终一致性——你得盯着每一步的 DDL 预览，尤其是字段级变更，那里最容易藏坑。
