推薦學習:
對於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上用命令可以檢視,如下:
這個值是可以修改的:
在開啟慢查詢紀錄檔開關的時候,報錯表示slow_query_log是一個global的變數(也有隻影響當前session的變數,如:long_query_time 、profiling),修改後會影響所有的session,即影響所有正在存取當前MySQL server的使用者端。
開啟慢查詢紀錄檔開關成功!
檢視另一個session
發現還是預設的10s,故long_query_time隻影響當前session
已經超過我們設定的long_query_time=0.1s
路徑:/var/lib/mysql/
做了整表的搜尋,把主鍵索引樹整個掃了一遍。
我們應該給password新增索引,然後記得password是字串格式,因為如果涉及型別轉換是用不了索引的
MySQL一般只顯示小數點後兩位的時間
開啟profiling開關,顯示更詳細的時間
沒有報錯,說明profiling變數隻影響當前session
推薦學習:
以上就是詳細瞭解MySQL慢紀錄檔查詢的詳細內容,更多請關注TW511.COM其它相關文章!