Navicat结构同步的Options直接影响DDL安全性与可执行性：Compare auto-increment value应取消以防主键重置；Drop objects not exist in source为高危项，需确认源库结构冻结；Compare comments和Compare collation跨版本/引擎时易致报错；Compare foreign keys勾选后需手动调整ALTER顺序以避免外键约束失败。
结构同步时“选项”里哪些配置真会影响SQL生成
navicat结构同步的options不是摆设，几个关键开关直接决定生成的ddl是否安全、是否可执行。默认全开看似省事，但容易触发不可逆操作（比如删表、删字段）或语法报错（尤其跨版本/跨引擎时）。
-
Compare auto-increment value：默认勾选，但多数场景应取消——自增ID是运行时状态，不是结构定义；同步它会导致目标库主键重置，引发后续插入冲突 -
Drop objects not exist in source：高危项！勾选=允许删表/删列/删索引；上线前务必确认源库结构已冻结，否则可能误删生产字段 -
Compare comments：MySQL/PostgreSQL支持字段注释，但Oracle旧版不支持COMMENT ON COLUMN语法；若目标库版本低，勾选此项会导致部署失败 -
Compare collation：字符集校对规则不一致时会触发ALTER语句；若目标库字符集为utf8mb4_general_ci而源库是utf8mb4_0900_as_cs，强行同步可能因排序规则不兼容报错
怎么让Navicat跳过特定对象（如日志表、临时表）
结构同步默认比对所有对象，但开发库常含_tmp、log_、backup_类表，这些不该上生产。Navicat不支持正则过滤，得靠手动排除。
- 在“结构比对”界面左上角的
Source Objects树形列表中，逐个展开表节点，取消勾选不需要同步的表（右键也可批量取消） - 视图/存储过程同理：若目标库已有同名函数但逻辑不同，不要依赖“覆盖”，先手动导出原定义备份，再勾选同步
- 注意：取消勾选后，该对象的**所有变更**（包括新增字段、改类型）都不会出现在部署脚本里——不是“跳过变更”，而是“彻底忽略这个对象”
为什么部署脚本里出现ALTER TABLE … MODIFY COLUMN却执行失败
这是MySQL常见报错：ERROR 1845 (HY000): Cannot change column 'x' to type 'y': used in a foreign key constraint。Navicat生成DDL时未主动检查外键依赖链，只按对象维度生成语句。
- 根源在
Options → Compare foreign keys：若勾选，Navicat会同步外键定义，但不会自动调整ALTER顺序；若没勾选，则外键差异被忽略，导致脚本缺失ADD CONSTRAINT，后续数据插入失败 - 实操建议：先勾选此项生成完整脚本 → 复制到SQL编辑器 → 手动拆分：先把
DROP FOREIGN KEY和ADD FOREIGN KEY拎出来，放在对应MODIFY COLUMN前后 - 更稳妥做法：在目标库提前执行
SET FOREIGN_KEY_CHECKS = 0;（仅限维护窗口期），同步完再设回1
跨数据库类型同步（如MySQL→PostgreSQL）能用结构同步吗
不能。Navicat结构同步严格限定同类型数据库（MySQL↔MySQL、PostgreSQL↔PostgreSQL），跨类型时连连接选项都不可选。
- 原因在于DDL语法根本不同：MySQL的
TINYINT(1)在PostgreSQL里没有等价类型，Navicat不会做类型映射转换 - 若真需迁移结构，必须用
Data Transfer功能（工具→数据传输），它内置基础类型映射表，但仅支持表结构+数据，且不处理视图/函数/权限 - 替代方案：用
mysqldump --no-data导出源库DDL → 人工改写为PG语法 → 在Navicat中执行（别走同步向导）
最易被忽略的其实是“比较前没清空目标库测试表”——比如本地开发库有users(id PK, name)，测试库已有users(id PK, name, email)，Navicat会认为email该被删，而不是新增。结构同步永远以源库为唯一事实来源，它不理解“增量演进”。
