MySQL自身不暴露CPU%或memory_usage等系统级指标，监控必须分两层：先看mysqld进程资源占用（如top -u mysql、pidstat），再看系统整体资源（free -m、/proc/meminfo）；SHOW GLOBAL STATUS仅提供间接线索，无法反映真实CPU使用率。
直接看系统级指标，MySQL自身不暴露CPU%或memory_usage这类操作系统维度的数值——它只管自己怎么用资源，不管宿主机还剩多少。所以监控必须分两层：先看mysqld进程本身吃了多少，再看整个系统是否快扛不住了。
top 或 htop 看 mysqld 进程的实时 CPU 和内存占用
这是最快速、无需配置的第一步。执行top -u mysql（假设 MySQL 以mysql用户运行）或htop -u mysql，重点关注两列：
-
%CPU：单个mysqld进程的 CPU 占用率，持续 >80% 就值得怀疑 -
RES（常以 MB 显示）：该进程实际使用的物理内存大小，不是VIRT
注意：top默认按 CPU 排序，但mysqld可能被其他进程（如备份脚本、日志轮转）盖过去，务必加-u mysql过滤；如果看到多个mysqld进程，说明启用了多实例，要逐个检查。
pidstat -p $(pgrep mysqld) 1 捕捉秒级波动
top是采样快照，容易漏掉短时尖峰。pidstat能稳定输出每秒数据，更适合抓取间歇性 CPU 飙高：
-
pidstat -p $(pgrep mysqld) 1输出%usr（用户态 CPU）、%sys（内核态 CPU）、VSZ（虚拟内存）、RSS（常驻内存） - 若
%usr远高于%sys，大概率是 SQL 执行逻辑耗 CPU；若%sys异常高，可能是锁竞争或上下文切换频繁 - 观察
ctxt（上下文切换次数）：突增往往意味着线程争抢严重，比如大量短连接或锁等待
free -m 和 /proc/meminfo 看系统内存是否被吃紧
MySQL 的内存使用会直接影响系统可用内存，但free显示的“used”不可信，关键看available：
-
free -m输出中，available字段才是可立即分配给新进程的内存，低于 1GB 就危险 - 如果
available持续偏低，而mysqld的RSS又很大，基本可判定是 MySQL 缓冲池（innodb_buffer_pool_size）配得太大，挤占了系统缓存和其它服务空间 - 进一步查
/proc/meminfo里的SwapTotal和SwapFree：一旦SwapFree接近 0，说明已开始交换，MySQL 性能必然断崖下跌
为什么不能只依赖 SHOW GLOBAL STATUS？
很多人想用SHOW GLOBAL STATUS查 CPU，但结果只会失望——MySQL 没有Cpu_usage这类状态变量。它提供的是间接指标：
-
Threads_running：活跃线程数突然翻倍，往往伴随 CPU 上升，但它不等于 CPU 使用率 -
Innodb_rows_read、Questions：QPS 或扫描行数激增，可能是 CPU 上升的原因，但不是结果本身 -
Handler_read_rnd_next：全表扫描次数猛增，说明索引失效，会推高 CPU，但需结合执行计划确认
这些值只能帮你推测“为什么 CPU 高”，不能告诉你“现在 CPU 到底多高”。真正的 CPU 监控，永远在操作系统层面，不在 SQL 层面。
