每次同步前必须手动确认三项设置，否则源表或目标表必然被静默清空；须逐项核验：Compare options选Structure and data、Target options禁用含source的选项、Advanced页签取消勾选Truncate source table before synchronization。
每次同步前必须手动确认三项设置，否则源表或目标表可能被静默清空——这不是概率问题，是必然结果。
为什么“清空源表”选项会静默生效
Navicat 数据同步的 Truncate source table before synchronization 选项一旦勾选，就直接执行 TRUNCATE TABLE，不走事务、不记 binlog、无法回滚。它不弹窗、不警告、不校验权限，只在「高级」页签底部以小字号呈现，且默认不勾选——但历史配置复用、模板导入、多人共用 profile 都可能导致它被意外启用。
常见错误现象包括：同步后源表 table_rows 突变为 0；SHOW ENGINE INNODB STATUS\G 中残留 Truncating source table 字样；历史记录里明确出现该操作日志。
- 该操作在 MySQL 5.7+ 默认不写 binlog，
mysqlbinlog完全查不到痕迹 -
TRUNCATE是 DDL，InnoDB 不生成 UNDO 日志，ROLLBACK无效 - 恢复只能靠备份或从目标库反向捞数据（前提是目标同步成功且未被覆盖）
同步前必须肉眼核验的三项设置
这不是建议，是保命动作。每次点「开始同步」前，必须逐项扫视：
-
Compare options→ 确认选的是Structure and data，不是Structure only（后者不会清空，但目标表会变空） -
Target options→ 检查If target table exists下拉菜单：只允许选Drop and recreate或Truncate and insert；绝不能出现含source字样的选项（如Truncate source table、Clear source data） -
Advanced页签 → 拉到底部，确认Truncate source table before synchronization未勾选，且旁边没有灰色「已启用」提示
团队协作中真正危险的隐藏风险
多人共用 Navicat profile 或模板时，Truncate source table before synchronization 的状态会被一并保存。A 同事上周为测试环境配过一次清空源表，B 同事本周直接加载该 profile 同步生产库，就等于亲手点了删除键。
更隐蔽的是连接标签页命名混乱：标签页写着「prod-read」，实际连接串指向的是 prod_write 库；或者源/目标方向点反后没注意交换按钮，把生产库当成了源。
- 禁止共享未经脱敏的 profile 文件，尤其含「高级」设置的
- 所有生产连接必须强制使用带环境标识的标签名，如
[PROD-WRITE]、[STAGE-READ] - 每次同步前先运行
SELECT DATABASE();和SELECT @@hostname;双重确认当前会话归属
比设置更关键的是执行前的最后一步
点击「预览」，不是走形式。重点看三行：
- 有没有
TRUNCATE TABLE `xxx`或DELETE FROM `xxx`开头的语句 - 所有
INSERT和UPDATE是否都带WHERE条件，且条件字段是主键或唯一索引 - 语句涉及的表名是否全部是你预期同步的，有没有冒出
log_、tmp_等临时表
预览里一旦出现任何 TRUNCATE 或无条件 DELETE，立刻停手，回头检查「高级」和「目标选项」——别信记忆，信屏幕上的 SQL。
