概述

最近比较忙，介绍一个之前做的简单点的实验，混合使用不同提示的hint，大家有空可以跟着做下。

基础环境准备

drop table t1;
create table t1 as select * from dba_objects;
insert into t1 select * from t1;
insert into t1 select * from t1;
commit;
select count(*) from t1; =>349300
create index idx_t1 on t1(object_id);
update t1 set object_id=1 where rownum<320000;
commit;

/手动修改了OBJECT_ID的值，将表中绝大多数记录的OBJECT_ID设置为1

select count(*) from t1 where object_id=1; =>319999

//收集表的统计信息，注意此时也收集了相关对象--索引的统计信息

exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'T1',estimate_percent=>100,method_opt=>'for columns size auto object_id',cascade=>true);

/*

查看当前索引的聚簇因子为5531,聚簇因子反映了索引字段的顺序和表中数据存储的有序关系。聚簇因子越小，说明索引字段顺序与表中数据存储顺序一致性越高；反之，则一致性越低，即越无序。

*/

select clustering_factor from dba_indexes where index_name='IDX_T1'; =》5531

//这里手动修改了聚簇因子为10000，手动修改统计信息，是一种常见优化手段，便于分析问题

exec dbms_stats.set_index_stats(ownname=>'SCOTT',indname=>'IDX_T1',clstfct=>10000,no_invalidate=>false);
select clustering_factor from dba_indexes where index_name='IDX_T1';

测试sql(默认情况)

默认情况采用索引扫描，因为上面修改了索引的聚簇因子，大大增加了索引扫描的成本，所以这里选择全表扫描

set autotrace traceonly;
select object_name,object_id from t1 where object_id=1;

测试sql(first_rows(10))

first_rows(10)作用是优先返回10条记录，在使用hint后，oracle认为此时扫描索引IDX_T1能够以最短响应时间返回where条件“object_id=1”的头10条记录，所以这里用了索引范围扫描。

select /*+ first_rows(10) */ object_name,object_id from t1 where object_id=1;

测试sql(first_rows(9))

first_rows(9)作用是优先返回9条记录，与上面变化是优化器对基数的估算不同，注意执行计划中的rows部分，从first_rows(10)的11变成了9。

select /*+ first_rows(9) */ object_name,object_id from t1 where object_id=1;

测试SQL（rule）

注意执行计划中的关键字“rule based...”,显示的具体执行步骤中并没有“cost”列，这说明RULE起作用了，现在是RBO。

select /*+ rule */ object_name,object_id from t1 where object_id=1;

测试SQL（rule+parallel）

输出中包含了“cost”列，表示SQL在解析时使用CBO，说明如果目标SQL使用了并行执行，其中的RULE HINT将会失效，此时Oracle自动启用CBO.

alter table t1 parallel;
select /*+ rule */ object_name,object_id from t1 where object_id=1;

后面小编会分享更多DBA方面的干货，感兴趣的朋友走一波关注哩~