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

声明: 此文观点不代表本站立场;转载须要保留原文链接;版权疑问请联系我们。