索引的資料結構及類別初探

2021-10-25 01:57:45 字數 2759 閱讀 8574

資料庫是我們開發程式設計中不可缺少的模組,而資料庫的索引又是重中之重。

在關聯式資料庫中,索引是一種對資料庫表中的值進行排序的儲存結構。索引的作用相當於圖書的目錄,可以根據目錄中的頁碼快速找到所需的內容。

索引提供指向儲存在表的指定列中的資料值的指標,然後根據您指定的排序順序對這些指標排序。資料庫使用索引以找到特定值,然後順指標找到包含該值的行。這樣可以使對應於表的sql語句執行得更快,可快速訪問資料庫表中的特定資訊。

在關係型資料庫中,主鍵,唯一鍵,普通鍵,都可以作為資料庫的索引。

說到索引的資料結構,我們先來看下大家熟悉的二叉樹。

如圖是乙個二叉查詢樹,在二叉查詢樹中,我們可以使用二分查詢法,去檢索需要的資料。

那為什麼不用二叉樹去作為索引的資料結構呢?如圖所示的二叉樹,如果我們刪除了資料為6的節點,增加乙個資料為10的節點,那此二叉樹便成為了乙個線形二叉樹。也就是說,在插入刪除的過程中,二叉樹可能回演變成線性結構,線性結構會明顯降低查詢的效率;同時,二叉樹在資料較多時,深度狠深,也不利於資料的查詢。

我們再來看一下b樹。

什麼是b樹呢,b樹,又稱b-樹,它具有以下特點:

(1)排序方式:所有節點關鍵字是按遞增次序排列,並遵循左小右大原則;

(2)它是乙個多階樹,他的葉子節點和非葉子節點都記錄有關鍵字;

(3)所有葉子節點均在同一層、葉子節點除了包含了關鍵字和關鍵字記錄的指標外也有指向其子節點的指標只不過其指標位址都為null。

b樹的這些規則保證了關鍵字資訊的順序排列,並且在b樹中進行刪除增加操作時,b樹仍然會保持樹形結構。

顯然b樹相較於平衡二叉樹,更加適合做索引的資料結構,但是呢,我們常用的mysql用的卻並不是b樹,而是更適合的b+樹。

b+樹是b樹的乙個公升級版,相對於b樹來說b+樹更充分的利用了節點的空間,讓查詢速度更加穩定,來看下b+樹:

b+樹具有以下特點:

(1)b+跟b樹不同b+樹的非葉子節點不儲存關鍵字記錄的指標,只進行資料索引;

(2)b+樹葉子節點儲存了父節點的所有關鍵字記錄的指標,所有資料位址必須要到葉子節點才能獲取到。所以每次資料查詢的次數都一樣;

(3)b+樹葉子節點的關鍵字從小到大有序排列,左邊結尾資料都會儲存右邊節點開始資料的指標。

所以,用b+樹作為索引結構,有著以下優點:

(1)b+樹的中間節點不儲存資料,是純索引,但是b樹的中間節點是儲存資料和索引的,相對來說,b+樹在磁碟頁中能容納更多節點元素。

(2)b+樹每次查詢都要從根節點一直查到葉節點,所以查詢效率更加穩定。

(3)因為每個葉子節點都存放了指向下乙個節點的指標,且關鍵資料有序排列,所以在範圍查詢中,b+樹更佔優勢。

(4)增刪節點時,效率更高,因為b+樹的葉子節點包含所有關鍵字,並以有序的鍊錶結構儲存。

我們常用的mysql就是預設採用了b+樹作為索引結構。

在我們建立索引時,可以看到mysql也是支援hash索引結構的,我們再來簡單介紹下hash索引。

雜湊索引就是採用一定的雜湊演算法,把鍵值換算成新的雜湊值,檢索時不需要類似b+樹那樣從根節點到葉子節點逐級查詢,只需一次雜湊演算法即可立刻定位到相應的位置,速度非常快。

聽起來很吊,但是hash索引雖然再等值查詢時占有一定的優勢,但是它相比於b+tree卻有一些無法彌補的缺點:

(1)它僅僅能滿足等值查詢,不支援範圍查詢。

(2)無法進行資料的排序操作。

(3)不支援多列聯合索引的最左匹配規則。因為hash索引的聯合索引,是把多個鍵值房子一起算hash值的。

(4)遇到大量hash值相等的情況後效能下降。

綜上,mysql採用了預設b+tree作為索引結構,也支援hash結構作為索引的方式。

我們再來看下聚簇索引和非聚簇索引。

聚簇索引,也就是說,b+樹的葉子節點儲存的不僅僅是索引鍵的值,還儲存了位於同一行記錄裡的其他列的資訊,同時,由於聚簇索引決定了表儲存資料時的物理排列順序,所以乙個表只有乙個聚簇索引。

非聚簇索引檔案只為索引碼的某些值建立索引項,也就是說,葉子節點僅儲存了鍵位資訊和該行資料的位址或主鍵。

再來說下mysql的兩種儲存引擎採用聚簇索引和非聚簇索引的區別。

對於innodb來說,每張表有且只有乙個聚簇索引。(優先使用主鍵作為聚簇索引,沒有主鍵則採用該錶的唯一非空索引,如果都沒有,innodb中會自動生成乙個隱藏主鍵作為聚簇索引。)

同時,它的表資料和這個索引會儲存在一起。而它的其他非聚簇索引的b+樹的葉子節點中,則只儲存了該行的主鍵值。所以,當使用非聚簇索引去查詢的時候,資料庫會先查到索引本身,再根據和索引儲存再一起的主鍵,去聚簇索引中查詢資料。如圖所示:

對於myisam來說,它的表索引全是非聚簇索引,每張表可以有多個非聚簇索引,它的資料和索引也沒有存在一起,它的b+樹葉子節點中只儲存了資料位址,查詢時如圖所示:

在我們平時的開發程式設計中,難免會和索引打交道。所以,只有更多的去了解索引,去了解索引的資料結構以及不同儲存引擎中索引的區別等知識,才能讓我們在解決平時遇到索引問題時游刃有餘。

MySQL索引及索引資料結構

索引是幫助mysql高效獲取資料的排好序的資料結構 索引分類 索引失效的情況 模糊查詢時,第乙個查詢字元是不確定值 或 時,索引失效 select name from stu where name like e 索引失效 select name from stu where name like h ...

Mysql索引的資料結構及索引優化

索引的本質 是幫助mysql高效獲取資料的排好序的資料結構。索引資料結構 1 二叉樹 儲存資料的時候是乙個鍊錶,如果要查詢0006的話要查詢6次,如果是全表掃瞄的話也得查詢6次。弊端 二叉樹的查詢效率很低。2 紅黑樹 儲存資料的時候會自旋,如果要查詢0006的話只需要查詢3次。如果是全表掃瞄或二叉樹...

索引 資料結構

子元素比根元素大,放在右邊,反之亦然。如果資料從1開始遞增,依然使用二叉樹的話,二叉樹就會變成鍊錶結構 本質上是二叉樹,如果某一邊的子元素與另一邊的子元素相比超過二個,會發生自旋,一種平衡方式。也叫二叉平衡樹 在自增資料量很大的時候,樹的層數太高,查詢效率也會變低 葉節點具有相同的深度,葉節點的指標...