Mysql之執行計畫

1.explain分析sql語句

例如：

explain select

*from blog_info bi inner
join uam_view_unit_account uua 
on bi.account_instance_id = uua.account_instance_id 
where bi.is_comment =
0or (bi.is_comment =
1and bi.is_forward =
1)order by bi.`publish_time`

而今天檢查的不是這條sql，遠比這條複雜，不過也能反映情況了。

（1）使用檢視導致sql在執行過程中需要用中間表，就是using temporary。 因為檢視無法使用索引，這也導致效能會比較低效。

（2）當有order by出現時，而且排序字段沒有新增索引，那就會導致using filesort，導致磁碟的檔案排序。

（3）而因為uam_view_unit_account 這個檢視是union4張表得出的（union result），這裡面rows和type都無法提高效能。

2.屬性解析

只記幾個重要的屬性：

select_type：所使用的查詢型別，主要有以下這幾種查詢型別。

dependent subquery：子查詢內層的第乙個select，依賴於外部查詢的結果集。
dependent union：子查詢中的union，且為union中從第二個select開始的後面所有select，同樣依賴於外部查詢的結果集。
primary：子查詢中的最外層查詢，注意並不是主鍵查詢。
******：除子查詢或union之外的其他查詢。
subquery：子查詢內層查詢的第乙個select，結果不依賴於外部查詢結果集。
uncacheable subquery：結果集無法快取的子查詢。
union：union語句中第二個select開始後面的所有select，第乙個select為primary。
union result：union 中的合併結果。

type：告訴我們對錶使用的訪問方式，主要包含如下集中型別。

all：全表掃瞄。
const
：讀常量，最多隻會有一條記錄匹配，由於是常量，實際上只須要讀一次。
eq_ref：最多隻會有一條匹配結果，一般是通過主鍵或唯一鍵索引來訪問。
fulltext：進行全文索引檢索。
index：全索引掃瞄。
index_subquery：子查詢中的返回結果字段組合是乙個索引（或索引組合），但不是乙個主鍵或唯一索引。
rang：索引範圍掃瞄。
ref：join語句中被驅動表索引引用的查詢。
ref_or_null：與ref的唯一區別就是在使用索引引用的查詢之外再增加乙個空值的查詢。
system：系統表，表中只有一行資料；
unique_subquery：子查詢中的返回結果字段組合是主鍵或唯一約束。

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

一般來說，得保證查詢至少達到range

級別，最好能達到

ref，否則就可能會出現效能問題。

extra：查詢中每一步實現的額外細節資訊，主要會是以下內容。

distinct：查詢distinct 值，當mysql找到了第一條匹配的結果時，將停止該值的查詢，轉為後面其他值查詢。
full scan on null key：子查詢中的一種優化方式，主要在遇到無法通過索引訪問null值的使用。
range checked 
foreach 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 。
impossible where noticed after reading 
const
tables：mysql query optimizer 通過收集到的統計資訊判斷出不可能存在結果。
no tables：query 語句中使用 from dual或不包含任何 from子句。
not exists：在某些左連線中，mysql query optimizer通過改變原有 query 的組成而使用的優化方法，可以部分減少資料訪問次數。

3.小總結

（1）如果發現某條sql執行非常慢，那就需要將直接sql在資料庫裡進行explain分析。

（2）檢視explain的**，重點檢視裡面的type、rows、extra三個屬性。

1.type為all或index；

2.extra有using filesort或using temporary；

3.rows的數值跟其表的資料條數差不多；

這個時候代表這條sql急需優化了。

（3）根據分析提示建相關的索引，甚至是修改sql寫法，以便提高效率。

mysql 之執行計畫

原文 執行計畫，簡單的來說，是sql在資料庫中執行時的表現情況,通常用於sql效能分析,優化等場景。在mysql中使用 explain 關鍵字來檢視。如下所示 1.查詢t base user select from t base user where name andyqian 2.檢視上述語句的執...

mysql執行計畫 MySQL 執行計畫

1.執行計畫的定義 什麼是執行計畫 查詢計畫 呢？執行計畫就是一系列的操作步驟。sql是宣告性語言，它只告訴資料庫要查詢什麼，但並不告訴資料庫如何去查。資料庫所要做的就是基於演算法和統計資訊計算出一條最佳的訪問路徑。這個工作是由優化器來完成的。優化器會比較不同的執行計畫，然後選擇其中最優的一套。2....

MySQL學習之執行計畫

執行計畫 乙個預估sql語句執行的時間的操作 關鍵字 explain 雖然有mysql優化的措施避免一些不能命中索引的方式，但是最後還是要看sql語句的執行時間，時間短就是好的。執行計畫是以最壞的打算進行預估sql語句執行的時間，所以只能作為參考。以後拿到乙個sql語句的時候，先進行執行計畫。exp...