无主键大表同步卡在“comparing records”是因为navicat降级为全量拉取比对，需确保源目标表主键或unique not null索引字段名、类型、not null属性、顺序、字符集、collate完全一致，否则必须手动分片或加where条件。
为什么无主键大表同步会卡在“Comparing records”并吃满CPU
Navicat 在这个阶段不走数据库索引，而是把源表和目标表的全量数据拉到本地内存，做哈希比对和排序。一旦任一端缺失主键或 UNIQUE NOT NULL 索引，它就自动降级为全量拉取 —— 千万级表意味着几GB内存占用、频繁 swap、macOS/Linux 上极易触发 OOM 或 CPU 100%。这不是 Navicat 设置能调回来的问题，是底层逻辑决定的硬限制。
必须先确认两边表是否真有匹配的主键或唯一键
别跳过这步。用 SHOW CREATE TABLE 分别查源和目标表，逐字对比：
- 主键字段名、类型（
INTvsBIGINT）、是否NOT NULL必须一致 -
UNIQUE NOT NULL索引的字段顺序、字符集、排序规则（COLLATE）也要完全相同 - 哪怕只是目标表多一个
GENERATED列或少一个COMMENT，Navicat 也可能拒绝使用该索引做比对
如果发现不一致，优先修复结构，而不是硬调线程数或批次大小。
实在没法加主键？那就放弃“全自动同步”，改用手动分片
对无主键大表，Navicat 的同步逻辑已经失效。此时强行点“同步”，等于让客户端扛下全部计算压力。可行路径只有两个：
- 用业务字段（如
created_at、order_no）人工构造 WHERE 条件，在同步向导的表映射页 →Options→ 勾选Use WHERE condition，填入类似created_at >= '2026-09-01' AND created_at - 若连时间字段都没有，且数据可接受按物理顺序切分，可用
LIMIT+OFFSET配合多次同步（注意 MySQL 的OFFSET深翻性能问题，建议改用游标式：上一批最大id作为下一批起点） - 每批控制在 5000～10000 行，
高级页中设每批记录数与之匹配；设太高会内存溢出，太低则事务过多、锁等待加剧
别信“调高线程数能提速”，它反而会让无主键同步更慢
Navicat 对无主键表的比对是单线程内存哈希，线程数只影响后续 INSERT/UPDATE 阶段。但如果你开了 8 个线程，它会并发拉 8 次全表 —— 不是更快，是直接把数据库和本地内存一起拖垮。
- 实测局域网环境下，无主键表同步时线程数设为
1反而最稳 - 若必须并发写入，应先用分片条件拆成多个独立 .ncx 任务，再用系统计划串行调度
- 检查 Navicat 日志里是否有
Too many open files或Connection refused，这是连接池被耗尽的信号，不是同步逻辑问题
最顽固的瓶颈从来不在 Navicat 界面里，而在你没加主键的那张表上。工具不会替你补设计缺陷，它只会把缺陷放大成 CPU 飙升和同步失败。
