B樹索引

  B-Tree索引是最多見的索引結構，默認建立的索引就是B-Tree索引。

1、B樹索引的結構

B-樹索引是基於二叉樹結構的。B-樹索引結構有3個基本組成部分：根節點、分支節點和葉子節點。其中根節點位於索引結構的最頂端，而葉子節點位於索引結構的最底端，中間爲分子節點。

    葉子節點（Leaf node）：包含條目直接指向表裏的數據行。

    分支節點（Branch node）：包含的條目指向索引裏其餘的分支節點或者是葉子節點。

    根節點（Branch node）：一個B樹索引只有一個根節點，它實際就是位於樹的最頂端的分支節點。

能夠用下圖一來描述B樹索引的結構。其中，B表示分支節點，而L表示葉子節點。

1.1關於分支節點塊（包括根節點塊）

一、 其所包含的索引條目都是按照順序排列的（缺省是升序排列，也能夠在建立索引時指定爲降序排列）。

二、 每一個索引條目（也能夠叫作每條記錄）都具備兩個字段。第一個字段表示當前該分支節點塊下面所連接的索引塊中所包含的最小鍵值；第二個字段爲四個字節，表示所連接的索引塊的地址，該地址指向下面一個索引塊。

三、 在一個分支節點塊中所能容納的記錄行數由數據塊大小以及索引鍵值的長度決定。好比從上圖一能夠看到，對於根節點塊來講，包含三條記錄，分別爲（0 B1）、（500 B2）、（1000 B3），它們指向三個分支節點塊。其中的0、500和1000分別表示這三個分支節點塊所連接的鍵值的最小值。而B一、B2和B3則表示所指向的三個分支節點塊的地址。

1.2關於葉子節點

一、 B樹索引的全部葉子塊必定位於同一層上，這是由B樹的數據結構定義的。Oracle 設計的B樹索引結構保證了B 樹索引從根到葉子都有相等的分支節點，保證了B樹索引的平衡，這樣就不會由於基表的數據插入後刪除操做形成B樹索引變得不平衡，從而影響索引的性能。所以，從根塊到達任何一個葉子塊的遍歷代價都是相同的； 索引高度是指從根塊到達葉子塊時所遍歷的數據塊的個數，一般，大多數的B樹索引的高度都是2到3，也就意味着，即便表中有上百萬條記錄，從索引中定位一個鍵字只須要2或3次I/O,索引越高，性能越差；

二、 葉子節點所包含的索引條目與分支節點同樣，都是按照順序排列的（缺省是升序排列，也能夠在建立索引時指定爲降序排列）

三、 每一個索引條目（也能夠 叫作每條記錄）也具備兩個字段。第一個字段表示索引的鍵值，對於單列索引來講是一個值；而對於多列索引來講則是多個值組合在一塊兒的。第二個字段表示鍵值所對應的記錄行的ROWID，該ROWID是記錄行在表裏的物理地址。ROWID 是惟一的Oracle 指針，指向該行的物理位置，使用ROWID 是Oracle 數據庫中訪問行最快的方法。參照Oracle中的rowid

四、 葉子節點實際上是一個雙向鏈表，每一個葉子節點包含一個指向下一個和上一個葉子點的指針，這樣在必定範圍內便利索引以搜索須要的記錄。

2、B樹索引的訪問

當oracle進程須要訪問數據文件裏的數據塊時，oracle會有兩種類型的I/O操做方式：
1） 隨機訪問，每次讀取一個數據塊（經過等待事件「db file sequential read」體現出來）。
2） 順序訪問，每次讀取多個數據塊（經過等待事件「db file scattered read」體現出來）。
第一種方式則是訪問索引裏的數據塊，而第二種方式的I/O操做屬於全表掃描。這裏順帶有一個問題，爲什麼隨機訪問會對應到db file sequential read等待事件，而順序訪問則會對應到db file scattered read等待事件呢？這彷佛反過來了，隨機訪問才應該是分散（scattered）的，而順序訪問才應該是順序（sequential）的。其實，等待事件主要根據實際獲取物理I/O塊的方式來命名的，而不是根據其在I/O子系統的邏輯方式來命名的。下面對於如何獲取索引數據塊的方式中會對此進行說明。
事實上在B樹索引雖然爲一個樹狀的立體結構，但其對應到數據文件裏的排列固然仍是一個平面的形式，也就是像下面這樣。
/根/分支/分支/葉子/…/葉子/分支/葉子/葉子/…/葉子/分支/葉子/葉子/…/葉子/分支/.....
所以，當oracle須要訪問某個索引塊的時候，勢必會在這個結構上跳躍的移動。
當oracle須要得到一個索引塊時，首先從根節點開始，根據所要查找的鍵值，從而知道其所在的下一層的分支節點，而後訪問下一層的分支節點，再次一樣根據鍵值訪問再下一層的分支節點，如此這般，最終訪問到最底層的葉子節點。能夠看出，其得到物理I/O塊時，是一個接着一個，按照順序，串行進行的。在得到最終物理塊的過程當中，咱們不能同時讀取多個塊，由於咱們在沒有得到當前塊的時候是不知道接下來應該訪問哪一個塊的。所以，在索引上訪問數據塊時，會對應到 db file sequential read等待事件，其根源在於咱們是按照順序從一個索引塊跳到另外一個索引塊，從而找到最終的索引塊的。
那麼對於全表掃描來講，則不存在訪問下一個塊以前須要先訪問上一個塊的狀況。全表掃描時，oracle知道要訪問全部的數據塊，所以惟一的問題就是儘量高效的訪問這些數據塊。所以，這時oracle能夠採用同步的方式，分幾批，同時獲取多個數據塊。這幾批的數據塊在物理上多是分散在表裏的，所以其對應到db file scattered read等待事件。

3、DML對B樹索引的影響

3.1 INSERT

在每一個INSERT操做過程當中，關鍵字必須被插入在正確葉節點的位置。若是葉節點已滿，不能容納更多的關鍵字，就必須將葉節點拆分。拆分的方法有兩種：

1)若是新關鍵字值在全部舊葉節點塊的全部關鍵字中是最大的，那麼全部的關鍵字將按照99:1的比例進行拆分，使得在新的葉節點塊中只存放有新關鍵字，而其餘的全部關鍵字（包括全部刪除的關鍵字）仍然保存在舊葉節點塊中。
2)若是新關鍵字值不是最大的，那麼全部的關鍵字將按照50:50的比例進行拆分，這時每一個葉節點塊（舊與新）中將各包含原始葉節點中的一半關鍵字。
這個拆分必須經過一個指向新葉節點的新入口向上傳送到父節點。若是父節點已滿，那麼這個父節點也必須進行拆分，而且須要將這種拆分向上傳送到父節點的父節點。這時，若是這個父節點也已滿，將繼續進行這個過程。這樣，某個拆分可能最終被一直傳送到根節點。若是根節點滿了，根結點也將進行分裂。根結點在進行分裂的時候，就是樹的高度增長的時候。根節點進行分裂的方式跟其餘的的節點分裂的方式相比較，在物理位置上的處理也是不一樣的。根節點分裂時，將原來的根結點分裂爲分支節點或葉節點，保存到新的塊中，而將新的根節點信息保存到原來的根結點塊中，這樣作的是爲由於避免修改數據字典所帶來的相對較大的開銷。
注意：如今Oracle都是採用了平衡算法，正常狀況下即便索引關鍵字不斷增大，也不會產生不平衡樹。當索引關鍵字不斷增大，致使樹級別單方向增加時，Oracle會自動進行索引翻轉以維持索引的平衡，固然這種操做很是消耗資源
在索引的每個層次之間，每個層最左邊的節點的block頭部都有一個指向下層最左邊的塊的指針，這樣有利於fast full scan 的快速定位最左邊的葉子節點。
每一個拆分過程都是要花費必定的開銷的，特別是要進行物理硬盤I/O動做。此外，在進行拆分以前，Oracle必須查找到一個空塊，用來保存這個拆分。能夠用如下步驟來進行查找空塊的動做：
1) 在索引的自由列表(free-list, 又稱爲空閒列表) 中查到一個空閒塊，能夠經過CREATE/ALTER INDEX命令爲一個索引定義多個空閒列表。索引空閒列表並不能幫助Oracle查找一個可用來存放將要被插入的新關鍵字的塊。這是由於關鍵字值不能隨機地存放在索引中可用的第一個「空閒」葉節點塊中，這個值必須通過適當的排序以後，放置在某個特定的葉節點塊中。只有在塊拆分過程當中才須要使用索引的空閒列表，每一個空閒列表都包含有一個關於「空」塊的連接列表。當爲某個索引定義了多個空閒列表時，首先將從分配給進程的空間列表中掃描一個空閒塊。若是沒有找到所須要的空閒塊，將從主空閒列表中進行掃描空閒塊的動做。
2) 若是沒有找到任何空閒塊，Oracle將試圖分配另外一個擴展段。若是在表空間中沒有更多的自由空間，Oracle將產生錯誤ORA-01654。
3) 若是經過上述步驟，找到了所需的空閒塊，那麼這個索引的高水位標(HWM)將加大。
4) 所找到的空閒塊將用來執行拆分動做。
在建立B*樹索引時，一個須要注意的問題就是要避免在運行時進行拆分，或者，要在索引建立過程當中進行拆分（「預拆分」），從而使得在進行拆分時可以快速命中，以便避免運行時插入動做。固然，這些拆分也不只僅侷限於插入動做，在進行更新的過程當中也有可能會發生拆分動做。

3.2 UPDATE

索引更新徹底不一樣於表更新，在表更新中，數據是在數據塊內部改變的（假設數據塊中有足夠的空間來容許進行這種改變）；但在索引更新中，若是有關鍵字發生改變，那麼它在樹中的位置也須要發生改變。請記住，一個關鍵字在B*樹中有且只有一個位置。所以，當某個關鍵字發生改變時，關鍵字的舊錶項必須被刪除，而且須要在一個新的葉節點上建立一個新的關鍵字。舊的表項有可能永遠不會被從新使用，這是由於只有在很是特殊的狀況下， Oracle纔會重用關鍵字表項槽，例如，新插入的關鍵字正好是被刪除的那個關鍵字（包括數據類型、長度等等）。（這裏重用的是塊，但徹底插入相同的值的時候，也不必定插入在原來的被刪除的位置，只是插入在原來的塊中，多是該塊中的一個新位置。也正由於如此，在索引塊中保存的的記錄可能並非根據關鍵字順序排列的，隨着update等的操做，會發生變化。）那麼，這種狀況發生的可能性有多大呢？許多應用程序使用一個數列來產生NUMBER關鍵字（特別是主關鍵字）。除非它們使用了RECYCLE選項，不然這個數列將不會兩次產生徹底相同的數。這樣，索引中被刪除的空間一直沒有被使用。這就是在大規模刪除與更新過程當中，表大小不斷減少或至少保持不變但索引不斷加大的緣由。

3.3 DELETE

當刪除表裏的一條記錄時，其對應於索引裏的索引條目並不會被物理的刪除，只是作了一個刪除標記。當一個新的索引條目進入一個索引葉子節點的時候，oracle會檢查該葉子節點裏是否存在被標記爲刪除的索引條目，若是存在，則會將全部具備刪除標記的索引條目從該葉子節點裏物理的刪除。
當一個新的索引條目進入索引時，oracle會將當前全部被清空的葉子節點（該葉子節點中全部的索引條目都被設置爲刪除標記）收回，從而再次成爲可用索引塊。
儘管被刪除的索引條目所佔用的空間大部分狀況下都可以被重用，但仍然存在一些狀況可能致使索引空間被浪費，並形成索引數據塊不少可是索引條目不多的後果，這時該索引能夠認爲出現碎片。而致使索引出現碎片的狀況主要包括：
一、不合理的、較高的PCTFREE。很明顯，這將致使索引塊的可用空間減小。
二、索引鍵值持續增長（好比採用sequence生成序列號的鍵值），同時對索引鍵值按照順序連續刪除，這時可能致使索引碎片的發生。由於前面咱們知道，某個索引塊中刪除了部分的索引條目，只有當有鍵值進入該索引塊時才能將空間收回。而持續增長的索引鍵值永遠只會向插入排在前面的索引塊中，所以這種索引裏的空間幾乎不能收回，而只有其所含的索引條目所有刪除時，該索引塊才能被從新利用。
三、常常被刪除或更新的鍵值，之後幾乎再也不會被插入時，這種狀況與上面的狀況相似。

4、總結

經過上面對B樹的分析，能夠得出如下的應用準則：
一、避免對那些可能會產生很高的更新動做的列進行索引。
二、避免對那些常常會被刪除的表中的多個列進行索引。如有可能，只對那些在這樣的表上會進行刪除的主關鍵字與/或列進行索引。若是對多個列進行索引是不可避免的，那麼就應該考慮根據這些列對錶進行劃分，而後在每一個這樣的劃分上執行TRUNCATE動做（而不是DELETE動做）。TRUNCATE在與 DROP STORAGE短語一同使用時，經過從新設置高水位標來模擬刪除表與索引以及從新建立表與索引的過程。
三、避免爲那些惟一度不高的列建立B*樹索引。這樣的低選擇性將會致使樹節點塊的稠密性，從而致使因爲索引「平鋪( flat)」而出現的大規模索引掃描。惟一性的程度越高，性能就越好，由於這樣可以減小範圍掃描，甚至可能用惟一掃描來取代範圍掃描。
4）空值不存儲在單列索引中。對於複合索引的方式，只有當某個列不空時，才須要進行值的存儲。在爲DML語句建立IS NULL或IS NOT NULL短語時，應該切記這個問題。
5）IS NULL不會致使索引掃描，而一個沒有帶任何限制的IS NOT NULL則可能會致使徹底索引掃描。

參考

B+樹索引

Oracle中B-TREE索引的深刻理解(原創)