現(xiàn)在，我們知道優(yōu)化器如何對這些技術做出反應，清楚地說明 bitmap 索引和 B-tree 索引各自的最好應用。
在 GENDER 列適當?shù)貛б粋€ bitmap 索引，在 SAL 列上創(chuàng)建另外一個位圖索引，然后執(zhí)行一些查詢。在這些列上，用 B-tree 索引重新執(zhí)行查詢。
從 TEST_NORMAL 表，查詢工資為如下的男員工：
1000
1500
2000
2500
3000
3500
4000
4500
因此：
SQL> select * from test_normal
2 where sal in (1000,1500,2000,2500,3000,3500,4000,4500,5000) and GENDER='M';
已選擇444行。

執(zhí)行計劃
----------------------------------------------------------
Plan hash value: 4115571900
--------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost(%CPU)| Time |
--------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 39 | 1 (0)| 00:00:01 |
|* 1 | TABLE ACCESS BY INDEX ROWID | TEST_NORMAL | 1 | 39 | 1 (0)| 00:00:01 |
| 2 | BITMAP CONVERSION TO ROWIDS| | | | | |
|* 3 | BITMAP INDEX SINGLE VALUE | NORMAL_GENDER_BMX | | | | |
--------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("SAL"=1000 OR "SAL"=1500 OR "SAL"=2000 OR "SAL"=2500 OR "SAL"=3000
OR
"SAL"=3500 OR "SAL"=4000 OR "SAL"=4500 OR "SAL"=5000)
3 - access("GENDER"='M')

統(tǒng)計信息
----------------------------------------------------------
0 recursive calls
0 db block gets
6280 consistent gets
0 physical reads
0 redo size
25451 bytes sent via SQL*Net to client
839 bytes received via SQL*Net from client
31 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
444 rows processed
SQL>
這是一個典型的數(shù)據(jù)倉庫查詢，不要再 OLTP（On-Line Transaction Processing，聯(lián)機事務處理系統(tǒng)）系統(tǒng)上執(zhí)行。下面是 bitmap 索引的結果：
而 B-tree 索引的查詢：
SQL> select * from test_normal
2 where sal in (1000,1500,2000,2500,3000,3500,4000,4500,5000) and GENDER='M';

已選擇444行。

執(zhí)行計劃
----------------------------------------------------------
Plan hash value: 654360527
-------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 39 | 2 (0)| 00:00:01 |
|* 1 | TABLE ACCESS BY INDEX ROWID| TEST_NORMAL | 1 | 39 | 2 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | NORMAL_GENDER_IDX | 1 | | 2 (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("SAL"=1000 OR "SAL"=1500 OR "SAL"=2000 OR "SAL"=2500 OR "SAL"=3000
OR
"SAL"=3500 OR "SAL"=4000 OR "SAL"=4500 OR "SAL"=5000)
2 - access("GENDER"='M')

統(tǒng)計信息
----------------------------------------------------------
0 recursive calls
0 db block gets
6854 consistent gets
0 physical reads
0 redo size
25451 bytes sent via SQL*Net to client
839 bytes received via SQL*Net from client
31 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
444 rows processed
SQL>
對 B-tree 索引，優(yōu)化器選擇了全表掃描，而在 bitmap 索引的情況下，使用了索引。可以通過 IO 推斷出性能。
一般，bitmap 索引對 DSS 最合適，而不管基數(shù)怎么樣，原因如下：

對于 bitmap 索引，優(yōu)化器可能高效低相應包含 AND、OR 或 XOR 的查詢。（Oracle 支持動態(tài)的 B-tree 到 bitmap 轉換，但是效率不是很高。
對 bitmap 索引，當查詢或計數(shù) null 時，優(yōu)化器會響應查詢。null 值也被 bitmap 索引索引（這不同于 B-tree 索引）。

更重要的是，DSS 系統(tǒng)的 bitmap 索引支持 ad hoc 查詢，而 B-tree 索引則不。更特別地，如果你有帶 50 列的一個表，而用戶頻繁查詢它們中的 10 個——或所有 10 個列的組合，或一個列——創(chuàng)建 B-tree 索引將會很困難。如果你在這些所有的列上創(chuàng)建 10 個 bitmap 索引，那么所有的查詢都會被這些索引響應，而不論是在 10 個列上查詢，還是 4、6 個列，或只一個列。AND_EQUAL 優(yōu)化器提示為 B-tree 索引提供這個功能，但是不能超過 5 個索引。bitmap 索引就沒有這個限制。

相比之下，B-tree 索引很適合 OLTP 應用程序，這樣的系統(tǒng)用戶查詢比較常規(guī)（在部署前，可以調整），與 ad hoc 查詢相對，它不是很頻繁，在飛業(yè)務高峰時間執(zhí)行。因為，OLTP 系統(tǒng)經(jīng)常更新和刪除，所以，在這種情況下，bitmap 索引可以導致一個嚴重的鎖問題。

這里的數(shù)據(jù)是很明顯。兩個索引目標相同：盡可能快地返回結果。但選擇使用哪個完全取決于應用的類型，而不是基數(shù)的水平。