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

用show processlist 看看正在執(zhí)行的語句。表現(xiàn)如下：

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

2.語句狀態(tài)一半多是sending data狀態(tài)，其余大多是sort 狀態(tài)；

3.cpu很高；

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

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

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

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

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

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

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

再查詢一下正式環(huán)境的正式mysql，執(zhí)行同樣的語句，發(fā)現(xiàn)賬號記錄數(shù)最多也就近千條。

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

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

有兩種方法解決：

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

2.找到為什么會出現(xiàn)這種壞數(shù)據(jù)，優(yōu)化查詢語句，從根源上解決問題。

最終采用第2種方法，找到這種壞數(shù)據(jù)的原因，發(fā)現(xiàn)因為這是測試環(huán)境的mysql，這種數(shù)據(jù)的產(chǎn)生是不可避免的。

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

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

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

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

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

4. 當找不到問題時，應該找找該表數(shù)據(jù)的來源情況、表的數(shù)據(jù)情況和數(shù)據(jù)的使用語句，也能發(fā)現(xiàn)一點線索。

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

頂

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。