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操作是很慢的.