现在，我们知道优化器如何对这些技术做出反应，清楚地说明 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 索引可以导致一个严重的锁问题。
这里的数据是很明显。两个索引目标相同：尽可能快地返回结果。但选择使用哪个完全取决于应用的类型，而不是基数的水平。