在做開發(fā)的朋友特別是和mysql有接觸的朋友會碰到有時mysql查詢很慢,當(dāng)然我指的是大數(shù)據(jù)量百萬千萬級了,不是幾十條了,
下面我們來看看解決查詢慢的辦法
會經(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)控做法 :
- 部署zabbix等開源分布式監(jiān)控系統(tǒng),獲取每天的數(shù)據(jù)庫的io,cpu,連接數(shù)
- 部署每周性能統(tǒng)計,包含數(shù)據(jù)增加量,iostat,vmstat,datasize的情況
- 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語句吧。
方法一: 這個方法我正在用,呵呵,比較喜歡這種即時性的。
Mysql5.0以上的版本可以支持將執(zhí)行比較慢的SQL語句記錄下來。
mysql> show variables like 'long%'; 注:這個long_query_time是用來定義慢于多少秒的才算“慢查詢”
+-----------------+-----------+
| Variable_name | Value |
+-----------------+-----------+
| long_query_time | 10.000000 |
+-----------------+-----------+
1 row in set (0.00 sec)
mysql> set long_query_time=1; 注: 我設(shè)置了1, 也就是執(zhí)行時間超過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會立即開始記錄。
/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
這會輸出記錄次數(shù)最多的10條SQL語句,其中:
-s
, 是表示按照何種方式排序,c
、t
、l
、r
分別是按照記錄次數(shù)、時間、查詢時間、返回的記錄數(shù)來排序,ac
、at
、al
、ar
,表示相應(yīng)的倒敘;
-t
, 是top n的意思,即為返回前面多少條的數(shù)據(jù);
-g
, 后邊可以寫一個正則匹配模式,大小寫不敏感的;
比如
/path/mysqldumpslow -s r -t 10 /tmp/slow-log
得到返回記錄集最多的10個查詢。
/path/mysqldumpslow -s t -t 10 -g “l(fā)eft join” /tmp/slow-log
得到按照時間排序的前10條里面含有左連接的查詢語句。 最后總結(jié)一下節(jié)點監(jiān)控的好處
- 輕量級的監(jiān)控,而且是實時的,還可以根據(jù)實際的情況來定制和修改
- 設(shè)置了過濾程序,可以對那些一定要跑的語句進(jìn)行過濾
- 及時發(fā)現(xiàn)那些沒有用索引,或者是不合法的查詢,雖然這很耗時去處理那些慢語句,但這樣可以避免數(shù)據(jù)庫掛掉,還是值得的
- 在數(shù)據(jù)庫出現(xiàn)連接數(shù)過多的時候,程序會自動保存當(dāng)前數(shù)據(jù)庫的processlist,DBA進(jìn)行原因查找的時候這可是利器
- 使用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ù)庫訪問速度。
到此這篇關(guān)于MySQL查詢優(yōu)化之查詢慢原因和解決技巧的文章就介紹到這了,更多相關(guān)MySQL查詢優(yōu)化內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
您可能感興趣的文章:- 一篇文章弄懂MySQL查詢語句的執(zhí)行過程
- 詳解MySQL 查詢語句的執(zhí)行過程
- Python使用sql語句對mysql數(shù)據(jù)庫多條件模糊查詢的思路詳解
- mysql查詢的控制語句圖文詳解
- Mysql將查詢結(jié)果集轉(zhuǎn)換為JSON數(shù)據(jù)的實例代碼
- 使用Visual Studio Code連接MySql數(shù)據(jù)庫并進(jìn)行查詢
- mysql聚合統(tǒng)計數(shù)據(jù)查詢緩慢的優(yōu)化方法
- MySQL多表查詢的具體實例
- mysql從一張表查詢批量數(shù)據(jù)并插入到另一表中的完整實例
- 分析mysql中一條SQL查詢語句是如何執(zhí)行的