必须用“数据同步”工具，因协同合作仅同步查询、代码段等元数据，不传输sys_dict等字典表的实际业务数据；共享对象≠同步数据。
直接同步团队共享的字典表数据，不能用“协同合作”功能，必须用“数据同步”（data synchronization）工具——因为协同合作只同步对象定义（如查询、代码段、bi 工作区），不传输实际表数据。
为什么“共享对象”不等于“同步数据”
Navicat 的 协同合作 功能（含 Navicat On-Prem Server）本质是元数据协作平台：它同步的是你保存的 查询、代码段、模型工作区 等配置型内容，不是数据库里 sys_dict、region_code 这类带真实业务值的字典表数据。想把 A 环境的字典数据推到 B 环境，唯一可靠路径是走 Data Synchronization 向导。
常见误操作：把本地写好的 SELECT * FROM sys_dict 查询拖进 On-Prem Server → 这只是共享了 SQL 文本，不会自动执行、不会更新目标库里的数据。
同步字典表前必须确认的 4 个前提
字典表结构简单但极易出错，以下检查缺一不可：
- 源和目标表的主键或唯一键必须一致，且在
Key Mapping中正确指定；否则 Navicat 无法判断“哪条记录该更新/跳过”，会全量插入或报错 - 目标表字段类型需兼容源表，尤其注意：
enum、set、json字段在不同 MySQL 版本间行为差异大，建议提前用SHOW CREATE TABLE对比 - 目标库外键约束必须临时关闭（
SET FOREIGN_KEY_CHECKS = 0），否则插入新字典项时可能因关联表缺失而失败 - 若字典表含自增主键（如
id INT AUTO_INCREMENT），务必在Options→Advanced中勾选Ignore auto-increment fields when comparing，否则每次同步都会触发冲突
安全同步字典表的推荐参数组合
字典表通常只增不删、极少更新，盲目启用全操作反而危险。按场景选配：
- 首次初始化或重建字典：只勾选
Insert records，取消Delete records和Update records；执行前手动清空目标表（TRUNCATE TABLE sys_dict） - 日常增量更新（如新增城市编码）：勾选
Insert records+Update records，取消Delete records；确保Key Mapping使用业务主键（如code字段），而非自增id - 绝对禁止勾选
Delete records，除非你明确知道目标库中多出的字典项是脏数据且可丢弃——生产环境几乎从不启用此项 - 在
Options中开启Continue on error，避免单条脏数据（如空字符串、超长描述）中断整批同步
预览阶段必须盯住的两个数字
点击 Compare & Preview 后，别急着执行。重点看每张字典表右侧显示的：
-
Insert: X—— 源有、目标无的记录数。如果远大于预期（比如region_code表突然要插 5000 行），立刻暂停，查源表是否混入测试数据 -
Update: Y—— 同键但字段值不同的记录数。若Y > 0，点开具体行对比，确认是业务逻辑需要更新（如状态码变更），还是因字符集/排序规则差异导致的假差异（例如'A 'vs'A'）
真正容易被忽略的是：Navicat 默认按字段全量比对，但字典表常含 create_time、update_time 等时间戳字段。这些字段在不同环境写入时间必然不同，会导致大量无效 Update。解决方法是在 Field Mapping 中取消勾选这些非业务字段的同步。
