總結(jié)mysql服務(wù)器查詢慢原因與解決方法

2013/7/15 20:51:04  出處：百度搜索   人氣：31次    字號：小  中  大

本文針對MySQL數(shù)據(jù)庫服務(wù)器查詢逐漸變慢的問題， 進(jìn)行分析，并提出相應(yīng)的解決辦法，具體的分析解決辦法如下：

會經(jīng)常發(fā)現(xiàn)開發(fā)人員查一下沒用索引的語句或者沒有l(wèi)imit n的語句，這些沒語句會對數(shù)據(jù)庫造成很大的影響，例如一個幾千萬條記錄的大表要全部掃描，或者是不停的做filesort，對數(shù)據(jù)庫和服務(wù)器造成io影響等。這是鏡像庫上面的情況。

而到了線上庫，除了出現(xiàn)沒有索引的語句，沒有用limit的語句，還多了一個情況,mysql連接數(shù)過多的問題。說到這里，先來看看以前我們的監(jiān)控做法 
1. 部署zabbix等開源分布式監(jiān)控系統(tǒng)，獲取每天的數(shù)據(jù)庫的io，cpu，連接數(shù) 
2. 部署每周性能統(tǒng)計，包含數(shù)據(jù)增加量，iostat，vmstat，datasize的情況 
3. Mysql slowlog收集，列出top 10

以前以為做了這些監(jiān)控已經(jīng)是很完美了，現(xiàn)在部署了mysql節(jié)點進(jìn)程監(jiān)控之后，才發(fā)現(xiàn)很多弊端 
第一種做法的弊端: zabbix太龐大，而且不是在mysql內(nèi)部做的監(jiān)控，很多數(shù)據(jù)不是非常準(zhǔn)備，現(xiàn)在一般都是用來查閱歷史的數(shù)據(jù)情況 
第二種做法的弊端：因為是每周只跑一次，很多情況沒法發(fā)現(xiàn)和報警 
第三種做法的弊端: 當(dāng)節(jié)點的slowlog非常多的時候，top10就變得沒意義了，而且很多時候會給出那些是一定要跑的定期任務(wù)語句給你。。參考的價值不大 
那么我們怎么來解決和查詢這些問題呢

對于排查問題找出性能瓶頸來說，最容易發(fā)現(xiàn)并解決的問題就是MYSQL的慢查詢以及沒有得用索引的查詢。 
OK，開始找出mysql中執(zhí)行起來不“爽”的SQL語句吧。

方法一： 這個方法我正在用，呵呵，比較喜歡這種即時性的。

方法二:mysqldumpslow命令

最后總結(jié)一下節(jié)點監(jiān)控的好處 
1． 輕量級的監(jiān)控，而且是實時的，還可以根據(jù)實際的情況來定制和修改 
2． 設(shè)置了過濾程序，可以對那些一定要跑的語句進(jìn)行過濾 
3． 及時發(fā)現(xiàn)那些沒有用索引，或者是不合法的查詢，雖然這很耗時去處理那些慢語句，但這樣可以避免數(shù)據(jù)庫掛掉，還是值得的 
4. 在數(shù)據(jù)庫出現(xiàn)連接數(shù)過多的時候，程序會自動保存當(dāng)前數(shù)據(jù)庫的processlist，DBA進(jìn)行原因查找的時候這可是利器
5. 使用mysqlbinlog 來分析的時候，可以得到明確的數(shù)據(jù)庫狀態(tài)異常的時間段 
有些人會建義我們來做mysql配置文件設(shè)置

調(diào)節(jié)tmp_table_size 的時候發(fā)現(xiàn)另外一些參數(shù) 
Qcache_queries_in_cache 在緩存中已注冊的查詢數(shù)目 
Qcache_inserts 被加入到緩存中的查詢數(shù)目 
Qcache_hits 緩存采樣數(shù)數(shù)目 
Qcache_lowmem_prunes 因為缺少內(nèi)存而被從緩存中刪除的查詢數(shù)目 
Qcache_not_cached 沒有被緩存的查詢數(shù)目 (不能被緩存的，或由于 QUERY_CACHE_TYPE) 
Qcache_free_memory 查詢緩存的空閑內(nèi)存總數(shù) 
Qcache_free_blocks 查詢緩存中的空閑內(nèi)存塊的數(shù)目 
Qcache_total_blocks 查詢緩存中的塊的總數(shù)目 
Qcache_free_memory 可以緩存一些常用的查詢,如果是常用的sql會被裝載到內(nèi)存。那樣會增加數(shù)據(jù)庫訪問速度。