在日常工作中，發(fā)現(xiàn) MySQL 的狀態(tài)不太對勁的時候，一般都會看看監(jiān)控指標(biāo)，很多時候會看到熟悉的一幕：CPU 使用率又爆了。本文將給大家介紹 MySQL 和 CPU 之間的關(guān)系，對此有一定的了解之后可以更準(zhǔn)確的判斷出問題的原因，也能夠提前發(fā)現(xiàn)一些引發(fā) CPU 問題的隱患。

怎么看懂CPU使用率

以 Linux 的 top 命令為例，效果如下：

Top 命令

在 %CPU 這一列就展示了 CPU 的使用情況，百分比指代的是總體上占用的時間百分比：

•  %us：表示用戶進(jìn)程的 CPU 使用時間（沒有通過 nice 調(diào)度）
•  %sy：表示系統(tǒng)進(jìn)程的 CPU 使用時間，主要是內(nèi)核使用。
•  %ni：表示用戶進(jìn)程中，通過 CPU 調(diào)度（nice）過的使用時間。
•  %id：空閑的 CPU 時間
•  %wa：CPU 運(yùn)行時在等待 IO 的時間
•  %hi：CPU 處理硬中斷花費(fèi)的時間
•  %si：CPU 處理軟中斷花費(fèi)的時間
•  %st：被虛擬機(jī)偷走的 CPU 時間

通常情況下，我們討論的 CPU 使用率過高，指的是 %us 這個指標(biāo)，監(jiān)控里面的 CPU 使用率通常也是這個值（也有用其他的方法計(jì)算出來的，不過簡單起見，不考慮其他的情況 ）。其他幾個指標(biāo)過高也代表出 MySQL 的狀態(tài)異常，簡單起見，這里主要還是指 %us 過高的場景。

MySQL和線程

MySQL 是單進(jìn)程多線程的結(jié)構(gòu)，意味著獨(dú)占的 MySQL 服務(wù)器里面，只能用 top 命令看到一行數(shù)據(jù)。

TOP 命令效果

這里能看到的是 MySQL 的進(jìn)程 ID，如果要看到線程的情況，需要用top -H

TOP 命令效果

在這里能看到的是 MySQL 各個線程的 ID，可以看到 MySQL 在啟動之后，會創(chuàng)建非常多的內(nèi)部線程來工作。

這些內(nèi)部線程包括 MySQL 自己用來刷臟，讀寫數(shù)據(jù)等操作的系統(tǒng)線程，也包括處理用戶 SQL 的線程，姑且叫做用戶線程吧。用戶線程有一個特殊的地方：程序端發(fā)送到 MySQL 端的 SQL，只會由一個用戶線程來執(zhí)行（one-thread-per-connection），所以 MySQL 在處理復(fù)雜查詢的時候，會出現(xiàn)“一核有難，多核圍觀”的尷尬現(xiàn)象。

參考 %us 的定義，對于 Linux 系統(tǒng)來說，MySQL 進(jìn)程和它啟動的所有線程都不算內(nèi)核進(jìn)程，因此 MySQL 的系統(tǒng)線程和用戶線程在繁忙的時候，都會體現(xiàn)在 CPU 使用率的 %us 指標(biāo)上。

什么時候CPU會100%

MySQL 干什么的時候，CPU 會 100%？從前文的分析來看，MySQL 主要是兩類線程占用 CPU：系統(tǒng)線程和用戶線程。因此 MySQL 獨(dú)占的服務(wù)器上，只需要留意一下這兩類線程的情況，就能 Cover 住絕大部分的問題場景。

系統(tǒng)線程

在實(shí)際的環(huán)境中，系統(tǒng)線程遇到問題的情況會比較少，一般來說，多個系統(tǒng)線程很少會同時跑滿，只要服務(wù)器的可用核心數(shù)大于等于 4 的話，一般也不會遇到 CPU 100%，當(dāng)然有一些 bug 可能會有影響，比如這個：

MySQL BUG

雖然情況比較少，但是在面對問題的常規(guī)排查過程中，系統(tǒng)線程的問題也是需要關(guān)注的。

用戶線程

提到用戶線程繁忙，很多時候肯定會第一時間憑經(jīng)驗(yàn)想到慢查詢。確實(shí) 90% 以上的時候都是“慢查詢”引起的，不過作為方法論，還是要根據(jù)分析再去得出結(jié)論的~

參考 us% 的定義，是指用戶線程占用 CPU 的時間多少，這代表著用戶線程占用了大量的時間。

一方面是在進(jìn)行長時間的計(jì)算，例如：order by，group by，臨時表，join 等。這一類問題可能是查詢效率不高，導(dǎo)致單個 SQL 語句長時間占用 CPU 時間，也有可能是單純的數(shù)據(jù)量比較多，導(dǎo)致計(jì)算量巨大。另一方面是單純的 QPS 壓力高，所以 CPU 的時間被用滿了，比如 4 核的服務(wù)器用來支撐 20k 到 30k 的點(diǎn)查詢，每個 SQL 占用的 CPU 時間并不多，但是因?yàn)檎w的 QPS 很高，所以 CPU 的時間被占滿了。

問題的定位

分析完之后，就要開始實(shí)戰(zhàn)了，這里根據(jù)前文的分析給出一些經(jīng)典的 CPU 100% 場景，并給出簡要的定位方法作為參考。

PS：系統(tǒng)線程的 bug 的場景 skip，以后有機(jī)會再作為詳細(xì)的案例來分析。

慢查詢

在 CPU 100% 這個問題已經(jīng)發(fā)生之后，真實(shí)的慢查詢和因?yàn)?CPU 100% 導(dǎo)致被影響的普通查詢會混在一起，難以直觀的看 processlist 或者 slowlog 來發(fā)現(xiàn)元兇，這時候就需要一些比較明確的特征來進(jìn)行甄別。

從前文的簡單分析可以看出來，查詢效率不高的慢查詢通常有以下幾種情況：

•  全表掃描：Handler_read_rnd_next 這個值會大幅度突增，且這一類查詢在 slowlog 中 row_examined 的值也會非常高。
•  索引效率不高，索引選錯了：Handler_read_next 這個值會大幅度的突增，不過要注意這種情況也有可能是業(yè)務(wù)量突增引起的，需要結(jié)合 QPS/TPS 一起看。這一類查詢在 slowlog 中找起來會比較麻煩，row_examined 的值一般在故障前后會有比較明顯的不同，或者是不合理的偏高。
  •  比如數(shù)據(jù)傾斜的場景，一個小范圍的 range 查詢在某個特定的范圍內(nèi) row_examined 非常高，而其他的范圍時 row_examined 比較低，那么就可能是這個索引效率不高。
•  排序比較多：order by，group by 這一類查詢通常不太好從 Handler 的指標(biāo)直接判斷，如果沒有索引或者索引不好，導(dǎo)致排序操作沒有消除的話，那么在 processlist 和 slowlog 通常能看到這一類查詢語句出現(xiàn)的比較多。

當(dāng)然，不想詳細(xì)的分析 MySQL 指標(biāo)或者是情況比較緊急的話，可以直接在 slowlog 里面用 rows_sent 和 row_examined 做個簡單的除法，比如 row_examined/rows_sent > 1000 的都可以拿出來作為“嫌疑人”處理。這類問題一般在索引方面做好優(yōu)化就能解決。

PS：1000 只是個經(jīng)驗(yàn)值，具體要根據(jù)實(shí)際業(yè)務(wù)情況來定。

計(jì)算量大

這一類問題通常是因?yàn)閿?shù)據(jù)量比較大，即使索引沒什么問題，執(zhí)行計(jì)劃也 OK，也會導(dǎo)致 CPU 100%，而且結(jié)合 MySQL one-thread-per-connection 的特性，并不需要太多的并發(fā)就能把 CPU 使用率跑滿。這一類查詢其實(shí)是是比較好查的，因?yàn)閳?zhí)行時間一般會比較久，在 processlist 里面就會非常顯眼，反而是 slowlog 里面可能找不到，因?yàn)闆]有執(zhí)行完的語句是不會記錄的。

這一類問題一般來說有三種比較常規(guī)的解決方案：

1.  讀寫分離，把這一類查詢放到平時業(yè)務(wù)不怎么用的只讀從庫去。
2.  在程序段拆分 SQL，把單個大查詢拆分成多個小查詢。
3.  使用 HBASE，Spark 等 OLAP 的方案來支持。

高 QPS

這一類問題單純的就是硬件資源的瓶頸，不論是 row_examined/rows_sent 的比值，還是 SQL 的索引、執(zhí)行計(jì)劃，或者是 SQL 的計(jì)算量都不會有什么明顯問題，只是 QPS 指標(biāo)會比較高，而且 processlist 里面可能什么內(nèi)容都看不到，例如：

processlist

總結(jié)

實(shí)際上 CPU 100% 的問題其實(shí)不僅僅是單純的 %us，還會有 %io，%sys 等，這些會涉及到 MySQL 與 Linux 相關(guān)聯(lián)的一部分內(nèi)容，展開來就會比較多了。本文僅從 %us 出發(fā)嘗試梳理一下排查&定位的思路和方法，在分析 %io，%sys 等方面的問題時，也可以用類似的思路，從這些指標(biāo)的意義開始，結(jié)合 MySQL 的一些特性或者特點(diǎn)，逐步理清楚表象背后的原因。