最近剛過完年，產品需求暫時不算多，研發這邊的一些優化的需求提上日程，其中很大一部分就是SQL優化，平時業務裏面寫的那些性能並不高效的SQL也都要回爐重寫，但是確實很耗費時間，很多時候又要改動表結構。
首先我們在要執行的語句前面加一個Explain 再執行，就可以看到這條SQL語句的性能了。
id:
就是簡單的ID標誌而已，如果是一條語句就只有1，如果Explain一條SQL語句裏面包含了N個子查詢，ID就會到N。
select_type:
搜索的類型
SIMPLE：簡單的單條搜索語句
PRIMARY：包含多條子查詢SQL中的主查詢語句
SUBQUERY / DEPENDENT SUBQUERY：包含在主查詢語句中的子查詢語句 / 包含在主查詢語句中的子查詢語句 且子查詢依賴於主查詢的（嚴重消耗性能！例如select * from a where id = (select id from b ) ; 這種select_type可以用union 鏈接查詢語句進行優化）
UNION / DEPENDENT UNION：使用union鏈接查詢 / 子查詢依賴於外層查詢的
DERIVED：子查詢的結果被當作臨時表使用的，驅動的子查詢
table：
涉及到的表名
type：
數據庫表引擎在搜索表數據時候的方法類型，要對type進行優化，首要前提就是必須有索引，主要優化點就是看這裏。主要級別類型有七種（性能由低至高）：
（1）all : 導致了全表查詢，性能最低，沒有用到任何索引。
（2）index：查詢的數據被索引所覆蓋，並且搜索返回匹配的所有行。
（3）range：使用了索引並且指定了搜索索引覆蓋的一個範圍，也就是查詢條件增加了 where 索引列 between （xx , xx）或者in ， 或者 > 號 < 號，等等。
（4）ref：當type爲ref的時候，表那個ref字段列纔會有值，ref指的是用到了非唯一性索引並且精確返回了幾條數據。
（5）eq_red：使用唯一性索引，並且對於每個索引鍵的查詢返回匹配的唯一一行數據（有且僅有一個），主鍵索引或者唯一性索引都能做到這一點。屬於高精確的查找，性能較高。
（6）const：使用到了主鍵索引並且僅僅能查到並且返回一條符合條件的SQL，除了主鍵外的索引做不到這個級別。
（7）System：最高級別的SQL，只有一條數據的系統表或者衍生表只有一條數據的
主查詢。
Possible Keys :
引擎進行表查詢時候可能用到的索引，若爲null，則沒有使用到索引，可能情況：表沒建立索引或者不規範的SQL語句導致索引失效。
Key：
引擎進行表查詢時候確切使用到的索引
key_len：
索引中使用的字節數，長度越短越好。
ref:
顯示索引的使用情況，在哪一行，哪一張表，甚至哪一個字段都會顯示出來。當且僅當查找級別優化type爲ref的時候纔會有值。
rows:
引擎進行表搜索時候查找了多少行，當然是越少越好。
Extra:
這裏是mysql給我們的一些優化分析提示，相當於小case。
（1）using file sort：
使用到了額外排序，性能消耗巨大。
例如：select a from aa order by b .
（2）using temporary：
使用到了臨時表，性能消耗巨大。
例如：select a from aa group by b.
（3）using where
需要回表查詢，意思是沒有使用到索引的列，不能光從索引樹上獲得，還得老老實實從表裏找
例如：
a 是索引列 , b不是
select a , b from c where a =XXX ;
（4）Null：
用到了部分索引，但是也有回表查詢
（5）using index condiction:
使用到了索引，但是搜索的數據沒完全被索引覆蓋
例如：select a,b from c ;
（6）using index:
使用到了索引，並且搜索返回的數據完全被索引覆蓋
例如 a, b ,c 都有索引
select a,b,c from XXX where a=’’ and b = ‘’ and c = ‘’ ;