通過上一篇部落格分析了slow_log和general_log,給耗時較長的sql添加了組合索引，執行時間從原來的0.9s優化到0.02s;給併發較高的sql加上了快取，但是cpu使用率還是未出現一點下降，其實從日誌分析報告中已經可以看出，這些即使不優化也絕不至於會讓cpu持續100%執行，並且是瞬間從低位上升到100%，不像正常的因為流量增大而導致的，下圖優化前cpu使用率圖：

饒了一圈，想到了mysql 有show full processlist 來檢視當前程序情況；果斷試試看，終於找到了真相；原來是一條語句一直卡在sending data的狀態，如下圖（圖片為後補的，之前的持續時間遠大於圖中顯示的值）

因為mysql使用的是db.m3.large型別，只有2個cpu，所以只要有2條併發就100%了。下圖為 kill掉執行緒之後又重新請求再kill對應的cpu使用率圖；

和預想的一樣、由此可見確實是這個原因引起的。下面就是隻要優化具體的這條sql就可以了。本次問題的排查到這裡就算是完成了；