單條查詢問題還是服務器問題（）
發現問題的蛛絲馬跡了嗎？如果有則首先要確認這是單條查詢的問題還是服務器的問題這將為解決問題指出正確的方向如果服務器上所有的程序都突然變慢又突然都變好每一條查詢也都變慢了那麼慢查詢可能就不一定是原因而是由於其他問題導致的結果反過來說如果服務器整體運行沒有問題只有某條查詢偶爾變慢就需要將注意力放到這條特定的查詢上面
服務器的問題非常常見在過去幾年硬件的能力越來越強配置 核或者更多CPU的服務器成了標配MySQL 在SMP 架構的機器上的可擴展性限制也就越來越顯露出來尤其是較老的版本其問題更加嚴重而目前生產環境中的老版本還非常多新版本MySQL 依然也還有一些擴展性限制但相比老版本已經沒有那麼嚴重而且出現的頻率相對小很多只是偶爾能碰到這是好消息也是壞消息好消息是很少會碰到這個問題壞消息則是一旦碰到則需要對MySQL 內部機制更加了解才能診斷出來當然這也意味著很多問題可以通過升級到MySQL 新版本來解決
那麼如何判斷是單條查詢問題還是服務器問題呢？如果問題不停地周期性出現那麼可以在某次活動中觀察到或者整夜運行腳本收集數據第二天來分析結果大多數情況下都可以通過三種技術來解決下面將一一道來
使用SHOW GLOBAL STATUS
這個方法實際上就是以較高的頻率比如一秒執行一次SHOW GLOBAL STATUS 命令捕獲數據問題出現時則可以通過某些計數器（比如Threads_runningThreads_connectedQuestions 和Queries）的尖刺或者凹陷來發現這個方法比較簡單所有人都可以使用（不需要特殊的權限）對服務器的影響也很小所以是一個花費時間不多卻能很好地了解問題的好方法下面是示例命令及其輸出
$ mysqladmin ext i | awk
/Queries/{q=$qp;qp=$}
/Threads_connected/{tc=$}
/Threads_running/{printf %d %d %d\n q tc $}
這個命令每秒捕獲一次SHOW GLOBAL STATUS 的數據輸出給awk 計算並輸出每秒的查詢數Threads_connected 和Threads_running（表示當前正在執行查詢的線程數）這三個數據的趨勢對於服務器級別偶爾停頓的敏感性很高一般發生此類問題時根據原因的不同和應用連接數據庫方式的不同每秒的查詢數一般會下跌而其他兩個則至少有一個會出現尖刺在這個例子中應用使用了連接池所以Threads_connected 沒有變化但正在執行查詢的線程數明顯上升同時每秒的查詢數相比正常數據有嚴重的下跌
如何解析這個現象呢？憑猜測有一定的風險但在實踐中有兩個原因的可能性比較大其中之一是服務器內部碰到了某種瓶頸導致新查詢在開始執行前因為需要獲取老查詢正在等待的鎖而造成堆積這一類的鎖一般也會對應用服務器造成後端壓力使得應用服務器也出現排隊問題另外一個常見的原因是服務區突然遇到了大量查詢請求的沖擊比如前端的memcached 突然失效導致的查詢風暴
這個命令每秒輸出一行數據可以運行幾個小時或者幾天然後將結果繪制成圖形這樣就可以方便地發現是否有趨勢的突變如果問題確實是間歇性的發生的頻率又較低也可以根據需要盡可能長時間地運行此命令直到發現問題再回頭來看輸出結果大多數情況下通過輸出結果都可以更明確地定位問題
使用SHOW PROCESSLIST
這個方法是通過不停地捕獲SHOW PROCESSLIST 的輸出來觀察是否有大量線程處於不正常的狀態或者有其他不正常的特征例如查詢很少會長時間處於statistics狀態這個狀態一般是指服務器在查詢優化階段如何確定表關聯的順序通常都是非常快的另外也很少會見到大量線程報告當前連接用戶是未經驗證的用戶（Unauthenticateduser）這只是在連接握手的中間過程中的狀態當客戶端等待輸入用於登錄的用戶信息的時候才會出現
返回目錄高性能MySQL
編輯推薦
ASP NET開發培訓視頻教程
數據倉庫與數據挖掘培訓視頻教程
Oracle索引技術
From:http://tw.wingwit.com/Article/program/MySQL/201311/29703.html
