一次業務邏輯優化，居然解決了MySQL CPU消耗800%的性能問題！

掃描下方海報二維碼，試聽課程：

（課程詳細大綱，請參見文末）

=========================================

文章來自頭條號：波波說運維

=========================================

概述

最近接到IDC監控告警說某臺服務器cpu太高，下面記錄下故障排查的過程，僅供參考，這裏主要看思路，細節不重要。

一、觀察服務器資源消耗

能夠看到服務器表現爲cpu問題，內存消耗正常。

1.一、查看具體cpu

ps -mp 2289 -o THREAD,tid,time

1.二、找到耗時最高的線程TID，並將其線程ID轉換爲16進制格式：

printf "%x\n" tid

1.三、打印線程的堆棧信息，thread dump

jstack pid |grep tid -A 30

進一步分析堆棧信息

二、檢查數據庫線程

這裏發現大概有8個線程，並且都是同一條sql

三、查看sql執行計劃

這個單條sql只須要2s就能夠跑完，不過看執行計劃是走了全表掃描，並無走索引

四、慢查詢分析

set global slow_query_log=on;set global long_query_time=30;set global log_output='TABLE';show variables like '%slow%';select * from mysql.slow_log order by 1;複製代碼

如下是由於先開了沒有走索引就記錄下來，因此能夠看到這條sql，可是開了慢查詢後並無超過30s的慢sql.

五、定時任務？

跟開發確認後是有個定時任務，每次都須要去查每一個用戶的考勤時間，最後再彙總統計，這個定時任務須要跑一天的時間。

這裏問題主要是嵌套循環，外層循環遍歷工號（8000），內層循環遍歷天數（30天），而後內層循環每次查數據都須要去跟數據庫作一次交互，在插入數據到緩存，最後彙總計算到彙總表。

六、優化方案

一、彙總表拆分

經常使用字段劃爲一張表，不經常使用字段劃分爲另外一張表，而後經常使用字段這些只作彙總計算，不走循環，不經常使用字段（如婚假、病假等）這些走循環。

二、優化單條查詢

這個建索引，控制在1s內

--大表建索引，驅動表不建索引create index idx_hwb1 on t_att_dd_attendance_info(user_id,class_id,check_type,plan_check_time)複製代碼

三、邏輯優化

這裏跟開發提了把邏輯改了，不過開發還沒實現，因此就不貼實現代碼了。邏輯大體以下：

END

《21天互聯網Java進階面試訓練營（分佈式篇）》詳細目錄，掃描圖片末尾的二維碼，試聽課程