Navicat结构同步中“Drop objects not exist in source”不删除冗余索引，因其仅作用于表、视图等一级对象，索引被视为附属结构；需手动清理或用mysqldump+diff比对。
navicat结构同步默认不删目标库多余索引，哪怕你勾选了“drop objects not exist in source”
因为“Drop objects not exist in source”这个开关只控制表、视图、存储过程、函数等一级数据库对象，INDEX（索引）不属于它管辖范围。Navicat 把索引视为“附属结构”，不归类为可被删除的独立对象。
常见错误现象：
- 目标库多了一个
idx_user_email_tmp，源库没有，但同步脚本里完全没出现DROP INDEX - 预览界面只显示新增/修改字段，索引差异被静默忽略
- 误以为勾选了“Drop objects not exist in source”就等于“全量清理”，结果上线后冗余索引照常存在、拖慢写入
实操建议：
- 手动清理：同步前在目标库执行
SELECT CONCAT('DROP INDEX ', index_name, ' ON ', table_name, ';') FROM information_schema.statistics WHERE table_schema = 'your_db' AND index_name NOT IN (/* 源库索引名列表 */); - 用
SHOW CREATE TABLE对比源/目标，逐个确认索引是否一致 - 若需自动化，改用
mysqldump --no-data --skip-triggers --routines导出源库 DDL，再用文本 diff 工具比对索引定义
为什么Compare foreign keys勾选后外键顺序错乱
Navicat 生成 DDL 时按对象类型分组输出：ALTER TABLE ... MODIFY COLUMN 全部排前面，ADD FOREIGN KEY 全部堆后面——它不解析依赖树，也不重排语句顺序。
典型报错就是：ERROR 1845 (HY000): Cannot change column 'x' to type 'y': used in a foreign key constraint
使用场景：
- 你要把
user_id INT改成BIGINT，但该列被orders.user_id_fk引用 - Navicat 脚本先跑
MODIFY user_id BIGINT，再跑ADD FOREIGN KEY，中间没DROP FOREIGN KEY
实操建议：
- 务必勾选
Compare foreign keys（否则外键直接丢失） - 生成脚本后，复制到 SQL 编辑器，手动拆分三段：① 所有
DROP FOREIGN KEY→ ② 所有MODIFY/CHANGE/ADD COLUMN→ ③ 所有ADD FOREIGN KEY - Navicat 16+ 可尝试开启
Resolve dependencies automatically（Tools → Options → Data Synchronization → Advanced），但旧版本或复杂嵌套仍需人工干预
Compare collation 和 Compare comments 为什么容易报错
这两项不是“要不要同步”的问题，而是“同步后能不能执行成功”的问题。它们触发的 ALTER TABLE ... CONVERT TO CHARACTER SET 或 COMMENT ON COLUMN 很可能因版本/引擎不兼容直接失败。
参数差异与风险：
-
Compare collation：源库用utf8mb4_0900_as_cs，目标库是 MySQL 5.7（仅支持utf8mb4_general_ci）→ 同步脚本含COLLATE utf8mb4_0900_as_cs→ 执行报错Unknown collation -
Compare comments：Oracle 11g 不支持COMMENT ON COLUMN，但 Navicat 仍会生成 → 部署失败；PostgreSQL 中注释含单引号未转义也会崩
实操建议：
- 跨版本同步前，先查目标库支持的校对规则：
SHOW COLLATION WHERE Charset = 'utf8mb4'; - 若目标库版本老旧，这两项直接取消勾选，后续用手工脚本补注释或调整字符集
- MySQL 8.0+ 且确认两端 collation 兼容时，才打开
Compare collation；否则留空让 Navicat 忽略此项比对
怎么跳过 _tmp、log_ 这类临时表
Navicat 不支持正则或通配符过滤，所谓“排除模式”只能靠手动点选 —— 这是它最反直觉的设计缺陷。
关键细节：
- 在“结构比对”界面左上角的
Source Objects树形列表中，必须逐个展开表节点，右键取消勾选那些backup_user、log_action_2025类表 - 取消勾选 ≠ 跳过变更，而是彻底从比对范围移除：哪怕源库给
tmp_order加了字段，也不会出现在脚本里 - 视图、函数、事件同理，不能只关表，还要检查其他对象类型下是否有命名带
_tmp的
容易踩的坑：
- 误以为在 Options 里关掉某项就能全局过滤 —— 实际没有这样的开关
- 批量右键取消后没刷新预览，导致脚本里仍含已取消的表（需点“重新比对”按钮）
- 开发库有
test_xxx表，测试库也有同名但结构不同，取消勾选后两边永远不一致，却毫无提示
真正安全的做法，是在同步前用 SQL 确认源库哪些表该上生产：SELECT table_name FROM information_schema.tables WHERE table_schema = 'dev' AND table_name NOT REGEXP '^(_|log_|backup_|tmp_)'，再对照手动勾选。
