前两天社群里一位用户在用 top 命令查看进程时，发现有个进程显示 CPU 占用 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 average: 12.17, 11.71, 10.50

很多人一看到 load > 10，立刻就下结论：“CPU 负载太高，快扛不住了！”

但你得先搞清一个问题：这台机器有多少个 CPU 核心？

正确判断方式是：
load average ≠ CPU 使用率。
它表示的是：正在运行 + 等待 CPU 的进程数量。

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

截图中的 CPU 状态行：

%Cpu(s): 39.9 us, 0.4 sy, 58.6 id

58.6% idle
这说明什么？
CPU 一半以上是空闲的。

这时候再结合：
mysqld：1265%
idle：58%

唯一合理的解释是：这是一台多核机器，且单个进程正在高并发地消耗 CPU。

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

VIRT 220.7g
RES  212.7g

很多人看到 VIRT 直接就慌了：“虚拟内存 220G？是不是内存泄漏了？”

正确理解是：
MySQL 的 VIRT 值很大是正常现象，因为：

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

判断内存是否有问题，应该看 RES + 系统是否出现 OOM，而不是看 VIRT。

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

截图中的内存信息：

KiB Mem:  263973326 total
        8088860 free
        28235512 buff/cache
        30766036 avail Mem

很多人只盯着：free 只有 8GB，内存要满了！

但 Linux 的内存哲学是：不用白不用，内存会尽可能用于缓存。

真正要看的字段是 avail Mem。

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

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

这张图最多只能得出结论：MySQL 正在大量消耗 CPU。

但你完全不知道原因，这就需要进入 MySQL 数据库内部查看了。很可能是慢查询导致的。

正确使用 top

先确认 CPU 核心数：

lscpu

load 要和核心数对比：

load < CPU核心数 ≠ 性能问题

%CPU > 100% 在多核时代是常态，不懂这个等于白用 top。

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