源表被清空导致目标为空，因误勾选“Truncate source table before synchronization”，该选项静默执行TRUNCATE且不记录binlog、不可回滚。
Truncate source table before synchronization 被勾选了，但你没注意到——这是目标端数据为空最常见、也最危险的原因。它不会清空目标表，而是直接把源表清空，导致同步时读不到任何数据，目标自然写入为空。
同步前源表被静默清空了
Navicat 数据同步默认是「读源、写目标」，但高级选项里藏着一个开关：Truncate source table before synchronization。一旦勾选，它会在同步开始前执行 TRUNCATE TABLE，不走 binlog、不可回滚、无确认弹窗。
- 现象：任务日志显示“Synchronization completed”，但目标表空，源表也空——说明源被清了，同步读了个寂寞
- 验证方式：右键 Navicat 左侧「同步」节点 → 「历史记录」→ 打开最近一次任务 → 搜索
Truncating source table，命中即实锤 - 注意：该选项在向导「Advanced」页签底部，文字小、位置偏；某些版本翻译为「清空源表」或「清除源数据」，字眼不统一，务必逐字核对
目标库只读导致写入失败但不报错
如果目标库开启了 read_only = 1（尤其 MySQL 从库），Navicat 同步会尝试插入/更新却全部被拒绝，而界面可能只显示“成功”或模糊错误（如 Access denied），实际一行未写入。
- 必须手动验证：
SELECT @@read_only;和SELECT @@super_read_only;，两个都得是0 - 云数据库（如阿里云 RDS）禁用
SET GLOBAL，只能通过控制台关闭只读实例，不能连上就执行 SQL - 即使解除只读，也要重连 Navicat 或手动执行一条
INSERT验证写入能力，避免权限缓存或连接未刷新
字段映射或键配置错误导致“零行同步”
同步依赖准确的键映射（Key Mapping）来比对源/目标记录。若主键/唯一键未正确指定，Navicat 无法识别“哪些该更新、哪些该插入”，最终可能跳过全部操作。
- 进入同步向导 Step 2 → 点击某张表 → 查看「Key Mapping」是否指向真实主键（如
id），而不是随便选了个字段 - 若目标表无主键或唯一索引，
Update records和Delete records会失效，只剩Insert records可用；但若源表也无主键，且启用了Delete records，可能因无法定位而跳过所有行 - 预览阶段（
Compare & Preview）中若显示 “0 rows to insert/update/delete”，基本可判定键或映射出了问题，不是数据没传过去，而是根本没比出来差异
用户权限不足导致“读不到源，也写不了目标”
同步过程需要两个权限环：源库的 SELECT（含所有字段）、目标库的 INSERT/UPDATE/DELETE。任一环节缺失，都会静默失败。
- 源端权限陷阱：账号只有列级
SELECT(id,name)权限，但 Navicat 默认执行SELECT *，整行被跳过 → 源数据为空 → 目标同步为空 - 查权限命令：
SHOW GRANTS FOR CURRENT_USER();，重点确认是否有SELECT ON `db`.`table` - 目标端权限陷阱：用户有
SELECT但没INSERT，Navicat 可能不报明确错误，只在日志里写 “Failed to execute statement”，需打开「详细日志」才能看到
TRUNCATE 的 OK，也可能是 read_only 拒绝写入后返回的“语句已解析完毕”。验证必须落到数据本身：查源表行数、查目标表行数、解压日志、翻详细输出。 
