[轉]:bitmap索引和B*tree索引分析
11.3 B-樹 索引
儘管Oracle中所有的索引都使用B-樹結構,但是B-樹索引這一術語通常是指如圖11-1所示的索引。
圖11-1
根據圖11-1所示:索引的頂端是根結點,這一結點中包含的是存有指向索引中下一級指標的項。接下來是分枝結點(塊),分枝結點中的記錄(項)存的是指向下一級(塊)的指標。最底層為葉子結點。在葉子結點存有指向表中資料行的索引項。葉子結點被雙向連結串列鏈在一起以方便按索引關鍵字的升序或降序掃描。
介紹完了B-樹索引的整體結構,現在來介紹索引葉子結點的索引項(記錄)的內部結構。索引項(記錄)是由三部分組成的,它們是:
Ø 索引項頭(Entry Header):儲存了行數和鎖的資訊。
Ø 索引列長度和值:必須成對出現,它定義了列的長度,緊跟在長度之後的就是列的值。
Ø ROWID:指向表中資料行的ROWID。
在非分割槽表上B-樹索引中的葉子結點的索引項(記錄)具有如下的特性:
Ø 如果具有相同索引鍵值的資料行有多行而且索引沒有被壓縮,索引鍵值會重複存放。
Ø 所有索引所在列的值為空(NULL)的資料行,Oracle將不儲存與之對應的索引項。因此,如果在WHERE子句中索引所在列的值為NULL,Oracle將不使用索引而進行全表掃描。
Ø 用於指向資料行的是限制性ROWID,因為所有的資料行都屬於相同的段。在索引項使用限制性ROWID的好處是節省了索引的儲存空間。
當對錶進行DML操作時,Oracle伺服器將自動地維護基於該表的全部索引。其維護的方法如下:
Ø 當對錶進行插入(INSERT)操作時,在對應的索引資料塊中插入一行索引項。
Ø 當對錶進行刪除(DELETE)操作時,Oracle伺服器僅對索引項進行邏輯刪除操作。即僅在所刪除的索引項上加一個標記並不真正地刪除這一項,而只有等該塊中所有的項都被刪除後才真正地刪除它們。
Ø 當對錶進行修改(UPDATE)操作時,Oracle伺服器實際上對索引進行的是兩個操作,一個是邏輯刪除操作而另一個是插入操作。
介紹完了B-樹索引,下面我們將開介紹Oracle中可能經常使用的另一種索引的結構,點陣圖索引。
11.4 點陣圖索引
與B-樹索引相比,在某些情況下點陣圖索引具有更多的優勢。點陣圖索引也是一種B-樹結構,但是點陣圖索引的葉子結點存的不是ROWID而是每一個鍵值的點陣圖。以下圖11-2就是點陣圖索引的一個結構示意圖。
圖11-2
根據圖11-2所示:點陣圖中的每一位對應著一個可能的ROWID,如果這一位被置位就意味著ROWID所對應的行中包含鍵值。其中點陣圖索引的葉子結點包含了如下部分:
Ø 索引項頭(Entry Header):儲存了行數和鎖的資訊。
Ø 鍵值(Key Values):由索引列的長度和值所組成。在圖11-2的例子中,索引鍵僅由一列所組成,並且它的最後一個索引項的鍵值為“壯士”。
Ø 起始ROWID:為點陣圖的起始地址,即點陣圖中第一行的ROWID。包括相對檔案號,在相對檔案中的塊號,和塊中的行號。
Ø 終止ROWID:為點陣圖的終止地址,即點陣圖中最後一行的ROWID。也包括相對檔案號,在相對檔案中的塊號,和塊中的行號。
Ø 點陣圖段(Bitmap segment):是由一串位所組成的。如果某一位置位(為1),就表示該位所對應的行包含索引的鍵值。如果該位沒有被置位(為0),就表示該位所對應的行不包含索引的鍵值。Oracle伺服器使用一個有專利的壓縮技術對點陣圖段進行壓縮之後再儲存,所以點陣圖索引可能會節省大量的儲存空間。
下面我們按照圖11-2所示的點陣圖,給出一個實用的解釋:
請看鍵值為學士的第一行:
點陣圖是從第4號檔案的第14(資料)塊的第0行開始到第4號檔案的第16(資料)塊的第8行結束。點陣圖中的第一行記錄為學士(因為點陣圖中相應位是1),第二行不是學士,第三行也不是,第四行也不是,但第五行是,以此類推。
接下來請看鍵值為壯士的最後一行:
點陣圖也是從第4號檔案的第14(資料)塊的第0行開始到第4號檔案的第16(資料)塊的第8行結束。點陣圖中的第一行記錄不是壯士(因為點陣圖中相應位是0,其實該行已經是學士了當然也就不可能再是壯士了),第二行不是壯士(因為該行已經是博士了當然也就不可能再是壯士了),第三行才是壯士(因為點陣圖中相應位是1),以此類推。
如果讀者對此感興趣,可以使用上述更加詳細地方法分析圖11-2所示的點陣圖。
11.5 B-樹索引和點陣圖索引的比較
介紹了這麼多的B-樹索引和點陣圖索引,那麼這兩種索引之間究竟有哪些差別呢?表11-1給出了它們比較結果的一個總結。
表11-1
下面我們來詳細解釋圖表11-1給出的結論。我曾查閱了幾本英語字典想找到cardinality的確切中文意思,但是沒找到一個令我滿意的答案。在這裡low-cardinality的含義就是列的值可以列舉,如性別和婚姻狀況,以及我們例子中的學位。而high-cardinality的含義就是列的值很難列舉,如人名等。
從上一節所介紹的點陣圖索引的儲存結構可知:對於low-cardinality的列使用點陣圖索引要比B-樹索引緊湊得多,從而節省大量的磁碟空間,這也就減少了輸入/輸出量,也達到了提高系統效率的效果。
另外,由於點陣圖索引所需要的儲存空間要比B-樹索引的小得多,所以一般Oracle伺服器在使用點陣圖索引時將整個點陣圖索引段裝入記憶體中。這實際上是將一個在磁碟上的搜尋過程變成了一個記憶體查詢過程,從而大大地提高了系統的效率。Oracle是用初始化引數檔案中的引數CREATE_BITMAP_AREA_SIZE來定義這個記憶體區的大小的。其預設值為8 MB。
讀者要注意的是:在圖表11-1中所說的B-樹索引對關建字列的修改相對不算昂貴,並不是真的不昂貴,只是與點陣圖索引相比較才不算昂貴,其實DML操作對任何型別的索引都很昂貴。在點陣圖索引中修改鍵值列(索引列)需要使用段一級的鎖,而B-樹索引是使用的行一級的鎖,還有在這種情況下可能要調整點陣圖。因此在點陣圖索引中對關建字列的修改是非常昂貴。
在對點陣圖索引進行邏輯操作時,Oracle伺服器使用的是位操作,因此點陣圖索引進行邏輯操作效率是非常高的。
最後的結論是:B-樹索引可能更適合於聯機事務處理(OLTP)系統,因為在聯機事務處理系統中DML操作頻繁。點陣圖索引可能更適合於資料倉儲(Data Warehouse)系統,因為在資料倉儲系統中表一般都較大但是為靜態的並且查詢較為複雜。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/12932950/viewspace-264924/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 【索引】Bitmap點陣圖索引與普通的B-Tree索引鎖的比較索引
- 【Bitmap Index】B-Tree索引與Bitmap點陣圖索引的鎖代價比較研究Index索引
- Oracle中B-Tree、Bitmap和函式索引使用案例總結Oracle函式索引
- 關於B*tree索引(index)的中度理解及bitmap 索引的一點探究(zt)索引Index
- B-Tree索引與Bitmap點陣圖索引的鎖代價比較研究索引
- MySQL Hash索引和B-Tree索引的區別MySql索引
- oracle的B-tree索引結構分析Oracle索引
- 轉儲B*Tree索引的分枝結構索引
- PostgreSQL的B-tree索引SQL索引
- 如何轉儲B*Tree索引的分枝結構(轉)索引
- 點陣圖索引(Bitmap Index)——從B*樹索引到點陣圖索引索引Index
- MySQL探索(一):B-Tree索引MySql索引
- 平衡樹索引(b-tree index)索引Index
- PG 12-2 B-Tree 索引 分析 分裂 level = 1索引
- MySQL 效能優化——B+Tree 索引MySql優化索引
- B-tree and Bitmap IndexIndex
- 點陣圖索引(Bitmap Index)——索引共用索引Index
- BITMAP索引的INLIST ITERATOR與BITMAP OR索引
- 索引組織表上建立BITMAP索引(三)索引
- 索引組織表上建立BITMAP索引(二)索引
- 索引組織表上建立BITMAP索引(一)索引
- _b_tree_bitmap_plans引數
- BITMAP索引異常增大索引
- Oracle表與索引的分析及索引重建(轉)Oracle索引
- B樹索引和點陣圖索引的結構介紹索引
- 分割槽索引和全域性索引(轉載)索引
- oracle 點陣圖索引(bitmap index)Oracle索引Index
- 點陣圖索引:原理(BitMap index)索引Index
- 點陣圖索引(bitmap-index)索引Index
- 物化檢視上使用bitmap索引索引
- oracle 表分析和索引Oracle索引
- 跳槽必看MySQL索引:B+樹原理揭秘與索引優缺點分析MySql索引
- [轉]Oracle分割槽索引--本地索引和全域性索引比較Oracle索引
- Oracle分割槽索引--本地索引和全域性索引比較(轉)Oracle索引
- [轉]聚集索引和非聚集索引的區別索引
- oracle 索引分析及索引重建Oracle索引
- bitmap index點陣圖索引系列(一)Index索引
- 索引分析索引