Navicat同步卡在“Comparing records”阶段导致CPU飙升，因其不走数据库索引，而是在本地内存全量拉取并哈希排序；源或目标表缺失主键或UNIQUE NOT NULL索引即触发该降级行为，须确保两边表结构及索引完全一致，否则应先加主键或改用条件分批同步。
Navicat 同步卡在 “Comparing records” 阶段导致 CPU 飙升
这阶段 navicat 并不走数据库索引比对，而是把整张表 select 到本地内存，做全量哈希计算和排序。一旦源表或目标表缺失主键或 unique not null 索引，就会触发该降级行为。
常见错误现象：同步进度长期停在 “Comparing records”，Mac/Linux 上更易触发 OOM 或系统级内存交换；Windows 上可能只表现为风扇狂转、Navicat 进程占满单核。
- 用
SHOW CREATE TABLE table_name分别检查源库和目标库的表结构，重点核对：PRIMARY KEY是否存在且字段顺序一致、UNIQUE NOT NULL索引是否同名同列同顺序、字符集与排序规则（COLLATE）是否完全匹配 - 若表确实无主键，不要硬同步 —— 先加主键，或改用带条件的分批同步（如
WHERE id BETWEEN ? AND ?） - Navicat 日志里若出现大量重复的
SELECT * FROM ...语句，基本可确认已进入全量拉取模式
并发线程数设太高反而加剧 CPU 压力
Navicat 的「高级」设置中可调同步线程数，但设成 8 或 16 不等于更快。它受限于本地 HTTP 连接池、MySQL 的 max_connections、甚至 Linux 的临时端口范围（默认 32768–65535）。
实测多数局域网环境，设为 2～4 最稳；超过 6 后平均耗时常反升，且容易触发 Too many open files 或 Connection refused 报错。
- 检查 Navicat 日志末尾是否有
java.net.SocketException: Too many open files—— 这是系统资源见顶的明确信号 - Windows 上可临时提高句柄上限（通过注册表或第三方工具），但治标不治本；Linux/macOS 应优先调低线程数，并用
ulimit -n确认当前限制 - 若目标库在远程云服务器，网络延迟会放大线程争抢效应，此时
2线程往往比4更快更稳
ER 图导出卡在 “Loading schema” 时 CPU 暴涨
Navicat 构建 ER 模型需多次短连接拉取 INFORMATION_SCHEMA，对连接稳定性比普通查询更敏感。一旦中间链路（如代理、防火墙、ZTNA 网关）静默中断，Navicat 会反复重试并堆积未释放的连接对象，导致本地 CPU 持续空转。
这不是权限问题（那种会明确报 Access denied），而是底层连接建立后，在首次元数据查询阶段就断开。
- 临时关闭所有代理软件（Clash、Surge、Proxyman 等），或在连接配置的「高级」页中显式取消勾选
Use proxy server - 用命令行验证端口连通性：
nc -zv your-db-host.com 3306（不通 ≠ 数据库挂了，很可能是安全组或 NAT 网关拦截） - 云数据库（如阿里云 RDS）务必确认白名单填的是你当前出口公网 IP，不是局域网 IP（如
192.168.x.x）
SQL 查询本身未优化，拖累 Navicat 渲染和解析
Navicat 执行一个未优化的查询（比如没加 LIMIT 的大表 SELECT *），不仅数据库 CPU 高，Navicat 自身也要解析成千上万行结果、渲染表格、维护滚动状态 —— 这部分逻辑纯吃本地 CPU，和数据库负载无关。
典型表现：执行完查询后 Navicat 界面卡死数秒，任务管理器里 Navicat 进程 CPU 占用突增，而 mysqld 已经返回完成。
- 始终用
EXPLAIN检查关键查询，避免type=ALL、rows远超预期、Extra出现Using filesort或Using temporary - 在 Navicat 中手动加
LIMIT 100再执行，观察 CPU 是否回落 —— 若明显改善，说明是结果集过大导致本地解析瓶颈 - 禁用 Navicat 的「自动调整列宽」和「高亮重复值」等 UI 功能（工具 → 选项 → 查看），这些在大数据量下会显著增加渲染开销
真正难处理的是无主键大表同步——它既不能靠调线程数解决，也很难靠错峰规避，必须前置改造表结构或拆成带条件的子任务。这点容易被忽略，但却是 CPU 长期飙高最顽固的根因。
