Navicat同步卡在“Comparing records”且CPU飙升，主因是并发线程数过高（建议设为2～4），需在同步向导Options→Advanced中修改Number of threads；若仍卡顿，须排查连接数限制、表缺失主键/唯一索引及业务高峰锁冲突。
同步时CPU飙升，先查并发线程数是否设太高
Navicat数据同步卡在“Comparing records”阶段且CPU持续90%+，大概率是并发线程数超出了本地资源或数据库连接池承受能力。它不是越快越好，而是容易因争抢连接、触发重试、放大锁等待而反向拖垮数据库。
- 默认值往往设为8或16——这在局域网小表同步中尚可，但对远程MySQL生产库基本不可用
- 实测稳定上限通常为2～4：超过6线程后，
Threads_running常突破10，SHOW PROCESSLIST里大量Sleep和Locked状态 - Windows上若目标库在云服务器（如阿里云RDS），网络延迟会加剧线程空转；Linux/macOS则更容易因内存不足触发swap，导致界面假死
在哪里改并发数？别只看“高级”按钮
Navicat的线程设置藏得深，且不同版本路径略有差异。v16+用户必须进深层配置，否则界面上的“高级”选项可能根本没生效。
- 启动同步向导 → Step 1点【Options】→ 切换到【Advanced】页签
- 找到
Number of threads输入框（不是“最大连接数”或“超时时间”） - 手动改为
2或3，务必点【OK】保存再点【Next】，否则该设置不写入任务配置 - v15及更早版本需在【Tools】→【Options】→【Data Synchronization】全局设置中修改，影响所有后续同步任务
改了线程数还卡？检查这三个隐性瓶颈
线程数只是表象，真正压垮数据库的往往是它暴露出来的底层问题。以下三点不排查，调线程等于白调。
-
Connection refused或Too many open files出现在Navicat日志里？说明系统级连接数已满，要调/proc/sys/net/ipv4/ip_local_port_range（Linux）或Windows注册表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\MaxUserPort - 源表或目标表缺失主键/UNIQUE NOT NULL索引？Navicat会自动降级为全量拉取+内存哈希比对，此时调线程毫无意义——先用
SHOW CREATE TABLE确认两边索引定义完全一致（含字段顺序、NULL属性、字符集） - 同步任务被安排在业务高峰（如9:00–11:30），即使线程数为2，也会因MDL锁、行锁等待导致反复重试，CPU空转。错峰不是权宜之计，而是必须项
真正顽固的负载问题，往往不在Navicat设置里
当表无主键、数据量超千万、且必须白天同步时，降低并发数只能缓解症状。这类场景下，Navicat同步逻辑本身已成瓶颈——它无法做条件分片、不支持游标式遍历、也不提供断点续传。这时候最有效的动作不是调参数，而是停掉同步任务，先用ALTER TABLE ADD PRIMARY KEY (id)补主键，或拆成WHERE id BETWEEN ? AND ?的多个子任务手动执行。这点最容易被忽略，但却是生产环境CPU长期飙高的根因。
