如果一個索引包含(或覆蓋)所有需要查詢的字段的值，稱爲‘覆蓋索引’。即只需掃描索引而無須回表。
只掃描索引而無需回表的優點：
1.索引條目通常遠小於數據行大小，只需要讀取索引，則mysql會極大地減少數據訪問量。
2.因爲索引是按照列值順序存儲的，所以對於IO密集的範圍查找會比隨機從磁盤讀取每一行數據的IO少很多。
3.一些存儲引擎如myisam在內存中只緩存索引，數據則依賴於操作系統來緩存，因此要訪問數據需要一次系統調用
4.innodb的聚簇索引，覆蓋索引對innodb表特別有用。(innodb的二級索引在葉子節點中保存了行的主鍵值，所以如果二級主鍵能夠覆蓋查詢，則可以避免對主鍵索引的二次查詢)
覆蓋索引必須要存儲索引列的值，而哈希索引、空間索引和全文索引不存儲索引列的值，所以mysql只能用B-tree索引做覆蓋索引。
當發起一個索引覆蓋查詢時，在explain的extra列可以看到using index的信息
覆蓋索引的坑：mysql查詢優化器會在執行查詢前判斷是否有一個索引能進行覆蓋，假設索引覆蓋了where條件中的字段，但不是整個查詢涉及的字段，mysql5.5和之前的版本也會回表獲取數據行，儘管並不需要這一行且最終會被過濾掉。
如上圖則無法使用覆蓋查詢，原因：
1.沒有任何索引能夠覆蓋這個索引。因爲查詢從表中選擇了所有的列，而沒有任何索引覆蓋了所有的列。
2.mysql不能在索引中執行LIke操作。mysql能在索引中做最左前綴匹配的like比較，但是如果是通配符開頭的like查詢，存儲引擎就無法做比較匹配。這種情況下mysql只能提取數據行的值而不是索引值來做比較
優化後SQL：添加索引（artist,title,prod_id），使用了延遲關聯(延遲了對列的訪問)
說明：在查詢的第一階段可以使用覆蓋索引，在from子句中的子查詢找到匹配的prod_id，然後根據prod_id值在外層查詢匹配獲取需要的所有值。
5.5時API設計不允許mysql將過濾條件傳到存儲引擎層（是把數據從存儲引擎拉到服務器層，在根據條件過濾），5.6之後由於ICP這個特性改善了查詢執行方式
原文：https://blog.csdn.net/jh993627471/article/details/79421363
不得不說，這篇文章刷新了對mysql中索引使用的認知，特別是通過延遲關聯(延遲了對列的訪問)使用覆蓋索引的方式，堪稱經典，很值得學習。