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

怎么看懂CPU使用率

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

Top 命令

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

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

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

MySQL和線程

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

TOP 命令效果

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

TOP 命令效果

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

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

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

什么時(shí)候CPU會(huì)100%

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

系統(tǒng)線程

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

MySQL BUG

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

用戶(hù)線程

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

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

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

問(wèn)題的定位

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

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

慢查詢(xún)

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

從前文的簡(jiǎn)單分析可以看出來(lái)，查詢(xún)效率不高的慢查詢(xún)通常有以下幾種情況：

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

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

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

計(jì)算量大

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

這一類(lèi)問(wèn)題一般來(lái)說(shuō)有三種比較常規(guī)的解決方案：

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

高 QPS

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

processlist

總結(jié)

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