Navicat结构同步需手动勾选“Compare collation”才能识别并生成字符集变更语句，否则即使源目标库校对规则不同也不会标蓝或输出ALTER；关键在于显式声明字段字符集与校对规则，并确认目标库支持对应COLLATION。
navicat 的结构同步功能不能直接“批量修改字段字符集”，它只会在源库与目标库字符集定义不一致时，自动生成 alter table ... convert to character set 或 modify column 类语句——前提是你在 options 里打开了 compare collation。
为什么结构同步有时不生成字符集变更语句
常见现象：源库字段是 VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs，目标库是 utf8mb4_general_ci，但比对结果里没标蓝、也没生成 ALTER 语句。
-
Compare collation默认关闭——这是最常被忽略的开关，必须手动勾选才触发校对规则比对 - 目标库引擎不支持该 collation（如 MySQL 5.7 不支持
utf8mb4_0900_as_cs），Navicat 会跳过比对，不报错也不提示 - 字段定义中未显式声明
CHARACTER SET和COLLATE，仅依赖表级默认值，此时 Navicat 可能认为“无差异”
如何让结构同步准确生成字符集变更 SQL
关键不在“怎么改字段”，而在“怎么让 Navicat 看出该改”：
- 进入结构同步向导 → 点击“选项”（Options）→ 勾选
Compare collation，**取消勾选Compare auto-increment value（避免主键重置）** - 确保源库字段定义中显式包含字符集与校对规则，例如：
name VARCHAR(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 若目标库是达梦 DM8，需确认其已启用
UTF-8模式；MySQL 目标库需支持对应COLLATION，否则脚本执行会报错Unknown collation - 比对完成后，在差异列表中筛选类型为“Collation”的条目，逐个确认是否勾选——Navicat 允许单条取消，避免全量覆盖
执行前必须手动检查的三类风险语句
生成的脚本里一旦出现以下任意一种，**不能直接点“运行”**：
-
ALTER TABLE t1 CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs：全表转换会锁表，大表可能阻塞业务数分钟 -
MODIFY COLUMN content TEXT CHARACTER SET gbk：从 utf8mb4 改为 gbk 极易导致乱码，Navicat 不做编码兼容性校验 -
ALTER TABLE t1 CHANGE COLUMN title title VARCHAR(255) CHARACTER SET ascii：ascii 不支持中文，现有数据将被截断或转成问号
真正安全的做法是：复制脚本 → 在新查询窗口中分段执行 → 对每张表先用 SELECT LENGTH(title), LENGTH(CONVERT(title USING gbk)) FROM t1 LIMIT 10; 验证转换可行性。
替代方案：比结构同步更可控的字符集批量处理方式
如果只是改字符集，不用动字段类型或约束，结构同步反而过度复杂。推荐组合命令行 + Navicat 导出：
- 在 Navicat 中右键源库 → “备份数据库” → 选“结构-only” → 保存为
schema.sql - 用 sed 或 VS Code 批量替换：
utf8mb4_general_ci→utf8mb4_0900_as_cs，注意保留引号和分号 - 用 Navicat 连接目标库 → 执行修改后的
schema.sql，勾选“停止执行遇到错误时”
这种方式绕开了 Navicat 的比对逻辑，完全由你控制变更粒度，也更容易加 IF NOT EXISTS 或条件判断——结构同步的自动化，省的是比对时间；但它省不掉对字符集兼容性的技术判断。
