1. 程式人生 > >SQL查詢語句優化 從explain入手 多使用Profile

SQL查詢語句優化 從explain入手 多使用Profile

、SQL查詢語句優化基本思路和原則

  • 優化更需要優化的Query。
  • 定位優化物件的效能瓶頸。
  • 明確優化目標。
  • 從Explain入手。
  • 多使用Profile。
  • 永遠用小結果集驅動大的結果集。
  • 儘可能在索引中完成排序。
  • 只取自己需要的Columns。
  • 僅僅使用最有效的過濾條件。
  • 儘可能避免複雜的Join和子查詢

 

二、explain入手

 

explain進行分析執行計劃,並解釋各個值

  • id 這個id不是主鍵的意思,他是用來標識select查詢的序列號,包含一組數字,表示查詢中執行select子句或者操作表的順序。會出現以下情況:

id相同:按從上到下順序執行。

id不同:id值越大,優先順序越高,越先被執行。

id相同不同的同時存在:優先執行id值大的,如果id值相同,則按從上到下的順序執行。

id為null表示是用來合併結果集的,在sql使用union關鍵字合併結果集就會出現他。

  • select_type

  • type

訪問型別,sql查詢優化中一個很重要的指標,結果值從好到壞依次是:

system>const>eq_ref>ref>fulltext >ref_or_null >index_merge >unique_subquery >index_subquery >range

>index>ALL

system 表只有一行記錄(等於系統表),這是const型別的特例,平時不會出現,可以忽略不計。

const 表示通過索引一次就找到了,const用於比較primary key 或者 unique索引。因為只需匹配一行資料,所有很快。如果將主鍵置於where列表中,mysql就能將該查詢轉換為一個const

eq_ref 唯一性索引掃描,對於每個索引鍵,表中只有一條記錄與之匹配。常見於主鍵 唯一索引掃描。

ref 非唯一性索引掃描,返回匹配某個單獨值的所有行。本質是也是一種索引訪問,它返回所有匹配某個單獨值的行,然而他可能會找到多個符合條件的行,所以它應該屬於查詢和掃描的混合體。

range 只檢索給定範圍的行,使用一個索引來選擇行。key列顯示使用了那個索引。一般就是在where語句中出現了bettween<>in等的查詢。這種索引列上的範圍掃描比全索引掃描要好。只需要開始於某個點,結束於另一個點,不用掃描全部索引。

index Full Index ScanindexALL區別為index型別只遍歷索引樹。這通常為ALL塊,應為索引檔案通常比資料檔案小。(IndexALL雖然都是讀全表,但index是從索引中讀取,而ALL是從硬碟讀取)。

ALL Full Table Scan,遍歷全表以找到匹配的行。

 

  • key

實際使用的索引,如果為NULL,則沒有使用索引。

查詢中如果使用了覆蓋索引,則該索引僅出現在key列表中

 

 

  • key_len

表示索引中使用的位元組數,查詢中使用的索引的長度(最大可能長度),並非實際使用長度,理論上長度越短越好。key_len是根據表定義計算而得的,不是通過表內檢索出的。

 

  • ref

顯示索引的那一列被使用了,如果可能,是一個常量const

  • rows

根據表統計資訊及索引選用情況,大致估算出找到所需的記錄所需要讀取的行數。

  • Extra

不適合在其他欄位中顯示,但是十分重要的額外資訊

  1. Using filesort mysql對資料使用一個外部的索引排序,而不是按照表內的索引進行排序讀取。也就是說mysql無法利用索引完成的排序操作成為檔案排序

 

2Using temporary 使用臨時表儲存中間結果,也就是說mysql在對查詢結果排序時使用了臨時表,常見於order by group by

3Using index 表示相應的select操作中使用了覆蓋索引,避免了訪問表的資料行,效率高。如果同時出現Using where,表明索引被用來執行索引鍵值的查詢(參考上圖)如果沒用同時出現Using where,表明索引用來讀取資料而非執行查詢動作

覆蓋索引也叫索引覆蓋。就是select列表中的欄位,只用從索引中就能獲取,不必根據索引再次讀取資料檔案,換句話說查詢列要被所建的索引覆蓋

注意:

a、如需使用覆蓋索引,select列表中的欄位只取出需要的列,不要使用select *

b、如果將所有欄位都建索引會導致索引檔案過大,反而降低crud效能。

 

三、多使用Profile

想優化一條SQL,就必須清楚這條SQL的查詢效能瓶頸到底在哪裡,是消耗的CPU計算太多還是IO操作太多。通過QUERY Profiler功能,可以分析多種資源的消耗情況,如CPUIOIPCSWAP等,同時還能得到該QUERY執行過程中MySQl所呼叫的各個函式在原始檔中的位置。

先開啟profile功能

使用命令 set profiling = 1 可以開啟關閉的功能。

開啟profile功能後,MySQl就會自動記錄所有執行的QUERYProfile資訊。如執行SQL

檢視所有執行的QUERYProfile資訊

使用命令show profiles 獲取當前系統中儲存的多個QUERYprofile資訊

 

獲取單個QUERY的詳細的profile資訊

show profile cpu,block io,IPC,SOURCE,SWAPS for query Query_ID;

  • All 顯示所有效能資訊
  • BLOCK IO 顯示塊IO操作的次數
  • CONTEXT SWITCHES 顯示上下文切換次數,不管是主動還是被動
  • CPU 顯示使用者CPU時間、系統CPU時間
  • IPC 顯示傳送和接收的訊息數量
  • PAGE FAULTS 顯示頁錯誤數量
  • SOURCE 顯示原始碼中的函式名稱與位置
  • SWAPS 顯示SWAP的次數