MySQL索引,快速記憶法
哈嘍,大家好,我是了不起。面試的時(shí)候,面試官總喜歡問(wèn)一些關(guān)于MySQL索引的問(wèn)題,但是如果單純的記憶,還是有難度的;今天了不起把MySQL索引的知識(shí)點(diǎn)進(jìn)行匯總,方便大家快速記憶MySQL索引的相關(guān)知識(shí)點(diǎn)。趕快收藏此文章吧!
索引結(jié)構(gòu):B+樹(shù)
索引其實(shí)是一種數(shù)據(jù)結(jié)構(gòu)
注意B+樹(shù)是MySQL,索引默認(rèn)的結(jié)構(gòu);一張表至少有一個(gè)索引(主鍵索引),是可以有多個(gè)索引的
MySQL中的B+Tree
- 非葉子節(jié)點(diǎn)也叫內(nèi)部節(jié)點(diǎn),只存儲(chǔ) 健值(主鍵的值) + 指針(存儲(chǔ)子節(jié)點(diǎn)的地址信息)
主鍵索引:健值(主鍵的值) + 指針(存儲(chǔ)子節(jié)點(diǎn)的地址信息)
非主鍵索引:非主鍵列的值 + 指向下一個(gè)節(jié)點(diǎn)的指針(存儲(chǔ)子節(jié)點(diǎn)的地址信息)
- 所有的數(shù)據(jù)都存在葉子節(jié)點(diǎn)中;
同時(shí)葉子節(jié)點(diǎn)上還存有一個(gè)指向相鄰葉子節(jié)點(diǎn)的指針
如果是聚簇索引(主鍵索引),葉子節(jié)點(diǎn)存儲(chǔ)的是實(shí)際數(shù)據(jù)
如果是非聚簇索引,則保存的是聚簇索引的索引key,也就是主鍵索引的值;查詢(xún)非聚簇索引會(huì)有一個(gè)回表操作
B+Tree的每個(gè)葉子節(jié)點(diǎn)增加了一個(gè)指向相鄰葉子節(jié)點(diǎn)的指針,它的最后一個(gè)數(shù)據(jù)會(huì)指向下一個(gè)葉子節(jié)點(diǎn)的第一個(gè)數(shù)據(jù),形成了一個(gè)有序鏈表的結(jié)構(gòu)。
為什么B+ 樹(shù)比B 樹(shù)更適合作為索引?
- B+ 樹(shù)的磁盤(pán)讀寫(xiě)代價(jià)更低 B+ 樹(shù)的數(shù)據(jù)都集中在葉子節(jié)點(diǎn),分支節(jié)點(diǎn) 只負(fù)責(zé)指針(索引);B 樹(shù)的分支節(jié)點(diǎn)既有指針也有數(shù)據(jù) 。這將導(dǎo)致B+ 樹(shù)的層高會(huì)小于B 樹(shù)的層高,也就是說(shuō)B+ 樹(shù)平均的Io次數(shù)會(huì)小于B 樹(shù)。
- B+ 樹(shù)的查詢(xún)效率更加穩(wěn)定 B+ 樹(shù)的數(shù)據(jù)都存放在葉子節(jié)點(diǎn),故任何關(guān)鍵字的查找必須走一條從根節(jié)點(diǎn)到葉子節(jié)點(diǎn)的路徑。所有關(guān)鍵字的查詢(xún)路徑相同,每個(gè)數(shù)據(jù)查詢(xún)效率相當(dāng)。
- B+樹(shù)更便于遍歷 由于B+樹(shù)的數(shù)據(jù)都存儲(chǔ)在葉子結(jié)點(diǎn)中,分支結(jié)點(diǎn)均為索引,遍歷只需要掃描一遍葉子節(jié)點(diǎn)即可;B樹(shù)因?yàn)槠浞种ЫY(jié)點(diǎn)同樣存儲(chǔ)著數(shù)據(jù),要找到具體的數(shù)據(jù),需要進(jìn)行一次中序遍歷按序來(lái)搜索。
- B+樹(shù)更擅長(zhǎng)范圍查詢(xún) B+樹(shù)葉子節(jié)點(diǎn)存放數(shù)據(jù),數(shù)據(jù)是按順序放置的雙向鏈表。B樹(shù)范圍查詢(xún)只能中序遍歷。
- B+ 樹(shù)占用內(nèi)存空間小 B+ 樹(shù)索引節(jié)點(diǎn)沒(méi)有數(shù)據(jù),比較小。在內(nèi)存有限的情況下,相比于B樹(shù)索引可以加載更多B+ 樹(shù)索引。
MyISAM與InnoDB 的區(qū)別
- InnoDB支持事務(wù),MyISAM不支持
- InnoDB支持外鍵,而MyISAM不支持
- InnoDB是聚集索引,數(shù)據(jù)和索引存到同一個(gè)文件里;MyISAM是非聚集索引,數(shù)據(jù)和索引不在同一個(gè)文件里;都是使用B+Tree作為索引結(jié)構(gòu)
- InnoDB不保存表的具體行數(shù),執(zhí)行select count(*) from table時(shí)需要全表掃描。而MyISAM用一個(gè)變量保存了整個(gè)表的行數(shù),執(zhí)行上述語(yǔ)句時(shí)只需要讀出該變量即可,速度很快(注意不能加有任何WHERE條件)
因?yàn)镮nnoDB的事務(wù)特性,在同一時(shí)刻表中的行數(shù)對(duì)于不同的事務(wù)而言是不一樣的,因此count統(tǒng)計(jì)會(huì)計(jì)算對(duì)于當(dāng)前事務(wù)而言可以統(tǒng)計(jì)到的行數(shù),而不是將總行數(shù)儲(chǔ)存起來(lái)方便快速查詢(xún)。InnoDB會(huì)嘗試遍歷一個(gè)盡可能小的索引除非優(yōu)化器提示使用別的索引。如果二級(jí)索引不存在,InnoDB還會(huì)嘗試去遍歷其他聚簇索引。
如果索引并沒(méi)有完全處于InnoDB維護(hù)的緩沖區(qū)(Buffer Pool)中,count操作會(huì)比較費(fèi)時(shí)??梢越⒁粋€(gè)記錄總行數(shù)的表并讓你的程序在INSERT/DELETE時(shí)更新對(duì)應(yīng)的數(shù)據(jù)。和上面提到的問(wèn)題一樣,如果此時(shí)存在多個(gè)事務(wù)的話這種方案也不太好用。如果得到大致的行數(shù)值已經(jīng)足夠滿足需求可以嘗試SHOW TABLE STATUS
那么為什么InnoDB沒(méi)有了這個(gè)變量呢?
- InnoDB支持表、行(默認(rèn))級(jí)鎖,而MyISAM僅支持表級(jí)鎖
- InnoDB表必須有唯一索引(如主鍵)(用戶沒(méi)有指定的話會(huì)自己找/生產(chǎn)一個(gè)隱藏列Row_id來(lái)充當(dāng)默認(rèn)主鍵),而Myisam可以沒(méi)有主鍵
- Innodb存儲(chǔ)文件有frm、ibd,而Myisam是frm、MYD、MYI
Innodb:frm是表定義文件,ibd是數(shù)據(jù)文件
Myisam:frm是表定義文件,myd是數(shù)據(jù)文件,myi是索引文件
索引失效的場(chǎng)景
- 對(duì)索引列使用了函數(shù)、表達(dá)式或運(yùn)算符:當(dāng)查詢(xún)條件中使用了函數(shù)、表達(dá)式或運(yùn)算符時(shí),MySQL就無(wú)法使用該列的索引,因?yàn)樗枰獙?duì)每行數(shù)據(jù)進(jìn)行計(jì)算,而不是直接查找索引。
- 查詢(xún)條件中使用了不等于操作符(<>、!=)、NOT NULL, NOT IN 等
- 模糊查詢(xún):當(dāng)查詢(xún)條件中使用了LIKE、%或_等模糊匹配符號(hào)時(shí),MySQL無(wú)法使用索引進(jìn)行快速定位。
- OR條件:當(dāng)查詢(xún)條件中包含多個(gè)OR條件時(shí),MySQL無(wú)法使用索引進(jìn)行快速定位。
- 范圍查詢(xún):當(dāng)查詢(xún)條件中使用了BETWEEN、<、>、<=、>=等操作符時(shí),MySQL只能使用索引中的一部分?jǐn)?shù)據(jù),需要讀取更多的數(shù)據(jù)進(jìn)行過(guò)濾,降低了查詢(xún)效率。
- 數(shù)據(jù)類(lèi)型不匹配,需要隱式轉(zhuǎn)換類(lèi)型
- 對(duì)索引列進(jìn)行排序,因?yàn)樗枰獙?shù)據(jù)按照指定的順序進(jìn)行排序
- 復(fù)合索引,如果不使用前列,后續(xù)列也將無(wú)法使用
小結(jié)
正確的使用索引,能夠顯著提高數(shù)據(jù)庫(kù)的查詢(xún)效率。本文匯總了MySQL索引的常用知識(shí)點(diǎn),幫助大家快速記憶,快快收藏吧。