www.久久久久|狼友网站av天堂|精品国产无码a片|一级av色欲av|91在线播放视频|亚洲无码主播在线|国产精品草久在线|明星AV网站在线|污污内射久久一区|婷婷综合视频网站

當(dāng)前位置:首頁(yè) > 公眾號(hào)精選 > 架構(gòu)師社區(qū)
[導(dǎo)讀]圖源 世上最好的豬豬 索引的概念基本所有人都會(huì)遇到過(guò),就算沒(méi)有了解過(guò)數(shù)據(jù)庫(kù)中的索引,在生活中也不可避免的接觸到。比方說(shuō)書(shū)籍的目錄,字典的查詢頁(yè),圖書(shū)館的科目檢索等等。其實(shí)這些都是一種索引,并且所起到的作用大同小異。 而對(duì)于數(shù)據(jù)庫(kù)而言,只不過(guò)是

別再一知半解啦!索引其實(shí)就這么回事!

圖源 世上最好的豬豬

索引的概念基本所有人都會(huì)遇到過(guò),就算沒(méi)有了解過(guò)數(shù)據(jù)庫(kù)中的索引,在生活中也不可避免的接觸到。比方說(shuō)書(shū)籍的目錄,字典的查詢頁(yè),圖書(shū)館的科目檢索等等。其實(shí)這些都是一種索引,并且所起到的作用大同小異。

而對(duì)于數(shù)據(jù)庫(kù)而言,只不過(guò)是將索引的概念抽象出來(lái),讓建立索引的過(guò)程更為靈活而自由,從而可以在不同的場(chǎng)景下優(yōu)化數(shù)據(jù)庫(kù)的查詢效率。

索引在數(shù)據(jù)庫(kù)的實(shí)際應(yīng)用場(chǎng)景中十分普遍,數(shù)據(jù)庫(kù)的優(yōu)化也離不開(kāi)對(duì)索引的優(yōu)化。同時(shí),索引相關(guān)的知識(shí)也是面試高頻的考點(diǎn)之一,是應(yīng)試者理論結(jié)合現(xiàn)實(shí)最為直接的體現(xiàn)。

因此,本文將從基礎(chǔ)理論出發(fā),介紹 MySQL 按照邏輯角度的索引分類和實(shí)現(xiàn),通過(guò)數(shù)據(jù)結(jié)構(gòu)的實(shí)現(xiàn)原理闡述不同結(jié)構(gòu)對(duì)建立索引帶來(lái)的優(yōu)劣勢(shì),同時(shí)針對(duì)物理存儲(chǔ)的方式對(duì)索引的組織特點(diǎn)和應(yīng)用場(chǎng)景進(jìn)行分析。最后根據(jù)不同的應(yīng)用場(chǎng)景盡可能的探究如何建立起高性能的索引。文章結(jié)構(gòu)如下:

別再一知半解啦!索引其實(shí)就這么回事!

 1   概念

什么是索引

索引似乎并沒(méi)有十分明確的定義,更多的是一種定性的描述。簡(jiǎn)單來(lái)講,索引就是一種將數(shù)據(jù)庫(kù)中的記錄按照特殊形式存儲(chǔ)的數(shù)據(jù)結(jié)構(gòu)。通過(guò)索引,能夠顯著地提高數(shù)據(jù)查詢的效率,從而提升服務(wù)器的性能。

專業(yè)一點(diǎn)來(lái)說(shuō)呢,索引是一個(gè)排好序的列表,在這個(gè)列表中存儲(chǔ)著索引的值和包含這個(gè)值的數(shù)據(jù)所在行的物理地址。在數(shù)據(jù)庫(kù)十分龐大的時(shí)候,索引可以大大加快查詢的速度,這是因?yàn)槭褂盟饕罂梢圆挥脪呙枞韥?lái)定位某行的數(shù)據(jù),而是先通過(guò)索引表找到該行數(shù)據(jù)對(duì)應(yīng)的物理地址然后訪問(wèn)相應(yīng)的數(shù)據(jù)。

說(shuō)起索引,其實(shí)并不是 MySQL 數(shù)據(jù)庫(kù)特有的機(jī)制,在關(guān)系型數(shù)據(jù)庫(kù)中都會(huì)有類似不同的實(shí)現(xiàn)。這里我們也只是討論 MySQL 數(shù)據(jù)庫(kù)中的索引實(shí)現(xiàn)。

事實(shí)上,說(shuō)是 MySQL 的索引其實(shí)并不準(zhǔn)確。因?yàn)樵?MySQL 中,索引是在存儲(chǔ)引擎層而不是服務(wù)器層實(shí)現(xiàn)的。這意味著我們所討論的索引準(zhǔn)確來(lái)說(shuō)是 InnoDB 引擎或 MyISAM 引擎或其它存儲(chǔ)引擎所實(shí)現(xiàn)的。

所以索引即便是在 MySQL 中也沒(méi)有統(tǒng)一的標(biāo)準(zhǔn),不同存儲(chǔ)引擎的所實(shí)現(xiàn)的索引工作方式也并不一樣。不是所有的存儲(chǔ)引擎都支持相同類型的索引,即便是多個(gè)引擎支持同一種類型的索引,其底層的實(shí)現(xiàn)也可能不同。

為什么需要索引

說(shuō)了這么多,索引似乎就是給數(shù)據(jù)庫(kù)添加了一個(gè)「目錄頁(yè)」,能夠方便查詢數(shù)據(jù)。但是索引的作用就僅此而已了嗎,為什么需要大費(fèi)周章的建立并優(yōu)化索引?

說(shuō)個(gè)題外話,我其實(shí)查字典從來(lái)都不喜歡查目錄頁(yè),無(wú)論是查中文還是英文。因?yàn)橛X(jué)得那樣很慢,一個(gè)個(gè)找索引,效率很低。我習(xí)慣用的方式就是直接翻開(kāi)字典,根據(jù)翻開(kāi)的位置進(jìn)行前后調(diào)整。比方說(shuō)我想找「醬 JIANG」字,會(huì)先隨機(jī)翻到一頁(yè),可能是「F」開(kāi)頭,在「J」前面,就往后翻一點(diǎn);如果隨機(jī)翻到「L」,那就往前翻一點(diǎn)。重復(fù)直至找到。

這大概就是類似于二分查找的方式,看起來(lái)好像是擺脫了索引的束縛,并且也能夠獲得比較高的查詢效率。但是其實(shí)轉(zhuǎn)念一想,在計(jì)算機(jī)的運(yùn)行處理中,「一個(gè)個(gè)找索引」這個(gè)過(guò)程其實(shí)非???,不能跟我們手動(dòng)比對(duì)偏旁部首的效率相提并論。同時(shí),為什么我可以直接翻開(kāi)字典根據(jù)字母進(jìn)行調(diào)整呢,這其實(shí)不就是因?yàn)槲业哪X子里存在一個(gè)大概的「索引表」,知道每個(gè)字母大概對(duì)應(yīng)于字典的哪一個(gè)位置。雖然是模糊的,但卻是真實(shí)存在的。(好不容易強(qiáng)行解釋了一波...)

如此一來(lái),可以看出索引的一大好處是如其概念中所提及的,使用索引后可以不用掃描全表來(lái)定位某行的數(shù)據(jù),而是先通過(guò)索引表找到該行數(shù)據(jù)對(duì)應(yīng)的物理地址然后訪問(wèn)相應(yīng)的數(shù)據(jù)。這樣的方式自然減少了服務(wù)器在響應(yīng)時(shí)所需要對(duì)數(shù)據(jù)庫(kù)掃描的數(shù)據(jù)量。

不僅如此,在執(zhí)行數(shù)據(jù)庫(kù)的范圍查詢時(shí),若不使用索引,那么MySQL會(huì)先掃描數(shù)據(jù)庫(kù)的所有行數(shù)據(jù)并從中篩選出目標(biāo)范圍內(nèi)的行記錄,將這些行記錄進(jìn)行排序并生成一張臨時(shí)表,然后通過(guò)臨時(shí)表返回用戶查詢的目標(biāo)行記錄。這個(gè)過(guò)程會(huì)涉及到臨時(shí)表的建立和行記錄的排序,當(dāng)目標(biāo)行記錄較多的時(shí)候,會(huì)大大影響范圍查詢的效率。

所以當(dāng)添加索引時(shí),由于索引本身具有的順序性,使得在進(jìn)行范圍查詢時(shí),所篩選出的行記錄已經(jīng)排好序,從而避免了再次排序和需要建立臨時(shí)表的問(wèn)題。

同時(shí),由于索引底層實(shí)現(xiàn)的有序性,使得在進(jìn)行數(shù)據(jù)查詢時(shí),能夠避免在磁盤不同扇區(qū)的隨機(jī)尋址。使用索引后能夠通過(guò)磁盤預(yù)讀使得在磁盤上對(duì)數(shù)據(jù)的訪問(wèn)大致呈順序的尋址。這本質(zhì)上是依據(jù)局部性原理所實(shí)現(xiàn)的。

局部性原理:當(dāng)一個(gè)數(shù)據(jù)被用到時(shí),其附近的數(shù)據(jù)也通常會(huì)馬上被使用。程序運(yùn)行期間所需要的數(shù)據(jù)通常比較集中。由于磁盤順序讀取的效率很高(不需要尋道時(shí)間,只需很少的旋轉(zhuǎn)時(shí)間) ,因此對(duì)于具有局部性的程序來(lái)說(shuō),磁盤預(yù)讀可以提高I/O效率。

磁盤預(yù)讀要求每次都會(huì)預(yù)讀的長(zhǎng)度一般為頁(yè)的整數(shù)倍。而且數(shù)據(jù)庫(kù)系統(tǒng)將一個(gè)節(jié)點(diǎn)的大小設(shè)為等于一個(gè)頁(yè),這樣每個(gè)節(jié)點(diǎn)只需要一次 I/O 就可以完全載入。這里的頁(yè)是通過(guò)頁(yè)式的內(nèi)存管理所實(shí)現(xiàn)的,概念在這里簡(jiǎn)單提一嘴。

分頁(yè)機(jī)制就是把內(nèi)存地址空間分為若干個(gè)很小的固定大小的頁(yè),每一頁(yè)的大小由內(nèi)存決定。這樣做是為了從虛擬地址映射到物理地址,提高內(nèi)存和磁盤的利用率。

所以呢,總結(jié)一下。索引的存在具有很大的優(yōu)勢(shì),主要表現(xiàn)為以下三點(diǎn):

  • 索引大大減少了服務(wù)器需要掃描的數(shù)據(jù)量
  • 索引可以幫助服務(wù)器避免排序和臨時(shí)表
  • 索引可以將隨機(jī) I/O 變成順序 I/O

以上三點(diǎn)能夠大大提高數(shù)據(jù)庫(kù)查詢的效率,優(yōu)化服務(wù)器的性能。因此一般來(lái)說(shuō),為數(shù)據(jù)庫(kù)添加高效的索引對(duì)數(shù)據(jù)庫(kù)進(jìn)行優(yōu)化的重要工作之一。

不過(guò),凡事都有兩面性。索引的存在能夠帶來(lái)性能的提升,自然在其它方面也會(huì)付出額外的代價(jià)。

索引本身以表的形式存儲(chǔ),因此會(huì)占用額外的存儲(chǔ)空間;

索引表的創(chuàng)建和維護(hù)需要時(shí)間成本,這個(gè)成本隨著數(shù)據(jù)量增大而增大;

構(gòu)建索引會(huì)降低數(shù)據(jù)的修改操作(刪除,添加,修改)的效率,因?yàn)樵谛薷臄?shù)據(jù)表的同時(shí)還需要修改索引表;

所以對(duì)于非常小的表而言,使用索引的代價(jià)會(huì)大于直接進(jìn)行全表掃描,這時(shí)候就并不一定非得使用索引了。沒(méi)辦法,成年人的世界總是這么的趨利避害。


 2   輯分類

從邏輯的角度來(lái)對(duì)索引進(jìn)行劃分的話,可以分為單列索引、全文索引、組合索引和空間索引。其中單列索引又可分為主鍵索引、唯一索引和普通索引。這里的邏輯可以理解為從 SQL 語(yǔ)句的角度,或者是從數(shù)據(jù)庫(kù)關(guān)系表的角度。下面就簡(jiǎn)單介紹這些索引的作用和用法,以及在修改表的時(shí)候如何添加索引。

主鍵索引

即主索引,根據(jù)主鍵建立索引,不允許重復(fù),不允許空值;

主鍵:數(shù)據(jù)庫(kù)表中一列或列組合(字段)的值,可唯一標(biāo)識(shí)表中的每一行。

加速查詢 + 列值唯一(不可以有null)+ 表中只有一個(gè)

ALTER TABLE 'table_name' ADD PRIMARY KEY pk_index('col');

唯一索引

用來(lái)建立索引的列的值必須是唯一的,允許空值。唯一索引不允許表中任何兩行具有相同的索引值。比方說(shuō),在 employee 表中職員的姓 name 上創(chuàng)建了唯一索引,那么就表示任何兩個(gè)員工都不能同姓。

加速查詢 + 列值唯一(可以有null)

ALTER TABLE 'table_name' ADD UNIQUE index_name('col');

普通索引

用表中的普通列構(gòu)建的索引,沒(méi)有任何限制。

僅加速查詢

ALTER TABLE 'table_name' ADD INDEX index_name('col');

全文索引

用大文本對(duì)象的列構(gòu)建的索引

ALTER TABLE 'table_name' ADD FULLTEXT INDEX ft_index('col');

組合索引

用多個(gè)列組合構(gòu)建的索引,這多個(gè)列中的值不允許有空值。

多列值組成一個(gè)索引,專門用于組合搜索,其效率大于索引合并。

ALTER TABLE 'table_name' ADD INDEX index_name('col1','col2','col3');

在對(duì)多列組合建立索引時(shí),會(huì)遵循「最左前綴」原則。

最左前綴原則:顧名思義,就是最左優(yōu)先,上例中我們創(chuàng)建了 (col1, col2, col3) 多列索引,相當(dāng)于創(chuàng)建了 (col1)  單列索引,(col1, col2) 組合索引以及 (col1, col2, col3) 組合索引。

所以當(dāng)我們?cè)趧?chuàng)建多列索引時(shí),要根據(jù)業(yè)務(wù)場(chǎng)景,將 where 子句中使用最頻繁的一列放在最左邊。

空間索引

對(duì)空間數(shù)據(jù)類型的字段建立的索引,底層可通過(guò) R 樹(shù)實(shí)現(xiàn)。只不過(guò)使用較少,了解即可。


 3   實(shí)現(xiàn)原理

我們知道,索引的底層本身就是通過(guò)數(shù)據(jù)結(jié)構(gòu)來(lái)進(jìn)行實(shí)現(xiàn)的。那么根據(jù)其底層的結(jié)構(gòu),常見(jiàn)的索引類型可分為哈希索引,BTree 索引,B+Tree 索引等。這里我們就主要來(lái)介紹這三種索引背后的實(shí)現(xiàn)機(jī)制。

哈希索引

顧名思義,哈希索引是通過(guò)哈希表實(shí)現(xiàn)的。哈希表的特點(diǎn)在之前的文章「九大數(shù)據(jù)結(jié)構(gòu)」中已經(jīng)詳細(xì)介紹過(guò)。通過(guò)哈希表的鍵值之間的對(duì)應(yīng)關(guān)系,能夠在查詢時(shí)精確匹配索引的所有列。哈希索引將所有的根據(jù)索引列計(jì)算出來(lái)的哈希碼存儲(chǔ)在索引中,同時(shí)將指向每個(gè)數(shù)據(jù)行的指針保存在哈希表中。

別再一知半解啦!索引其實(shí)就這么回事!

上圖是通過(guò)哈希索引查詢行數(shù)據(jù)的示意圖,可以發(fā)現(xiàn)哈希索引同樣會(huì)發(fā)生哈希沖突,并且是通過(guò)鏈地址法解決沖突的。當(dāng)發(fā)送沖突時(shí),還需要對(duì)鏈表進(jìn)行遍歷對(duì)比,才能夠找到最終的結(jié)果。

在 MySQL 中,只有 Memory 存儲(chǔ)引擎顯式的支持哈希索引,而innodb是隱式支持哈希索引的。

這里的隱式支持是指,innodb引擎有一個(gè)特殊的功能 “自適應(yīng)哈希索引”,當(dāng)innodb注意到一些索引值被使用的非常頻繁時(shí),且符合哈希特點(diǎn)(如每次查詢的列都一樣),它會(huì)在內(nèi)存中基于 B-Tree 索引之上再創(chuàng)建一個(gè)哈希索引。這樣就讓 BTree 索引也具有哈希索引的一些有點(diǎn)。這是一個(gè)完全自動(dòng)的、內(nèi)部的行為。

由于哈希結(jié)構(gòu)的特殊性,其用于非常高的檢索效率,通過(guò)哈希函數(shù)的映射可以一步到位。但是同樣也是因?yàn)榻Y(jié)構(gòu)的特殊,導(dǎo)致哈希索引只適用于某些特定的場(chǎng)合。哈希索引的限制[1]:

  1. 不支持范圍查詢,比如 WHERE a > 5;只支持等值比較查詢,包括 、 IN 、 <=>
  2. 無(wú)法被用來(lái)避免數(shù)據(jù)的排序操作;因?yàn)榻?jīng)過(guò)了哈希函數(shù)的映射過(guò)程,使得丟失了哈希前后的大小關(guān)系,從而無(wú)法按照索引值的順序存儲(chǔ)。
  3. 不支持部分索引列的匹配查找,因?yàn)楣K饕冀K使用索引列的全部?jī)?nèi)容來(lái)計(jì)算哈希值。例如在數(shù)據(jù)列 (A, B) 上建立哈希索引,如果查詢只有數(shù)據(jù)列 A,則無(wú)法使用該索引。
  4. 無(wú)法避免表掃描。因?yàn)楫?dāng)出現(xiàn)哈希沖突的時(shí)候,存儲(chǔ)引擎必須遍歷鏈表(拉鏈法)中所有的行指針,逐行進(jìn)行比較,直到找到所有符合條件的行。
  5. 哈希沖突很多的情況下,其索引維護(hù)的代價(jià)很高,并且性能并不一定會(huì)比 BTree 索引高。

BTree 索引

BTree 實(shí)際上是一顆多叉平衡搜索樹(shù)。從名字可以看出,BTree 首先是一顆多叉搜索樹(shù),這意味著它是具有順序的;其次 BTree 還是平衡的,這意味著它的左右子樹(shù)高度差小于等于1。

事實(shí)上一顆 BTree 需要滿足以下幾個(gè)條件:

每個(gè)葉子結(jié)點(diǎn)的高度都是一樣的;

每個(gè)非葉子結(jié)點(diǎn)由 n-1 個(gè) key 和 n 個(gè)指針 point 組成,其中 d<=n<=2d, key 和 point 相互間隔,結(jié)點(diǎn)兩端一定是 key;

葉子結(jié)點(diǎn)指針都為 null;

非葉子結(jié)點(diǎn)的key都是 [key, data] 二元組,其中 key 表示作為索引的鍵,data 為鍵值所在行的數(shù)據(jù);

一顆常見(jiàn)的BTree樹(shù)見(jiàn)下圖。

別再一知半解啦!索引其實(shí)就這么回事!

這是一顆三階的BTree,可通過(guò)鍵值的大小排序進(jìn)行數(shù)據(jù)的查詢和檢索,其中葉子節(jié)點(diǎn)的指針都為空,因此省略沒(méi)畫(huà)。從上圖可以發(fā)現(xiàn),BTree 的樹(shù)形狀相較于我們之前常見(jiàn)的二叉樹(shù)等結(jié)構(gòu),更為扁平和矮胖。

之所以這樣設(shè)計(jì),還是跟磁盤讀取的特點(diǎn)有關(guān)。我們知道在建立索引時(shí),也是需要占據(jù)物理空間的。而實(shí)際上當(dāng)數(shù)據(jù)量比較大的時(shí)候,索引文件的大小也十分嚇人??紤]到一個(gè)表上可能有多個(gè)索引、組合索引、數(shù)據(jù)行占用更小等情況,索引文件的大小可能達(dá)到物理盤中數(shù)據(jù)的1/10,甚至可達(dá)到1/3。

這就意味著索引無(wú)法全部裝入內(nèi)存之中。當(dāng)通過(guò)索引對(duì)數(shù)據(jù)進(jìn)行訪問(wèn)時(shí),不可避免的需要對(duì)磁盤進(jìn)行讀寫訪問(wèn)。同時(shí)我們還知道,內(nèi)存的讀寫速度是磁盤的幾個(gè)數(shù)量級(jí)。因此在對(duì)索引結(jié)構(gòu)進(jìn)行設(shè)計(jì)時(shí)要盡可能的減少對(duì)磁盤的讀寫次數(shù),也就是所謂的磁盤 I/O 次數(shù)。

這也就是索引會(huì)采用 BTree 這種扁平樹(shù)結(jié)構(gòu)的原因,樹(shù)的層數(shù)越少,磁盤I/O的次數(shù)自然就越少。不僅如此,我們上面提到過(guò)磁盤預(yù)讀的局部性原理。根據(jù)這個(gè)原理再加上頁(yè)表機(jī)制,能夠在進(jìn)行磁盤讀取的時(shí)候更大化的提升性能。

BTree 相較于其它的二叉樹(shù)結(jié)構(gòu),對(duì)磁盤的 I/O 次數(shù)已經(jīng)非常少了。但是在實(shí)際的數(shù)據(jù)庫(kù)應(yīng)用中仍有些問(wèn)題無(wú)法解決。

一是無(wú)法定位到數(shù)據(jù)行。通過(guò) BTree 可以根據(jù)主鍵的排序定位出主鍵的位置,但是由于數(shù)據(jù)表的記錄有多個(gè)字段,僅僅定位到主鍵是不夠,還需要定位到數(shù)據(jù)行。雖然這個(gè)問(wèn)題可以通過(guò)在 BTree 的節(jié)點(diǎn)中存儲(chǔ)數(shù)據(jù)行或者增加定位的字段,但是這種方式會(huì)使得 BTree 的深度大幅度提高,從而也導(dǎo)致 I/O 次數(shù)的提高。

二是無(wú)法處理范圍查詢。在實(shí)際的應(yīng)用中,數(shù)據(jù)庫(kù)范圍查詢的頻率非常高,而 BTree 只能定位到一個(gè)索引位置。雖然可以通過(guò)先后查詢范圍的左右界獲得,但是這樣的操作實(shí)際上無(wú)法很好的利用磁盤預(yù)讀的局部性原理,先后查詢可能會(huì)造成通過(guò)預(yù)讀取的物理地址離散,使得 I/O 的效率并不高。

三是當(dāng)數(shù)據(jù)量一大時(shí),BTree的高度依舊會(huì)變得很高,搜索效率還是會(huì)大幅度的下降。

問(wèn)題總是推動(dòng)改進(jìn)的前提?;谝陨系膯?wèn)題考慮,就出現(xiàn)了對(duì) BTree 的優(yōu)化版本,也就是 B+Tree。

B+Tree索引

B+Tree 一看就是在 BTree 的基礎(chǔ)上做了改進(jìn),那么到底改變了什么呢。廢話不多說(shuō),先上圖

別再一知半解啦!索引其實(shí)就這么回事!

上圖實(shí)際上是一種帶有順序索引的 B+Tree,與最基本的 B+Tree 的區(qū)別就在于葉子節(jié)點(diǎn)是否通過(guò)指針相連。一般數(shù)據(jù)庫(kù)中常用的結(jié)構(gòu)都是這種帶有順序索引的 B+Tree。后文探討的也都是帶順序索引的 B+Tree 結(jié)構(gòu)。

對(duì)比 BTree 和 B+Tree,我們可以發(fā)現(xiàn)二者主要在以下三個(gè)方面上的不同:

  1. 非葉子節(jié)點(diǎn)只存儲(chǔ)鍵值信息,不再存儲(chǔ)數(shù)據(jù)。
  2. 所有葉子節(jié)點(diǎn)之間都有一個(gè)鏈指針,指向下一個(gè)葉子節(jié)點(diǎn)。
  3. 數(shù)據(jù)都存放在葉子節(jié)點(diǎn)中。

看著 B+Tree,像不像是一顆樹(shù)與一個(gè)有序鏈表的結(jié)合體。因而其實(shí) B+Tree 也就是帶有樹(shù)和鏈表的部分優(yōu)勢(shì)。樹(shù)結(jié)構(gòu)使得有序檢索更為簡(jiǎn)單,I/O 次數(shù)更少;有序鏈表結(jié)構(gòu)使得可以按照鍵值排序的次序遍歷全部記錄。

B+Tree 在作為索引結(jié)構(gòu)時(shí)能夠帶來(lái)的好處有:

一,I/O 次數(shù)更少。這是因?yàn)樯衔囊舱f(shuō)過(guò),BTree 的節(jié)點(diǎn)是存放在內(nèi)存頁(yè)中的。那么在相同的內(nèi)存頁(yè)大小(一般為4k)的情況下,B+Tree 能夠存儲(chǔ)更多的鍵值,那么整體樹(shù)結(jié)構(gòu)的高度就會(huì)更小,需要的 I/O 次數(shù)也就越小。

二,數(shù)據(jù)遍歷更為方便。這個(gè)優(yōu)勢(shì)很明顯是由有序鏈表帶來(lái)的。通過(guò)葉子節(jié)點(diǎn)的鏈接,使得對(duì)所有數(shù)據(jù)的遍歷只需要在線性的鏈表上完成,這就非常適合區(qū)間檢索和范圍查詢

三,查詢性能更穩(wěn)定。這自然是由于只在葉子節(jié)點(diǎn)存儲(chǔ)數(shù)據(jù),所以所有數(shù)據(jù)的查詢都會(huì)到達(dá)葉子節(jié)點(diǎn),同時(shí)葉子節(jié)點(diǎn)的高度都相同,因此理論上來(lái)說(shuō)所有數(shù)據(jù)的查詢速度都是一致的。

正是由于 B+Tree 優(yōu)秀的結(jié)構(gòu)特性,使得常用作索引的實(shí)現(xiàn)結(jié)構(gòu)。在 MySQL 中,存儲(chǔ)引擎 MyISAM 和 InnoDB 都分別以 B+Tree 實(shí)現(xiàn)了響應(yīng)的索引設(shè)計(jì)。


 4   物理存儲(chǔ)

雖說(shuō) B+Tree 結(jié)構(gòu)都可以用在 MyISAM 和 InnoDB,但是這二者對(duì)索引的在物理存儲(chǔ)層次的實(shí)現(xiàn)方式卻不相同。InnoDB 實(shí)現(xiàn)的是聚簇索引,而 MyISAM 實(shí)現(xiàn)的卻是非聚簇索引。在介紹聚簇索引之前,我們需要先了解以下啥是佩奇,不對(duì),是啥是「主鍵索引」和「輔助索引」。

其實(shí)概念很簡(jiǎn)單。我們剛剛不是在講 B+Tree 的時(shí)候說(shuō)過(guò),樹(shù)的非葉子節(jié)點(diǎn)只存儲(chǔ)鍵值。沒(méi)錯(cuò)就是這個(gè)鍵值,當(dāng)這個(gè)鍵值是數(shù)據(jù)表的主鍵時(shí),那么所建立的就是主鍵索引;當(dāng)這個(gè)鍵值是其它字段的時(shí)候,就是輔助索引。因而可以得出,主鍵索引只能有一個(gè),而輔助索引卻可以有很多個(gè)。

聚簇索引和非聚簇索引的區(qū)別也就是根據(jù)其對(duì)應(yīng)的主鍵索引和輔助索引的不同特點(diǎn)而實(shí)現(xiàn)的。

聚簇索引

說(shuō)回聚簇索引。先丟個(gè)定義。

聚簇索引的主鍵索引的葉子結(jié)點(diǎn)存儲(chǔ)的是鍵值對(duì)應(yīng)的數(shù)據(jù)本身;輔助索引的葉子結(jié)點(diǎn)存儲(chǔ)的是鍵值對(duì)應(yīng)的數(shù)據(jù)的主鍵鍵值。

這句話的信息量挺大的。首先,分析第一句話,主鍵索引的葉子節(jié)點(diǎn)存儲(chǔ)的是鍵值對(duì)應(yīng)的數(shù)據(jù)本身

我們知道,主鍵索引存儲(chǔ)的鍵值就是主鍵。那么也就是說(shuō),聚簇索引的主鍵索引,在葉子節(jié)點(diǎn)中存儲(chǔ)的是主鍵和主鍵對(duì)應(yīng)的數(shù)據(jù)。數(shù)據(jù)和主鍵索引是存儲(chǔ)在一起的,一起作為葉子節(jié)點(diǎn)的一部分。

然后,分析第二句話,輔助索引的葉子結(jié)點(diǎn)存儲(chǔ)的是鍵值對(duì)應(yīng)的數(shù)據(jù)的主鍵鍵值。

我們又知道,輔助索引存儲(chǔ)的鍵值是非主鍵的字段。那就也就是說(shuō),通過(guò)輔助索引,可以找到非主鍵字段對(duì)應(yīng)的數(shù)據(jù)行中的主鍵。

重點(diǎn)來(lái)了。當(dāng)然主鍵索引和輔助索引一結(jié)合,能干啥呢。當(dāng)直接采用主鍵進(jìn)行檢索時(shí),可通過(guò)主鍵索引直接獲得數(shù)據(jù);而當(dāng)采用非主鍵進(jìn)行檢索時(shí),先需要通過(guò)輔助索引來(lái)獲得主鍵,然后再通過(guò)這個(gè)主鍵在主鍵索引中找到對(duì)應(yīng)的數(shù)據(jù)行。

舉個(gè)例子吧。假設(shè)有這么一個(gè)數(shù)據(jù)表。

別再一知半解啦!索引其實(shí)就這么回事!

那么采用聚簇索引的存儲(chǔ)方式,對(duì)應(yīng)的主鍵索引為:(主鍵為ID)

別再一知半解啦!索引其實(shí)就這么回事!

對(duì)應(yīng)的輔助索引為:(鍵值為Name,大概的意思):

別再一知半解啦!索引其實(shí)就這么回事!

所以當(dāng)使用where ID = 7這樣的條件查找主鍵,則按照B+樹(shù)的檢索算法即可查找到對(duì)應(yīng)的葉節(jié)點(diǎn),之后獲得行數(shù)據(jù)。對(duì)Name列進(jìn)行條件搜索,則需要兩個(gè)步驟:第一步在輔助索引B+樹(shù)中檢索Name,到達(dá)其葉子節(jié)點(diǎn)獲取對(duì)應(yīng)的主鍵。第二步使用主鍵在主鍵索引B+樹(shù)種再執(zhí)行一次B+樹(shù)檢索操作,最終到達(dá)葉子節(jié)點(diǎn)即可獲取整行數(shù)據(jù)。

最后把以上過(guò)程整理總結(jié)一下,聚簇索引實(shí)際上的過(guò)程就分為以下兩個(gè)過(guò)程?,F(xiàn)在這個(gè)圖應(yīng)該能夠看懂了吧。

別再一知半解啦!索引其實(shí)就這么回事!

非聚簇索引

學(xué)完了聚簇索引,非聚簇索引就簡(jiǎn)單多啦。同樣,先上定義。

非聚簇索引的主鍵索引和輔助索引幾乎是一樣的,只是主索引不允許重復(fù),不允許空值,他們的葉子結(jié)點(diǎn)都存儲(chǔ)指向鍵值對(duì)應(yīng)的數(shù)據(jù)的物理地址。

與聚簇索引來(lái)對(duì)比著看,上面的定義能夠說(shuō)明什么呢。首先,主鍵索引和輔助索引的葉子結(jié)點(diǎn)都存儲(chǔ)著鍵值對(duì)應(yīng)的數(shù)據(jù)的物理地址,這說(shuō)明無(wú)論是主鍵索引還是輔助索引都能夠通過(guò)直接獲得數(shù)據(jù),而不需要像聚簇索引那樣在檢索輔助索引時(shí)還得多繞一圈。

同時(shí)還說(shuō)明一個(gè)點(diǎn),葉子結(jié)點(diǎn)存儲(chǔ)的是物理地址,那么表示數(shù)據(jù)實(shí)際上是存在另一個(gè)地方的,并不是存儲(chǔ)在B+樹(shù)的結(jié)點(diǎn)中。這說(shuō)明非聚簇索引的數(shù)據(jù)表和索引表是分開(kāi)存儲(chǔ)的。

同樣,對(duì)非聚簇索引的檢索過(guò)程來(lái)個(gè)總結(jié)。別再一知半解啦!索引其實(shí)就這么回事!

無(wú)論是主鍵索引還是輔助索引的檢索過(guò)程,都只需要通過(guò)相應(yīng)的 B+Tree 進(jìn)行搜索即可獲得數(shù)據(jù)對(duì)應(yīng)的物理地址,然后經(jīng)過(guò)依次磁盤 I/O 就可訪問(wèn)數(shù)據(jù)。

對(duì)比聚簇索引和非聚簇索引,可以發(fā)現(xiàn)二者最主要的區(qū)別就是在于是否在 B+Tree 的節(jié)點(diǎn)中存儲(chǔ)數(shù)據(jù),也就是數(shù)據(jù)和索引是否存儲(chǔ)在一起。這個(gè)區(qū)別導(dǎo)致最大的問(wèn)題就是聚簇索引的索引的順序和數(shù)據(jù)本身的順序是相同的,而非聚簇索引的順序跟數(shù)據(jù)的順序沒(méi)有啥關(guān)系。


 5   索引優(yōu)化

介紹了這么多的索引,其實(shí)最終都是為了建立高性能的索引策略,對(duì)數(shù)據(jù)庫(kù)中的索引進(jìn)行優(yōu)化。索引的優(yōu)化有很多角度,針對(duì)特定的業(yè)務(wù)場(chǎng)景可采用不同的優(yōu)化策略。這里考慮到文章篇幅,就不具體介紹,下次再出一篇專門講索引優(yōu)化的文章。簡(jiǎn)單列舉一下在進(jìn)行優(yōu)化時(shí)可以考慮的幾個(gè)方向:

1 獨(dú)立的列。索引列不能是表達(dá)式的一部分,也不能是函數(shù)的參數(shù)。

2 前綴索引和索引選擇性。這二者實(shí)際上是相互制約的關(guān)系,制約條件在于前綴的長(zhǎng)度。一般應(yīng)選擇足夠長(zhǎng)的前綴以保證較高的選擇性(保證查詢效率),同時(shí)又不能太長(zhǎng)以便節(jié)省空間。

3 盡量使用覆蓋索引。覆蓋索引是指一個(gè)索引包含所有需要查詢的字段的值,這樣在查詢時(shí)只需要掃描索引而無(wú)須再去讀取數(shù)據(jù)行,從而極大的提高性能。

4 使用索引掃描來(lái)做排序。要知道,掃描索引本身是很快的,在設(shè)計(jì)索引時(shí),可盡可能的使用同一個(gè)索引既滿足排序,又滿足查找行數(shù)據(jù)。

最后,在建立索引時(shí)給幾個(gè)小貼士:

1 優(yōu)先使用自增key作為主鍵

2 記住最左前綴匹配原則

3 索引列不能參與計(jì)算

4 選擇區(qū)分度高的列作索引

5 能擴(kuò)展就不要新建索引


 6   總結(jié)

索引的概念和原理是我們?cè)诹私夂途〝?shù)據(jù)庫(kù)過(guò)程中無(wú)法逃避的重點(diǎn),而事實(shí)上建立高性能的索引對(duì)實(shí)際的應(yīng)用場(chǎng)景也具有重要意義。本文的目的依舊是由淺入深的介紹索引這么個(gè)東西,從概念到實(shí)現(xiàn)再到最終的優(yōu)化策略。

點(diǎn)到為止,學(xué)無(wú)止境。掌握了基本的理論和概念后,還需要在實(shí)際的服務(wù)器開(kāi)發(fā)場(chǎng)景中針對(duì)具體的問(wèn)題和服務(wù)進(jìn)行索引優(yōu)化方案的設(shè)計(jì)和使用。功力不夠,仍需努力。


 7   Reference

  • 高性能 MySQL,Baron Schwartz 等人著,電子工業(yè)出版社
  • 公眾號(hào)碼海系列文章 
  • https://www.jianshu.com/p/9e9aca844c13
  • https://www.runoob.com/mysql/mysql-index.html
  • https://www.cnblogs.com/Aiapple/p/5693239.html
  • https://blog.csdn.net/tongdanping/article/details/79878302
  • https://www.cnblogs.com/igoodful/p/9361500.html

特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容,還沒(méi)關(guān)注的小伙伴,可以長(zhǎng)按關(guān)注一下:

別再一知半解啦!索引其實(shí)就這么回事!

別再一知半解啦!索引其實(shí)就這么回事!

長(zhǎng)按訂閱更多精彩▼

別再一知半解啦!索引其實(shí)就這么回事!

如有收獲,點(diǎn)個(gè)在看,誠(chéng)摯感謝

免責(zé)聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn),不代表本平臺(tái)立場(chǎng),如有問(wèn)題,請(qǐng)聯(lián)系我們,謝謝!

本站聲明: 本文章由作者或相關(guān)機(jī)構(gòu)授權(quán)發(fā)布,目的在于傳遞更多信息,并不代表本站贊同其觀點(diǎn),本站亦不保證或承諾內(nèi)容真實(shí)性等。需要轉(zhuǎn)載請(qǐng)聯(lián)系該專欄作者,如若文章內(nèi)容侵犯您的權(quán)益,請(qǐng)及時(shí)聯(lián)系本站刪除。
關(guān)閉
關(guān)閉