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 索引可以导致一个严重的锁问题。 

这里的数据是很明显。两个索引目标相同：尽可能快地返回结果。但选择使用哪个完全取决于应用的类型，而不是基数的水平。