一個通常的建議是爲WHERE條件創建索引，但這其實是片面的。索引應當爲全部查詢設計，而不僅僅是WHERE條件。索引確實能有效地查找數據行，但MySQL也能夠使用索引獲取列數據，這樣根本不需要去讀取一行數據。畢竟，索引的葉子節點包含了索引對應的值。當年能夠讀取索引就能夠拿到想要的數據時爲什麼還去讀數據行呢？當索引包含了所有查詢的數據時，這個索引就稱之爲覆蓋索引。
覆蓋索引能夠成爲一個非常有力的工具並且能夠顯著改善性能。考慮一下不讀數據只需要讀取索引的情況：
- 索引值通常會比整個行存儲空間小很多，因此MySQL只讀取索引值時可以只讀取很少的數據。這對於緩存負荷來說十分重要——響應時間大部分消耗在複製數據。對於磁盤I/O而言也是一樣，因爲索引數據相比行數據存儲空間小很多，因此更節省I/O負載和內存佔用（對於MyISAM引擎更顯著，因爲MyISAM可以將索引打包使得存儲空間更小）。
- 索引是按索引值的順序存儲的，因此I/O訪問跨度相比隨機磁盤位置獲取行數據而言消耗的I/O頻次更少。對於某些存儲引擎，例如MyISAM和Percona XtraDB，你甚至能夠使用OPTIMIZE優化表獲得完全有序的索引，這會使得簡單範圍的查詢完全使用順序訪問。
- 有些存儲引擎，例如MyISAM，MySQL內存中只緩存索引。由於操作系統爲MyISAM緩存了數據，訪問時通常需要一個系統調用。這可能導致巨大的性能影響，尤其是對於緩存負荷場景來說，系統調用對於數據訪問來說是最昂貴的代價。
- 由於InnoDB的聚集索引，覆蓋索引對於InnoDB來說十分有幫助。InnoDB的輔助索引在其葉子節點中保存了行的主鍵值。因此，輔助索引覆蓋查詢後可以避免進行主鍵查詢。
在所有的場景中，最典型的就是相比查找數據行，只包含索引列的查詢的代價相當低。需要注意的是，聚集索引並不是任意類型的索引。聚集索引必須存儲索引數據列對應的值。哈希，空間和全文索引並沒有存儲這些值，因此MySQL只能使用二叉樹去覆蓋查詢。而且，不同的存儲引擎實現覆蓋索引的方式不同，並且並不是全部的存儲引擎都支持覆蓋索引（例如Memory存儲引擎當前就不支持）。
當你驗證查詢中索引使用了覆蓋索引時，使用Explain語句時，會在Extra列中看到“Using index”。例如，在store_goods表有一個(shop_id, goods_category_id1)的多列索引。MySQL可以在查詢返回數據只有這兩列時使用索引：
EXPLAIN SELECT `goods_category_id1`,`shop_id` FROM `store_goods` WHERE 1
覆蓋索引查詢有些細節能夠停用這樣的優化。MySQL查詢優化器在執行查詢時會判斷索引是否覆蓋到。假設索引覆蓋了WHERE條件，但沒有覆蓋整個查詢。如果評估結果不走覆蓋索引，那麼MySQL 5.5及以前的版本會直接獲取數據行，即便是不需要這些數據，然後纔會過濾掉。
讓我們看一下爲什麼這種情況會發生，然後如何重寫查詢以便解決這個問題。首先查詢是這樣的：
EXPLAIN SELECT * FROM products WHERE actor='SEAN CARREY' AND title like '%APOLLO%'
這個時候的結果是不會走覆蓋索引，而是普通的索引，這是因爲：
- 沒有索引覆蓋了查詢數據列，因爲我們從數據表讀取了全部列並且沒有索引列覆蓋了全部列。理論上，MySQL還有一個快捷方式可以使用，那就是WHERE條件中使用了索引覆蓋的列，因此MySQL可以先使用這個索引找到對應的actor，然後在檢查他們的title是否匹配，然後在讀取滿足條件的全部的數據行。
- 對於早期的低版本的存儲引擎API（MySQL 5.5以前的版本）來說，MySQL無法在索引中使用LIKE操作，而只支持簡單的比較操作（=，IN，>=）。MySQL可以在索引中使用前綴匹配的LIKE查詢，這是因爲它可以將它們轉換爲比較操作。但是前導通配符（也就是LIKE中前置的%）導致存儲引擎無法評估匹配條件。因此，MySQL會獲取行數據再比較，而不是索引的值。
有一種方式可以使用巧妙的組合索引和重寫查詢條件。我們可以將索引擴展到(artist, title, prod_id)，然後像下面那樣重寫查詢語句：
EXPLAIN SELECT *
FROM products
JOIN (
SELECT prod_id
FROM products
WHERE actor='SEAN CARREY' AND TITLE LIKE '%APOLLO%'
) AS t1 ON (t1.prod_id=products.prod_id)
我們稱之爲“遞延JOIN(deferred join)”，因爲它延遲了列的訪問。在第一階段的查詢中，當它在子查詢中找到了匹配的行的過程中，MySQL使用了覆蓋索引。雖然在整個查詢中沒有覆蓋到，但總比沒有的好。
這種優化的效果好壞取決於WHERE條件查找到了多少行數據。假設products表包含了上百萬行的數據。可以對比一下這兩種查詢的性能對比，總的數據爲100萬行。
- 第一種情況：有30000個products的actor是“SEAN CARREY”，其中20000個的title包含“APOLLO”；
- 第二種情況：有30000個products的actor是“SEAN CARREY”，其中40個的title包含“APOLLO”；
- 第三種情況：有50個products的actor是“SEAN CARREY”，其中10個的title包含“APOLLO”。
對比結果如下表。
| 數據集 | 原始查詢 | 優化後查詢 |
|---|---|---|
| 第一種情況 | 5qps | 5qps |
| 第二種情況 | 7qps | 35qps |
| 第三種情況 | 2400qps | 2000qps |
結果的解釋如下：
- 在第一種情況中，查詢返回了很大的結果集，因此看不到優化效果。大部分時間花在了讀取和發送數據。
- 在第二種情況中，使用覆蓋索引後子查詢過濾得到了一個小的結果集，這樣優化的效果是性能提升了5倍。產生這種效果的原因是相比查出30000行的數據集，這裏只需要讀取40行。
- 第三種情況顯示了子查詢失效了。覆蓋索引過濾返回的結果集太少了，導致子查詢的代價比直接從數據表讀取數據還要高。
在大多數存儲引擎中，一個索引只能夠覆蓋訪問列是索引的一部分。然而，InnoDB實際上會做進一步的優化。想想InnoDB的的輔助索引在葉子節點中存儲了主鍵的值。這意味着InnoDB的輔助索引實際上有了額外的列幫助InnoDB使用覆蓋索引。
例如，sakila.actor表使用了InnoDB，然後在last_name有一個索引，因此這個索引能夠覆蓋或者主鍵actor_id的查詢——即便這個列並不是索引的一部分。
EXPLAIN SELECT actor_id, last_name
FROM sakila.actor WHERE last_name = 'HOPPER'