理解 B*tree index內部結構,tree內部結構

來源:互聯網
上載者:User

理解 B*tree index內部結構,tree內部結構


轉載請註明出處:http://write.blog.csdn.net/postedit/40589651


    Oracle資料庫裡的B樹索引就好象一棵倒長的樹,它包含兩種類型的資料區塊:一種是索引分支塊,另一種是索引葉子塊 索引分支塊包含指向相應索引分支塊/葉子塊的指標和索引健值列(這裡的指標是指相關分支塊/葉子塊的塊地址RDBA。


      每個索引分支塊都會有兩種類型的指標,一種是LMC,另一種就索引分支的索引行記錄所記錄的指標.lmc是Left Most Child的縮寫,每個索引分支塊都只有一個lmc,這個lmc指向的分支塊/葉子塊中所有索引索引值列中的最大值一定小於該lmc所在過引索分支塊的所有索引索引值列中的最小值;而索引分支塊的索引行記錄所記錄的指標所指向的分支塊/葉子塊的所有索引索引值列中的最小值一定大於或等於該行記錄的索引索引值列的值)。


      注意:這個索引值列不一定是完整的被索引索引值,它可能只是被索引索引值的首碼。只要Oracle能通過這些首碼區分相應的索引分支塊/葉子塊就行,這樣Oracle就能夠既節省索引分支的儲存空間,又可以快速定位其下層的索引分支塊/葉塊。

   事實上,如果使用準確的名字來描述關係型資料庫中的B-Tree索引,並不能稱其為B-Tree索引,而應當稱其為B*-Tree索引。
   由於沒有必要非常準確的學名,所以一般都使用它的廣義名稱。T-tree索引的結構就像它的名字所表述的意思那樣類似一個樹結構,從樹榦開始依次向樹枝蔓延,直到樹葉。
 
  有人認為是Binary的首字母
  有人認為是最早提出該理論的那個人的名字縮寫
  但更普遍的說法是它是單詞“balanced”的首字母縮寫---均衡

分支塊頭部中的“Lmc”是指比分支塊中的第一行資料值小的下層資料區塊的地址(DBA),使用這種表示方法不僅可以減少塊中的所要儲存行的數量,而且還能表示“未滿”的意思。這裡的“未滿”是指位於該分支塊左邊的索引中的值都小於這個分支塊中第一行中的值。分枝塊中的“Term”代表下層索引塊中一部分沒有被描述的列值,在這裡只是為了簡化問題,它有點類似於在比較子LIKE中可以把 ‘ABC%’簡寫為‘ABC’。


   看下面的索引結構圖:

 

/+*drop table gyj_t1;create table gyj_t1 (id int,name varchar2(100));begin  for i in  1 .. 5000 loop   insert into gyj_t1 values(i,'gyj'||i);    commit; end loop; end;/非唯一索引create index idx_gyj_t1 on gyj_t1(id);唯一索引drop index idx_gyj_t1;create unique index idx_gyj_t1 on gyj_t1(id);gyj@ZMDB> select object_id from dba_objects where object_name='IDX_GYJ_T1'; OBJECT_ID----------     24515gyj@ZMDB> select header_file,header_block from dba_segments where segment_name='IDX_GYJ_T1';HEADER_FILE HEADER_BLOCK----------- ------------          7         2618+/



 ALTER SESSION SET EVENTS 'immediate trace name treedump level 24515';
 

 ----- begin tree dump
branch: 0x1c00a3b 29362747 (0: nrow: 110, level: 1)
          --DBA(16進位,10進位)
         starting at –1 except root starting at 0
         nrow: 110個branck或leaf
         level : branch block level (leaf block implicitly 0)
           root block split(通常是level發生改變了),branch block split,leaf block split(5-5,9-1)
         high=level+1

   leaf: 0x1c00a3c 29362748 (-1: nrow: 485 rrow: 485)
                            除了root其它的都是從-1開始,
                            nrow:  number of all index entries (including deleted entries)
                            rrow:  number of current index entries
                            level: leaf block implicitly 0
----- end tree dump




*********************************************************************************************轉儲枝塊
 alter system dump datafile 7 block 2619;
 
Branch block dump
=================
header address 139782541810252=0x7f21a8c01a4c
kdxcolev 1                   +++index level (0 represents leaf blocks)level為1,
                             表示這是一個branch block >0 (root block)
KDXCOLEV Flags = - - -
kdxcolok 0                   ++++++denotes whether structural block transaction is occurring
                             表示該索引上是否正在發生修改塊結構的事務;
kdxcoopc 0x80: opcode=0: iot flags=--- is converted=Y     +++internal operation code 表示Oracle內部作業碼
kdxconco 2                   +++index column count 表示索引條目中列的數量
kdxcosdc 0                +++count of index structural changes involving block
                          表示索引結構發生變化的數量,當你修改表裡的某個索引索引值時,該值增加;
kdxconro 109               +++number of index entries (does not include kdxbrlmc pointer)
                           表示當前索引中的條目數量,不包括lmc指標
kdxcofbo 246=0xf6         +++offset to beginning of free space within block
kdxcofeo 6987=0x1b4b     +++offset to the end of free space (i.e.. first portion of block containing index data)
kdxcoavs 6741            +++available space in block (effectively area between kdxcofbo and kdxcofeo)
kdxbrlmc 29362748=0x1c00a3c    +++block address if index value is less than the first (row#0) value
kdxbrsno 0                     +++last index entry to be modified
                               表示最後一個被修改的索引第目號,這裡看到是0,表示該索引是建立的索引
kdxbrbksz 8056                 +++size of usable block space 表示可用資料區塊的空間大小
kdxbr2urrc 0                   +++這裡在Oracle內部文檔中沒有說明,我通過bbed觀察沒有發現這個結構

row#0[8047] dba: 29362749=0x1c00a3d
col 0; len 3; (3):  c2 05 57
col 1; TERM
row#1[8038] dba: 29362750=0x1c00a3e
col 0; len 3; (3):  c2 0a 42
col 1; TERM


sys@ZMDB> select UTL_RAW.CAST_TO_NUMBER ('c20557') from dual;

UTL_RAW.CAST_TO_NUMBER('C20557')
--------------------------------
                             486    (nrow: 485)


sys@ZMDB> select UTL_RAW.CAST_TO_NUMBER ('c20a42') from dual;

UTL_RAW.CAST_TO_NUMBER('C20A42')
--------------------------------
                             965  (nrow: 479 ==>  486+479)



********************************************************************************轉儲葉塊
alter system dump datafile 7 block 2620;

Leaf block dump
===============
header address 140046263134820=0x7f5f0fc42a64
kdxcolev 0                +++index level (0 represents leaf blocks)
KDXCOLEV Flags = - - -
kdxcolok 0             +++denotes whether structural block transaction is occurring(表示結構塊事務是否正在發生)
kdxcoopc 0x80: opcode=0: iot flags=--- is converted=Y    +++internal operation code
kdxconco 2                    +++index column count
kdxcosdc 0                    +++count of index structural changes involving block(包含塊的索引結構化改變數目
)
kdxconro 485                  +++number of index entries (does not include kdxbrlmc pointer)
kdxcofbo 1006=0x3ee           +++offset to beginning of free space within block
kdxcofeo 1830=0x726           +++offset to the end of free space (i.e.. first portion of block containing index data)
kdxcoavs 824                  +++available space in block (effectively area between kdxcofbo and kdxcofeo)
kdxlespl 0                    +++bytes of uncommitted data at time of block split that have been cleaned out
                                    表示當葉子節點被拆分時未提交的事務數量
kdxlende 0                    +++number of deleted entries
                               表示被刪除的索引條目的數量
kdxlenxt 29362749=0x1c00a3d   +++pointer to the next leaf block in the index structure via corresponding rba
                              表示當前葉子節點的下一個葉子節點的地址
kdxleprv 0=0x0                +++pointer to the previous leaf block in the index structure via corresponding
                              表示當前葉子節點的上一個葉子節點的地址
kdxledsz 0                    +++deleted space 表示可用空間,目前是0
kdxlebksz 8032                +++usable block space (by default less than branch due to the additional ITL entry)
row#0[8020] flag: ------, lock: 0, len=12  +++row header(1byte)+flag (2byte) +lock (1byte) + col 8 = 12
                                  +++其中flag表示標記,比如刪除標記等,lock表示鎖定資訊
col 0; len 2; (2):  c1 02                  +++索引索引值
col 1; len 6; (6):  01 c0 00 87 00 00      +++檔案號(2byte)+塊號(2byte)+行號(2byte)
row#1[8008] flag: ------, lock: 0, len=12
col 0; len 2; (2):  c1 03
col 1; len 6; (6):  01 c0 00 87 00 01


gyj@ZMDB> select id,name,dbms_rowid.rowid_relative_fno(rowid) file#,dbms_rowid.rowid_block_number(rowid) block#,dbms_rowid.rowid_row_number(rowid) row# from gyj_t1 where id=1;

        ID NAME            FILE#     BLOCK#       ROW#
---------- ---------- ---------- ---------- ----------
         1 gyj1                7        135          0

0x01 c0 00 87 00 00===>檔案號:01 c0  塊號:00 87   行號:00 00


。。。。。。。。。。。。。。。。。。。。。。

 


問一下ORACLE的位元影像索引與B*tree索引的實現原理是怎的?

1、文法
create bitmap index index_name on 表名(欄位);
2、舉個例子你就能明白了:
如有表 test(id,name,address)
資料
(1,張三,大連)
(2,李四,天津)
(3,王五,北京)
(4,趙六,大連)
....

類似這樣的資料,如果查詢的時候用到 ,因為資料庫中有很多這樣的資料,所以一般的索引起不到查詢加速的作用,而建立位元影像索引後會產生如下點陣圖效果:
假設有4條資料(就如上所示)

大連 天津 北京
1 0 0
0 1 0
0 0 1
1 0 0

這樣當查詢:
select * from 表 where address='大連' or address='北京';
的時候資料庫很快就能根據 同行的 1和0 判斷出那一條資料符合要求。

---
以上,希望對你有所協助。
 
BSTree *tree; BSTree tree;他們的不同在哪?下面的是定義一個結構體類型的指標那BSTree *tree;是什

如果BSTNode表示一個果子
BSTress就表示有一個果子以上的果樹
tree表示有一個果樹以上的果圓

tree表示指向指標的指標
 

相關文章

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.