問題描述

問題分析

第一步：

使用linux的top命令追蹤，發現是mysql進程占用了幾乎所有的cpu資源，得到mysql的進程號。

第二步：

mysql為單進程多線程的數據庫，因此使用top –H –p MYDQLPID的方式追蹤，發現mysql的多線程中7點30左右開始是有1-3線程占用cpu單核90%資源，到8點40左右，40+線程占用cpu單核90%資源，服務器只有48邏輯核心，服務器資源耗盡。

第三步：

在問題發生的時段去觀測比較困難，但是mysql也沒有類似oracle的ash機制，因此采用了一個笨一點的辦法采用mysql定時任務機制，每5秒采集一次mysql進程信息。將performance_schema.threads中的數據插入到臨時表im_threads_monitor中， 分析在并發起來的時刻占用mysql的資源sql。

第四步：

問題最終指向了下面這條sql，在im_threads_monitor中占比90%以上

select id,created_at into v_archive_id,v_archive_created_at

from archive

where created_at >= v_created_date

and created_at <= DATE_ADD(v_created_date, INTERVAL 10 minute )

and xml like concat(‘%id=/’’,v_msg_unique_id,’/’%’)

該sql單次執行在1s-2s，但是并發上來以后變成20s+，事件為send date(該事件名字可能存在誤導性，其真實含義代表收集數據和發送數據)全表掃描180萬條數據，該表有時間分區，但是數據基本都是近期的分區，另外該sql沒有使用到索引。

第五步：

分析慢SQL頻繁被執行的原因。

該sql是未讀消息提示業務。業務中存在bug導致產生了一些無效的未讀消息，這些消息不會因為后邊的未讀消息發送功能發送出去，所以產生堆積，當產生無效未讀消息很多時，以上慢SQL在用戶登錄時被執行，但是無效消息只會在超過30天以后才被清理掉，用戶反復登錄會被重復執行。

第六步：

修改清理無效未讀消息的機制，縮短保存時間；對archive表的created_at字段建立索引。觀察cpu使用率明顯降低

第七步：

修改mysql的參數innodb_thread_concurrency，將其設置為40，此時mysql最多可以使用40個線程。因此即使mysql壓力過大也不會影響Nginx。

https://www.cndba.cn/hehdba/article/4211https://www.cndba.cn/hehdba/article/4211

https://www.cndba.cn/hehdba/article/4211

總結：

1、早oltp系統中索引的涉及非常重要，很多業務會因為1條索引的確實而導致數據庫整個崩潰，而在數據量小的時候索引的作用往往看不出來。本次的問題也是業務的異常導致的一個小表變大表，進而影響了整個業務。

2、合理的設置innodb_thread_concurrency參數對mysql來說非常重要。https://www.cndba.cn/hehdba/article/4211

https://www.cndba.cn/hehdba/article/4211

版權聲明：本文為博主原創文章，未經博主允許不得轉載。

總結

以上是生活随笔為你收集整理的mysql服务器端口cpu_mysql导致服务器cpu100%的问题一例的全部內容，希望文章能夠幫你解決所遇到的問題。

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