訪問MySQL頻繁超時，隔一陣子就堵塞一會兒。

用show processlist 看看正在執行的語句。表現如下：

1.有100多個語句在執行，查詢語句集中在兩個表A和B，大多數都是select語句，少量insert和update；

2.語句狀態一半多是sending data狀態，其余大多是sort 狀態；

3.cpu很高；

過一會兒這些語句執行完，又恢復正常了。

剛開始懷疑表沒有建索引，導致查詢太慢，看一下，已經建好了索引，排除索引問題；

再看語句，sending data狀態的語句是最多的，上網搜了一下，有些說是可能是query_cache太小，導致賭賽。

想了一下，應該不是這問題，在安裝mysql時，四臺主備mysql(正式環境主備兩臺，測試環境主備兩臺)，都沒有修改過這參數，其他三臺是正常的，就這臺不正常，應該是其他問題。

搗鼓了半天，沒搞定，有點郁悶，過了一會兒，又堵了，不知道該怎么辦，就把其他一條查詢語句拷貝了，執行一下，結果找到問題了。

這條select語句查詢結果是5萬多條！那就是這張表的記錄有問題。

按照賬號把A表group一下，找出top20條，發現有三個賬號的記錄都是過萬的。

再查詢一下正式環境的正式mysql，執行同樣的語句，發現賬號記錄數最多也就近千條。

認真看一下對這張表的查詢語句，發現大部分都是有"order by Ftime desc limit 1"

那么就找到原因了：每次查詢這三個賬號中某一個時，就會查詢到上萬條記錄，然后排序，問題就在這里了，排序太耗時，而且會導致cpu升高。

有兩種方法解決：

1.刪除壞數據，盡快恢復服務(治標不治本，過陣子還會出現這種數據)，；

2.找到為什么會出現這種壞數據，優化查詢語句，從根源上解決問題。

最終采用第2種方法，找到這種壞數據的原因，發現因為這是測試環境的mysql，這種數據的產生是不可避免的。

那就從業務的使用上解決問題，看了一下查詢語句，都是只需要找到某賬號在A表有沒有記錄，而不需要知道記錄是怎么時候的，那就簡單了，把"order by Ftime" 部分去掉就行，直接就是“select * from A where ?xxx limit 1”。問題解決。

事后回想一下整個過程，其實走了不少彎路。

1. 從表象上看，結合第2條和第3條，sort 狀態和cpu突高，應該就能判斷是排序花的時間多，就應該懷疑是某些賬號的記錄數過多，應該先看看表的數據情況。

2. 不應該被表象迷惑，不能因為sending data 狀態比sort狀態多，就判斷是sending data狀態出問題了，一瞬間的狀態，只能是作參考。

3. 四個mysql的數據是不一樣的，兩個備都是只寫不讀，不會出現查詢賭賽。兩個主數據庫理論上是相近的，但是因為某些業務的特殊性，數據可能相差較大，這個是應該考慮到的。

4. 當找不到問題時，應該找找該表數據的來源情況、表的數據情況和數據的使用語句，也能發現一點線索。

這次問題的解決，主要是靠運氣，隨便拷貝一條語句，剛好是三個壞賬號之一，問題找到了，運氣還真是不錯，哈哈，如果能頭腦清醒一點，應該能更快找到問題。

頂

總結

以上是生活随笔為你收集整理的mysql堵塞 sending data和sort状态多，cpu高的全部內容，希望文章能夠幫你解決所遇到的問題。

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