共計 2407 個字符，預計需要花費 7 分鐘才能閱讀完成。
這篇文章主要講解了“mysql 如何查詢慢的 sql 語句”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著丸趣 TV 小編的思路慢慢深入，一起來研究和學習“mysql 如何查詢慢的 sql 語句”吧！
方法：1、若未開啟慢查詢，用“set global slow_query_log= ON”開啟慢；2、用“set global slow_query_log_file= 路徑”設置慢查詢文件保存位置；3、用“subl 路徑”查詢文件即可。
本教程操作環境：centos 7 系統、mysql8.0.22 版本、Dell G3 電腦。
mysql 怎么查詢慢的 sql 語句
Mysql 中 查詢慢的 Sql 語句的記錄查找
慢查詢日志 slow_query_log，是用來記錄查詢比較慢的 sql 語句，通過查詢日志來查找哪條 sql 語句比較慢，這樣可以對比較慢的 sql 可以進行優化。
登陸 mysql 數據庫：
1、查看一下當前的慢查詢是否開啟，若未開啟則開啟
以及慢查詢所規定的時間：
show variables like slow_query_log
show variableslike long_query_time如果你的查詢后的結果是 OFF 狀態的話，就需要通過相關設置將其修改為 ON 狀態：
set global slow_query_log= ON將慢查詢追蹤的時間設置為 1s：
這里你在設置之后，這個世界是不會立即變成 1s 的，需要在數據庫重啟后才生效：
2、設置慢查詢日志文件保存的位置：
set global slow_query_log_file= /var/lib/mysql/test_1116.log3、查看以下配置后的文件：
sudo subl /var/lib/mysql/test_1116.log擴展知識：
MySQL 數據庫慢查詢問題排查方法
最近碰到了幾次數據庫響應變慢的問題，整理了一下處理的流程和分析思路，執行腳本。希望對其他人有幫助。
MySQL 慢查詢表現
明顯感覺到大部分的應用功能都變慢，但也不是完全不能工作，等待比較長的時間還是有響應的。但是整個系統看起來就非常的卡。
查詢慢查詢數量
一般來說一個正常運行的 MySQL 服務器，每分鐘的慢查詢在個位數是正常的，偶爾飆升到兩位數也不是不能接受，接近 100 系統可能就有問題了，但是還能勉強用。這幾次出問題慢查詢的數量已經到了 1000 多。
慢查詢的數量保存在 mysql 庫里面的 slow_log 表。
SELECT * FROM `slow_log` where start_time 2019/05/19 00:00:00這樣就能查出一天以來的慢查詢了。
查看當前進行的查詢狀態
大家應該都比較常用 show processlist 來查看當前系統中正在執行的查詢，其實這些數據也保存在 information_schema 庫里面的 processlist 表，因此如果要做條件查詢，直接查詢這張表更方便。
比如查看當前所有的 process
select * from information_schema.processlist查看當前正在進行的查詢并按照已經執行時間倒排
select * from information_schema.processlist where info is not null order by time desc正常運行的數據庫，因為一條查詢的執行速度很快，被我們的 select 抓到的 info 不是 null 的查詢數量會很少。我們這樣負荷很大的庫一般也就只能查到幾條。如果一次能查到 info 非空的查詢有幾十條，那么也可以認為系統出問題了。
系統問題和定位
當我們察覺到系統變慢之后，馬上用慢查詢和查看 processlist 的方式做了檢查，結果發現每分鐘慢查詢數量飆升到 1000 多，同時淤積了大量的查詢在執行中。
因為當務之急是盡快恢復系統的正常運行，因此影響最直接的做法是在 processlist 的查詢結果中，查看有多少哪些查詢處于 lock 狀態，或者已經執行了很長時間，把這些 process 用 kill 指令干掉。通過不停的殺死這些可能會引發系統阻塞的 process，最終能夠暫時讓系統逐步恢復到正常狀態，當然這只是權宜之計。
此外，最重要的當然是分析到底是哪些查詢為什么會引發系統阻塞，我們還是使用慢查詢來做分析。
慢查詢表查詢結果里面有幾個比較重要的指標：
start_time 開始時間，要通過這個參數，配合系統出問題的時間，定位哪些查詢是罪魁禍首。
query_time 查詢時間
rows_sent 和 rows_examined 發送的結果數以及查詢掃過的行數，這兩個值特別重要，特別是 rows_examined。基本上就能告訴我們，哪個查詢是需要注意的“大”查詢。
實際操作中，我們也是把有大量 rows_examined 的查詢一個個拿出來分析，添加索引，修改查詢語句的編寫，來徹底的解決問題。
處理結果和反思
經過對所有慢查詢的檢查和整改，目前 MySQL 每分鐘慢查詢數徘徊在 1~2 之間，CPU 的負荷也非常低。問題算是基本得到了解決。
反思一下問題出現的原因，有幾個地方需要注意：
1，數據庫出問題往往不是上線即引發問題，而是有一個累積的過程，不斷累加的糟糕的查詢語句會逐步增加系統負載，最后壓倒駱駝的最后一根稻草往往看上去莫名其妙
2，最后的一根稻草甚至有可能根本不存在，不是一次發版或者是功能上線，而是隨著用戶使用量上升，數據量的累積而爆發
3，既然問題的出現是累積的過程，就需要在每次代碼發版之前做好 review
4，索引的添加很重要
5，慢查詢的監控也需要納入到 Zabbix 的監控范圍
感謝各位的閱讀，以上就是“mysql 如何查詢慢的 sql 語句”的內容了，經過本文的學習后，相信大家對 mysql 如何查詢慢的 sql 語句這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是丸趣 TV，丸趣 TV 小編將為大家推送更多相關知識點的文章，歡迎關注！
