索引原理（平衡樹資料結構）

索引索引索引

本質：通過不斷地縮小想要獲取資料的範圍來篩選出最終想要的結果，同時把隨機的事件變成順序的事件，也就是說，有了這種索引機制，我們可以總是用同一種查詢方式來鎖定資料

想要了解索引的原理就必須了解一種資料結構——平衡樹（b tree或b+ tree），也有寫索引是用雜湊桶作為其資料結構，但是主流的rdbms都是把平衡樹作為預設的索引儲存結構

這裡的平衡樹，類似我們熟悉的二叉樹，但不等於二叉樹，儲存結構也是有根節點，葉結點，真正的資料只存在葉子結點上，其他非葉子結點只儲存指引搜尋的方向。事實上，建立表時如果未指定主鍵，則資料無序地放置在磁碟儲存器上，一列一列很整齊地存放著，但是沒有規律，如果指定了主鍵，資料儲存結構立刻變為樹狀結構，也就是所說的平衡樹結構，同時生成了乙個聚集索引，這就是為什麼乙個表只能有乙個主鍵，乙個表只能有乙個聚集索引，因為主鍵的作用就是把錶的資料儲存格式轉換成索引（平衡樹）的格式放置。

例如這條sql語句：

select * from kxf where id=20;

首先根據索引定位到20這個值所在的葉結點，然後再通過葉結點取到id等於20的資料行。這裡不講解平衡樹的執行細節，但是樹有多少層，從根節點至葉節點就只需要經過多少次查詢就能得到結果，這裡樹有三層，也就是說只需要三次io，如下圖

假如一張表有一億條資料，需要查詢其中某一條，按照常規邏輯，一條一條的去匹配的話，最壞的情況下需要匹配一億次才能得到結果，時間複雜度就是o(n)，這顯然無法接受，而且這一億條資料顯然不能一次性讀入記憶體供程式使用，因此，這一億次匹配在不僅快取優化的情況下就是一億次io開銷，以現在磁碟的io能力和cpu運算能力，有可能需要幾個月才能得出結果。如果把這張表轉換成平衡樹結構，假設這棵樹有10層，那就只需要10次io開銷就能查詢到資料，速度以指數級別提公升。

所以假設當前資料表的資料為n，每個磁碟塊的資料項的數量是m，則有h=㏒(m+1)n，當資料量n一定的情況下，m越大，h越小；而m = 磁碟塊的大小 / 資料項的大小，磁碟塊的大小也就是乙個資料頁的大小，是固定的，如果資料項佔的空間越小，資料項的數量越多，樹的高度越低。這就是為什麼每個資料項，即索引欄位要盡量的小，比如int佔4位元組，要比bigint8位元組少一半。這也是為什麼b+樹要求把真實的資料放到葉子節點而不是內層節點，一旦放到內層節點，磁碟塊的資料項會大幅度下降，導致樹增高。當資料項等於1時將會退化成線性表。

講完聚集索引，接下來說一下非聚集索引，也就是我們平時經常用到的常規索引

非聚集索引和聚集索引一樣，同樣是採用平衡樹作為索引的資料結構。索引樹結構中各節點的值來自於表中的索引字段，假如給user表的name欄位加上索引，那麼索引就是由name欄位中的值構成，在資料改變時， dbms需要一直維護索引結構的正確性。如果給表中多個字段加上索引，那麼就會出現多個獨立的索引結構，每個索引（非聚集索引）互相之間不存在關聯。

非聚集索引和聚集索引的區別在於，通過聚集索引可以直接查詢到所需要的資料，而通過非聚集索引可以查詢到記錄對應的主鍵，然後再通過聚集索引查詢到所需要的記錄，查詢步驟如下圖：

無論採用哪種方式查詢表，最終都會通過聚集索引來定位資料，聚集索引（主鍵）是通往真實資料所在的唯一路徑。

然而，有一種例外可以不使用聚集索引就能查詢出所需要的資料，這種非主流的方法稱之為覆蓋索引查詢，也就是平時所說的復合索引或者多欄位索引查詢。文章上面的內容已經指出，當為字段建立索引以後，欄位中的內容會被同步到索引之中，如果為乙個索引指定兩個字段，那麼這個兩個欄位的內容都會被同步至索引之中。

先看下面這個sql語句

//建立索引

create index index_birthday on user_info(birthday);

//查詢生日在2023年11月1日出生使用者的使用者名稱

select user_name from user_info where birthday = '1991-11-1'

這句sql語句的執行過程如下

首先，通過非聚集索引index_birthday查詢birthday等於1991-11-1的所有記錄的主鍵id值

然後，通過得到的主鍵id值執行聚集索引查詢，找到主鍵id值對就的真實資料（資料行）儲存的位置

最後，從得到的真實資料中取得user_name欄位的值返回，也就是取得最終的結果

我們把birthday欄位上的索引改成雙字段的覆蓋索引

create index index_birthday_and_user_name on user_info(birthday, user_name);

這句sql語句的執行過程就會變為

通過非聚集索引index_birthday_and_user_name查詢birthday等於1991-11-1的葉節點的內容，然而，葉節點中除了有user_name表主鍵id的值以外， user_name欄位的值也在裡面，因此不需要通過主鍵id值的查詢資料行的真實所在，直接取得葉節點中user_name的值返回即可。通過這種覆蓋索引直接查詢的方式，可以省略不使用覆蓋索引查詢的後面兩個步驟，大大的提高了查詢效能。

下面的表總結了何時使用聚集索引或非聚集索引：

動作描述

使用聚集索引

使用非聚集索引

列經常被分組排序應應

返回某範圍內的資料應不應

乙個或極少不同值

不應不應

小數目的不同值應不應

大數目的不同值不應應

頻繁更新的列不應應

外來鍵列應

應主鍵列應應

頻繁修改索引列不應應

索引原理（平衡樹資料結構）

js資料結構平衡查詢樹

splay 文藝平衡樹資料結構

mysql 索引原理索引的資料結構

索引原理（平衡樹資料結構）

js資料結構 平衡查詢樹

splay 文藝平衡樹 資料結構

mysql 索引原理 索引的資料結構

相關推薦

js資料結構平衡查詢樹

splay 文藝平衡樹資料結構

mysql 索引原理索引的資料結構