mysql服務(wù)器查詢慢原因分析與解決方法小結(jié)
更新時(shí)間:2012年04月19日 00:51:49 作者:
在開發(fā)的朋友特別是和mysql有接觸的朋友會(huì)碰到有時(shí)mysql查詢很慢,當(dāng)然我指的是大數(shù)據(jù)量百萬(wàn)千萬(wàn)級(jí)了,不是幾十條了,下面我們來(lái)看看解決查詢慢的辦法
會(huì)經(jīng)常發(fā)現(xiàn)開發(fā)人員查一下沒(méi)用索引的語(yǔ)句或者沒(méi)有l(wèi)imit n的語(yǔ)句,這些沒(méi)語(yǔ)句會(huì)對(duì)數(shù)據(jù)庫(kù)造成很大的影響,例如一個(gè)幾千萬(wàn)條記錄的大表要全部掃描,或者是不停的做filesort,對(duì)數(shù)據(jù)庫(kù)和服務(wù)器造成io影響等。這是鏡像庫(kù)上面的情況。
而到了線上庫(kù),除了出現(xiàn)沒(méi)有索引的語(yǔ)句,沒(méi)有用limit的語(yǔ)句,還多了一個(gè)情況,mysql連接數(shù)過(guò)多的問(wèn)題。說(shuō)到這里,先來(lái)看看以前我們的監(jiān)控做法
1. 部署zabbix等開源分布式監(jiān)控系統(tǒng),獲取每天的數(shù)據(jù)庫(kù)的io,cpu,連接數(shù)
2. 部署每周性能統(tǒng)計(jì),包含數(shù)據(jù)增加量,iostat,vmstat,datasize的情況
3. Mysql slowlog收集,列出top 10
以前以為做了這些監(jiān)控已經(jīng)是很完美了,現(xiàn)在部署了mysql節(jié)點(diǎn)進(jìn)程監(jiān)控之后,才發(fā)現(xiàn)很多弊端
第一種做法的弊端: zabbix太龐大,而且不是在mysql內(nèi)部做的監(jiān)控,很多數(shù)據(jù)不是非常準(zhǔn)備,現(xiàn)在一般都是用來(lái)查閱歷史的數(shù)據(jù)情況
第二種做法的弊端:因?yàn)槭敲恐苤慌芤淮?,很多情況沒(méi)法發(fā)現(xiàn)和報(bào)警
第三種做法的弊端: 當(dāng)節(jié)點(diǎn)的slowlog非常多的時(shí)候,top10就變得沒(méi)意義了,而且很多時(shí)候會(huì)給出那些是一定要跑的定期任務(wù)語(yǔ)句給你。。參考的價(jià)值不大
那么我們?cè)趺磥?lái)解決和查詢這些問(wèn)題呢
對(duì)于排查問(wèn)題找出性能瓶頸來(lái)說(shuō),最容易發(fā)現(xiàn)并解決的問(wèn)題就是MYSQL的慢查詢以及沒(méi)有得用索引的查詢。
OK,開始找出mysql中執(zhí)行起來(lái)不“爽”的SQL語(yǔ)句吧。
=========================================================
方法一: 這個(gè)方法我正在用,呵呵,比較喜歡這種即時(shí)性的。
Mysql5.0以上的版本可以支持將執(zhí)行比較慢的SQL語(yǔ)句記錄下來(lái)。
mysql> show variables like 'long%'; 注:這個(gè)long_query_time是用來(lái)定義慢于多少秒的才算“慢查詢”
+-----------------+-----------+
| Variable_name | Value |
+-----------------+-----------+
| long_query_time | 10.000000 |
+-----------------+-----------+
1 row in set (0.00 sec)
mysql> set long_query_time=1; 注: 我設(shè)置了1, 也就是執(zhí)行時(shí)間超過(guò)1秒的都算慢查詢。
Query OK, 0 rows affected (0.00 sec)
mysql> show variables like 'slow%';
+---------------------+---------------+
| Variable_name | Value |
+---------------------+---------------+
| slow_launch_time | 2 |
| slow_query_log | ON | 注:是否打開日志記錄
| slow_query_log_file | /tmp/slow.log | 注: 設(shè)置到什么位置
+---------------------+---------------+
3 rows in set (0.00 sec)
mysql> set global slow_query_log='ON' 注:打開日志記錄
一旦slow_query_log變量被設(shè)置為ON,mysql會(huì)立即開始記錄。
/etc/my.cnf 里面可以設(shè)置上面MYSQL全局變量的初始值。
long_query_time=1
slow_query_log_file=/tmp/slow.log
方法二:mysqldumpslow命令
/path/mysqldumpslow -s c -t 10 /tmp/slow-log
這會(huì)輸出記錄次數(shù)最多的10條SQL語(yǔ)句,其中:
-s, 是表示按照何種方式排序,c、t、l、r分別是按照記錄次數(shù)、時(shí)間、查詢時(shí)間、返回的記錄數(shù)來(lái)排序,ac、at、al、ar,表示相應(yīng)的倒敘;
-t, 是top n的意思,即為返回前面多少條的數(shù)據(jù);
-g, 后邊可以寫一個(gè)正則匹配模式,大小寫不敏感的;
比如
/path/mysqldumpslow -s r -t 10 /tmp/slow-log
得到返回記錄集最多的10個(gè)查詢。
/path/mysqldumpslow -s t -t 10 -g “l(fā)eft join” /tmp/slow-log
得到按照時(shí)間排序的前10條里面含有左連接的查詢語(yǔ)句。
最后總結(jié)一下節(jié)點(diǎn)監(jiān)控的好處
1. 輕量級(jí)的監(jiān)控,而且是實(shí)時(shí)的,還可以根據(jù)實(shí)際的情況來(lái)定制和修改
2. 設(shè)置了過(guò)濾程序,可以對(duì)那些一定要跑的語(yǔ)句進(jìn)行過(guò)濾
3. 及時(shí)發(fā)現(xiàn)那些沒(méi)有用索引,或者是不合法的查詢,雖然這很耗時(shí)去處理那些慢語(yǔ)句,但這樣可以避免數(shù)據(jù)庫(kù)掛掉,還是值得的
4. 在數(shù)據(jù)庫(kù)出現(xiàn)連接數(shù)過(guò)多的時(shí)候,程序會(huì)自動(dòng)保存當(dāng)前數(shù)據(jù)庫(kù)的processlist,DBA進(jìn)行原因查找的時(shí)候這可是利器
5. 使用mysqlbinlog 來(lái)分析的時(shí)候,可以得到明確的數(shù)據(jù)庫(kù)狀態(tài)異常的時(shí)間段
有些人會(huì)建義我們來(lái)做mysql配置文件設(shè)置
調(diào)節(jié)tmp_table_size 的時(shí)候發(fā)現(xiàn)另外一些參數(shù)
Qcache_queries_in_cache 在緩存中已注冊(cè)的查詢數(shù)目
Qcache_inserts 被加入到緩存中的查詢數(shù)目
Qcache_hits 緩存采樣數(shù)數(shù)目
Qcache_lowmem_prunes 因?yàn)槿鄙賰?nèi)存而被從緩存中刪除的查詢數(shù)目
Qcache_not_cached 沒(méi)有被緩存的查詢數(shù)目 (不能被緩存的,或由于 QUERY_CACHE_TYPE)
Qcache_free_memory 查詢緩存的空閑內(nèi)存總數(shù)
Qcache_free_blocks 查詢緩存中的空閑內(nèi)存塊的數(shù)目
Qcache_total_blocks 查詢緩存中的塊的總數(shù)目
Qcache_free_memory 可以緩存一些常用的查詢,如果是常用的sql會(huì)被裝載到內(nèi)存。那樣會(huì)增加數(shù)據(jù)庫(kù)訪問(wèn)速度。
而到了線上庫(kù),除了出現(xiàn)沒(méi)有索引的語(yǔ)句,沒(méi)有用limit的語(yǔ)句,還多了一個(gè)情況,mysql連接數(shù)過(guò)多的問(wèn)題。說(shuō)到這里,先來(lái)看看以前我們的監(jiān)控做法
1. 部署zabbix等開源分布式監(jiān)控系統(tǒng),獲取每天的數(shù)據(jù)庫(kù)的io,cpu,連接數(shù)
2. 部署每周性能統(tǒng)計(jì),包含數(shù)據(jù)增加量,iostat,vmstat,datasize的情況
3. Mysql slowlog收集,列出top 10
以前以為做了這些監(jiān)控已經(jīng)是很完美了,現(xiàn)在部署了mysql節(jié)點(diǎn)進(jìn)程監(jiān)控之后,才發(fā)現(xiàn)很多弊端
第一種做法的弊端: zabbix太龐大,而且不是在mysql內(nèi)部做的監(jiān)控,很多數(shù)據(jù)不是非常準(zhǔn)備,現(xiàn)在一般都是用來(lái)查閱歷史的數(shù)據(jù)情況
第二種做法的弊端:因?yàn)槭敲恐苤慌芤淮?,很多情況沒(méi)法發(fā)現(xiàn)和報(bào)警
第三種做法的弊端: 當(dāng)節(jié)點(diǎn)的slowlog非常多的時(shí)候,top10就變得沒(méi)意義了,而且很多時(shí)候會(huì)給出那些是一定要跑的定期任務(wù)語(yǔ)句給你。。參考的價(jià)值不大
那么我們?cè)趺磥?lái)解決和查詢這些問(wèn)題呢
對(duì)于排查問(wèn)題找出性能瓶頸來(lái)說(shuō),最容易發(fā)現(xiàn)并解決的問(wèn)題就是MYSQL的慢查詢以及沒(méi)有得用索引的查詢。
OK,開始找出mysql中執(zhí)行起來(lái)不“爽”的SQL語(yǔ)句吧。
=========================================================
方法一: 這個(gè)方法我正在用,呵呵,比較喜歡這種即時(shí)性的。
復(fù)制代碼 代碼如下:
Mysql5.0以上的版本可以支持將執(zhí)行比較慢的SQL語(yǔ)句記錄下來(lái)。
mysql> show variables like 'long%'; 注:這個(gè)long_query_time是用來(lái)定義慢于多少秒的才算“慢查詢”
+-----------------+-----------+
| Variable_name | Value |
+-----------------+-----------+
| long_query_time | 10.000000 |
+-----------------+-----------+
1 row in set (0.00 sec)
mysql> set long_query_time=1; 注: 我設(shè)置了1, 也就是執(zhí)行時(shí)間超過(guò)1秒的都算慢查詢。
Query OK, 0 rows affected (0.00 sec)
mysql> show variables like 'slow%';
+---------------------+---------------+
| Variable_name | Value |
+---------------------+---------------+
| slow_launch_time | 2 |
| slow_query_log | ON | 注:是否打開日志記錄
| slow_query_log_file | /tmp/slow.log | 注: 設(shè)置到什么位置
+---------------------+---------------+
3 rows in set (0.00 sec)
mysql> set global slow_query_log='ON' 注:打開日志記錄
一旦slow_query_log變量被設(shè)置為ON,mysql會(huì)立即開始記錄。
/etc/my.cnf 里面可以設(shè)置上面MYSQL全局變量的初始值。
long_query_time=1
slow_query_log_file=/tmp/slow.log
方法二:mysqldumpslow命令
復(fù)制代碼 代碼如下:
/path/mysqldumpslow -s c -t 10 /tmp/slow-log
這會(huì)輸出記錄次數(shù)最多的10條SQL語(yǔ)句,其中:
-s, 是表示按照何種方式排序,c、t、l、r分別是按照記錄次數(shù)、時(shí)間、查詢時(shí)間、返回的記錄數(shù)來(lái)排序,ac、at、al、ar,表示相應(yīng)的倒敘;
-t, 是top n的意思,即為返回前面多少條的數(shù)據(jù);
-g, 后邊可以寫一個(gè)正則匹配模式,大小寫不敏感的;
比如
/path/mysqldumpslow -s r -t 10 /tmp/slow-log
得到返回記錄集最多的10個(gè)查詢。
/path/mysqldumpslow -s t -t 10 -g “l(fā)eft join” /tmp/slow-log
得到按照時(shí)間排序的前10條里面含有左連接的查詢語(yǔ)句。
最后總結(jié)一下節(jié)點(diǎn)監(jiān)控的好處
1. 輕量級(jí)的監(jiān)控,而且是實(shí)時(shí)的,還可以根據(jù)實(shí)際的情況來(lái)定制和修改
2. 設(shè)置了過(guò)濾程序,可以對(duì)那些一定要跑的語(yǔ)句進(jìn)行過(guò)濾
3. 及時(shí)發(fā)現(xiàn)那些沒(méi)有用索引,或者是不合法的查詢,雖然這很耗時(shí)去處理那些慢語(yǔ)句,但這樣可以避免數(shù)據(jù)庫(kù)掛掉,還是值得的
4. 在數(shù)據(jù)庫(kù)出現(xiàn)連接數(shù)過(guò)多的時(shí)候,程序會(huì)自動(dòng)保存當(dāng)前數(shù)據(jù)庫(kù)的processlist,DBA進(jìn)行原因查找的時(shí)候這可是利器
5. 使用mysqlbinlog 來(lái)分析的時(shí)候,可以得到明確的數(shù)據(jù)庫(kù)狀態(tài)異常的時(shí)間段
有些人會(huì)建義我們來(lái)做mysql配置文件設(shè)置
調(diào)節(jié)tmp_table_size 的時(shí)候發(fā)現(xiàn)另外一些參數(shù)
Qcache_queries_in_cache 在緩存中已注冊(cè)的查詢數(shù)目
Qcache_inserts 被加入到緩存中的查詢數(shù)目
Qcache_hits 緩存采樣數(shù)數(shù)目
Qcache_lowmem_prunes 因?yàn)槿鄙賰?nèi)存而被從緩存中刪除的查詢數(shù)目
Qcache_not_cached 沒(méi)有被緩存的查詢數(shù)目 (不能被緩存的,或由于 QUERY_CACHE_TYPE)
Qcache_free_memory 查詢緩存的空閑內(nèi)存總數(shù)
Qcache_free_blocks 查詢緩存中的空閑內(nèi)存塊的數(shù)目
Qcache_total_blocks 查詢緩存中的塊的總數(shù)目
Qcache_free_memory 可以緩存一些常用的查詢,如果是常用的sql會(huì)被裝載到內(nèi)存。那樣會(huì)增加數(shù)據(jù)庫(kù)訪問(wèn)速度。
相關(guān)文章
Mysql 出現(xiàn)故障應(yīng)用直接中斷連接導(dǎo)致數(shù)據(jù)被鎖(生產(chǎn)故障)詳解
這篇文章主要介紹了 Mysql 出現(xiàn)故障應(yīng)用直接中斷連接導(dǎo)致數(shù)據(jù)被鎖(生產(chǎn)故障)詳解的相關(guān)資料,需要的朋友可以參考下2017-01-01使用ORM新增數(shù)據(jù)在Mysql中的操作步驟
這篇文章主要介紹了使用ORM新增數(shù)據(jù)在Mysql中,但是在這需要注意需要大家新建ORM模型,具體搭建步驟及詳細(xì)過(guò)程跟隨小編一起看看吧2021-07-07一步步教你在Navicat上如何停止正在運(yùn)行的MYSQL語(yǔ)句
很多時(shí)候我們會(huì)提交一些耗時(shí)比較長(zhǎng)的sql,可能出現(xiàn)mysql服務(wù)器內(nèi)存或者CPU暴增,引起報(bào)警,甚至影響其他業(yè)務(wù),下面這篇文章主要給大家介紹了關(guān)于在Navicat上如何停止正在運(yùn)行的MYSQL語(yǔ)句的相關(guān)資料,需要的朋友可以參考下2023-03-03MySQL中g(shù)roup_concat函數(shù)深入理解
本文通過(guò)實(shí)例介紹了MySQL中的group_concat函數(shù)的使用方法,需要的朋友可以適當(dāng)參考下2012-11-11mysql如何設(shè)置主從數(shù)據(jù)庫(kù)的同步
這篇文章主要介紹了mysql如何設(shè)置主從數(shù)據(jù)庫(kù)的同步問(wèn)題,具有很好的參考價(jià)值,希望對(duì)大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2023-10-10Mysql導(dǎo)入導(dǎo)出時(shí)遇到的問(wèn)題解決
這篇文章主要給大家介紹了關(guān)于Mysql導(dǎo)入導(dǎo)出時(shí)遇到問(wèn)題的解決方法,文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家學(xué)習(xí)或者使用Mysql具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面來(lái)一起學(xué)習(xí)學(xué)習(xí)吧2019-08-08