ROWID走索引之嫌疑犯抓获

通过自己做的分区表来分析,发现不走索引,而把原来的表结构改名,创建新表. 分析后发现 走索引了!

难道是分区的 储存参数? 还是分区达不到个数.

storage
    (
      initial 80K
      minextents 1
      maxextents unlimited
    );

继续实验,也不走索引!

对改造的表不断的减少分区,测试还是走索引,减少不必要的字段,保留两个索引,关键索引所需要的字段. 还是走索引.
 

create table t_test_2
(  id         number ,
  name        varchar2(35),
  create_time date
)partition by range (create_time)

create index idx_idname_test2 on t_test_2(id,name);

create table  USER_SUM_DAY_201210
(
  RECDATE      NUMBER(8) not null,
  OPERID       NUMBER(10) default 0 not null,
  CONTENTID    NUMBER(10) default 0 not null,
  PROVCODE     NUMBER(5) default 0 not null,
  CREATETIME   DATE default sysdate not null,
  MODIFYTIME   DATE default sysdate not null
)
partition by range (PROVCODE);

create index IDX_USER_SUM_DAY_201210_N1 on USER_SUM_DAY_201210(RECDATE, OPERID);

唯一区别是 id number 和 recdate number(8) not null, 非空.

把表改造成非空字段

create table t_test_2
(  id         number (8) not null,
  name        varchar2(35),
  create_time date
)partition by range (create_time)

create index idx_idname_test2 on t_test_2(id);

插入5万条数据

SQL> insert into t_test_2 select * from t_test;

50000 rows inserted

不做分析 该删除语句依旧走索引.

分析后不走索引了

如果 TRUNCATE TABLE T_TEST_2  并且分析 EXEC dbms_stats.gather_table_stats (tabname=>'T_TEST_2',estimate_percent=>100,cascade=>true);

结果:走索引!

如果是 delete t_test_2 并且分析后 不走索引!

小总: 1 对空表和非空索引分析完后,实行DELETE ROWID操作 结果走索引. 如果以后不断地往里面插入数据,并且没做分析.后果非常的慢

2 truncate 和delete 操作后 并且做了分析 delete rowid的执行计划 是有区别的! 

 也就是说如果将来还往里面查入数据,truncate并且不做分析,那么再执行DELETE ROWID操作是很慢的.