mysql的監控和排錯

一收集手段：

既然出了問題，首先要進行資料問題的收集，所以做好mysql平時資料收集的準備，已方便作為排查問題的手段

1 慢日誌的開啟（強烈建議),慢日誌記錄的sql語句對於排查大部分問題相當有幫助，和研發聯絡討論也有了根據，是非常必要的。可以用lepus的慢日誌切割指令碼,按照小時進行切割檔案，方面檢視。然後進行遠端插入到資料庫進行備份。被切割的慢日誌進行定期刪除

2 processlist的收集（建議),對於processlist的收集為每分鐘，可能語句執行很快不會記錄，但是對於檢視當時執行的情況依然會有幫助，尤其是執行的耗時等待

3 對於一些全域性變數的把握收集，並繪製成圖表，用於展示資料庫的一些效能變化。推薦引數（thread_running,thread_wait,qps,tps,open_tables) 收集你認為對資料庫影響的效能引數

4 對於linux伺服器本身的監控包括 cpu,io,network，流量和raid磁碟陣列的監控情況（尤其注意硬碟成員是否健康和raid卡電池的充放電，否則可能導致效能問題甚至down機)

總結：針對以上的監控資料的收集，我們的情況是check_mk(一款新型監控軟體）搭配天兔（二次開發）綜合監控，check_mk用以彌補天兔對於硬體資源監控的不足，推薦各位可以採用天兔和zabbix監控，都是比較成熟的產品。

二解決思路

說完了收集手段，咱們來說解決問題的思路，本文只針對作者本身遇到的一些情況，特殊的情況不在考慮範圍內

資料庫問題分為兩類

1 已經發生過的

情景：xx研發詢問，在某個時間段內程式有問題，詢問是否某個庫有效能問題。

思考方式 :

1 首先要確保監控資料在手

2 第一步檢視linux的負載和io是否在這段時間內有較大波動，硬體是否在短暫故障問題

3 第二步檢視mysql的慢日誌在這段時間的慢日誌進行統計分析，歸納。假如出現大量相同的sql慢日誌，進一步explain分析，定位問題，進行優化

4 第三步檢視mysql的dml統計曲線圖，檢視這個時間段的qps和tps操作是否較大波動，分析是否由較大併發導致

核心思想慢日誌+併發+磁碟狀態+記憶體狀態

2 正在發生的

1 分析指令碼

select count(*)from information_schema.processlist where info is not null; 過濾統計當前thread_running的個數

select count(*)from information_schema.processlist where info is not null; 過濾統計當前每個db的訪問session個數

select * from information_schema.innodb_locks;

select * from information_schema.innodb_locks_wait ;過濾統計當前持有鎖和鎖等待的事物

2 觀察linux本身的記憶體和io情況

free -m 觀測可用記憶體和swap應用情況

iostat -d -x -k 2 觀測磁碟組以下指標(tps,util,iowait)

cpu 耗時

根據 1和2 的處理進行分析

三總結:

1 測試環境下某個介面由於程式有問題，頻繁呼叫，導致伺服器負載出現飆公升。這是由於併發導致的效能問題，和研發聯絡後恢復正常

2 生產環境下某個innodb表由於聯合主鍵的問題（需要去掉然後重新新增)，導致大量查詢sql變慢，由於慢查詢所引起的查詢堆積，導致業務部可用，和研發聯絡後，增加自增列作為主。這是典型因為慢查詢堆積所引起的效能問題

3 生產環境下某個表(myisam引擎)，併發量大導致出現大量table lock等待，和研發聯絡後，轉為innodb引擎，業務變快，效能恢復正常,這是由於引擎設定不當所引起的問題

4 生產環境下某些sql語句對於一張2000萬的表進行掃瞄，雖然走了索引，但是不是最優，優化後效能提公升，選擇合適的索引是非常重要的

我所遇到的mysql效能問題大部分都是 1 併發太大 2 慢查詢所引起的sql堆積 3 非innodb引擎 4 不合適的索引 5 對大表進行拆分

以上為我的遇到的一些案例和感悟，請諸君點評

原文出處：