溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
位圖索引區別于傳統B*樹索引有兩個結構特點：其一是葉子節點上是一個可能的索引列取值對應一個葉子節點。另一個就是葉子節點上通過一個位圖向量表示對應行是否取定這個索引值。
使用位圖向量記錄對應行的取值情況不僅可以帶來存儲空間上的節省，而且可以借助計算機位圖運算的快速特性來提高索引結果利用率。下面我們通過模擬情況來進行分析。
Bitmap Index模擬說明
假設存在數據表T，有兩個數據列A和B，取值如下。
|
序號 |
A |
B |
|
1 |
L |
1 |
|
2 |
T |
2 |
|
3 |
L |
2 |
|
4 |
M |
1 |
對兩個數據列A、B分別建立位圖索引：idx_t_bita和idx_t_bitb。兩個索引對應的存儲邏輯結構如下：
Idx_t_bita索引結構，對應的是葉子節點：
|
索引鍵值 |
起始rowid |
結束rowid |
位圖向量 |
|
L |
xxx |
ttt |
1010 |
|
T |
xxx |
ttt |
0100 |
|
M |
xxx |
ttt |
0001 |
Idx_t_bitb索引結構，對應的是葉子節點：
|
索引鍵值 |
起始rowid |
結束rowid |
位圖向量 |
|
1 |
xxx |
ttt |
1001 |
|
2 |
xxx |
ttt |
0110 |
|
|
|
|
|
對查詢“select * from t where b=1 and (a=’L’ or a=’M’)”
分析：位圖索引使用方面，和B*索引有很大的不同。B*索引的使用，通常是從根節點開始，經過不斷的分支節點比較到最近的符合條件葉子節點。通過葉子節點上的不斷Scan操作，“掃描”出結果集合rowid。
而位圖索引的工作方式截然不同。通過不同位圖取值直接的位運算（與或），來獲取到結果集合向量（計算出的結果）。
針對實例SQL，可以拆分成如下的操作：
1、a=’L’ or a=’M’
a=L：向量：1010
a=M：向量：0001
or操作的結果，就是兩個向量的或操作：結果為1011。
2、結合b=1的向量
中間結果向量：1011
B=1：向量：1001
and操作的結果，1001。翻譯過來就是第一和第四行是查詢結果。
3、獲取到結果rowid
目前知道了起始rowid和終止rowid，以及第一行和第四行為操作結果。可以通過試算的方法獲取到結果集合rowid。
上面的操作演算過程，說明了兩個問題：
位圖索引是可以多索引共同合作操作的，不像B*樹索引只有一個會加入結果集合；
位圖索引的工作是通過位邏輯運算，非掃描操作；
實際試驗
下面我們通過一系列的實驗，來進一步觀察結果。
實驗環境構建
SQL> create table t as select owner owner1, object_type type1, owner owner2, object_type type2 from dba_objects;
Table created
SQL> desc t;
Name Type Nullable Default Comments
------ ------------ -------- ------- --------
OWNER1 VARCHAR2(30) Y
TYPE1 VARCHAR2(19) Y
OWNER2 VARCHAR2(30) Y
TYPE2 VARCHAR2(19) Y
SQL> create index idx_t_owner1 on t(owner1);
Index created
SQL> create index idx_t_type1 on t(type1);
Index created
SQL> create bitmap index idx_t_owner2bit on t(owner2);
Index created
SQL> create bitmap index idx_t_type2bit on t(type2);
Index created
SQL> exec dbms_stats.gather_table_stats(user,'T',cascade => true);
PL/SQL procedure successfully completed
常規索引實驗
我們構建的環境中，字段和類型完全相同。區別就在于使用的索引類型差異。下面我們先進行常規索引實驗。
//為防止影響執行計劃，先禁用Bitmap Index
SQL> alter index idx_t_owner2bit unusable;
Index altered
SQL> alter index idx_t_type2bit unusable;
Index altered
SQL> set pagesize 1000;
SQL> set linesize 1000;
SQL> explain plan for select * from t where owner1='SCOTT' and type1='TABLE';
已解釋。
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------
Plan hash value: 2154532428
--------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time|
--------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 28 | 2 (0)| 00:00:01 |
|* 1 | TABLE ACCESS BY INDEX ROWID| T | 1 | 28 | 2 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | IDX_T_OWNER1 | 28 | | 1 (0)| 00:00:01 |
--------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("TYPE1"='TABLE')
2 - access("OWNER1"='SCOTT')
已選擇15行。
注意：owner1和type1上均有B*索引，而且均出現在where條件上。結果采用的Scan方式，而且只使用到了一個索引對象。
Bitmap Index索引實驗
此次使用Bitmap Index列對應查詢條件。
//索引處理
SQL> alter index idx_t_type2bit rebuild;
Index altered
SQL> alter index idx_t_owner2bit rebuild;
Index altered
SQL> alter index idx_t_owner1 unusable;
Index altered
SQL> alter index idx_t_type1 unusable;
Index altered
SQL> explain plan for select * from t where owner2='SCOTT' and type2='TABLE';
已解釋。
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
-------------------------------------------------------------------------------------------------
Plan hash value: 244872826
------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 61 | 1708 | 13 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID | T | 61 | 1708 | 13 (0)| 00:00:01 |
| 2 | BITMAP CONVERSION TO ROWIDS| | | | | |
| 3 | BITMAP AND | | | | | |
|* 4 | BITMAP INDEX SINGLE VALUE| IDX_T_TYPE2BIT | | | | |
|* 5 | BITMAP INDEX SINGLE VALUE| IDX_T_OWNER2BIT | | | | |
------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - access("TYPE2"='TABLE')
5 - access("OWNER2"='SCOTT')
已選擇18行。
在一個SQL中，兩個Bitmap索引均使用到。
下面實驗一個比較復雜的條件。
SQL> explain plan for select * from t where owner2='SCOTT' and (type2='TABLE' or type2='INDEX');
已解釋。
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------
Plan hash value: 3499411373
-------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 122 | 3416 | 24 (5)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID | T | 122 | 3416 | 24 (5)| 00:00:01 |
| 2 | BITMAP CONVERSION TO ROWIDS | | | | | |
| 3 | BITMAP AND | | | | | |
|* 4 | BITMAP INDEX SINGLE VALUE | IDX_T_OWNER2BIT | | | | |
| 5 | BITMAP OR | | | | | |
|* 6 | BITMAP INDEX SINGLE VALUE| IDX_T_TYPE2BIT | | | | |
|* 7 | BITMAP INDEX SINGLE VALUE| IDX_T_TYPE2BIT | | | | |
-------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - access("OWNER2"='SCOTT')
6 - access("TYPE2"='INDEX')
7 - access("TYPE2"='TABLE')
已選擇21行。
請注意Bitmap系列and和or操作，和我們在開篇中做的模擬計算如出一轍。
Bitmap Index是一種適應范圍比較窄，但是特效針對性很強的索引類型。在一些場合下合適使用，可以帶來出乎意料的效果。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
