Navicat虽无断点续传开关，但可通过手动跳过已同步表+自定义WHERE条件切片实现：先查目标库已存在表，再在源库反查未同步表并取消勾选；大数据量时启用高级模式，用主键ID分段传输。
同步中断后怎么接着传，不重跑也不丢数据
navicat 本身没有“断点续传”这个开关，但通过组合配置可以实现等效效果——关键是让下次同步只处理**未完成的表**或**未写入的记录**，而不是清空重来。实际操作中，90% 的中断问题出在目标库已有部分数据却没被跳过。
- 先确认中断时哪些表已成功同步：在 MySQL 目标库执行
SELECT table_name FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'your_db'，记下结果 - 回到 Oracle 源库，用这些表名反查缺失项：
SELECT table_name FROM all_tables WHERE owner = 'YOUR_SCHEMA' AND table_name NOT IN ('t1','t2','t3') - 在 Navicat 数据传输向导的【选择对象】步骤中，**手动取消勾选已同步的表**；不要依赖“自动识别”，它不会感知上次中断状态
- 如果单表数据量大（比如超百万行），务必进【高级模式】→启用【自定义记录集】→用主键 ID 切片，例如
WHERE id > 1000000 AND id ，后续从中断 ID 继续
为什么“保持连接间隔”设了还是断连？
同步过程耗时长，连接空闲被中间网络设备（如防火墙、云厂商SLB）主动切断，光靠 Navicat 的 保持连接间隔 不够，得双保险。
- 在连接编辑页 → 【高级】选项卡，把
保持连接间隔设为60（单位秒），不是 0 - 同时勾选
使用Keep Alive，这会触发操作系统级 TCP 心跳，比应用层探测更底层、更可靠 - 若目标库是云数据库（如阿里云 RDS、腾讯云 CDB），还需在控制台检查「连接空闲超时」设置，默认常为 300 秒，建议调大到 1800
- 实测发现：仅设间隔不勾 Keep Alive，仍可能在 4~5 分钟后断开；两者都开，稳定运行 2 小时以上无异常
同步配置保存成 Profile 后，下次加载为啥映射全乱了
Profile 保存的是连接名、库名、表映射关系和动作选项，但**不保存连接的实际状态**。如果源或目标库结构变了（比如加了字段、改了主键），再 Load Profile 就会错配。
- 每次 Load Profile 后，必须点进 Step 2【表映射】，逐个核对
Key Mapping是否仍指向主键或唯一索引列 - 特别注意字段映射：如果源表新增了
updated_at字段，而目标表还没加，Profile 会默认把它也拖过去，导致同步失败报错Unknown column 'updated_at' in 'field list' - 安全做法是：首次同步成功后，立刻导出 Profile；之后每次复用前，先做一次
Compare&Preview，看预览里有没有红色报错行
跨库同步（Oracle→MySQL）时字段类型不兼容怎么办
Navicat 会自动做基础类型映射（如 NUMBER→DECIMAL），但遇到 CLOB、BLOB、DATE 精度差异或自定义类型时，容易卡在预览或执行阶段。
- Oracle 的
CLOB默认映射到 MySQL 的TEXT，但如果内容超 64KB，需手动改为MEDIUMTEXT或LONGTEXT - Oracle 的
DATE包含时分秒，MySQL 的DATE只存日期，会导致时间截断；应将目标字段改为DATETIME或TIMESTAMP - 在 Step 2【Field Mapping】里，双击目标字段名可修改其类型；别信默认值，尤其当预览显示
Warning: Type conversion may cause data loss - 如果字段含特殊字符（如中文注释、emoji），同步前确保两边库字符集都是
utf8mb4，否则可能报错Incorrect string value
真正麻烦的不是操作步骤多，而是每一步都依赖上一步的准确状态——比如连接没保活，同步到一半断了；Profile 没重验 Key Mapping，更新时把主键当普通字段覆盖了；类型没手动校正，某张表永远卡在预览页。这些坑不会报错，但会让同步结果不可信。
