MySQL慢日誌查詢實例分析

一、慢查詢日誌概念

使用explain分析SQL語句是為了最佳化SQL和索引的問題。對於真正的企業級項目，其SQL語句可能達到成千上萬條，因此我們無法逐條解釋並進行分析。我們從什麼地方可以取得那些運行時間長，耗效能的SQL？ ？

我們可以開啟慢查詢日誌：

根據特定的業務和並發量來預估一個時間上限（20ms、100ms），設定好後開啟業務，壓測後開啟慢查詢日誌，就會看到超過執行時間的SQL，然後使用explain分析這些耗時的SQL語句

步驟如下：

• 打開慢查詢日誌開關slow_query_log

• 設定合理的、業務可以接受的慢查詢時間上限

• ##壓測執行各種業務

• 查看慢查詢日誌，找出所有執行耗時的SQL語句

• 用explain分析這些耗時的SQL語句，從而針對性優化

MySQL可以設定慢查詢日誌，當SQL執行的時間超過我們設定的時間，那麼這些SQL就會被記錄在慢查詢日誌當中，然後我們透過查看日誌，用explain分析這些SQL的執行計劃，來判定為什麼效率低下，是沒有使用到索引？還是索引本身創建的有問題？或者索引使用到了，但是由於表的資料量太大，花費的時間就是很長，那麼此時我們可以把表分成多個小表等。

慢查詢日誌相關的參數如下所示：

（MySQL定義的很多的全局的開關，都是在全局變數中存儲，可以用
show/set variables查看或設定全域變數的值）

慢查詢日誌開關預設是關閉的
慢查詢日誌的路徑：預設在
/var/lib/mysql/下

慢查詢日誌記錄了包含所有執行時間超過參數long_query_time（單位：秒）所設定值的SQL語句的日誌，在MySQL上用指令可以查看，如下：

# 這個值是可以修改的：

二、慢查詢日誌實作

1. 開啟慢速查詢日誌開關slow_query_log

在開啟慢速查詢日誌開關的時候，報錯表示slow_query_log是一個global的變數（也有隻影響當前session的變量，如：long_query_time 、profiling ），修改後會影響所有的session，也就是影響所有正在存取目前MySQL server的客戶端。

開啟慢速查詢日誌開關成功！

2. 設定合理的、業務可以接受的慢查詢時間上限long_query_time

看另一個session

發現還是預設的10s，故long_query_time只影響當前session

#3. 壓測執行各種業務

已經超過我們設定的long_query_time=0.1s

4. 查看慢查詢日誌

路徑：

/var/lib/mysql/

#5. 用explain分析這些耗時的SQL語句，以便針對性最佳化

做了整表的搜索，把主鍵索引樹整個掃了一遍。

我們應該要為password加上索引，然後記得password是字串格式，因為如果涉及型別轉換是用不了索引的

三、show profiles看sql具體的運行時間

MySQL一般只顯示小數點後兩位的時間

開啟profiling開關，顯示更詳細的時間

沒有報錯，表示profiling變數只會影響目前session

以上是MySQL慢日誌查詢實例分析的詳細內容。更多資訊請關注PHP中文網其他相關文章！