您好,登錄后才能下訂單哦!
這篇文章主要講解了“mysql如何查詢慢的sql語句”,文中的講解內(nèi)容簡單清晰,易于學(xué)習(xí)與理解,下面請大家跟著小編的思路慢慢深入,一起來研究和學(xué)習(xí)“mysql如何查詢慢的sql語句”吧!
方法:1、若未開啟慢查詢,用“set global slow_query_log='ON';”開啟慢;2、用“set global slow_query_log_file=路徑”設(shè)置慢查詢文件保存位置;3、用“subl 路徑”查詢文件即可。
本教程操作環(huán)境:centos 7系統(tǒng)、mysql8.0.22版本、Dell G3電腦。
Mysql中 查詢慢的 Sql語句的記錄查找
慢查詢?nèi)罩?slow_query_log,是用來記錄查詢比較慢的sql語句,通過查詢?nèi)罩緛聿檎夷臈lsql語句比較慢,這樣可以對比較慢的sql可以進行優(yōu)化。
登陸mysql數(shù)據(jù)庫:
1、查看一下當(dāng)前的慢查詢是否開啟,若未開啟則開啟
以及慢查詢所規(guī)定的時間:
show variables like 'slow_query_log'; show variableslike 'long_query_time';
如果你的查詢后的結(jié)果是OFF 狀態(tài)的話,就需要通過相關(guān)設(shè)置將其修改為ON狀態(tài):
set global slow_query_log='ON';
將慢查詢追蹤的時間設(shè)置為1s:
這里你在設(shè)置之后,這個世界是不會立即變成1s的,需要在數(shù)據(jù)庫重啟后才生效:
2、設(shè)置慢查詢?nèi)罩疚募4娴奈恢茫?/strong>
set global slow_query_log_file='/var/lib/mysql/test_1116.log';
3、 查看以下配置后的文件:
sudo subl /var/lib/mysql/test_1116.log
擴展知識:
MySQL數(shù)據(jù)庫慢查詢問題排查方法
最近碰到了幾次數(shù)據(jù)庫響應(yīng)變慢的問題,整理了一下處理的流程和分析思路,執(zhí)行腳本。希望對其他人有幫助。
MySQL慢查詢表現(xiàn)
明顯感覺到大部分的應(yīng)用功能都變慢,但也不是完全不能工作,等待比較長的時間還是有響應(yīng)的。但是整個系統(tǒng)看起來就非常的卡。
查詢慢查詢數(shù)量
一般來說一個正常運行的MySQL服務(wù)器,每分鐘的慢查詢在個位數(shù)是正常的,偶爾飆升到兩位數(shù)也不是不能接受,接近100系統(tǒng)可能就有問題了,但是還能勉強用。這幾次出問題慢查詢的數(shù)量已經(jīng)到了1000多。
慢查詢的數(shù)量保存在mysql庫里面的slow_log表。
SELECT * FROM `slow_log` where start_time > '2019/05/19 00:00:00';
這樣就能查出一天以來的慢查詢了。
查看當(dāng)前進行的查詢狀態(tài)
大家應(yīng)該都比較常用show processlist來查看當(dāng)前系統(tǒng)中正在執(zhí)行的查詢,其實這些數(shù)據(jù)也保存在information_schema庫里面的processlist表,因此如果要做條件查詢,直接查詢這張表更方便。
比如查看當(dāng)前所有的process
select * from information_schema.processlist
查看當(dāng)前正在進行的查詢并按照已經(jīng)執(zhí)行時間倒排
select * from information_schema.processlist where info is not null order by time desc
正常運行的數(shù)據(jù)庫,因為一條查詢的執(zhí)行速度很快,被我們的select抓到的info不是null的查詢數(shù)量會很少。我們這樣負荷很大的庫一般也就只能查到幾條。如果一次能查到info非空的查詢有幾十條,那么也可以認為系統(tǒng)出問題了。
系統(tǒng)問題和定位
當(dāng)我們察覺到系統(tǒng)變慢之后,馬上用慢查詢和查看processlist的方式做了檢查,結(jié)果發(fā)現(xiàn)每分鐘慢查詢數(shù)量飆升到1000多,同時淤積了大量的查詢在執(zhí)行中。
因為當(dāng)務(wù)之急是盡快恢復(fù)系統(tǒng)的正常運行,因此影響最直接的做法是在processlist的查詢結(jié)果中,查看有多少哪些查詢處于lock狀態(tài),或者已經(jīng)執(zhí)行了很長時間,把這些process用kill指令干掉。通過不停的殺死這些可能會引發(fā)系統(tǒng)阻塞的process,最終能夠暫時讓系統(tǒng)逐步恢復(fù)到正常狀態(tài),當(dāng)然這只是權(quán)宜之計。
此外,最重要的當(dāng)然是分析到底是哪些查詢?yōu)槭裁磿l(fā)系統(tǒng)阻塞,我們還是使用慢查詢來做分析。
慢查詢表查詢結(jié)果里面有幾個比較重要的指標:
start_time 開始時間,要通過這個參數(shù),配合系統(tǒng)出問題的時間,定位哪些查詢是罪魁禍首。
query_time 查詢時間
rows_sent 和 rows_examined發(fā)送的結(jié)果數(shù)以及查詢掃過的行數(shù),這兩個值特別重要,特別是 rows_examined?;旧暇湍芨嬖V我們,哪個查詢是需要注意的“大”查詢。
實際操作中,我們也是把有大量rows_examined的查詢一個個拿出來分析,添加索引,修改查詢語句的編寫,來徹底的解決問題。
處理結(jié)果和反思
經(jīng)過對所有慢查詢的檢查和整改,目前MySQL每分鐘慢查詢數(shù)徘徊在1~2之間,CPU的負荷也非常低。問題算是基本得到了解決。
反思一下問題出現(xiàn)的原因,有幾個地方需要注意:
1,數(shù)據(jù)庫出問題往往不是上線即引發(fā)問題,而是有一個累積的過程,不斷累加的糟糕的查詢語句會逐步增加系統(tǒng)負載,最后壓倒駱駝的最后一根稻草往往看上去莫名其妙
2,最后的一根稻草甚至有可能根本不存在,不是一次發(fā)版或者是功能上線,而是隨著用戶使用量上升,數(shù)據(jù)量的累積而爆發(fā)
3,既然問題的出現(xiàn)是累積的過程,就需要在每次代碼發(fā)版之前做好review
4,索引的添加很重要
5,慢查詢的監(jiān)控也需要納入到Zabbix的監(jiān)控范圍
感謝各位的閱讀,以上就是“mysql如何查詢慢的sql語句”的內(nèi)容了,經(jīng)過本文的學(xué)習(xí)后,相信大家對mysql如何查詢慢的sql語句這一問題有了更深刻的體會,具體使用情況還需要大家實踐驗證。這里是億速云,小編將為大家推送更多相關(guān)知識點的文章,歡迎關(guān)注!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。