Navicat在Windows下CPU或内存持续飙高，主因是连接/同步/本地计算失控：无主键大表同步触发全量加载致CPU 100%；闲置连接不释放致内存堆积；自动更新与SQL历史引发隐性泄漏；需优先加主键、限连接数、禁自动功能并清理历史。
navicat 在 windows 下 cpu 或内存持续飙高，**通常不是软件本身“坏了”，而是连接、同步或本地计算行为失控导致的资源堆积**。直接调大 -xmx 或重启往往治标不治本——关键得切断泄漏源和降级策略。
为什么“Comparing records”阶段会让CPU冲到100%
这个阶段 Navicat 并不依赖数据库索引比对，而是把整张表数据拉到本地内存做哈希+排序。一旦源或目标表缺主键、缺 UNIQUE NOT NULL 索引，它就自动退化为全量加载。
- 用
SHOW CREATE TABLE对比两边表结构，确认主键/唯一索引字段名、顺序、NULL 属性、字符集完全一致 - 无主键的大表别硬同步——先加主键，或改用
WHERE id > ? AND id <= ?分批次手动同步 - Navicat 日志里若反复出现
Connection refused或Too many open files，说明线程数已超出系统连接池或端口范围极限
连接管理不当是内存缓慢爬升的主因
每个活动连接默认独占 30–60MB JVM 堆空间（含结果缓存、语法树），而关闭标签页 ≠ 断开连接。闲置连接长期驻留，JVM 不会主动回收这部分内存。
- 右键连接 → 编辑连接 → 高级 → 把最大连接数从默认 100 改为
8，最小连接数设为1 - 断开不用的连接：右键连接 →
断开（不是只关查询窗口）；Oracle 连接断开后建议等 10 秒再重连 - 禁用代码自动完成：工具 → 选项 → 编辑器 → 取消勾选
启用代码自动完成
自动更新和历史记录是隐蔽的内存泄漏点
默认每 24 小时检查更新会常驻 HTTP 连接池，在代理或网络不稳定时反复重试，堆积未释放的 TLS 对象；SQL 历史默认存 1000 条，每条含执行时间+结果摘要，长期不清理可累积几百 MB。
- 关闭自动更新：工具 → 选项 → 常规 → 取消勾选
检查更新；改完后建议关闭所有查询窗口再重连 - 削减历史记录：工具 → 选项 → 环境 → SQL 历史 → 把数量改为
100，并每月手动清一次 - 验证效果：任务管理器中观察
navicat.exe的“工作集”内存是否在空闲 5 分钟后回落 100–300MB
真正难处理的是无主键 + 数千万行的大表同步——它既不受线程数调节影响，也避不开锁竞争，必须前置改造表结构或拆成带条件的子任务。这点最容易被跳过，但恰恰是 CPU 长期飙高的根因。
