CPU占用达1265%，一点都不慌，90% 的人都误解了 top命令

前两天社群有个用户用top命令查看进程时，有一个进程100%，以为CPU占满了，其实不然，下面我们就详细聊一下这个top命令。

很多人用 top 用了几年，却一直在错误解读它。

下面，我们就用一张真实的 top 截图，系统性讲清楚 top 的正确使用方式，以及最容易踩的认知坑。

先看截图图

MySQL 为何CPU能跑到 1265% ？

截图中最“刺眼”的一行：

PID   USER   VIRT   RES   %CPU   %MEM   COMMAND

6308  mysql 220.7g 212.7g 1265   84.5   mysqld

很多人第一反应：

“CPU 都 1265% 了？服务器要炸了”

但这恰恰是对 top 的第一个误解。上面截图中，MySQL服务多少有点问题，但业务并没有受影响。

误区 1：%CPU 最大只能是 100%

错误理解：

%CPU 是“CPU 使用率”，最大 100%

正确理解：

top 中的 %CPU = 使用的 CPU 核心数 × 100%

我的机器是 16 核：

100% = 1 个核满载1265% ≈ 12.6 个核被 mysqld 占用，并没有达到上限

结论：这台机器的 MySQL 不是异常显示，而是在多核上疯狂并行执行。

误区 2：load average很高 = CPU 已经打满

截图顶部：

很多人一看到 load > 10，立刻下结论：

“CPU负载太高 快扛不住了！”

但你要先清楚一个问题：

这台机器有多少核？

正确判断方式

CPU 核数load ≈ 核数含义4 核load ≈ 4接近满载16 核load ≈ 12完全可接受32 核load ≈ 12偏空闲

load average ≠ CPU 使用率它表示的是：正在运行 + 等待 CPU 的进程数

误区 3：id 很低才说明 CPU 有问题

截图中的 CPU 行：

58.6% idle

这说明什么？

CPU 一半以上是空闲的

这时候再结合：

mysqld：1265%idle：58%

唯一合理的解释是：

多核机器 + 单个进程高并发消耗

误区 4：VIRT 很大 = 内存要炸VIRT 220.7g

很多人看到 VIRT 直接慌了：

“虚拟内存 220G？是不是内存泄漏？”

正确理解

字段含义VIRT进程可用的虚拟地址空间RES真正占用的物理内存SHR可共享内存

MySQL 的 VIRT 很大是正常现象：

InnoDB buffer pool内存映射文件malloc 预留

判断内存是否有问题，看 RES + 系统是否 OOM，而不是看 VIRT

误区 5：free 很小 = 内存不够

截图中：

很多人盯着：

free 只有 8GB，内存要满了！

但 Linux 的内存哲学是：

不用白不用，有些在缓存中

真正要看的字段是：

avail Mem

avail ≈ 30GB说明：系统仍然有足够内存可用

误区 6：top 能直接定位“根因”

这张图最多能得出结论：

MySQL 正在大量消耗 CPU

但你完全不知道为什么，这个就要进入MySQL数据库查看了，很大可能是慢SQL的问题。

正确使用 top

先确认 CPU 核数

load 要和核数对比

%CPU > 100% 是常态

多核时代，不懂这个等于白用 top

内存优先看 avail，不是 free，不是 buff/cache