-在網上隨便搜搜，就能找到大把的關於MySQL優化的文章，不過裡面很多都不准確，說個常見的：
SELECT a FROM ... WHERE b = ...
一般來說，很多文章會告誡你類似這樣的查詢，不要在“a”字段上建立索引，而應該在“b”上建立索引。這樣做確實不錯，但是很多時候這並不是最佳結果。為什麼這樣說？讓我們先來分析一下查詢的處理過程：在執行查詢時，系統會查詢“b”索引進行定位，然後再利用此定位去表裡查詢需要的數據“a”。也就是說，在這個過程中存在兩次查詢，一次是查詢索引，另一次是查詢表。那有沒有辦法用一次查詢搞定問題呢？有，就是Covering Index！具體到此例中就是建立一個復合索引“b, a”，當查詢進行時，通過復合索引的“b”部分去定位，至於需要的數據“a”，立刻就可以在索引裡得到，從而省略了表查詢的過程。
如果你想利用Covering Index，那麼就要注意SELECT方式，只SElECT必要的字段，千萬別SELECT *，因為我們不太可能把所有的字段一起做索引，雖然可以那樣做，但那樣會讓索引文件過大，結果反倒會弄巧成拙。
如何才能確認查詢使用了Covering Index呢？很簡單，使用explain即可！只要在Extra裡出現Using index就說明使用的是Covering Index。
知道了以上這些知識，估計對Coverging Index的了解也差不多了。再舉兩個例子，讓大家印象深點：
（一）比如說在文章系統裡統計總數的時候，一般的查詢是這樣的：
SELECT COUNT(*) FROM articles WHERE category_id = ...
當我們在category_id建立索引後，這個查詢使用的就是Covering Index。
（二）比如說在文章系統裡分頁顯示的時候，一般的查詢是這樣的：
SELECT id, title, content FROM articles ORDER BY created DESC LIMIT 10000, 10;
通常這樣的查詢會把索引建在created字段（其中id是主鍵），不過當LIMIT偏移很大時，查詢效率仍然很低，改變一下查詢：
SELECT id, title, content FROM articles
INNER JOIN (
SELECT id FROM articles ORDER BY created DESC LIMIT 10000, 10
) AS page USING(id)
ORDER BY created DESC
此時，建立復合索引"created, id"就可以在子查詢裡利用上Covering Index，快速定位id，查詢效率嗷嗷的。
Covering Index並不是什麼很難的概念，但是人們往往會忽視它的價值，希望本文能給你提個醒。
