站長資訊網
        最全最豐富的資訊網站

        mysql怎么查詢慢的sql語句

        方法:1、若未開啟慢查詢,用“set global slow_query_log='ON';”開啟慢;2、用“set global slow_query_log_file=路徑”設置慢查詢文件保存位置;3、用“subl 路徑”查詢文件即可。

        mysql怎么查詢慢的sql語句

        本教程操作環(huán)境:centos 7系統(tǒng)、mysql8.0.22版本、Dell G3電腦。

        mysql怎么查詢慢的sql語句

        Mysql中 查詢慢的 Sql語句的記錄查找

        慢查詢日志 slow_query_log,是用來記錄查詢比較慢的sql語句,通過查詢日志來查找哪條sql語句比較慢,這樣可以對比較慢的sql可以進行優(yōu)化。

        登陸mysql數據庫:

        mysql怎么查詢慢的sql語句

        1、查看一下當前的慢查詢是否開啟,若未開啟則開啟

        以及慢查詢所規(guī)定的時間:

        show variables like 'slow_query_log'; show variableslike 'long_query_time';

        mysql怎么查詢慢的sql語句

        如果你的查詢后的結果是OFF 狀態(tài)的話,就需要通過相關設置將其修改為ON狀態(tài):

        set global slow_query_log='ON';

        mysql怎么查詢慢的sql語句

        將慢查詢追蹤的時間設置為1s:

        mysql怎么查詢慢的sql語句

        這里你在設置之后,這個世界是不會立即變成1s的,需要在數據庫重啟后才生效:

        mysql怎么查詢慢的sql語句

        2、設置慢查詢日志文件保存的位置:

        set global slow_query_log_file='/var/lib/mysql/test_1116.log';

        3、 查看以下配置后的文件:

        sudo subl /var/lib/mysql/test_1116.log

        mysql怎么查詢慢的sql語句

        擴展知識:

        MySQL數據庫慢查詢問題排查方法

        最近碰到了幾次數據庫響應變慢的問題,整理了一下處理的流程和分析思路,執(zhí)行腳本。希望對其他人有幫助。

        MySQL慢查詢表現(xiàn)

        明顯感覺到大部分的應用功能都變慢,但也不是完全不能工作,等待比較長的時間還是有響應的。但是整個系統(tǒng)看起來就非常的卡。

        查詢慢查詢數量

        一般來說一個正常運行的MySQL服務器,每分鐘的慢查詢在個位數是正常的,偶爾飆升到兩位數也不是不能接受,接近100系統(tǒng)可能就有問題了,但是還能勉強用。這幾次出問題慢查詢的數量已經到了1000多。

        慢查詢的數量保存在mysql庫里面的slow_log表。

        SELECT * FROM `slow_log` where start_time > '2019/05/19 00:00:00';

        這樣就能查出一天以來的慢查詢了。

        查看當前進行的查詢狀態(tài)

        大家應該都比較常用show processlist來查看當前系統(tǒng)中正在執(zhí)行的查詢,其實這些數據也保存在information_schema庫里面的processlist表,因此如果要做條件查詢,直接查詢這張表更方便。

        比如查看當前所有的process

        select * from information_schema.processlist

        查看當前正在進行的查詢并按照已經執(zhí)行時間倒排

        select * from information_schema.processlist where info is not null order by time desc

        正常運行的數據庫,因為一條查詢的執(zhí)行速度很快,被我們的select抓到的info不是null的查詢數量會很少。我們這樣負荷很大的庫一般也就只能查到幾條。如果一次能查到info非空的查詢有幾十條,那么也可以認為系統(tǒng)出問題了。

        系統(tǒng)問題和定位

        當我們察覺到系統(tǒng)變慢之后,馬上用慢查詢和查看processlist的方式做了檢查,結果發(fā)現(xiàn)每分鐘慢查詢數量飆升到1000多,同時淤積了大量的查詢在執(zhí)行中。

        因為當務之急是盡快恢復系統(tǒng)的正常運行,因此影響最直接的做法是在processlist的查詢結果中,查看有多少哪些查詢處于lock狀態(tài),或者已經執(zhí)行了很長時間,把這些process用kill指令干掉。通過不停的殺死這些可能會引發(fā)系統(tǒng)阻塞的process,最終能夠暫時讓系統(tǒng)逐步恢復到正常狀態(tài),當然這只是權宜之計。

        此外,最重要的當然是分析到底是哪些查詢?yōu)槭裁磿l(fā)系統(tǒng)阻塞,我們還是使用慢查詢來做分析。

        慢查詢表查詢結果里面有幾個比較重要的指標:

        start_time 開始時間,要通過這個參數,配合系統(tǒng)出問題的時間,定位哪些查詢是罪魁禍首。

        query_time 查詢時間

        rows_sent 和 rows_examined發(fā)送的結果數以及查詢掃過的行數,這兩個值特別重要,特別是 rows_examined。基本上就能告訴我們,哪個查詢是需要注意的“大”查詢。

        實際操作中,我們也是把有大量rows_examined的查詢一個個拿出來分析,添加索引,修改查詢語句的編寫,來徹底的解決問題。

        處理結果和反思

        經過對所有慢查詢的檢查和整改,目前MySQL每分鐘慢查詢數徘徊在1~2之間,CPU的負荷也非常低。問題算是基本得到了解決。

        反思一下問題出現(xiàn)的原因,有幾個地方需要注意:

        1,數據庫出問題往往不是上線即引發(fā)問題,而是有一個累積的過程,不斷累加的糟糕的查詢語句會逐步增加系統(tǒng)負載,最后壓倒駱駝的最后一根稻草往往看上去莫名其妙

        2,最后的一根稻草甚至有可能根本不存在,不是一次發(fā)版或者是功能上線,而是隨著用戶使用量上升,數據量的累積而爆發(fā)

        3,既然問題的出現(xiàn)是累積的過程,就需要在每次代碼發(fā)版之前做好review

        4,索引的添加很重要

        5,慢查詢的監(jiān)控也需要納入到Zabbix的監(jiān)控范圍

        推薦學習:mysql視頻教程

        贊(0)
        分享到: 更多 (0)
        網站地圖   滬ICP備18035694號-2    滬公網安備31011702889846號
        主站蜘蛛池模板: 网友偷拍日韩精品| 午夜精品久久久久久久久| 久久久久国产精品三级网| 国产精品久久久久…| 亚洲国产成人精品91久久久 | 国产欧美日本亚洲精品一5| 99re热这里只有精品视频中文字幕| 尤物TV国产精品看片在线| 国产精品女同一区二区久久| 999在线视频精品免费播放观看 | jiucao在线观看精品| 亚洲精品一级无码鲁丝片| 久久精品夜色噜噜亚洲A∨| 隔壁老王国产在线精品| 四虎精品成人免费观看| 2021精品国产综合久久| 日韩人妻无码精品久久免费一| 三级国产精品| 久久亚洲国产成人精品无码区| 国产精品成人99久久久久91gav| 国产精品一区二区久久| 凹凸国产熟女精品视频app| 精品久久久久久久无码 | 亚洲av午夜精品一区二区三区 | 97精品伊人久久大香线蕉app| 亚洲AV成人无码久久精品老人| 伊人久久精品无码二区麻豆| 亚洲精品一级无码中文字幕| 亚洲精品乱码久久久久久不卡| 亚洲国产91精品无码专区| 一本精品中文字幕在线| 亚洲精品国产字幕久久不卡| 亚洲欧美日韩国产精品一区二区| 婷婷成人国产精品| 最新国产精品精品视频| 日韩精品一区二区亚洲AV观看| 无码日韩人妻精品久久蜜桃| 人妻少妇精品视频一区二区三区| 亚洲国产精品一区第二页| 人妻少妇乱子伦精品| 国产成人精品无码免费看 |