寫會MySQL索引
本文首發於個人微信公眾號《andyqian》,期待您的關注!
前言
繼上篇《讀懂MySQL執行計劃》後,在文章末尾,我們談到了索引的概念,那麼,今天我們就一起來聊一聊MySQL索引。
什麼是索引?
百度百科是這樣描述的:
索引是為來加速對表中數據行中的檢索而創建的一種分散的數據結果,時針對錶而建立的,它是由數據頁面以外的索引頁面組成,每個索引頁中的行都含有邏輯指針,以便加速檢索物理數據
其實,索引的概念大家都很清楚,也知道索引能夠提升查詢效率,但大部分童鞋在怎麼建索引,建在哪些欄位上有以下常見誤解:
- 新建表時不需要建索引,後續才添加索引
- where條件後的欄位均建索引
- 簡單SQL不需要索引,聯合查詢才需要索引
- 聯合索引的順序是where條件後欄位的先後順序
- 對於區分度小的欄位上也新建索引,如狀態,性別等欄位等。
索引區分度
在說上述問題之前,我們先來看看另一個概念,就是區分度。
區分度: 指欄位在資料庫中的不重複比
區分度在新建索引時有著非常重要的參考價值,在MySQL中,區分度的計算規則如下:
欄位去重後的總數與全表總記錄數的商。
例如:
select count(distinct(name))/count(*) from t_base_user;
結果如下:
count(distinct(name))/count(*)1.0000
其中區分度最大值為1.000,最小為0.0000,區分度的值越大,也就是數據不重複率越大,新建索引效果也越好,在主鍵以及唯一鍵上面的區分度是最高的,為1.0000。在狀態,性別等欄位上面的區分度值是最小的。 (這個就要看數據量了,如果只有幾條數據,這時區分度還挺高的,如果數據量多,區分度基本為0.0000。也就是在這些欄位上添加索引後,效果也不佳的原因。)
值得注意的是: 如果表中沒有任何記錄時,計算區分度的結果是為空值,其他情況下,區分度值均分布在0.0000-1.0000之間。
如何建索引
(一) : 區分度
個人強烈建議, 建索引時,一定要先計算該欄位的區分度,原因如下:1. 單列索引
可以查看該欄位的區分度,根據區分度的大小,也能大概知道在該欄位上的新建索引是否有效,以及效果如何。區分度越大,索引效果越明顯。2.多列索引(聯合索引)
多列索引中其實還有一個欄位的先後順序問題,一般是將區分度較高的放在前面,這樣聯合索引才更有效,例如:select * from t_base_user where name="" and status=1;
像上述語句,如果建聯合索引的話,就應該是:
alter table t_base_user add index idx_name_status(name,status);
而不是:
alter table t_base_user add index idx_status_name(status,name);
(二) 最左前綴匹配原則
MySQL會一直向右匹配直到遇到範圍查詢(>、<、between、like)就停止匹配,比如select * from t_base_user where type="10" and created_at<"2017-11-03" and status=1, (該語句僅作為演示)
在上述語句中,status就不會走索引,因為遇到<時,MySQL已經停止匹配,此時走的索引為:(type,created_at),其先後順序是可以調整的,而走不到status索引,此時需要修改語句為:
select * from t_base_user where type=10 and status=1 and created_at<"2017-11-03"
即可走status索引。
(三) 函數運算
不要在索引列上,進行函數運算,否則索引會失效。因為b+樹中存的都是數據表中的欄位值,但進行檢索時,需要把所有元素都應用函數才能比較,顯然成本太大。(四) 擴展優先
擴展優先,不要新建索引,盡量在已有索引中修改。如下:select * from t_base_user where name="andyqian" and email="andytohome"
在表t_base_user表中已經存在idx_name索引,如果需要加入idx_name_email的索引,應該是修改idx_name索引,而不是新建一個索引。
誤解糾正
上面說了,如何新建索引,現在我們就可以來回答,在第一步中存在的誤解了。
誤解一: 新建表時不需要建立索引,後續才加索引
答: 一個好的數據表設計,在一開始就要考慮索引的創建,而不是等到後續出問題了,影響業務使用了,才新建索引來救場,而且後續創建索引的成本也相對高很多。(這就是給生產事故留下生根發芽的機會呀)
誤解二: where條件後的欄位均建索引
答: 這個誤解比較常見,但where條件後的欄位不需要全部建立索引,過多的索引,也會導致索引文件劇增,也還達不到期望中的效果。詳細請參考上述新建索引的小節。
誤解三: 簡單SQL不需要建立索引,聯合查詢采建立索引
答: 這個誤解就得好好說說了,現在互聯網公司特別是B/S架構下,業務邏輯均剝離在代碼邏輯層,到最後SQL層面,其實都是一些簡單的SQL,只有些許連接查詢,更多的還是單表操作,(C/S架構中有很多在SQL層面的寫邏輯的),你說這些語句簡不簡單。
誤解四: 聯合索引的順序是where條件後欄位的先後順序
答: 我們剛才說過,聯合索引的順序,是根據最左前綴原則,以及區分度來區分的,和where條件後欄位的先後順序無關。
誤解五: 對於區分度較小的欄位新建索引
答: 在區分度較小的欄位上新建索引,基本無效,還會增加大量的索引文件,你說是不是得不償失。
索引重不重要?
上面介紹了MySQL索引的概念,新建索引時的一些技巧。這麼理論的東西,對於平時沒有使用或使用比較少的童鞋,此時對索引的重要性可能還沒那麼直觀,那麼,我就來說說我在索引上吃過的虧,踩過的坑!同時也是未建索引常見問題!
0. 導致慢查詢
這個問題可是未建索引的常客哦,(這裡也還有很多細節呢,如: 隱式類型轉換等等)1. 導致服務超時
場景 :
在某次上線時,作為服務提供者,提供服務給業務方使用。一開始以為就提供一個簡單的服務,也已經測試完成,心裡還在竊喜,今天總算可以早早回家了!描述 :
實際一上線,在生產環境中導致業務方請求調用時,而且每次請求均超時,數據也已落地,此時只能review代碼,最後發現生產中有個慢查詢導致,活活的花費了10多秒,這個語句有多簡單呢,你絕對想不到,其實就是一個單表的where條件查詢語句。你說這種原因導致服務不可用,你說冤不冤,氣不氣!(這也是我為什麼說,一個好的數據表設計,從一開始就要考慮新建索引了)。2. 資料庫伺服器CPU 100%
在查詢頻率比較高的SQL上,如果由於未建索引,導致慢查詢的話,那可是會導致資料庫伺服器CPU 100%,影響可是整個系統哦。
小結
上面說了好幾類,由於沒建立索引而導致的問題,輕則導致慢查詢,影響系統效率,重則,導致CPU 100%,影響整個系統的使用,看到這裡,你說索引重不重要?最後
上面簡單說了,索引是什麼?有什麼用,以及建立索引時的一些技巧,還著重說了,索引的重要性。那麼索引這麼重要,在平時編碼時如何避免呢? 以下是我個人的建議:
- 在建表時就應該考慮添加索引,如: 外鍵欄位,等等。
- 在寫完SQL後,一定要查看執行計劃。盡量避免全表掃描。
- 如果是已有表中添加索引,一定要先計算該欄位的區分度。
- 聯合索引,將區分度大放在前面。
- 遵從MySQL左列前綴優先原則
最後的最後: 大家辛苦一周,馬上就是周末了,祝大家周末愉快!
http://weixin.qq.com/r/7zlVTU-EbxIQrQsu92z9 (二維碼自動識別)
推薦閱讀:
※华为自研的数据库gaussdb怎么样?
※数据库这么羸弱会不会被取缔?
※新浪SAE中的資料庫常量是如何實現的?
※KV引擎到關係型資料庫存儲引擎之間的距離
※Android資料庫存儲之一SQLite的基本操作