前言

	在實際數據庫項目開發中，由於我們不知道實際查詢時數據庫里發生了什么，也不知道數據庫是如何掃描表、如何使用索引的，因此，我們能感知到的就只有SQL語句的執行時間。尤其在數據規模比較大的場景下，如何寫查詢、優化查詢、如何使用索引就顯得很重要了。

	那么，問題來了，在查詢前有沒有可能估計下查詢要掃描多少行、使用哪些索引呢？

答案是肯定的。以MySQL為例，MySQL通過explain命令輸出執行計划，對要執行的查詢進行分析。
什么是執行計划呢？

	簡單來說，就是SQL在數據庫中執行時的表現情況，通常用於SQL性能分析、優化等場景。

MySQL查詢過程

如果能搞清楚MySQL是如何優化和執行查詢的，對優化查詢一定會有幫助。很多查詢優化實際上就是遵循一些原則讓優化器能夠按期望的合理的方式運行。

下圖是MySQL執行一個查詢的過程。實際上每一步都比想象中的復雜，尤其優化器，更復雜也更難理解。本文只給予簡單的介紹。

MySQL查詢過程如下：

客戶端將查詢發送到MySQL服務器；
服務器先檢查查詢緩存，如果命中，立即返回緩存中的結果；否則進入下一階段；
服務器對SQL進行解析、預處理，再由優化器生成對象的執行計划；
MySQL根據優化器生成的執行計划，調用存儲引擎API來執行查詢；
服務器將結果返回給客戶端，同時緩存查詢結果；

能干嘛

使用EXPLAIN關鍵字可以模擬優化器執行SQL查詢語句，從而知道MySQL是如何處理你的SQL語句的。分析你的查詢語句或是表結構的性能瓶頸。

MySQL常見瓶頸

CPU：CPU在飽和的時候一般發生在數據裝入內存或從磁盤上讀取數據時候
IO：磁盤I/O瓶頸發生在裝入數據遠大於內存容量的時候
服務器硬件的性能瓶頸：top，free，iostat和vmstat來查看系統的性能狀態

具體可分析

表的讀取順序
數據讀取操作的操作類型
哪些索引可以使用
哪些索引被實際使用
表之間的應用
每張表有多少行被優化器查詢

使用

Explain + SQL語句

id

select查詢的序列號，表示查詢中執行select子句或操作表的順序

id相同，執行順序由上至下
id不同，如果是子查詢，id的序號會遞增，id值越大優先級越高，越先被執行

主要是用於區別普通查詢、聯合查詢、子查詢等的復雜查詢

SIMPLE：簡單的select查詢，查詢中不包含子查詢或者UNION。
PRIMARY：查詢中包含任何復雜的子部分，最外層查詢則被標記為PRIMARY。
SUBQUERY：在FROM列表中包含的子查詢被標記為DERIVED（衍生），MySQL會遞歸執行這些子查詢，把結果放在臨時表里。
DERIVED：在FROM列表中包含的子查詢被標記為DERIVED（衍生）。MySQL會遞歸執行這些子查詢，把結果放在臨時表里。
UNION：若第二個SELECT出現在UNION之后，則被標記為UNION；若UNION包含在FROM子句的子查詢中，外層SELECT將被標記為：DERIVED。
UNION RESULT：從UNION表中獲取結果的SELECT

table

顯示這一行的數據是關於哪些表的

type

type顯示的是訪問類型，是較為重要的一個指標，其值性能從好到壞依次是：

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

常用的幾種類型：system > const > eq_ref > ref > range > index > All

類型	說明
system	表只有一行記錄（等於系統表），這是const類型的特例，平時不會出現，這個也可以忽略不計。
const	表示通過索引一次就找到了，const用於比較primary key或則unique索引。因為只匹配一行數據，所以很快。如將主鍵置於where列表中，MySQL就能將該查詢轉換為一個常量。
eq_ref	唯一性索引掃描，對於每個索引鍵，表中只有一條記錄與之匹配。常見於主鍵或唯一索引掃描。
ref	非唯一性索引掃描，返回匹配某個單獨值的所有行。本質上也是一種索引訪問，它返回所有匹配某個單獨值的行，然而，它可能會找到多個符合條件的行，所以它應該屬於查找和掃描的混合體。
range	只檢索給定范圍的行，使用一個索引來選擇行。key列顯示使用了哪個索引。一般就是在你的where語句中出現了between、<、>、in等的查詢。這種范圍掃描索引掃描比全表掃描要好，因為它只需要開始於索引的某一點，而結束於另一點，不會掃描全部索引。
index	Full Index Scan，index與All區別為index類型只遍歷索引樹。這通常比All快，因為索引文件通常比數據文件小。（也就是說雖然all和index都是讀全表，但index是從索引中讀取的，而all是從硬盤中讀的）
all	Full Table Scan，將遍歷全表以找到匹配的行。

一般來說，得保證查詢至少達到range級別，最好能達到ref。

possible_keys | keys | key_len

possible_keys : 顯示可能應用在這張表中的索引，一個或多個。查詢涉及到的字段上若存在索引，則該索引將被列出。但不一定被查詢實際使用。
key : 實際使用的索引。如果為NULL，則沒有使用索引。查詢中若使用了覆蓋索引，則該索引僅出現在key列表中，不會出現在possible_keys列表中。（覆蓋索引：查詢的字段與建立的復合索引的個數一一吻合）
key_len : 表示索引中使用的字節數，可通過該列計算查詢中使用的索引的長度。在不損失精確性的情況下，長度越短越好。key_len顯示的值為索引字段的最大可能長度，並非實際使用長度，即key_len是根據表定義計算而得，不是通過表內檢索出的。

ref

顯示該表的索引字段關聯了哪些列或常量

rows

根據表統計信息及選用情況，大致估算出要得到最終結果所需讀取的行數，數值越小越好，最理想的值是1

extra

包含十分重要的額外信息。

屬性	說明
Using filesort	查詢包含ORDER BY ，且無法利用索引完成排序操作的時候，MySQL Query Optimizer 不得不選擇相應的排序算法來實現。看到這個的時候，查詢就需要優化了。mysql需要進行額外的步驟來發現如何對返回的行排序。它根據連接類型以及存儲排序鍵值和匹配條件的全部行的行指針來排序全部行
Using temporary	當MySQL 在某些操作中必須使用臨時表的時候，在Extra 信息中就會出現Using temporary 。主要常見於GROUP BY 和ORDER BY 等操作中。看到這個的時候，查詢需要優化了。
Using index	所需要的數據只需要在Index 即可全部獲得而不需要再到表中取數據。列數據是從僅僅使用了索引中的信息而沒有讀取實際的行動的表返回的，這發生在對表的全部的請求列都是同一個索引的部分的時候。
Using where	表明使用了where過濾。
Using join buffer	使用了連接緩存。