1、索引的使用場景

　　哪些情況使用索引：

　　1、主鍵自動建立唯一索引 　　2、頻繁作為查詢條件的欄位應該建立索引 where 　　3、多表關聯查詢中，關聯欄位應該建立索引on兩邊都要建立索引 　　　　select * from user left join order on user.id = order.userid 　　4、查詢中排序的欄位，應該建立索引B + tree 有順序 　　5、覆蓋索引 好處是？不需要回表組合索引 　　　　user表 組合索引（name,age） 　　　　select * from user ------- 全表掃描，沒有使用索引 　　　　select name,age from user ---- 索引覆蓋，不需要回表。 　　6、統計或者分組欄位，應該建立索引

　　哪些情況不適用索引：　

　　1、表記錄太少 索引是要有儲存的開銷 　　2、頻繁更新 索引要維護 　　3、查詢欄位使用頻率不高

　　為什麼使用組合索引

　　　　由多個欄位組成的索引 使用順序就是建立的順序 　　　　 　　　　ALTER TABLE 'table_name' ADD INDEX index_name(col1,col2,col3） 　　　　在一顆索引樹上由多個欄位 　　　　優勢： 效率高、省空間、容易形成覆蓋索引　　　　 　　　　使用： 　　　　　　遵循最左字首原則 　　　　1、字首索引 　　　　　　like 常量% 使用索引 like %常量 不使用索引 　　　　2、最左字首 　　　　　　從左向右匹配直到遇到範圍查詢 > < between 索引失效

2、索引失效

　　　　檢視索引計劃：EXPLAIN 命令　　　　

　　　　　　可以通過explain命令深入瞭解MySQL的基於開銷的優化器，還可以獲得很多可 　　　　　　能被優化器考慮到的訪問策略的細節，以及當執行SQL語句時哪種策略預計會被優化器採用。 　　　　eg: explain select * from user where id = 1 　　　　 　　　　　*************************** 1. row *************************** 　　　　　　id: 1 　　　　　　select_type: SIMPLE 　　　　　　table: user_info 　　　　　　partitions: NULL 　　　　　　type: const 　　　　　　possible_keys: PRIMARY 　　各列的含義如下: 　　　id: SELECT 查詢的識別符號. 每個 SELECT 都會自動分配一個唯一的識別符號. 　　　select_type: SELECT 查詢的型別. 　　　table: 查詢的是哪個表 　　    partitions: 匹配的分割槽            type: join 型別 　　　possible_keys: 此次查詢中可能選用的索引 　　　key: 此次查詢中確切使用到的索引. 　　　ref: 哪個欄位或常數與 key 一起被使用 　　　rows: 顯示此查詢一共掃描了多少行. 這個是一個估計值. 　　　fifiltered: 表示此查詢條件所過濾的資料的百分比 　　　extra: 額外的資訊

id

　　每個單位查詢的SELECT語句都會自動分配的一個唯一識別符號，表示查詢中操作表的順序， 　　有四種情況： 　　　　id相同：執行順序由上到下 　　　　id不同：如果是子查詢，id號會自增，id越大，優先順序越高。 　　　　id相同的不同的同時存在 　　　　id列為null的就表示這是一個結果集，不需要使用它來進行查詢。

select_type（重要）

　　單位查詢的查詢型別，比如：普通查詢、聯合查詢(union、union all)、子查詢等複雜查詢。     包括

　   simple

　　　　表示不需要union操作或者不包含子查詢的簡單select查詢。有連線查詢時， 　　　　   外層的查詢為simple，且只有一個 　　 　　primary 　　　　一個需要union操作或者含有子查詢的select，位於最外層的單位 　　　　查詢的select_type即為primary。且只有一個 　　union 　　　　union連線的兩個select查詢，第一個查詢是dervied派生表，除 　　　　了第一個表外，第二個以後的表select_type都是union 　　dependent union 　　　　與union一樣，出現在union 或union all語句中，但是這個查詢要 　　　　受到外部查詢的影響  　　union result 　　　　包含union的結果集，在union和union all語句中,因為它不需要參 　　　　與查詢，所以id欄位為null 　　subquery 　　　　除了from字句中包含的子查詢外，其他地方出現的子查詢都可能 　　　　是subquery  　　dependent subquery 　　　　與dependent union類似，表示這個subquery的查詢要受到外部表 　　　　查詢的影響 　　derived 　　　　from字句中出現的子查詢，也叫做派生表，其他資料庫中可能叫 　　　　做內聯檢視或巢狀select  

table

　　顯示的單位查詢的表名，有如下幾種情況：

• 　　如果查詢使用了別名，那麼這裡顯示的是別名
• 　　如果不涉及對資料表的操作，那麼這顯示為null
• 　　如果顯示為尖括號括起來的就表示這個是臨時表，後邊的N就是執行計劃中的id，表示結果來自於這個查詢產生。
• 　　如果是尖括號括起來的<union M,N>，與類似，也是一個臨時表，表示這個結果來自於union查詢的id為M,N的結果集。 

type（重要）

　　顯示的是單位查詢的連線型別或者理解為訪問型別，訪問效能依次從好到差： 　　　　system、const、eq_ref、ref、fulltext、ref_or_null、unique_subquery、index_subquery、 　　　　range、index_merge、index、ALL 　　注意事項：　　　 　　　　- 除了all之外，其他的type都可以使用到索引 　　　　- 除了index_merge之外，其他的type只可以用到一個索引 　　　　- 最少要使用到range級別

possible_keys

　　此次查詢中可能選用的索引，一個或多個 　　key查詢真正使用到的索引，select_type為index_merge時，這裡可能出現兩個以上的索引，其他的 　　select_type這裡只會出現一個。

key_len

　　用於處理查詢的索引長度，如果是單列索引，那就整個索引長度算進去，如果是多列索引，那麼查 　　詢不一定都能使用到所有的列，具體使用到了多少個列的索引，這裡就會計算進去，沒有使用到的 　　列，這裡不會計算進去。 　　留意下這個列的值，算一下你的多列索引總長度就知道有沒有使用到所有的列了。 　　另外，key_len只計算where條件用到的索引長度，而排序和分組就算用到了索引，也不會計算到 　　key_len中。

ref

　　如果是使用的常數等值查詢，這裡會顯示const 　　如果是連線查詢，被驅動表的執行計劃這裡會顯示驅動表的關聯欄位 　　如果是條件使用了表示式或者函式，或者條件列發生了內部隱式轉換，這裡可能顯示為func

rows

　　這裡是執行計劃中估算的掃描行數，不是精確值（InnoDB不是精確的值，MyISAM是精確的值，主要原 　　因是InnoDB裡面使用了MVCC併發機制）

extra（重要）

　　這個列包含不適合在其他列中顯示單十分重要的額外的資訊，這個列可以顯示的資訊非常多，有幾十 　　種，常用的有：using fifilesort（重要）、using index（重要）、using index condition(重要)、 　　　　　　　　　　using temporary、distinct、using where（重要） 　　 　　　　using fifilesort（重要）：

• 　　　　　　　    排序時無法使用到索引時，就會出現這個。常見於order by和group by語句中
• 　　　　　　　　說明MySQL會使用一個外部的索引排序，而不是按照索引順序進行讀取。
• 　　　　　　　　MySQL中無法利用索引完成的排序操作稱為“檔案排序”

索引失效分析