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

創(chuàng)新互聯(lián)公司長期為上千余家客戶提供的網(wǎng)站建設(shè)服務(wù)，團(tuán)隊從業(yè)經(jīng)驗10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為蒼南企業(yè)提供專業(yè)的做網(wǎng)站、成都網(wǎng)站建設(shè)，蒼南網(wǎng)站改版等技術(shù)服務(wù)。擁有十余年豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。

我們先看一個表

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

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

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

分別是 first_name    last_name   first_name_lat_name

可以看到的是查詢執(zhí)行器選擇了 first_name_last_name 這樣的聯(lián)合索引

為什么，我們帶著問題繼續(xù)

我這邊將這個聯(lián)合索引刪除

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

我們還繼續(xù)帶著問題看（不要著急，你的問題會在最下面來進(jìn)行總結(jié)和揭曉）

我們刪除IX_LAST_NAME 這個索引，然后在繼續(xù)進(jìn)行查詢

OK ，到此，我覺得可以小結(jié)一下了，

問題1 ，那種索引更好

問題2，intersect   索引好還是聯(lián)合索引方式好

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

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

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

下面的數(shù)字體現(xiàn)了查詢的cost 值

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

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'  （使用單獨(dú)first_name 索引）

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

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

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

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

我們繼續(xù),建立一個index   IX_first_name_last_name_hire_date

因為我們要用ORDER BY

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

但 但 但，重要的事情的說三遍，這個查詢其實和上邊雷同，但不一樣的是你的查詢條件變?yōu)榱?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來說還是適用的一句話。

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

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

文章題目：如何看待MYSQL索引
文章源于：http://aaarwkj.com/article22/igcdcc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供域名注冊、自適應(yīng)網(wǎng)站、網(wǎng)頁設(shè)計公司、網(wǎng)站收錄、Google、外貿(mào)網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)