索引系列九--索引特性之有序优化distinct
2014-06-03 20:00
411 查看
--DISTINCT测试前的准备
drop table t purge;
create table t as select * from dba_objects;
update t set object_id=rownum;
alter table T modify OBJECT_ID not null;
update t set object_id=2;
update t set object_id=3 where rownum<=25000;
commit;
/*
在oracle10g的R2环境之后,DISTINCT由于其 HASH UNIQUE的算法导致其不会产生排序,其调整的
ALTER SESSION SET "_gby_hash_aggregation_enabled" = FALSE
*/
set linesize 1000
set autotrace traceonly
select distinct object_id from t ;
执行计划
-----------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
-----------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 88780 | 1127K| | 717 (1)| 00:00:09 |
| 1 | HASH UNIQUE | | 88780 | 1127K| 1752K| 717 (1)| 00:00:09 |
| 2 | TABLE ACCESS FULL| T | 88780 | 1127K| | 292 (1)| 00:00:04 |
-----------------------------------------------------------------------------------
统计信息
----------------------------------------------------------
0 recursive calls
0 db block gets
1047 consistent gets
0 physical reads
0 redo size
462 bytes sent via SQL*Net to client
416 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
2 rows processed
/*不过虽然没有排序,通过观察TempSpc可知distinct消耗PGA内存进行HASH UNIQUE运算,
接下来看看建了索引后的情况,TempSpc关键字立即消失,COST也立即下降许多,具体如下*/
--为T表的object_id列建索引
create index idx_t_object_id on t(object_id);
set linesize 1000
set autotrace traceonly
select /*+index(t)*/ distinct object_id from t ;
执行计划
--------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 88780 | 1127K| 582 (1)| 00:00:07 |
| 1 | SORT UNIQUE NOSORT| | 88780 | 1127K| 582 (1)| 00:00:07 |
| 2 | INDEX FULL SCAN | IDX_T_OBJECT_ID | 88780 | 1127K| 158 (1)| 00:00:02 |
--------------------------------------------------------------------------------------
统计信息
----------------------------------------------------------
0 recursive calls
0 db block gets
145 consistent gets
0 physical reads
0 redo size
462 bytes sent via SQL*Net to client
416 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
2 rows processed
drop table t purge;
create table t as select * from dba_objects;
update t set object_id=rownum;
alter table T modify OBJECT_ID not null;
update t set object_id=2;
update t set object_id=3 where rownum<=25000;
commit;
/*
在oracle10g的R2环境之后,DISTINCT由于其 HASH UNIQUE的算法导致其不会产生排序,其调整的
ALTER SESSION SET "_gby_hash_aggregation_enabled" = FALSE
*/
set linesize 1000
set autotrace traceonly
select distinct object_id from t ;
执行计划
-----------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
-----------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 88780 | 1127K| | 717 (1)| 00:00:09 |
| 1 | HASH UNIQUE | | 88780 | 1127K| 1752K| 717 (1)| 00:00:09 |
| 2 | TABLE ACCESS FULL| T | 88780 | 1127K| | 292 (1)| 00:00:04 |
-----------------------------------------------------------------------------------
统计信息
----------------------------------------------------------
0 recursive calls
0 db block gets
1047 consistent gets
0 physical reads
0 redo size
462 bytes sent via SQL*Net to client
416 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
2 rows processed
/*不过虽然没有排序,通过观察TempSpc可知distinct消耗PGA内存进行HASH UNIQUE运算,
接下来看看建了索引后的情况,TempSpc关键字立即消失,COST也立即下降许多,具体如下*/
--为T表的object_id列建索引
create index idx_t_object_id on t(object_id);
set linesize 1000
set autotrace traceonly
select /*+index(t)*/ distinct object_id from t ;
执行计划
--------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 88780 | 1127K| 582 (1)| 00:00:07 |
| 1 | SORT UNIQUE NOSORT| | 88780 | 1127K| 582 (1)| 00:00:07 |
| 2 | INDEX FULL SCAN | IDX_T_OBJECT_ID | 88780 | 1127K| 158 (1)| 00:00:02 |
--------------------------------------------------------------------------------------
统计信息
----------------------------------------------------------
0 recursive calls
0 db block gets
145 consistent gets
0 physical reads
0 redo size
462 bytes sent via SQL*Net to client
416 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
2 rows processed
相关文章推荐
- 索引系列八--索引特性之有序难优化union
- 索引系列十一--索引特性之有序与存列值优化max
- 索引系列十--索引特性之有序优化order by
- 索引系列五--索引特性之存列值优化sum avg
- 索引系列四 --索引特性之存列值优化count
- 索引系列七--索引特性之高度较低是优化利器
- Lucene系列 - 索引(五) - Lucene索引高级特性:索引优化与同步锁
- MySQL 数据库性能优化之索引优化(这是 MySQL数据库性能优化专题 系列的第三篇文章)
- 索引的特性与优化
- sql优化之:深入浅出理解索引(系列一)(讲解非常透彻)
- SQL Server 2005 性能优化实战系列(文章索引)
- Asp.Net网站优化系列 数据库的优化措施 索引优化
- Asp.Net网站优化系列 数据库的优化措施 索引优化
- sql 优化之:聚集索引的重要性和如何选择聚集索引(系列五)
- sql优化之:深入浅出理解索引(系列二)
- SQL Server 性能优化实战系列(文章索引)
- Asp.Net网站优化系列之数据库的优化措施与索引优化方法
- MySQL查询优化技术系列——索引
- Asp.Net网站优化系列 数据库的优化措施 索引优化
- sql 优化之:聚集索引的重要性和如何选择聚集索引(系列五)