Navicat 17自动化任务CPU占满的根因是无主键表触发全量内存哈希比对、navicat.exe误用于计划任务强制GUI初始化、闲置连接堆积致JVM GC飙升或SQL历史/自动更新隐性泄漏；必须改用navicatcmd.exe、加主键或分片同步、限连接数并禁用自动功能。
Navicat 17 自动化任务占满 CPU 不是任务本身“太忙”，而是它在无主键表同步、闲置连接堆积或 GUI 线程被错误触发时，进入不可控的本地计算循环——根本没把资源花在数据库上，全耗在自己内存里了。
无主键大表同步触发全量哈希比对
Navicat 同步（尤其是「数据同步」功能）默认用主键/唯一索引做增量比对。一旦源或目标表缺主键、缺 UNIQUE NOT NULL 索引，它就自动退化为「全表拉取 + 内存哈希 + 逐行比对」，CPU 直接飙到 100%。
- 用
SHOW CREATE TABLE table_name检查两边表结构，确认主键字段名、NOT NULL属性、字符集、排序规则完全一致 - 千万级无主键表别硬同步：先加主键，或改用
WHERE id BETWEEN ? AND ?分批次手动导出+导入 - 同步前在 Navicat 中右键表 →「分析表」，看是否提示「No primary key found」
navicat.exe 被误用于计划任务导致 GUI 初始化失控
Windows 任务计划程序调用 navicat.exe 执行自动化任务时，即使没图形界面，它仍会强制初始化完整 GUI 子系统（窗口管理、渲染、消息泵），在无桌面会话下极易卡死并持续占用 CPU。
- 必须改用
navicatcmd.exe：任务中「程序或脚本」填绝对路径，如"C:\Program Files\PremiumSoft\Navicat Premium 17\navicatcmd.exe" - 「起始于(可选)」字段必须填同一目录，否则依赖 DLL 加载失败，进程反复重启抢 CPU
- 参数中
--profile值必须与连接属性「常规」页里的 Profile Name 完全一致（区分大小写），错一个字符就会无限重试
闲置连接不释放引发 JVM 堆膨胀与 GC 飙升
每个活动连接在 Navicat 17 中默认独占 40–70MB JVM 堆空间（含结果缓存、语法树、连接状态）。关闭标签页 ≠ 断开连接，闲置连接长期驻留，JVM 不主动回收，最终触发频繁 Full GC，CPU 被 GC 线程吃满。
- 任务执行完后，在 Navicat 中手动执行
KILL CONNECTION [id]（从SHOW PROCESSLIST获取 ID），别只关窗口 - 工具 → 选项 → 环境 → 设置「最大并发连接数」≤ 3，避免自动开太多连接
- 禁用「自动重连」：连接属性 → 高级 → 取消勾选，防止网络抖动后不断新建连接
SQL 历史与自动更新隐性泄漏 CPU
默认开启的 SQL 历史（1000 条）和每 24 小时一次的自动更新检查，会在后台常驻 HTTP 连接池和 TLS 上下文。网络不稳定时反复重试，TLS 握手对象堆积，GC 压力陡增。
- 工具 → 选项 → 常规 → 取消勾选「检查更新」
- 工具 → 选项 → 环境 → SQL 历史 → 数量改为
100，并每月清空一次 - 验证是否生效：空闲 5 分钟后打开任务管理器，观察「工作集」内存是否回落至 200MB 以内
真正难处理的是那种既没主键、又没索引、还跨库同步的千万级表——它绕过了所有线程限制，直接把整张表加载进内存哈希比对，CPU 占满是必然结果。这点最容易被跳过，但恰恰是自动化任务卡死的根因。
