mysql 卡死線程長時間處於sending data 狀態

有台服務器，訪問量挺大，每天近250w動態pv，數據庫查詢平均每秒近600次
另一台服務器，跑的程序跟這台一樣，不過只有每天約40w動態 pv
前段時間連續卡死過幾次，當時的狀態是
服務器沒崩潰，數據庫可正常登陸。只是所有的查詢都卡在「sending data」狀態，長時間無法執行完，這些簡單的sql語句，有時候集中在A表上，有時候集中在B表上，同時還有一些卡死在locked狀態或update 狀態

看mysql的說明，sending data狀態表示兩種情況，一種是mysql已經查詢了數據，正在發給客戶端；另一種情況是，mysql已經知道某些數據需要去什麼地方讀取，正在從數據文件中讀取

mysql官方說，這不是mysql的bug，但是官方也沒說怎麼處理......那麼，看情況，就應該是配置方面的問題了。
首先從sql優化的角度來查了查，那些卡死的sql語句，都是簡單查詢，消耗非常低，索引做的非常好，所以覺得應該不是sql語句的問題。而且慢查詢日誌裡也沒有出現慢查詢。

把表都做了優化，就是optimize table ，過幾天發現，還是會出現卡死的情況.....

後來考慮增加並發性能，增加了key_buffer thread_cache 等一系列的內存配置，發現沒什麼作用。情況依舊

再後來，把query_cache減小到默認值 16M，把一些不怎麼變動的數據，做了靜態化。驚奇的發現，12天過去了，沒再出過問題......

後來想想，修改 query_cache可能對這個問題有些幫助，畢竟數據更新比較頻繁，query_cache的更新也很頻繁。不過看mysql的狀態，query_cache的命中率還是相當高的，差不多75％。

覺得問題可能出在程序上，只是沒查出來。後來靜態化的那些內容，是一些產品的說明文字，一般一個產品的說明也就三五十個漢字。

這裡出問題的嫌疑比較大，一個頁面有七八個產品，加起來可能三五百個漢字，雖然不多，不過查詢很頻繁，從這個表上查詢的數據量應該是很可觀的，mysql會頻繁的從這個表拿數據。不過，不過有時候卡死的語句並不是在查詢這個表......

手頭沒有好使的工具，鬱悶。反正問題貌似好了，先放下備案吧，等以後水平高些，再來查。