共計 1350 個字符，預計需要花費 4 分鐘才能閱讀完成。

本篇文章給大家分享的是有關 MySQL 引起的 CPU 消耗過大該如何優化，丸趣 TV 小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著丸趣 TV 小編一起來看看吧。

誰在消耗 cpu?

用戶 + 系統 +IO 等待 + 軟硬中斷 + 空閑

禍首是誰?

用戶

用戶空間 CPU 消耗，各種邏輯運算

正在進行大量 tps

函數 / 排序 / 類型轉化 / 邏輯 IO 訪問 hellip;

用戶空間消耗大量 cpu，產生的系統調用是什么? 那些函數使用了 cpu 周期?

IO 等待

等待 IO 請求的完成

此時 CPU 實際上空閑

如 vmstat 中的 wa 很高。但 IO 等待增加，wa 也不一定會上升 (請求 I / O 后等待響應，但進程從核上移開了)

產生影響

用戶和 IO 等待消耗了大部分 cpu

吞吐量下降 (tps)

查詢響應時間增加

慢查詢數增加

對 mysql 的并發陡增，也會產生上訴影響

如何減少 CPU 消耗?

減少等待

減少 IO 量

SQL/index，使用合適的索引減少掃描的行數 (需平衡索引的正收益和維護開銷，空間換時間)

提升 IO 處理能力

加 cache/ 加磁盤 /SSD

減少計算

減少邏輯運算量

避免使用函數，將運算轉移至易擴展的應用服務器中

如 substr 等字符運算，dateadd/datesub 等日期運算，abs 等數學函數

減少排序，利用索引取得有序數據或避免不必要排序

如 union all 代替 union，order by 索引字段等

禁止類型轉換，使用合適類型并保證傳入參數類型與數據庫字段類型絕對一致

如數字用 tiny/int/bigint 等，必需轉換的在傳入數據庫之前在應用中轉好

簡單類型，盡量避免復雜類型，降低由于復雜類型帶來的附加運算。更小的數據類型占用更少的磁盤、內存、cpu 緩存和 cpu 周期

hellip;.

減少邏輯 IO 量

index，優化索引，減少不必要的表掃描

如增加索引，調整組合索引字段順序，去除選擇性很差的索引字段等等

table，合理拆分，適度冗余

如將很少使用的大字段拆分到獨立表，非常頻繁的小字段冗余到“引用表”

SQL，調整 SQL 寫法，充分利用現有索引，避免不必要的掃描，排序及其他操作

如減少復雜 join，減少 order by，盡量 union all，避免子查詢等

數據類型，夠用就好，減少不必要使用大字段

如 tinyint 夠用就別總是 int，int 夠用也別老 bigint，date 夠用也別總是 timestamp

hellip;.

減少 query 請求量 (非數據庫本身)

適當緩存，降低緩存數據粒度，對靜態并被頻繁請求的數據進行適當的緩存

如用戶信息，商品信息等

優化實現，盡量去除不必要的重復請求

如禁止同一頁面多次重復請求相同數據的問題，通過跨頁面參數傳遞減少訪問等

合理需求，評估需求產出比，對產出比極端底下的需求合理去除

hellip;.

升級 cpu

若經過減少計算和減少等待后還不能滿足需求，cpu 利用率還高 T_T

是時候拿出最后的殺手锏了，升級 cpu，是選擇更快的 cpu 還是更多的 cpu 了?

低延遲 (快速響應)，需要更快的 cpu(每個查詢只能使用一個 cpu)

高吞吐，同時運行很多查詢語句，能從多個 cpu 處理查詢中收益  

以上就是 MySQL 引起的 CPU 消耗過大該如何優化，丸趣 TV 小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注丸趣 TV 行業資訊頻道。