Navicat 不直接导致数据库 CPU 飙高，而是暴露或触发慢查询、锁争用等底层问题；需通过系统监控区分是 Navicat 客户端还是 mysqld/postgres 服务端进程占用高，并借助其查询分析器、EXPLAIN、SHOW PROCESSLIST 等功能定位根因。
navicat 本身不直接导致数据库 cpu 飙高，但它暴露、触发甚至放大底层问题——比如慢查询、锁争用或低效连接。诊断必须分清：是 navicat 进程自身吃 cpu，还是它执行的 sql 让 mysqld / postgres 进程 cpu 拉满。
查清到底是哪个进程在飙 CPU
打开系统任务管理器（Windows）或 top -H（Linux/macOS），观察两个关键进程：
-
navicat.exe或Navicat Premium进程占用高 → 问题在客户端：可能是大结果集渲染、插件卡死、或编辑器语法高亮崩了 -
mysqld/postgres/sqlservr.exe进程占用高 → 问题在服务端：Navicat 只是“扳机”，真正要查的是它发出去的 SQL
别跳过这步。很多人一看到 Navicat 卡就去重装，其实 mysqld 正在跑一个没索引的 SELECT * FROM huge_log_table WHERE created_at > '2020-01-01'，这才是根因。
用 Navicat 自带功能抓慢查询
Navicat 的「查询分析器」和「服务器监控」能快速定位问题 SQL，但得会用：
- 执行可疑语句前，先点「解释」按钮看
EXPLAIN输出：重点关注type是否为ALL（全表扫描）、rows是否远超预期、Extra里有没有Using filesort或Using temporary - 连上数据库后，运行
SHOW PROCESSLIST（MySQL）或SELECT * FROM pg_stat_activity WHERE state = 'active'（PostgreSQL），按Time倒序，揪出卡住超过 5 秒的Info字段内容 - 在 Navicat Monitor 中打开「查询分析器」面板，它会自动聚合「运行时间累计最长」和「平均响应最慢」的 SQL，比手动刷
PROCESSLIST更稳
避开 Navicat GUI 的假象干扰
Navicat 界面本身会引入额外开销，尤其在以下场景下容易误判：
- 结果集超过 1 万行时开启「表格视图」：它会尝试渲染全部单元格，CPU 飙高跟数据库无关，关掉「自动调整列宽」和「启用语法高亮」能立竿见影
- 使用「数据同步」或「结构同步」功能：默认开启「比较所有字段」+「校验和验证」，对大表就是 CPU 密集型任务；改用「仅比较主键」或导出 SQL 后用命令行工具执行
- 后台开着「自动保存查询历史」+「启用查询日志」：每条语句都落盘并索引，小库没事，但当历史记录超 10 万条，Navicat 启动/切换标签就会明显卡顿
真正该盯住的不是 Navicat，而是数据库侧指标
Navicat 是镜子，不是源头。一旦确认是服务端 CPU 高，立刻转向数据库原生指标：
- MySQL：查
information_schema.PROCESSLIST+performance_schema.threads关联，用thread_os_id对齐系统线程 PID，再结合top -H -p $PID看具体线程行为 - PostgreSQL：重点看
pg_stat_statements扩展，执行SELECT * FROM pg_stat_statements ORDER BY total_time DESC LIMIT 10，直接列出耗时 Top 10 的 SQL 模板 - 通用技巧：在 Navicat 中执行
SELECT SLEEP(5)，观察是否仍卡 —— 如果卡，说明是 Navicat 渲染问题；如果不卡，那之前卡的一定是真实慢查询
很多团队花两天调 Navicat 设置，却漏掉一条没加索引的 WHERE status = 'pending' AND updated_at ，它每天扫 800 万行，CPU 怎么可能不红？
