關於點陣圖索引的split及bitmap to rowid實現問題

下面是參考網路上一些文件整理的bitmap的資料(部分)，


Key     start_rowid       end_rowid          理論上的bitmap             轉儲檔案的bitmap
<01     00c01ce4.0    00c01ce4.0017   00100110000110000010 >    ca 64 18 04
<02     00c01ce4.0    00c01ce4.0017   01000001010000110100 >    ca 82 c2 02
<03     00c01ce4.0    00c01ce4.0017   10011000101001001001 >    ca 19 25 09

其實dump出來的start-rowid及end-rowid分別如 srid=00c01ce4.0  erid=00c01ce4.17，左邊的表示檔案號（從左邊第一個位元組開始的4個位元組表示）和資料塊號（從左邊第五個位元組開始的4個位元組表示），點右邊表示資料塊裡的行號。

bitmap字元長度與start-rowid和end-rowid之間包含的rowid數量(表的資料行)一樣，每個塊的大小是8192*8bit*90%*87%(如果資料塊大小為8K，pctfree=10%, 塊頭部佔用一些)，那麼一個bitmap索引的葉子節點大概能索引51314 條記錄。

bitmap中沒有直接記錄rowid, 而是記錄了一個點陣圖, 點陣圖中的每一個bit位都對應一個rowid, 之間有轉換關係的.所以用bitmap索引的時候你可以在執行計劃裡看到 bitmap to rowid 這樣的步驟.   

當我們發出where c1='01'這樣的SQL時，oracle會搜尋01所在的索引條目，然後掃描該索引條目中的bitmap裡的所有bit位。第一個bit位是1，表示第一條上的c1的值是01，於是返回第一條記錄所在的rowid(根據該索引條目裡記錄的start rowid加上行號得到該記錄所在的rowid), 第二個bit位為0, 則說明第二條記錄上的c1值不為01,依此類推。特別注意，如果索引列為空，也會在點陣圖索引中記錄，對應的bit位為0 ；



關於bitmap索引， 還有以下一些疑問：

1.   bitmap to rowid  是在SQL執行過程中的一個步驟，  假設列中的 01 值對應的點陣圖 001010010 ,   SQL查詢條件where col='01' ， 根
      據該索引條目裡記錄的start rowid加上行號得到該記錄所在的rowid ，  從點陣圖中可以看出對應的 3，5，8 行記錄符合條件， 如果出現
      3，5，8 行的記錄分別在兩個不同的索引塊中，  那麼 start_rowid + 所在塊中的行號 是如何找到的 ？   也就是說 “所在塊中的行號”
      應該是參照 start_rowid 的值， 和在哪個塊中沒有關係 ？   

2.   在檢視dump出來的start_rowid 值的時候，start_rowid存在不同的情況，這也就是說問題1中的“塊中行號”是參考start_rowid 不是
      太準確， 應該是參照各自的start_rowid  .  不知道這樣理解是否正確。

3.   一個bitmap索引的葉子節點大概能索引51314 條記錄(8k block size)，假設一個表列gender僅有'M','F' 值， 類似B-Tree，根節點
      存放兩個索引條目  M  B1,  F   B2 (B1,B2表示branch地址)，  B1 分支節點中存放M  L1, M  L2, M  L3 (L1等表示葉子節點地址)，
      B2 分支節點存放  F  L4, F  L5, F  L6  等， 假設存放M的葉子節點L1中bitmap 是 00001000010010000010010100001001001
      00010100100101000000010100000000000000011111000000000 ...... 直到滿為止， L2 同樣000100011100....,  那麼在
      進行查詢動作時， L1, L2, L3 中的bitmap會被首尾組合起來進行運算 ？    如果記錄足夠多， 導致分支節點B1中空間不足，需要進行
      split ,  這裡不存在類似b-tree中“插入的值”是最大值還是中間值的情況，都相等，比如是M,   那麼B1中的索引條目會分出一半給新的
      分支節點 ？