sql優化過程 執行計畫

1 什麼是sql執行計畫

sql執行計畫，就是一條sql語句，在資料庫中實際執行的時候，一步步的分別都做了什麼。就是我們用explain分析一條sql語句時展示出來的那些資訊

sql執行計畫的意義就在於我們可以通過執行計畫更加清晰的認識到這一條語句，分為了哪幾步，有沒有用到索引，是否有一些可優化的地方等

使用 explain 關鍵字可以讓你知道 mysql 是如何處理你的 sql 語句的。這 可以幫你分析你的查詢語句或是表結構的效能瓶頸。

挑乙個你的 select 語句(推薦挑選那個最複雜的，有多表聯接的)，把關鍵 字 explain 加到前面。你可以使用 phpmyadmin 來做這個事。然後，你會看到一 張**。下面的這個示例中，我們忘記加上了 group_id 索引，並且有表聯接：

當我們為 group_id 字段加上索引後：

我們可以看到，前乙個結果顯示搜尋了 7883 行，而後乙個只是搜尋了兩個 表的 9 和 16 行。檢視 rows 列可以讓我們找到潛在的效能問題。

字段型別解釋

其中，id 表示查詢表的執行優先順序 id 值越大執行優先順序越高;id相同說明是重上往下執行 ;

select_type : 查詢的型別，主要是用於區分普通查詢、聯合查詢、子查詢等複雜的查詢

1、******：簡單的select查詢，查詢中不包含子查詢或者union

2、primary：查詢中包含任何複雜的子部分，最外層查詢則被標記為primary

3、subquery：在select 或 where列表中包含了子查詢

4、derived：在from列表中包含的子查詢被標記為derived（衍生），mysql或遞迴執行這些子查詢，把結果放在零時表裡

5、union：若第二個select出現在union之後，則被標記為union；若union包含在from子句的子查詢中，外層select將被標記為derived

6、union result：從union表獲取結果的select

type訪問型別

，sql查詢優化中乙個很重要的指標，結果值從好到壞依次是：

system > const > eq_ref > ref > fulltext > ref_or_null > index_merge >

unique_subquery > index_subquery > range > index > all

1、system：表只有一行記錄（等於系統表），這是const型別的特例，平時不會出現，可以忽略不計

2、const：表示通過索引一次就找到了，const用於比較primary key 或者

unique索引。因為只需匹配一行資料，所有很快。如果將主鍵置於where列表中，mysql就能將該查詢轉換為乙個const

3、eq_ref：唯一性索引掃瞄，對於每個索引鍵，表中只有一條記錄與之匹配。常見於主鍵 或 唯一索引掃瞄。

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

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

6、index：full index

scan，index與all區別為index型別只遍歷索引樹。這通常為all塊，應為索引檔案通常比資料檔案小。（index與all雖然都是讀全表，但index是從索引中讀取，而all是從硬碟讀取）

7、all：full table scan，遍歷全表以找到匹配的行

查詢涉及到的字段上存在索引，則該索引將被列出，但不一定被查詢實際使用

key

實際使用的索引，如果為null，則沒有使用索引。 查詢中如果使用了覆蓋索引，則該索引僅出現在key列表中

primary的話，表示使用了主鍵；

key_len

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

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

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

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

mysql對資料使用乙個外部的索引排序，而不是按照表內的索引進行排序讀取。也就是說mysql無法利用索引完成的排序操作成為「檔案排序」

由於索引是先按email排序、再按address排序，所以查詢時如果直接按address排序，索引就不能滿足要求了，mysql內部必須再實現一次「檔案排序」

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

表示相應的select操作中使用了覆蓋索引（covering index），避免了訪問表的資料行，效率高 如果同時出現using

where，表明索引被用來執行索引鍵值的查詢（參考上圖） 如果沒用同時出現using where，表明索引用來讀取資料而非執行查詢動作

覆蓋索引（covering index）：也叫索引覆蓋。就是select列表中的字段，只用從索引中就能獲取，不必根據索引再次讀取資料檔案，換句話說查詢列要被所建的索引覆蓋。

注意：a、如需使用覆蓋索引，select列表中的字段只取出需要的列，不要使用select *

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

使用了where過濾

使用了鏈結快取

where子句的值總是false，不能用來獲取任何元祖

在沒有group

by子句的情況下，基於索引優化min/max操作或者對於myisam儲存引擎優化count（*）操作，不必等到執行階段在進行計算，查詢執行計畫生成的階段即可完成優化

優化distinct操作，在找到第乙個匹配的元祖後即停止找同樣值得動作

Sql優化 執行計畫

一段sql 寫好以後，可以通過檢視sql的執行計畫，初步 該sql在執行時的效能好壞，尤其是在發現某個sql語句的效率較差時，我們可以通過檢視執行計畫，分析出該sql 的問題所在。1 開啟熟悉的檢視工具 pl sql developer。在pl sql developer中寫好一段sql 後，按f5...

SQL執行計畫 02 通過執行計畫優化sql

1 where子句的查詢條件中，如果是範圍查詢那麼索引列的值 是走索引的 和 是不走索引的 舉例 age列有普通索引 select from test table where age 100 走索引 select from test table where age 100 不走索引 2 盡量使用主鍵...

高效能sql優化 執行計畫

一 序言 執行計畫是sql調優必不可少的一部分，如果你還是簡單的認為我們向資料庫發出一條sql語句，資料庫只是根據我們的需求解析sql語句，然後返回我們想要的結果，那你真的是太天真了，因為資料庫還會對每條通過會話發出的sql進行一系列的檢查 分析和處理，然後由優化器選擇生成護著選定出乙個成本最低的執...