索引與表一樣，也屬於段（segment）的一種。裡面存放了使用者的資料，跟表一樣需要佔用磁碟空間。只不過，在索引裡的資料存放形式與表裡的資料存放形式非常的不一樣。在理解索引時，可以想象一本書，其中書的內容就相當於表裡的資料，而書前面的目錄就相當於該表的索引。同時，通常情況下，索引所佔用的磁碟空間要比表要小的多，其主要作用是為了加快對資料的搜尋速度。

但是，索引作為一種可選的資料結構，你可以選擇為某個表裡的建立索引，也可以不建立。這是因為一旦建立了索引，就意味著oracle對錶進行DML（包括INSERT、UPDATE、DELETE）時，必須處理額外的工作量（也就是對索引結構的維護）以及儲存方面的開銷。所以建立索引時，需要考慮建立索引所帶來的查詢效能方面的提高，與引起的額外的開銷相比，是否值得。

B樹索引是一個典型的樹結構，始終是平衡的，也就是說從Root節點到 Leaf 節點的任何一個路徑都是等距離的。其包含的主要是：

葉子節點（Leaf node）：包含條目直接指向表裡的資料行。

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

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

對於分支節點塊（包括根節點塊）來說，其所包含的索引條目都是按照順序排列的（可以指定reverse，倒序）。每個索引條目（也可以叫做每條記錄）都具有兩個欄位。第一個欄位表示當前該分支節點塊下面所連結的索引塊中所包含的最小鍵值（按B+tree最小鍵值複製原則）；第二個欄位為四個位元組，表示所連結的索引塊的地址，該地址指向下面一個索引塊。在一個分支節點塊中所能容納的記錄行數由資料塊大小以及索引鍵值的長度決定。

對於葉子節點塊來說，其所包含的索引條目與分支節點一樣，都是按照順序排列的（預設是升序排列，也可以在建立索引時指定為降序排列）。每個索引條目（也可以叫做每條記錄）也具有兩個欄位。第一個欄位表示索引的鍵值，對於單列索引來說是一個值；而對於多列索引來說則是多個值組合在一起的。第二個欄位表示鍵值所對應的記錄行的ROWID，該ROWID是記錄行在表裡的實體地址。在葉子節點中，每個索引條目都會在資料塊中佔一行空間。每一行用2到3個位元組作為行頭，行頭用來存放標記以及鎖定型別等資訊。同時，在第一個表示索引的鍵值的欄位中，每一個索引列都有1個位元組表示資料長度，後面則是該列具體的值。

下面分別把分支節點的索引結構和葉子節點的索引資訊dump出來

建立測試資料

[sql]

sys@ORCL> select * from v$version where rownum=1;

BANNER

----------------------------------------------------------------

Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod

sys@ORCL> drop table tt purge;

drop table tt purge

*

ERROR at line 1:

ORA-00942: table or view does not exist

sys@ORCL> create table tt as select * from dba_objects;

Table created.

sys@ORCL> select count(*) from tt;

COUNT(*)

----------

50356

sys@ORCL> insert into tt select * from tt;

50356 rows created.

sys@ORCL> commit;

Commit complete.

sys@ORCL> select count(*) from tt;

COUNT(*)

----------

100712

sys@ORCL> create index btree_tt on tt(object_name);

Index created.

檢視索引的Blevel、height（blevel：節點的深度。root位於第0層，以此類推。height=blevel+1）

[sql]

sys@ORCL> select index_name,blevel from dba_indexes where index_name='BTREE_TT';

INDEX_NAME BLEVEL

------------------------------ ----------

BTREE_TT 2

sys@ORCL> analyze index btree_tt validate structure;

Index analyzed. sys@ORCL> select name,height from index_stats where name='BTREE_TT';

NAME HEIGHT

------------------------------ ----------

BTREE_TT 3

獲得btree_tt的物件號，進行索引結構的dump

[sql]

sys@ORCL> select object_id from dba_objects where owner='SYS' and object_name='BTREE_TT';

OBJECT_ID

----------

52614

sys@ORCL> oradebug setmypid

Statement processed.

sys@ORCL> alter session set events 'immediate trace name treedump level 52614';

Session altered.

sys@ORCL> oradebug tracefile_name

/u01/app/oracle/admin/orcl/udump/orcl_ora_5234.trc

檢視treedump trc檔案

[sql]

----- begin tree dump

branch: 0x40efaa 4255658 (0: nrow: 2, level: 2)

branch: 0x40f603 4257283 (-1: nrow: 247, level: 1)

leaf: 0x40efab 4255659 (-1: nrow: 182 rrow: 182)

leaf: 0x40efac 4255660 (0: nrow: 182 rrow: 182)

leaf: 0x40efad 4255661 (1: nrow: 186 rrow: 186)

leaf: 0x40efae 4255662 (2: nrow: 189 rrow: 189)

leaf: 0x40efaf 4255663 (3: nrow: 186 rrow: 186)

leaf: 0x40efb0 4255664 (4: nrow: 190 rrow: 190)

leaf: 0x40efb1 4255665 (5: nrow: 185 rrow: 185)

leaf: 0x40efb2 4255666 (6: nrow: 179 rrow: 179)

leaf: 0x40efb3 4255667 (7: nrow: 187 rrow: 187)

leaf: 0x40efb4 4255668 (8: nrow: 181 rrow: 181)

............................................

branch: 0x40f6fb 4257531 (0: nrow: 248, level: 1)

leaf: 0x40f602 4257282 (-1: nrow: 228 rrow: 228)

leaf: 0x40f604 4257284 (0: nrow: 226 rrow: 226)

leaf: 0x40f605 4257285 (1: nrow: 224 rrow: 224)

leaf: 0x40f606 4257286 (2: nrow: 223 rrow: 223)

leaf: 0x40f607 4257287 (3: nrow: 217 rrow: 217)

leaf: 0x40f608 4257288 (4: nrow: 253 rrow: 253)

leaf: 0x40f609 4257289 (5: nrow: 232 rrow: 232)

............................................

leaf: 0x40f6f8 4257528 (244: nrow: 191 rrow: 191)

leaf: 0x40f6f9 4257529 (245: nrow: 181 rrow: 181)

leaf: 0x40f6fa 4257530 (246: nrow: 99 rrow: 99)

----- end tree dump

解釋trc檔案

每一行第一列表示：節點型別，branch是分支節點（包括了根節點），而leaf則是葉子節點

第二列表示：節點地址，16進位制

第三列表示：節點地址，10進位制

第四列表示：相對於前一個節點的位置：根節點從0算起，其他分支節點和葉子節點從1開始算

第五列表示：（nrow）當前節點所含索引條目的數量（包括delete的條目）

第六列表示：（level）分支節點的層級，在oracle的索引中，層級號是倒過來的，也就是說假設某個索引有N層，則根節點的層級號為N，而根節點下一層的分支節點的層級號為N-1

第七列表示：（rrow）有效的索引條目的數量，因為索引條目如果被刪除，不會立即被清除出索引塊中。所以nrow減rrow的數量就表示已經被刪除的索引條目數量

上面這種方式以樹狀形式轉儲整個索引。同時，我們可以轉儲一個索引節點來看看其中存放了些什麼。

下面轉儲根節點的索引塊內容。

從trc檔案可知：根節點branch: 0x40efaa 4255658 (0: nrow: 2, level: 2)

[sql]

sys@ORCL> select dbms_utility.data_block_address_file(4255658 ) fno，

2 dbms_utility.data_block_address_block(4255658 ) bno

3 from dual;

FNO BNO

---------- ----------

1 61354

sys@ORCL> alter system dump datafile 1 block 61354;

System altered.

sys@ORCL> oradebug tracefile_name

/u01/app/oracle/admin/orcl/udump/orcl_ora_5234.trc

檢視root節點的trc內容

[sql]

header address 230057028=0xdb66444

kdxcolev 2

KDXCOLEV Flags = - - -

kdxcolok 0

kdxcoopc 0x80: opcode=0: iot flags=--- is converted=Y

kdxconco 2

kdxcosdc 0

kdxconro 1

kdxcofbo 30=0x1e

kdxcofeo 8026=0x1f5a

kdxcoavs 7996

kdxbrlmc 4257283=0x40f603

kdxbrsno 0

kdxbrbksz 8056

kdxbr2urrc 0

row#0[8026] dba: 4257531=0x40f6fb

col 0; len 18; (18): 41 4c 4c 5f 43 4f 4c 5f 50 52 49 56 53 5f 4d 41 44 45

col 1; len 6; (6): 00 40 ee c5 00 2c

----- end of branch block dump -----

kdxcolev 表示：索引層級號，我們這個例子中，根節點的level是2，葉子該是0

kdxcolok 表示：該索引上是否有DML活動事務

kdxconco 表示：索引條目中列的數量

kdxcosdc 表示：索引結構發生變化的數量，當你修改某個索引鍵值時，該值加1

kdxconro 表示：當前索引節點中索引條目的數量

kdxcofbo 表示：當前索引節點從第幾個位元組開始記錄

kdxcofeo 表示：當前索引節點可用空間的最尾端在哪個位元組

kdxcoavs 表示：當前索引節點可用空間總量。也就是kdxcofeo - kdxcofbo 的值

kdxbrlmc 表示：分支節點的位置

kdxbrsno 表示：最後一個被修改的索引條目號，這裡為0，表明是新建索引

kdxbrbksz 表示：可用資料塊大小，從這裡我們可以知道，即便pctfree為0，對於8k資料塊，我們也不能完全用完

[sql]

row#0[8026] dba: 4257531=0x40f6fb

col 0; len 18; (18): 41 4c 4c 5f 43 4f 4c 5f 50 52 49 56 53 5f 4d 41 44 45

col 1; len 6; (6): 00 40 ee c5 00 2c

這部分內容就是根節點裡面記錄的索引條目，總共1行（在B+樹的定義裡，如果按最小關鍵碼複寫原則，則樹中每個非葉子節點中有m棵子樹必有m-1個關鍵碼）。每個索引條目都指向一個分支節點，其中，col 1表示所連結的分支節點的地址，如果根節點下沒有其他的分支節點，則col 1為TERM；col 0表示該分支節點所連結的最小鍵值。注意一點，這裡的col 0; len 18; (18):--列的行號，從0開始，緊接著的就是列的長度以及列的值，那麼這個值稱之為separator key,這個separator key 可以區分真實的索引值，所以從這裡我們也知道 branch block不會儲存完整的索引值，只要能區分就行。也就是說，Oracle在 Branch block中只記錄索引鍵值的字首，而不是所有值，是因為這樣可以節約空間，從而能夠儲存更多的索引條目。同時，我們也能理解了為什麼查詢使用 like '%xxx' 這種方法不會走Btree 索引，因為Branch block 儲存的是字首。

下面轉儲葉子節點塊的內容

隨便選一葉：leaf: 0x40f6fa 4257530 (246: nrow: 99 rrow: 99)

[sql]

sys@ORCL> select dbms_utility.data_block_address_file(4257530) fno,

2 dbms_utility.data_block_address_block(4257530) bno

3 from dual;

FNO BNO

---------- ----------

1 63226

sys@ORCL> oradebug setmypid

Statement processed.

sys@ORCL> alter system dump datafile 1 block 63226；

sys@ORCL> oradebug tracefile_name

/u01/app/oracle/admin/orcl/udump/orcl_ora_6177.trc

葉子節點的部分內容摘入如下：

[sql]

Block header dump: 0x0040f6fa

Object id on Block? Y

seg/obj: 0xcd86 csc: 0x00.a3506 itc: 2 flg: - typ: 2 - INDEX

fsl: 0 fnx: 0x0 ver: 0x01

Itl Xid Uba Flag Lck Scn/Fsc

0x01 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000

0x02 0xffff.000.00000000 0x00000000.0000.00 C--- 0 scn 0x0000.000a3506

Leaf block dump

===============

header address 221234268=0xd2fc45c

kdxcolev 0

KDXCOLEV Flags = - - -

kdxcolok 0

kdxcoopc 0x80: opcode=0: iot flags=--- is converted=Y

kdxconco 2

kdxcosdc 0

kdxconro 99

kdxcofbo 234=0xea

kdxcofeo 4692=0x1254

kdxcoavs 4458

kdxlespl 0

kdxlende 0

kdxlenxt 0=0x0

kdxleprv 4257529=0x40f6f9

kdxledsz 0

kdxlebksz 8032

row#0[7992] flag: ------, lock: 0, len=40

col 0; len 30; (30):

73 75 6e 2f 74 6f 6f 6c 73 2f 74 72 65 65 2f 53 77 69 74 63 68 53 74 61 74

65 6d 65 6e 74

col 1; len 6; (6): 00 40 f3 25 00 0a

row#1[7953] flag: ------, lock: 0, len=39

col 0; len 29; (29):

73 75 6e 2f 74 6f 6f 6c 73 2f 74 72 65 65 2f 54 68 69 73 45 78 70 72 65 73

73 69 6f 6e

col 1; len 6; (6): 00 40 f0 74 00 31

row#2[7914] flag: ------, lock: 0, len=39

col 0; len 29; (29):

73 75 6e 2f 74 6f 6f 6c 73 2f 74 72 65 65 2f 54 68 69 73 45 78 70 72 65 73

73 69 6f 6e

col 1; len 6; (6): 00 40 f0 74 00 32

............................

row#97[4727] flag: ------, lock: 0, len=35

col 0; len 25; (25):

79 43 62 43 72 53 75 62 53 61 6d 70 6c 69 6e 67 54 79 70 65 31 37 30 5f 54

col 1; len 6; (6): 00 40 f1 f1 00 0c

row#98[4692] flag: ------, lock: 0, len=35

col 0; len 25; (25):

79 43 62 43 72 53 75 62 53 61 6d 70 6c 69 6e 67 54 79 70 65 31 37 30 5f 54

col 1; len 6; (6): 00 40 f4 a2 00 10

----- end of leaf block dump -----

和分支節點不同的值解析如下：

kdxlespl 表示：當葉子節點被拆分時，未提交的事務數量

kdxlende 表示：被刪除的索引條目數量

kdxlenxt 表示：當前葉子節點的下一個葉子節點的地址

kdxlprv 表示：當前葉子節點的上一個葉子節點的地址

kdxledsz 表示：被刪除的空間

轉儲檔案中接下來的部分就是索引條目部分。lock: 0 表示ITL中的鎖資訊 0表示沒有被鎖；len ：表示索引值長度；flag 表示標記，如刪除標記等。col 表示列號，從0開始那麼接下來就是索引的鍵值以及 rowid中後三部分（相對檔案號、塊號、行號）即：col 0 是鍵值， col 1 是rowid。

也就是說，Leaf節點主要儲存了完整的索引鍵值，以及相關索引鍵值的部分rowid(這個rowid去掉了data object number部分)，同時leaf 節點還儲存了2個指標(DBA)，他們分別指向上一個leaf節點以及下一個leaf節點.這樣葉子節點便是雙向連結串列的結構。我們看到前面對B樹索引的體系結構的描述，可以知道其為一個樹狀的立體結構。但對應到資料檔案裡的排列當然還是一個平面的形式，也就是像下面這樣。因此，當oracle需要訪問某個索引塊的時候，勢必會在這個結構上跳躍的移動。

/根/分支/分支/葉子/…/葉子/分支/葉子/葉子/…/葉子/分支/葉子/葉子/…/葉子/分支/.....

當oracle需要獲得一個索引塊時，首先從根節點開始，根據所要查詢的鍵值，從而知道其所在的下一層的分支節點，然後訪問下一層的分支節點，再次同樣根據鍵值訪問再下一層的分支節點，如此這般，最終訪問到最底層的葉子節點。可以看出，其獲得物理I/O塊時，是一個接著一個，按照順序，序列進行的。在獲得最終物理塊的過程中，我們不能同時讀取多個塊，因為我們在沒有獲得當前塊的時候是不知道接下來應該訪問哪個塊的。因此，在索引上訪問資料塊時，會對應到db file sequential read等待事件，其根源在於我們是按照順序從一個索引塊跳到另一個索引塊，從而找到最終的索引塊的。

淺析oracle b-tree index搜尋原理

相關文章