單條查詢問題還是服務器問題（）
使用SHOW PROCESSLIST 命令時在尾部加上\G 可以垂直的方式輸出結果這很有用 因為這樣會將每一行記錄的每一列都單獨輸出為一行 這樣可以方便地使用sort|uniq|sort 一類的命令來計算某個列值出現的次數
$ mysql e SHOW PROCESSLIST\G | grep State: | sort | uniq c | sort rn
State:
State: Sending data
State: freeing items
State: NULL
State: end
State: Updating
State: cleaning up
State: update
State: Sorting result
State: logging slow query
如果要查看不同的列只需要修改grep 的模式即可在大多數案例中State 列都非常有用從這個例子的輸出中可以看到有很多線程處於查詢執行的結束部分的狀態包括freeing itemsendcleaning up和logging slow query事實上在案例中的這台服務器上同樣模式或類似的輸出采樣出現了很多次大量的線程處於freeingitems狀態是出現了大量有問題查詢的很明顯的特征和指示
用這種技術查找問題上面的命令行不是唯一的方法如果MySQL 服務器的版本較新也可以直接查詢INFORMATION_SCHEMA 中的PROCESSLIST 表或者使用innotop 工具以較高的頻率刷新以觀察屏幕上出現的不正常查詢堆積上面演示的這個例子是由於InnoDB 內部的爭用和髒塊刷新所導致但有時候原因可能比這個要簡單得多一個經典的例子是很多查詢處於Locked狀態這是MyISAM 的一個典型問題它的表級別鎖定在寫請求較多時可能迅速導致服務器級別的線程堆積
使用查詢日志
如果要通過查詢日志發現問題需要開啟慢查詢日志並在全局級別設置long_query_time 為並且要確認所有的連接都采用了新的設置這可能需要重置所有連接以使新的全局設置生效或者使用Percona Server 的一個特性可以在不斷開現有連接的情況下動態地使設置強制生效
如果因為某些原因不能設置慢查詢日志記錄所有的查詢也可以通過tcpdump 和ptquerydigest 工具來模擬替代要注意找到吞吐量突然下降時間段的日志查詢是在完成階段才寫入到慢查詢日志的所以堆積會造成大量查詢處於完成階段直到阻塞其他查詢的資源占用者釋放資源後其他的查詢才能執行完成這種行為特征的一個好處是當遇到吞吐量突然下降時可以歸咎於吞吐量下降後完成的第一個查詢（有時候也不一定是第一個查詢當某些查詢被阻塞時其他查詢可以不受影響繼續運行所以不能完全依賴這個經驗）
再重申一次好的工具可以幫助診斷這類問題否則要人工去幾百GB 的查詢日志中找原因下面的例子只有一行代碼卻可以根據MySQL 每秒將當前時間寫入日志中的模式統計每秒的查詢數量
$ awk /^# Time:/{print $ $ c;c=}/^# User/{c++} slowquerylog
::
::
::
::
::
::
::
::
::
::
::
::
從上面的輸出可以看到有吞吐量突然下降的情況發生而且在下降之前還有一個突然的高峰僅從這個輸出而不去查詢當時的詳細信息很難確定發生了什麼但應該可以說這個突然的高峰和隨後的下降一定有關聯不管怎麼說這種現象都很奇怪值得去日志中挖掘該時間段的詳細信息（實際上通過日志的詳細信息可以發現突然的高峰時段有很多連接被斷開的現象可能是有一台應用服務器重啟導致的所以不是所有的問題都是MySQL 的問題）
理解發現的問題（Making sense of the findings）
可視化的數據最具有說服力上面只演示了很少的幾個例子但在實際情況中利用上面的工具診斷時可能產生大量的輸出結果可以選擇用gnuplot或R或者其他繪圖工具將結果繪制成圖形這些繪圖工具速度很快比電子表格要快得多而且可以對圖上的一些異常的地方進行縮放這比在終端中通過滾動條翻看文字要好用得多除非你是黑客帝國中的矩陣觀察者
我們建議診斷問題時先使用前兩種方法SHOW STATUS和SHOW PROCESSLIST這兩種方法的開銷很低而且可以通過簡單的shell腳本或者反復執行的查詢來交互式地收集數據分析慢查詢日志則相對要困難一些經常會發現一些蛛絲馬跡但仔細去研究時可能又消失了這樣我們很容易會認為其實沒有問題
發現輸出的圖形異常意味著什麼？通常來說可能是查詢在某個地方排隊了或者某種查詢的量突然飙升了接下來的任務就是找出這些原因
返回目錄高性能MySQL
編輯推薦
ASP NET開發培訓視頻教程
數據倉庫與數據挖掘培訓視頻教程
Oracle索引技術
From:http://tw.wingwit.com/Article/program/MySQL/201311/29702.html
