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

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

先看截图：

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

PID   USER   VIRT   RES   %CPU   %MEM   COMMAND6308  mysql 220.7g 212.7g 1265   84.5   mysqld

很多人第一反应：

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

错误理解：

正确理解：

我的机器是 16 核：

• 100% = 1 个核满载

   

• 1265% ≈ 12.6 个核被 mysqld 占用，并没有达到上限

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

截图顶部：

load average: 12.17, 11.71, 10.50

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

但你要先清楚一个问题：

这台机器有多少核？

正确判断方式：

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

截图中的 CPU 行：

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

58.6% idle

这说明什么？

CPU一半以上是空闲的。

这时候再结合：

• mysqld：1265%

   

• idle：58%

唯一合理的解释是：

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

VIRT 220.7gRES  212.7g

很多人看到 VIRT 直接慌了：

正确理解：

MySQL 的 VIRT 很大是正常现象：

• InnoDB buffer pool

   

• 内存映射文件

   

• malloc 预留

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

截图中：

KiB Mem:263973326 total8088860 free28235512 buff/cache30766036 avail Mem

很多人盯着：

但 Linux 的内存哲学是：不用白不用，有些在缓存中。

真正要看的字段是：avail Mem。

• avail ≈ 30GB

   

• 说明：系统仍然有足够内存可用。

这张图最多能得出结论：

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

1）先确认 CPU 核数

lscpu

2）load 要和核数对比

load < CPU核数 ≠ 性能问题

%CPU > 100% 是常态。

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

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