當(dāng) MySQL 出現(xiàn) CPU 持續(xù)飆高 時(shí)，問題往往不只存在于數(shù)據(jù)庫本身，而可能涉及：

• SQL 執(zhí)行效率
• 系統(tǒng)資源瓶頸
• 并發(fā)模型
• 內(nèi)核調(diào)度
• I/O 或網(wǎng)絡(luò)行為

本文提供一套 工程化三階段排查方法：

主機(jī)層定位 → 系統(tǒng)層分析 → MySQL 內(nèi)部根因

目標(biāo)是精準(zhǔn)回答三個(gè)問題：

1. CPU 被誰消耗？
2. 為什么消耗？
3. 如何優(yōu)化？

第一階段：確認(rèn)問題范圍（定位 CPU 消耗主體）

目標(biāo)：明確 是誰在消耗 CPU。

• MySQL 整體？
• 單個(gè)線程？
• SQL 計(jì)算？
• 內(nèi)核系統(tǒng)調(diào)用？

1.1 查看主機(jī)整體 CPU 負(fù)載

命令

top -c 

CPU 行解讀

%Cpu(s): 10.4 us, 2.6 sy, 0.0 ni, 86.5 id, 0.1 wa, 0.0 hi, 0.4 si, 0.0 st 

經(jīng)驗(yàn)判斷

• us > 70% → SQL 問題概率極高
• sy 高 → 鎖 / 內(nèi)核調(diào)度問題
• wa 高 → I/O 偽 CPU 高

Load Average 判斷

load average: 8.2, 7.9, 6.5 

規(guī)則：

Load > CPU 核心數(shù) = 系統(tǒng)過載

示例：

• 4 核 CPU
• load = 8
  ? 存在運(yùn)行隊(duì)列堆積

1.2 定位 MySQL 進(jìn)程 PID

ps -ef | grep mysqld
# 或
pidof mysqld

記錄 PID，例如：

12345 

1.3 查看 MySQL 內(nèi)部線程 CPU（關(guān)鍵步驟）

MySQL = 多線程模型
一個(gè)連接 ≈ 一個(gè)線程。

top -H -p 12345 -d 1 

場景分析

? 場景 A：單線程 100%

含義：

單條慢 SQL

行動(dòng)：

• 記錄線程 ID
• 去 MySQL 查 SQL

? 場景 B：大量線程均高

含義：

并發(fā)過高 / 連接風(fēng)暴

行動(dòng)：

• 檢查連接池
• 限制最大連接

? 場景 C：線程不高但整體 CPU 高

可能原因：

• MySQL 后臺(tái)線程
• 鎖競爭
• 上下文切換

1.4 區(qū)分用戶態(tài)與內(nèi)核態(tài) CPU

pidstat -p 12345 -u -h 1 5 

第二階段：系統(tǒng)層面排查

確認(rèn) mysqld 占 CPU 后，需要排除 操作系統(tǒng)導(dǎo)致的性能下降。

2.1 上下文切換檢查

vmstat 1 5 

重點(diǎn)字段：

判斷：

• 正常：幾千/s
• 異常：> 20000/s

原因：

• 線程過多
• 鎖競爭
• CPU 搶占

進(jìn)一步：

pidstat -w -p 12345 1 5 

關(guān)注：

• cswch/s
• nvcswch/s

2.2 內(nèi)存與 Swap 檢查

free -m
vmstat 1 5

關(guān)鍵字段：

?? si/so != 0 = 嚴(yán)重問題

影響：

• CPU sy 飆升
• 數(shù)據(jù)庫性能斷崖下降

優(yōu)化：

• 增內(nèi)存
• 調(diào)整 buffer pool
• swapoff -a

2.3 網(wǎng)絡(luò)連接檢查

netstat -an | grep ESTABLISHED | wc -l
netstat -an | grep TIME_WAIT | wc -l
ss -ant | grep :3306 | wc -l

判斷：

優(yōu)化：

• 使用連接池
• tcp_tw_reuse

2.4 磁盤 I/O 與 CPU 關(guān)聯(lián)

iostat -x -k 1 5 

關(guān)注：

若同時(shí)：

• wa 高
• %util 高

? CPU 是被動(dòng)等待。

2.5 NUMA 架構(gòu)檢查

numactl --hardware
dmesg | grep -i numa

問題：

CPU 與內(nèi)存跨節(jié)點(diǎn)訪問

建議：

numactl --interleave=all /usr/sbin/mysqld 

2.6 硬中斷檢查

watch -n 1 'cat /proc/interrupts | grep -E "CPU|eth|nvme|sda"' 

如果某 CPU 中斷暴漲：

? IRQ 未均衡

解決：

irqbalance 

第一、二階段總結(jié)

第三階段：MySQL 層面排查（核心階段）

當(dāng)系統(tǒng)層無異常：

問題幾乎一定在 SQL 或 MySQL 內(nèi)部機(jī)制

3.1 實(shí)時(shí)會(huì)話分析（抓現(xiàn)行）

SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO
FROM information_schema.PROCESSLIST
WHERE COMMAND != 'Sleep'
ORDER BY TIME DESC
LIMIT 20;

STATE 含義

OS 線程關(guān)聯(lián)（8.0）

通過：

performance_schema.threads 

關(guān)聯(lián)：

• PROCESSLIST_ID
• THREAD_OS_ID

3.2 慢查詢分析（歷史問題）

開啟：

SET GLOBAL slow_query_log='ON';
SET GLOBAL long_query_time=0.1;
SET GLOBAL log_queries_not_using_indexes='ON';

mysqldumpslow

mysqldumpslow -s t -t 10 slow.log 

pt-query-digest（推薦）

pt-query-digest slow.log 

關(guān)注：

• Rows examine
• Response time

3.3 狀態(tài)指標(biāo)分析

線程

SHOW STATUS LIKE 'Threads_running'; 

規(guī)則：

Threads_running ≤ CPU 核心數(shù)

臨時(shí)表

SHOW STATUS LIKE 'Created_tmp%'; 

磁盤臨時(shí)表高 ⇒ SQL 或 tmp_table_size 問題。

Buffer Pool 命中率

計(jì)算：

1 - reads / read_requests 

目標(biāo)：

≥ 99%

3.4 鎖與事務(wù)分析

SHOW ENGINE INNODB STATUS\G 

關(guān)注：

• TRANSACTIONS
• SEMAPHORES

大量 spin/wait ⇒ 鎖競爭。

SELECT * FROM sys.innodb_lock_waits; 

檢查：

• 長事務(wù)
• DDL 阻塞

3.5 執(zhí)行計(jì)劃分析（最終定位）

EXPLAIN FORMAT=JSON SELECT ...

關(guān)鍵字段：

常見索引失效

1. 違反最左前綴
2. 函數(shù)計(jì)算
3. 隱式類型轉(zhuǎn)換
4. %abc 模糊查詢

3.6 Performance Schema 深度分析

SELECT EVENT_NAME, COUNT_STAR, SUM_TIMER_WAIT
FROM performance_schema.events_statements_summary_by_global_by_event_name
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 10;

實(shí)時(shí)：

SELECT *
FROM sys.session
ORDER BY current_statement_latency DESC;

第三階段決策表

推薦排查順序（實(shí)戰(zhàn)經(jīng)驗(yàn)）

① SHOW PROCESSLIST
        ↓
② Threads_running
        ↓
③ Slow Log
        ↓
④ EXPLAIN

以上就是MySQL CPU飆高排查的全流程指南的詳細(xì)內(nèi)容，更多關(guān)于MySQL CPU飆高排查的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！