数据库CPU占用过高如何排查_慢查询日志分析与Show Processlist

2次阅读

SHOW PROCESSLIST 可实时查看正在执行的慢 SQL,重点关注 State 为 Sending data 等、Time 超 5 秒的连接;需启用 slow_query_log 并设 long_query_time≤1,结合 Rows_examined 分析真实 CPU 消耗源。

数据库 CPU 占用过高如何排查_慢查询日志分析与 Show Processlist

查当前正在跑的慢 SQL:用 SHOW PROCESSLIST 快速抓活口

CPU 飙高时,最直接的线索就是“此刻正在干啥”。SHOW PROCESSLIST 不查日志、不等采样,立刻看到所有连接在执行什么语句、卡在哪一步、跑了多久。

  • 重点关注 State 列为 Sending dataCopying to tmp tableSorting result 的行——这些不是简单查询,是真正在消耗 CPU 的重操作
  • Time 值大于 5 秒的,基本可判定为异常;若大量连接 Time 持续增长,说明查询堵住了,可能锁表或索引失效
  • 别只看 root 用户,应用连接池常用固定账号(如 app_user),要盯住实际业务用户下的长时连接
  • 注意:SHOW PROCESSLIST 默认只显示本用户会话,加 WITH FULL(MySQL 8.0+)或用 SUPER 权限才能看到完整列表,否则可能漏掉关键线程

确认慢查询是否被记录:检查并启用 slow_query_log

临时抓到的语句只能反映“此刻”,但 CPU 飙升往往是周期性或批量触发的。慢查询日志才是回溯根因的证据链。

  • 先确认是否开启:SHOW VARIABLES LIKE 'slow_query_log' —— 返回 OFF 就白忙,得立刻开
  • 开日志本身不耗资源,但 long_query_time 设太高(比如默认 10 秒)等于没开:线上建议设为 10.5,尤其 QPS 高的实例
  • 务必同时打开 log_queries_not_using_indexes:很多“不慢”的查询因没走索引,在高并发下集体压垮 CPU,这类语句不会进慢日志,除非显式开启该选项
  • 日志路径由 slow_query_log_file 决定,别假设它在 /var/lib/mysql/ 下——用 SELECT @@slow_query_log_file 确认真实位置,避免查错文件

分析慢日志时,别只盯着 Query_time

很多人一看到 Query_time: 2.345s 就去优化这条 SQL,结果改完发现 CPU 还是 100%——因为真正吃 CPU 的,可能是 Rows_examined: 2847391 这种扫描了近三百万行的“伪快查询”。

  • Rows_examined 高 + Query_time 低 = 典型索引缺失或条件未命中索引,语句本身短,但每秒执行几百次就把 CPU 拉满
  • Lock_time 显著高于 Query_time?说明不是 CPU 问题,是锁争用,得看 INFORMATION_SCHEMA.INNODB_TRX 和锁等待链
  • mysqldumpslow -s t -t 10 /path/to/slow.log 聚合统计,但注意:它会把带不同参数的同构 SQL(如 WHERE id=123WHERE id=456)合并,掩盖参数化查询的真实分布
  • 真正有效的做法是:用 grep "SELECT" slow.log | awk '{print $NF}' | sort | uniq -c | sort -nr | head -20 快速揪出高频模板,再结合 Rows_examined 排序筛选

索引不是万能解药:警惕 CREATE INDEX 引发的写放大

看到 Rows_examined 高就加索引?小心从 CPU 瓶颈变成 IO 瓶颈甚至主从延迟爆炸。

  • 对写多读少的表(如订单明细、日志类),在 user_id 上加索引可能让每次 INSERT 多写 3–4 次磁盘(聚簇索引 + 二级索引 +undo+redolog),反而推高 CPU 和 IO
  • ALTER TABLE …… ADD INDEX 在大表上是阻塞操作(MySQL 5.6+ 支持 ALGORITHM=INPLACE,但仍有锁),线上慎用;优先考虑 pt-online-schema-change
  • 复合索引顺序错位(比如 WHERE a=1 AND b>10 ORDER BY c 却建了 INDEX(a,c,b))会导致排序无法利用索引,CPU 依然在内存里归并
  • 一个字段上存在多个功能重叠的索引(如 idx_aidx_a_bidx_a_b_c),MySQL 优化器可能选错执行计划,反而让 Rows_examined 更高

真正卡住排查节奏的,往往不是找不到慢 SQL,而是分不清“谁在消耗 CPU”和“谁在引发等待”。SHOW PROCESSLIST 看的是现场,慢日志看的是痕迹,而 Rows_examined 才是连接两者的标尺——它不撒谎,但需要你主动去读。

星耀云
版权声明:本站原创文章,由 星耀云 2026-03-18发表,共计1855字。
转载说明:转载本网站任何内容,请按照转载方式正确书写本站原文地址。本站提供的一切软件、教程和内容信息仅限用于学习和研究目的;不得将上述内容用于商业或者非法用途,否则,一切后果请用户自负。本站信息来自网络,版权争议与本站无关。
text=ZqhQzanResources