通常大家都會根據查詢的where條件來創建合適的索引,不過這只是索引優化的一個方面.設計優秀的索引應該考慮到整個查詢,而不單單是where條件部分.索引確實是一種查詢數據的高效方式.但是mysql也可以使用索引來直接獲取列的數據,這樣就不再需要讀取數據行.如果索引的葉子節點中已經包含要查詢的數據,那么還有什么必要再回表查詢呢? 如果一個索引包含(或者覆蓋)所有需要查詢的字段的值,我們就稱為"覆蓋索引" 覆蓋索引是非常有用的工具,能夠極大的提高性能,考慮下如果查詢只需要掃描索引而無需回表,會帶來多少好處: * 索引條目通常遠小于數據行大小,所以如果只需要讀取索引,那mysql就會極大地減少數據訪問量.這對緩存的負載非常重要,因為這種情況下響應時間大部分花費在數據拷貝上.覆蓋索引對于IO密集型的應用也有幫助,因為索引比數據更小,更容易放到內存中(對于myisam,他能壓縮索引) * 因為索引是按照列值順序存儲的(至少在單個頁內是如此).所以對于IO密集型的范圍查詢會比隨機從磁盤讀取每一行數據的IO要少的多.對于某些存儲引擎,例如myisam和XtraDB,甚至可以用OPTIMIZE命令使得索引完全順序排列,這讓簡單的范圍查詢能使用完全順序的索引訪問 * 一些存儲引擎如myisam在內存中只緩存索引,數據則依賴于操作系統來緩存,因為要訪問數據需要一次系統調用.這可能會導致嚴重的性能問題,尤其是那些系統調用占了數據訪問中的最大開銷場景 * 由于Innodb的聚簇索引,覆蓋索引對Innodb表特別有用,Innodb的二級索引在葉子節點中保存了行的主鍵值,所以如果二級主鍵能夠覆蓋查詢,則可以避免對主鍵索引的二次查詢 在這些場景中,在索引中滿足查詢的成本一般比查詢行要小很多 不是所有類型的索引都可以成為覆蓋索引.覆蓋索引必須要存儲索引列的值,而哈希索引,空間索引和全文索引等都不存儲索引列的值,所以mysql只能使用B-Tree索引做覆蓋索引.另外,不同的存儲引擎實現覆蓋索引的方式也不同,而且不是所有的引擎都支持覆蓋索引 當發起一個被索引覆蓋的查詢(也叫索引覆蓋查詢),在explain的extra列可以看到Using index的信息.例如:表sakila.inventory有一個多列索引(store_id,film_id).mysql如果只需訪問這兩列,就可以使用這個索引做覆蓋索引  (很容易把extra列的Using index和type列的index搞混淆.其實這兩者完全不同,type列和覆蓋索引毫無關系,它只是表示這個查詢訪問數據的方式,或者說mysql查找行的方式) 索引覆蓋還有很多陷阱可能會導致無法實現優化.mysql查詢優化器會在執行查詢錢判斷是否有一個索引能進行覆蓋 假設索引覆蓋了where條件中的字段,但不是整個查詢涉及的字段.如果條件為假,mysql5.5和更早的版本也總是會回表獲取數據行,盡管并不需要這一行且最終會被過濾掉