1.Sleep
通常代表資源未釋放，如果是通過連接池，sleep狀態應該恆定在一定數量範圍內
實戰範例：因前端數據輸出時（特別是輸出到用戶終端）未及時關閉數據庫連接，導致因網絡連接速度產生大量sleep連接，在網速出現異常時，數據庫too many connections掛死。
簡單解讀，數據查詢和執行通常只需要不到0.01秒，而網絡輸出通常需要1秒左右甚至更長，原本數據連接在0.01秒即可釋放，但是因爲前端程序未執行close操作，直接輸出結果，那麼在結果未展現在用戶桌面前，該數據庫連接一直維持在sleep狀態！
2.Waiting for net, reading from net, writing to net
偶爾出現無妨
如大量出現，迅速檢查數據庫到前端的網絡連接狀態和流量
案例:因外掛程序，內網數據庫大量讀取，內網使用的百兆交換迅速爆滿，導致大量連接阻塞在waiting for net，數據庫連接過多崩潰
3.Locked
有更新操作鎖定
通常使用innodb可以很好的減少locked狀態的產生，但是切記，更新操作要正確使用索引，即便是低頻次更新操作也不能疏忽。如上影響結果集範例所示。
在myisam的時代，locked是很多高併發應用的噩夢。所以mysql官方也開始傾向於推薦innodb。
4.Copy to tmp table
索引及現有結構無法涵蓋查詢條件，纔會建立一個臨時表來滿足查詢要求，產生巨大的恐怖的i/o壓力。
很可怕的搜索語句會導致這樣的情況，如果是數據分析，或者半夜的週期數據清理任務，偶爾出現，可以允許。頻繁出現務必優化之。
Copy to tmp table通常與連表查詢有關，建議逐漸習慣不使用連表查詢。
實戰範例：
u 某社區數據庫阻塞，求救，經查，其服務器存在多個數據庫應用和網站，其中一個不常用的小網站數據庫產生了一個恐怖的copy to tmp table操作，導致整個硬盤i/o和cpu壓力超載。Kill掉該操作一切恢復。
5.Sending data
Sending data並不是發送數據，別被這個名字所欺騙，這是從物理磁盤獲取數據的進程，如果你的影響結果集較多，那麼就需要從不同的磁盤碎片去抽取數據，
偶爾出現該狀態連接無礙。
回到上面影響結果集的問題，一般而言，如果sending data連接過多，通常是某查詢的影響結果集過大，也就是查詢的索引項不夠優化。
如果出現大量相似的SQL語句出現在show proesslist列表中，並且都處於sending data狀態，優化查詢索引，記住用影響結果集的思路去思考。
6.Storing result to query cache
出現這種狀態，如果頻繁出現，使用set profiling分析，如果存在資源開銷在SQL整體開銷的比例過大（即便是非常小的開銷，看比例），則說明query cache碎片較多
使用flush query cache可即時清理，也可以做成定時任務
Query cache參數可適當酌情設置。
7.Freeing items
理論上這玩意不會出現很多。偶爾出現無礙
如果大量出現，內存，硬盤可能已經出現問題。比如硬盤滿或損壞。
i/o壓力過大時，也可能出現Free items執行時間較長的情況。
8.Sorting for …
和Sending data類似，結果集過大，排序條件沒有索引化，需要在內存裏排序，甚至需要創建臨時結構排序。