绝不能让结构同步工具直接在生产库执行删表操作，因其生成的drop table语句不可逆且navicat无二次确认；必须关闭“drop objects not exist in source”和“drop columns not exist in source”选项；删表须走独立评审流程，在测试环境验证后人工执行并监控。
绝不能让结构同步工具直接在生产库执行删表操作。它生成的 drop table 语句一旦运行，就不可逆，且 navicat 不做二次确认——哪怕你只是手滑点错源/目标方向。
为什么“删表”在结构同步里特别危险
结构同步默认把「源库结构」当唯一正确标准。如果源库里某张表被删了，而你又没关掉 Drop objects not exist in source，它就会在目标库（比如生产库）自动生成并执行 DROP TABLE。这不是 bug，是设计逻辑。
- 常见错误现象：
No valid connection selected提示后强行跳过检查，或看到比对结果里有带x标记的表就直接点「Run」 - 使用场景：开发库删了一张废弃中间表，想同步到生产库——但生产库这张表可能还在被某个定时任务读取
- 性能影响：大表
DROP会阻塞元数据锁（MDL），导致后续所有对该库的查询排队，业务接口大面积超时
必须关闭的两个关键选项
进入结构同步向导第二步（Options 页面）后，这两项必须手动取消勾选：
-
Drop objects not exist in source—— 关掉它，否则任何在源库缺失的表、视图、索引都会被删 -
Drop columns not exist in source—— 同理，字段级删除也得禁用；删字段应走独立评审流程，不是结构同步该干的事
注意：Ignore auto-increment value 可以保留勾选，避免因自增 ID 起始值差异误判为结构不一致。
真要删生产表，应该怎么做
结构同步只负责「让目标结构匹配源结构」，不负责「是否该删」的业务判断。删表属于高危变更，必须脱离同步工具走完整流程：
- 先在从库或低峰期测试库执行
DROP TABLE，观察SHOW PROCESSLIST和慢日志是否有异常阻塞 - 确认无应用连接、无定时任务、无外键引用（查
INFORMATION_SCHEMA.KEY_COLUMN_USAGE） - 用
mysqldump --no-data备份原表结构，再执行DROP TABLE IF EXISTS - 删完立刻验证监控指标（如
Table_open_cache_hits是否突降，Innodb_row_lock_waits是否飙升）
真正容易被忽略的是：Navicat 同步界面里那个小小的 x 图标，代表「将在目标库删除」——但它不会告诉你这张表最后一次被 SELECT 是什么时候，也不会提醒你下游 ETL 任务还依赖它。别信图标，信日志和监控。
