mysql sql執行計畫

標籤：分析   mys   開始   資料庫   alt   explain   min()   file   dex   

查看Mysql執行計畫

使用navicat查看mysql執行計畫：

開啟profile分析工具：

查看是否生效：show variable like ‘%profil%’;

查看進程：show processlist;

選擇資料庫：use db_jiakao;

全部分析的類型：show PROFILE all;

查看錶索引：show index from user_member;##查看錶索引

使用explain命令查看query語句的效能：

EXPLAIN select * from user_feedback;##查看執行計畫中的sql效能

第一個查詢是全表掃描，第二個是索引掃描：

區別在於type:all是全表掃描 index 通過索引掃描

select_type：是否是複雜語句

下面是MySQL文檔關於ref連線類型的說明：

“對於每一種與另一個表中記錄的組合，MySQL將從當前的表讀取所有帶有匹配索引值的記錄。如果串連操作只使用鍵的最左首碼，或者如果鍵不是 UNIQUE或PRIMARY KEY類型（換句話說，如果串連操作不能根據索引值選擇出唯一行），則MySQL使用ref連線類型。如果串連操作所用的鍵只匹配少量的記錄，則ref是一 種好的連線類型。”

在本例中，由於索引不是UNIQUE類型，ref是我們能夠得到的最好連線類型。

如果EXPLAIN顯示連線類型是“ALL”，而且你並不想從表裡面選擇出大多數記錄，那麼MySQL的操作效率將非常低，因為它要掃描整個表。你可以加入更多的索引來解決這個問題。預知更多資訊，請參見MySQL的手冊說明。
possible_keys：
可能可以利用的索引的名字。這裡的索引名字是建立索引時指定的索引暱稱；如果索引沒有暱稱，則預設顯示的是索引中第一個列的名字。預設索引名字的含義往往不是很明顯。

Key：
它顯示了MySQL實際使用的索引的名字。如果它為空白（或NULL），則MySQL不使用索引。
key_len：
索引中被使用部分的長度，以位元組計。
ref：
它顯示的是列的名字（或單詞“const”），MySQL將根據這些列來選擇行。在本例中，MySQL根據三個常量選擇行。
rows：
MySQL所認為的它在找到正確的結果之前必須掃描的記錄數。顯然，這裡最理想的數字就是1。
Extra：
這裡可能出現許多不同的選項，其中大多數將對查詢產生負面影響。在本例中，MySQL只是提醒我們它將用WHERE子句限制搜尋結果集

 

◆ ID：Query Optimizer 所選定的執行計畫中查詢的序號；
◆ Select_type：所使用的查詢類型，主要有以下這幾種查詢類型
◇ DEPENDENT SUBQUERY：子查詢中內層的第一個SELECT，依賴於外部查詢的結果集；
◇ DEPENDENT UNION：子查詢中的UNION，且為UNION 中從第二個SELECT 開始的後面所有
SELECT，同樣依賴於外部查詢的結果集；
◇ PRIMARY：子查詢中的最外層查詢，注意並不是主鍵查詢；
◇ SIMPLE：除子查詢或者UNION 之外的其他查詢；
◇ SUBQUERY：子查詢內層查詢的第一個SELECT，結果不依賴於外部查詢結果集；
◇ UNCACHEABLE SUBQUERY：結果集無法緩衝的子查詢；
◇ UNION：UNION 語句中第二個SELECT 開始的後面所有SELECT，第一個SELECT 為PRIMARY
◇ UNION RESULT：UNION 中的合并結果；
◆ Table：顯示這一步所訪問的資料庫中的表的名稱；
◆ Type：告訴我們對錶所使用的訪問方式，主要包含如下集中類型；
◇ all：全表掃描
◇ const：讀常量，且最多隻會有一條記錄匹配，由於是常量，所以實際上只需要讀一次；
◇ eq_ref：最多隻會有一條匹配結果，一般是通過主鍵或者唯一鍵索引來訪問；
◇ fulltext：
◇ index：全索引掃描；
◇ index_merge：查詢中同時使用兩個（或更多）索引，然後對索引結果進行merge 之後再讀
取表資料；
◇ index_subquery：子查詢中的返回結果欄位組合是一個索引（或索引組合），但不是一個
主鍵或者唯一索引；
◇ rang：索引範圍掃描；
◇ ref：Join 語句中被驅動表索引引用查詢；
◇ ref_or_null：與ref 的唯一區別就是在使用索引引用查詢之外再增加一個空值的查詢；
◇ system：系統資料表，表中只有一行資料；
◇ unique_subquery：子查詢中的返回結果欄位組合是主鍵或者唯一約束；
◇
◆ Possible_keys：該查詢可以利用的索引. 如果沒有任何索引可以使用，就會顯示成null，這一
項內容對於最佳化時候索引的調整非常重要；
◆ Key：MySQL Query Optimizer 從possible_keys 中所選擇使用的索引；
◆ Key_len：被選中使用索引的索引鍵長度；
◆ Ref：列出是通過常量（const），還是某個表的某個欄位（如果是join）來過濾（通過key）
的；
◆ Rows：MySQL Query Optimizer 通過系統收集到的統計資訊估算出來的結果集記錄條數；
◆ Extra：查詢中每一步實現的額外細節資訊，主要可能會是以下內容：
◇ Distinct：尋找distinct 值，所以當mysql 找到了第一條匹配的結果後，將停止該值的查
詢而轉為後面其他值的查詢；
◇ Full scan on NULL key：子查詢中的一種最佳化方式，主要在遇到無法通過索引訪問null
值的使用使用；
◇ Impossible WHERE noticed after reading const tables：MySQL Query Optimizer 通過
收集到的統計資訊判斷出不可能存在結果；
◇ No tables：Query 語句中使用FROM DUAL 或者不包含任何FROM 子句；
◇ Not exists：在某些左串連中MySQL Query Optimizer 所通過改變原有Query 的組成而
使用的最佳化方法，可以部分減少資料訪問次數；
◇ Range checked for each record (index map: N)：通過MySQL 官方手冊的描述，當
MySQL Query Optimizer 沒有發現好的可以使用的索引的時候，如果發現如果來自前面的
表的列值已知，可能部分索引可以使用。對前面的表的每個行組合，MySQL 檢查是否可以使
用range 或index_merge 存取方法來索取行。
◇ Select tables optimized away：當我們使用某些彙總函式來訪問存在索引的某個欄位的
時候，MySQL Query Optimizer 會通過索引而直接一次定位到所需的資料行完成整個查
詢。當然，前提是在Query 中不能有GROUP BY 操作。如使用MIN()或者MAX（）的時
候；
◇ Using filesort：當我們的Query 中包含ORDER BY 操作，而且無法利用索引完成排序操
作的時候，MySQL Query Optimizer 不得不選擇相應的排序演算法來實現。
◇ Using index：所需要的資料只需要在Index 即可全部獲得而不需要再到表中取資料；
◇ Using index for group-by：資料訪問和Using index 一樣，所需資料只需要讀取索引即
可，而當Query 中使用了GROUP BY 或者DISTINCT 子句的時候，如果分組欄位也在索引
中，Extra 中的資訊就會是Using index for group-by；
◇ Using temporary：當MySQL 在某些操作中必須使用暫存資料表的時候，在Extra 資訊中就會
出現Using temporary 。主要常見於GROUP BY 和ORDER BY 等操作中。
◇ Using where：如果我們不是讀取表的所有資料，或者不是僅僅通過索引就可以擷取所有需
要的資料，則會出現Using where 資訊；
◇ Using where with pushed condition：這是一個僅僅在NDBCluster 儲存引擎中才會出現
的資訊，而且還需要通過開啟Condition Pushdown 最佳化功能才可能會被使用。控制參數
為engine_condition_pushdown 。

mysql sql執行計畫