一、慢查詢日誌概念

對於SQL和索引的優化問題，我們會使用explain去分析SQL語句。但是真正的企業級專案有成千上萬條SQL，我們不可能從頭開始一條一條explain去分析。我們從什麼地方可以獲取那些執行時間長，耗效能的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. 壓測執行各種業務

4. 檢視慢查詢日誌

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

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

三、show profiles檢視sql具體的執行時間

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

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

沒有報錯，說明profiling變數隻影響當前session