如何看待MYSQL 索引

這篇文章給大家介紹如何看待MYSQL 索引，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

我們先看一個表

select * from employees where first_name = 'Kyoichi' and last_name = 'Maliniak';

按照一般思路，根據數據量我們決定是不是要建立索引，而建立索引針對這樣的情況，到底那種索引更好。

我們來做一個實驗，建立為這個一個查詢我們建立三個索引

分別是 first_name    last_name   first_name_lat_name

可以看到的是查詢執行器選擇了 first_name_last_name 這樣的聯合索引

為什么，我們帶著問題繼續

我這邊將這個聯合索引刪除

我們可以看到結果是什么，結果是走的一種叫 intersect 方式的索引，

我們還繼續帶著問題看（不要著急，你的問題會在最下面來進行總結和揭曉）

我們刪除IX_LAST_NAME 這個索引，然后在繼續進行查詢

OK ，到此，我覺得可以小結一下了，

問題1 ，那種索引更好

問題2，intersect   索引好還是聯合索引方式好

問題3，你為什么刪除了 LAST_NAME 而不刪除 FIRST_NAME

帶著這三個問題，我們繼續開始旅程

在提那種索引更好的情況下，其實我們應該知道這些索引到底給查詢帶來了什么效應。

下面的數字體現了查詢的cost 值

 0.00081800 | select * from employees where first_name = 'Kyoichi' and last_name = 'Maliniak'  （復合索引）

0.00145100 | select * from employees where first_name = 'Kyoichi' and last_name = 'Maliniak'  （intersect 索引）

0.00250350 | select * from employees where first_name = 'Kyoichi' and last_name = 'Maliniak'  （使用單獨first_name 索引）

從以上的值上面我們就可以很清楚的看到

Sending data  經過在細致的查看，具體的cost 的主要發生在 sending data 這個階段，另外一個位置雖然消耗的不同可以在微妙這個等級，但確實system lock 這個東西，比較起來， 復合索引和intersect 不相伯仲。

所以這次對比中，可以說復合索引獲勝。

故事就到此結束了？  Nein  Nein  Nein  (我很喜歡Tomas ,這個梗你懂伐)

我們繼續,建立一個index   IX_first_name_last_name_hire_date

因為我們要用ORDER BY

我們可以通過圖來清晰的看出，我們的查詢沒有走 filesort 直接走了索引，這樣的效率，自然比走filesort 的要好的多，尤其數據量較大的情況。

但 但 但，重要的事情的說三遍，這個查詢其實和上邊雷同，但不一樣的是你的查詢條件變為了 LIKE  雖然也走了索引，但最后并未走我們的 using index condition only, 還是帶了 filesort

WHY

我們分析一下，走using index condition only 中的 type  是  ref ,而 走filesort的 卻是， type 是 range ， 我們看一下profiling， 頭一個是range 后面是等值查詢，我們可以清晰的看出，如果走了range 則要多一個步驟，creating sort index ,并且消耗不低可以說占了整體查詢消耗的90%，所以那句能不排序就不排序，在MYSQL 5.7來說還是適用的一句話。

另外本次要戳穿的假象就是，即使你創建了索引，并且也考慮了order by適用的字段加入索引，在某些查詢時，ASC時他也要 filesort ，而不是向網上有的人說的，把ORDER BY 的字段添加到索引，就完全可以不在FILESORT（ASC），這樣的說法可不是對的哦

關于如何看待MYSQL 索引就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。