一個通常的建議是為WHERE條件創建索引,但這其實是片面的。索引應當為全部查詢設計,而不僅僅是WHERE條件。索引確實能有效地查找數據行,但MySQL也能夠使用索引獲取列數據,這樣根本不需要去讀取一行數據。畢竟,索引的葉子節點包含了索引對應的值。當年能夠讀取索引就能夠拿到想要的數據時為什么還去讀數據行呢?當索引包含了所有查詢的數據時,這個索引就稱之為覆蓋索引。
覆蓋索引能夠成為一個非常有力的工具并且能夠顯著改善性能。考慮一下不讀數據只需要讀取索引的情況:
在所有的場景中,最典型的就是相比查找數據行,只包含索引列的查詢的代價相當低。需要注意的是,聚集索引并不是任意類型的索引。聚集索引必須存儲索引數據列對應的值。哈希,空間和全文索引并沒有存儲這些值,因此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%'
這個時候的結果是不會走覆蓋索引,而是普通的索引,這是因為:
有一種方式可以使用巧妙的組合索引和重寫查詢條件。我們可以將索引擴展到(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萬行。
對比結果如下表。
數據集 | 原始查詢 | 優化后查詢 |
---|---|---|
第一種情況 | 5qps | 5qps |
第二種情況 | 7qps | 35qps |
第三種情況 | 2400qps | 2000qps |
結果的解釋如下:
在大多數存儲引擎中,一個索引只能夠覆蓋訪問列是索引的一部分。然而,InnoDB實際上會做進一步的優化。想想InnoDB的的輔助索引在葉子節點中存儲了主鍵的值。這意味著InnoDB的輔助索引實際上有了額外的列幫助InnoDB使用覆蓋索引。 例如,sakila.actor表使用了InnoDB,然后在last_name有一個索引,因此這個索引能夠覆蓋或者主鍵actor_id的查詢——即便這個列并不是索引的一部分。
EXPLAIN SELECT actor_id, last_name FROM sakila.actor WHERE last_name = 'HOPPER'
以上就是MySQL 覆蓋索引的優點的詳細內容,更多關于MySQL 覆蓋索引的資料請關注腳本之家其它相關文章!