1.背景：

在監控線上數據庫的運行是否安全、正常的過程中，cpu 使用率是一個重要的指標，一旦cpu使用率飆升至90%+甚至達到100%，必然會對數據庫的正常工作產生影響。

在排查數據庫的cpu 飆升的問題前，我們先看下cpu 飆升的原因有哪些。

2.cpu使用率飆升的原因

首先直觀的，cpu使用率過高可能和流量和慢查詢有一定的關系

進一步查閱相關資料，得到公式：單位時間 CPU 資源 = 查詢執行的平均成本 x 單位時間執行的查詢數量

顯然，cpu使用率與【查詢執行的平均成本】和【單位時間執行的查詢數量】線性相關，而這兩項就是我們常說的慢sql以及數據庫QPS。

所以：一般而言，cpu使用率飆升可歸納為以下兩點：大量的慢sql占用了cpu資源，拖垮了數據庫，這類的慢sql常常表現為：查詢的數據量過大，全表掃描、鎖搶占甚至死鎖、復雜查詢等

QPS過高，本質上是數據庫的承載的流量過大

3.如何解決

3.1 定位問題

定位是否為qps原因:

例如以下案例：

首先，查看當前cpu曲線：

發現此時的cpu已經解決100%在運行，再查看此時的qps曲線，

會發現此時的qps曲線基本和cpu曲線保持一致，此時我們可斷定cpu飆升必然存在qps過高的原因。為了驗證是否有慢sql的存在，再查看慢sql曲線：

發現此案例中完全不存在慢sql。因此責任可100%歸為qps過高，如果我們對該庫所在實例開通的sql審計的功能，我們可查看過去一個月的qps記錄，判斷是由哪臺機器發出的高頻請求，以及請求的Top調用量的sql。

如果我們沒開通sql審計功能的話，阿里云也可查看當前對庫的實時請求記錄，或者我們可以以root用戶登陸數據庫，執行‘SHOW PROCESSLIST’命令查看。

最后 定位了具體sql或者接口后 就可以針對性的解決問題：降級或者限流。

定位是否為慢sql原因

案例1 CPU峰刺

例如以下案例：

首先，查看當前cpu和qps曲線：

從上圖我們可看出，cpu和qps的整體的整體走勢是基本一致的，但是上圖中相對qps曲線，cpu有好幾次的抖動，甚至峰值達到80%，我們需要排查出這些峰刺點。

由于此時的cpu抖動和qps曲線不一致，可推測是慢sql引起的，觀察下圖抖動時間段內的慢sql，確定是否有慢sql，以及慢sql的具體信息。

觀察上圖發現該時間段內一些慢sql在庫上使得cpu曲線發生了抖動，此時可采取kill+id的方法定制該sql的執行。

案例2 CPU明顯飆升

有時，我們會發現cpu和qps的曲線不夠吻合，此時我們有較大的把握推測出原因就是慢sql引起的。如以下情況：

紅框內的cpu使用率在上升，但qps卻在下降，觀察以下慢sql監聽：

說明這段時間內的異常是100%是由慢sql引起的，可采取kill+id的方法定制該sql的執行。

4 總結

4.1 慢sql優化思路

慢sql的優化思路較多，本文不打算贅述，僅提供以下幾個方面優化思路。1.掃描數據庫記錄數較多。

考慮表是否設置了合理的索引，表字段是否設置了合理的數據類型，sql是否有效的利用了索引等。2.sql中是否有做了大量的聚合、計算？

考慮將sql簡化，把邏輯操作上浮到業務中去做。3.sql返回的記錄數過多。

考慮分頁實現，通過limit將一次請求轉為多次請求。

4.表中是否冗余字段過多？

表若為寬表，包含大量冗余字段，可考慮分表。

5.庫中是否有很多張表？

此時可考慮將表拆分到多個庫中，分庫。

6.若庫的讀寫較多，鎖爭搶激勵，甚至死鎖。

可考慮多庫做讀寫分離。

7.機器的本身性能較低，不符合業務需求。

可考慮機器升級了。

4.2 qps過高優化思路。1.qps過高時，考慮是否可以使用緩存。

2.使用批量操作，將多個操作合并為一次請求，但此種方式需要考慮是否可以一次批量的數據有多大，避免造成慢sql。

3.考慮分庫、讀寫分離，減少對一個機器的訪問壓力。

4.機器升級，沒什么是錢解決不了的。

關注我們

酷家樂質量效能團隊熱衷于技術的成長和分享，幾乎每個月都會舉辦技術分享活動(海星日)，每半年舉辦一次技術專題競賽分享(火星日)，并將優秀內容寫成技術文章。

我們盡可能保障分享到社區的內容，是我們用心編寫、精心挑選的優質文章。如果您想更全面地閱讀我們的文章，請您關注我們的微信公眾號"酷家樂技術質量"。

總結

以上是生活随笔為你收集整理的mysql查询cpu使用率100%_数据库CPU使用率100% 排查记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。