Navicat数据同步不支持断点续传，需人工定位断点并添加WHERE条件；结构同步必须先于数据同步；跨版本或字符集不一致易致乱码；大表同步卡顿多因锁表，应调小批次并清理长事务。
同步中断后 Navicat 不自动续传，得手动定位断点
navicat 的数据同步（data sync）本身不支持断点续传——它没有“从上次失败处继续”的内置机制。一旦同步中途失败（比如网络抖动、目标库锁表、超时），下次运行默认从头开始，既浪费时间又可能引发主键冲突或重复写入。
真正能“续传”的，是靠你人工判断已同步到哪一行，并在同步设置里加 WHERE 条件过滤掉已处理的数据。这要求源表有稳定单调递增的字段（如自增 id、带索引的 create_time）。
- 检查同步日志末尾的最后一条成功插入语句，找到其
id或create_time值 - 在同步配置的「高级」页中勾选「使用 SQL WHERE 条件」，填入类似
id > 123456或create_time > '2024-05-20 14:22:33' - 务必确认该字段在源表和目标表都存在、类型一致、且目标表已有对应数据（否则条件过滤会导致漏同步）
用结构同步（Structure Sync）+ 数据同步（Data Sync）组合时顺序不能错
如果同时要同步表结构变更和存量数据，先跑结构同步再跑数据同步是硬性前提。反过来操作，轻则报错 Table xxx doesn't exist，重则因字段缺失导致数据截断或类型转换失败。
更隐蔽的问题是：结构同步默认不勾选「删除目标中不存在的字段」，如果你删了源表一个字段，但没手动勾选该选项，后续数据同步仍会尝试写入这个已不存在的列，直接失败。
- 结构同步前，手动对比源/目标表字段差异，确认是否需要启用「删除字段」和「删除索引」
- 结构同步成功后，立刻点击「刷新目标连接」，避免 Navicat 缓存旧元数据导致数据同步读取错的列定义
- 跨版本数据库（如 MySQL 5.7 → 8.0）同步时，注意
datetime默认精度变化，可能触发隐式转换警告甚至失败
不同环境间同步时，连接配置里的字符集不一致会静默丢数据
常见现象是中文变问号、emoji 被截断、特殊符号乱码，但 Navicat 同步界面不报错，只显示“同步完成 100%”。根本原因是源库、目标库、Navicat 客户端三者的字符集不统一，尤其容易忽略的是 Navicat 连接配置里的「字符集」下拉框——它独立于数据库服务端设置。
例如源库是 utf8mb4，目标库也是 utf8mb4，但 Navicat 连接配置里选了 utf8，那所有 4 字节字符（如 ?、??）都会被转成 ? 写入。
- 在 Navicat 连接属性 → 「高级」页中，把「字符集」明确设为
utf8mb4（不是utf8） - 执行
SHOW VARIABLES LIKE 'character_set%';确认源/目标库的character_set_client、character_set_connection、character_set_database全部为utf8mb4 - 对已有乱码数据，不能靠重新同步修复，必须先清空目标表并修正连接配置，再重跑
大表同步卡住不动？不是网络问题，大概率是 Navicat 默认分批逻辑撞上锁表
Navicat 数据同步默认按 1000 行一批提交，对大表（千万级）来说，每批都走 INSERT ... SELECT 或临时表方式，极易触发目标库行锁或元数据锁（MDL），尤其当目标库有长事务或慢查询正在运行时，你会看到进度条停在 99% 长达几分钟，SHOW PROCESSLIST 里能看到大量 Waiting for table metadata lock。
这不是 Navicat 崩溃，而是它在等锁释放。强行关闭再重试只会让锁堆积更严重。
- 同步前，在目标库执行
KILL掉所有非必要长事务（特别是State为Waiting for table metadata lock的连接） - 在同步配置「高级」页中，把「每批次记录数」调小到
100或50，降低单次锁持有时间 - 避开业务高峰同步；若必须在线同步，优先考虑用
mysqldump --single-transaction+ 命令行导入，比 Navicat 更可控
断点续传本质是权衡：用人工干预换确定性，用字符集和锁意识换数据保真。工具不会替你判断哪一行是安全的“断点”，这一步永远得你来拍板。
