navicat本身不执行sql计算，cpu飙升一定发生在数据库服务端；诊断需聚焦show processlist和explain analyze，排查sending data、sorting result等状态及未走索引的过滤、全量聚合、隐式嵌套分页等问题。
Navicat 本身不执行 SQL 计算，CPU 飙升一定发生在数据库服务端（如 MySQL、PostgreSQL），Navicat 只是触发者和结果接收方；诊断必须聚焦数据库内部线程与执行计划，而非 Navicat 进程本身。
查 SHOW PROCESSLIST 看实时状态
连接数据库后立即执行：SHOW FULL PROCESSLIST WHERE COMMAND != 'Sleep' AND TIME > 5 ORDER BY TIME DESC LIMIT 10;
重点关注以下字段：
-
STATE值为Sending data、Copying to tmp table、Sorting result或Creating sort index→ 表明正在做大量计算或临时表操作 -
INFO显示的 SQL 是否含GROUP BY、ORDER BY、DISTINCT、多表JOIN或窗口函数 → 这些是 CPU 密集型操作高发点 -
TIME持续增长且远超预期 → 说明执行卡在某个阶段，不是网络或客户端问题
用 EXPLAIN ANALYZE 看真实执行开销
把 Navicat 中跑慢的统计 SQL 拿出来，在数据库命令行中加前缀执行：
EXPLAIN ANALYZE SELECT COUNT(*), AVG(price) FROM orders WHERE created_at > '2026-08-01';
关键看输出里的：
-
Rows Removed by Filter（PostgreSQL）或filtered（MySQL）值极大 → 条件未走索引，实际扫描行数远超返回行数 -
Execution Time占比集中在Sort或Hash Aggregate节点 → CPU 瓶颈明确在内存排序或聚合计算 - 出现
Materialize或Temporary table→ 说明中间结果无法流式处理，被迫落盘或全量加载
确认是否被 Navicat 自动改写或分页拖累
Navicat 在 GUI 中执行查询时，默认会加隐式 LIMIT 和偏移逻辑，尤其在「结果表格」视图下。它可能把原 SQL 改写成：
SELECT * FROM (your_original_agg_sql) AS _navicat_subquery LIMIT 1000 OFFSET 0;
这种嵌套会导致：
- 聚合计算先全量做完，再截断 → 白耗 CPU
- 若原 SQL 含
ORDER BY，排序仍需完整执行，哪怕只取前 1000 行 - Navicat 日志里若出现重复执行同一语句 + 不同
LIMIT/OFFSET→ 是它在“懒加载”翻页，加重负担
解决办法：在 Navicat 的查询窗口右键 → 「取消自动分页」，或手动加 LIMIT 到原始 SQL 末尾，避免嵌套。
检查 Navicat 是否启用「获取全部结果」模式
这个选项（常位于查询执行按钮旁下拉菜单）会让 Navicat 强制拉取全部结果集到本地内存，对聚合类 SQL 尤其危险：
- 一个
COUNT(DISTINCT user_id)在千万级表上，结果只有 1 行，但 Navicat 仍会尝试缓存整个中间哈希表 - Mac/Linux 上容易触发
java.lang.OutOfMemoryError: Java heap space，继而引发频繁 GC，CPU 暴涨 - Windows 上表现为 Navicat 进程单核占满、鼠标卡顿，但
mysqld进程反而回落——说明压力已转移到客户端
务必关闭该选项，改用「按需获取」或明确加 LIMIT 控制结果集大小。
真正容易被忽略的是：Navicat 的「统计分析」功能（比如点击列头自动算 MIN/MAX/COUNT）会悄悄发起额外元数据查询 + 全字段采样，这些请求不显示在主 SQL 区域，却一样吃 CPU。关掉所有列自动统计，只在必要时手动执行目标 SQL。
