本文針對MySQL資料庫伺服器查詢逐漸變慢的問題， 進行分析，並提出相應的解決辦法，具體的分析解決辦法如下：
會經常發現開發人員查一下沒用索引的語句或者沒有limit n的語句，這些沒語句會對資料庫造成很大的影響，例如一個幾千萬條記錄的大表要全部掃描，或者是不停的做filesort，對資料庫和伺服器造成io影響等。這是映象庫上面的情況。
而到了線上庫，除了出現沒有索引的語句，沒有用limit的語句，還多了一個情況,mysql連線數過多的問題。說到這裡，先來看看以前我們的監控做法
1. 部署zabbix等開源分散式監控系統，獲取每天的資料庫的io，cpu，連線數
2. 部署每週效能統計，包含資料增加量，iostat，vmstat，datasize的情況
3. Mysql slowlog收集，列出top 10
以前以為做了這些監控已經是很完美了，現在部署了mysql節點程式監控之後，才發現很多弊端
第一種做法的弊端: zabbix太龐大，而且不是在mysql內部做的監控，很多資料不是非常準備，現在一般都是用來查閱歷史的資料情況
第二種做法的弊端：因為是每週只跑一次，很多情況沒法發現和報警
第三種做法的弊端: 當節點的slowlog非常多的時候，top10就變得沒意義了，而且很多時候會給出那些是一定要跑的定期任務語句給你。。參考的價值不大
那麼我們怎麼來解決和查詢這些問題呢
對於排查問題找出效能瓶頸來說，最容易發現並解決的問題就是MYSQL的慢查詢以及沒有得用索引的查詢。
OK，開始找出mysql中執行起來不“爽”的SQL語句吧。
方法一： 這個方法我正在用，呵呵，比較喜歡這種即時性的。
| 01 |
Mysql5.0以上的版本可以支援將執行比較慢的SQL語句記錄下來。 |
| 02 |
mysql> show variables like 'long%'; 注：這個long_query_time是用來定義慢於多少秒的才算“慢查詢” |
| 03 |
+-----------------+-----------+ |
| 04 |
| Variable_name | Value | |
| 05 |
+-----------------+-----------+ |
| 06 |
| long_query_time | 10.000000 | |
| 07 |
+-----------------+-----------+ |
| 08 |
1 row in set (0.00 sec) |
| 09 |
mysql> set long_query_time=1; 注： 我設定了1, 也就是執行時間超過1秒的都算慢查詢。 |
| 10 |
Query OK, 0 rows affected (0.00 sec) |
| 11 |
mysql> show variables like 'slow%'; |
| 12 |
+---------------------+---------------+ |
| 13 |
| Variable_name | Value | |
| 14 |
+---------------------+---------------+ |
| 15 |
| slow_launch_time | 2 | |
| 16 |
| slow_query_log | ON | 注：是否開啟日誌記錄 |
| 17 |
| slow_query_log_file | /tmp/slow.log | 注： 設定到什麼位置 |
| 18 |
+---------------------+---------------+ |
| 19 |
3 rows in set (0.00 sec) |
| 20 |
mysql> set global slow_query_log='ON' 注：開啟日誌記錄 |
| 21 |
一旦slow_query_log變數被設定為ON，mysql會立即開始記錄。 |
| 22 |
/etc/my.cnf 裡面可以設定上面MYSQL全域性變數的初始值。 |
| 24 |
slow_query_log_file=/tmp/slow.log |
方法二:mysqldumpslow命令
| 01 |
/path/mysqldumpslow -s c -t 10 /tmp/slow-log |
| 02 |
這會輸出記錄次數最多的10條SQL語句，其中： |
| 03 |
-s, 是表示按照何種方式排序，c、t、l、r分別是按照記錄次數、時間、查詢時間、返回的記錄數來排序，ac、at、al、ar，表示相應的倒敘； |
| 04 |
-t, 是top n的意思，即為返回前面多少條的資料； |
| 05 |
-g, 後邊可以寫一個正則匹配模式，大小寫不敏感的； |
| 07 |
/path/mysqldumpslow -s r -t 10 /tmp/slow-log |
| 09 |
/path/mysqldumpslow -s t -t 10 -g “left join” /tmp/slow-log |
| 10 |
得到按照時間排序的前10條裡面含有左連線的查詢語句。 |
最後總結一下節點監控的好處
1． 輕量級的監控，而且是實時的，還可以根據實際的情況來定製和修改
2． 設定了過濾程式，可以對那些一定要跑的語句進行過濾
3． 及時發現那些沒有用索引，或者是不合法的查詢，雖然這很耗時去處理那些慢語句，但這樣可以避免資料庫掛掉，還是值得的
4. 在資料庫出現連線數過多的時候，程式會自動儲存當前資料庫的processlist，DBA進行原因查詢的時候這可是利器
5. 使用mysqlbinlog 來分析的時候，可以得到明確的資料庫狀態異常的時間段
有些人會建義我們來做mysql配置檔案設定
調節tmp_table_size 的時候發現另外一些引數
Qcache_queries_in_cache 在快取中已註冊的查詢數目
Qcache_inserts 被加入到快取中的查詢數目
Qcache_hits 快取取樣數數目
Qcache_lowmem_prunes 因為缺少記憶體而被從快取中刪除的查詢數目
Qcache_not_cached 沒有被快取的查詢數目 (不能被快取的，或由於 QUERY_CACHE_TYPE)
Qcache_free_memory 查詢快取的空閒記憶體總數
Qcache_free_blocks 查詢快取中的空閒記憶體塊的數目
Qcache_total_blocks 查詢快取中的塊的總數目
Qcache_free_memory 可以快取一些常用的查詢,如果是常用的sql會被裝載到記憶體。那樣會增加資料庫訪問速度。