bitmap 索引和 B-tree 索引在使用中如何选择

时间:2022-02-18 04:11:57

现在,我们知道优化器如何对这些技术做出反应,清楚地说明 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 索引可以导致一个严重的锁问题。 

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