现在，我们知道优化器如何对这些技术做出反应，清楚地说明 bitmap 索引和 B-tree 索引各自的最好应用
现在，我们知道优化器如何对这些技术做出反应，清楚地说明 bitmap 索引和 B-tree 索引各自的最好应用。
在 GENDER 列适当地带一个 bitmap 索引，在 SAL 列上创建另外一个位图索引，然后执行一些查询。在这些列上，用 B-tree 索引重新执行查询。
从 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行。
执行计划
----------------------------------------------------------
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')
统计信息
----------------------------------------------------------
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>
这是一个典型的数据仓库查询，不要再 OLTP（On-Line Transaction Processing，联机事务处理系统）系统上执行。下面是 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行。
执行计划
----------------------------------------------------------
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')
统计信息
----------------------------------------------------------
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 索引，优化器选择了全表扫描，而在 bitmap 索引的情况下，使用了索引。可以通过 IO 推断出性能。
一般，bitmap 索引对 DSS 最合适，而不管基数怎么样，原因如下：
对于 bitmap 索引，优化器可能高效低相应包含 AND、OR 或 XOR 的查询。（Oracle 支持动态的 B-tree 到 bitmap 转换，但是效率不是很高。
对 bitmap 索引，当查询或计数 null 时，优化器会响应查询。null 值也被 bitmap 索引索引（这不同于 B-tree 索引）。
更重要的是，DSS 系统的 bitmap 索引支持 ad hoc 查询，而 B-tree 索引则不。更特别地，如果你有带 50 列的一个表，而用户频繁查询它们中的 10 个——或所有 10 个列的组合，或一个列——创建 B-tree 索引将会很困难。如果你在这些所有的列上创建 10 个 bitmap 索引，那么所有的查询都会被这些索引响应，而不论是在 10 个列上查询，还是 4、6 个列，或只一个列。AND_EQUAL 优化器提示为 B-tree 索引提供这个功能，但是不能超过 5 个索引。bitmap 索引就没有这个限制。
相比之下，B-tree 索引很适合 OLTP 应用程序，这样的系统用户查询比较常规（在部署前，可以调整），与 ad hoc 查询相对，它不是很频繁，在飞业务高峰时间执行。因为，OLTP 系统经常更新和删除，所以，在这种情况下，bitmap 索引可以导致一个严重的锁问题。
这里的数据是很明显。两个索引目标相同：尽可能快地返回结果。但选择使用哪个完全取决于应用的类型，而不是基数的水平。
