Oracle索引的奇怪工作

Question

我已将位图索引添加到现有表中

CREATE BITMAP INDEX idx_1 ON table1 (col1) COMPUTE STATISTICS;

但是当我解释查询计划时，新索引没有被优化器使用并且表被全扫描。

之后我创建了我的表的副本并创建了相同的索引，并且优化器使用了索引！

我在原始表和副本表上删除并重新创建了索引，但结果相同 - 原始表索引不起作用，而副本表索引正在工作。

当我尝试提示优化器在原始表上使用索引时，成本是全表扫描方法的 3 倍。

我正在使用 Oracle 11gr2。

    create table AP_IT.T_LEAD_MAIN3
(
  id                NUMBER not null,
  fill_date         DATE not null,
  source_code       NUMBER default 0 not null,
  product_code      NUMBER not null,
  phone             VARCHAR2(64) not null,
  amount            NUMBER,
  amount_scored     NUMBER,
  birthdate         DATE,
  children          NUMBER,
  city_name         VARCHAR2(200),
  city_type         VARCHAR2(4),
  convenient_time   VARCHAR2(400),
  email             VARCHAR2(200),
  firstname         VARCHAR2(200),
  homephone         VARCHAR2(64),
  id_type_form      VARCHAR2(120),
  iin               VARCHAR2(48),
  lastname          VARCHAR2(200),
  marriage          VARCHAR2(4),
  middlename        VARCHAR2(200),
  name              VARCHAR2(600),
  offer_type        VARCHAR2(80),
  order_number      VARCHAR2(120),
  pensioner         VARCHAR2(4),
  period            NUMBER default 0,
  period_scored     NUMBER,
  place_to_get_loan VARCHAR2(400),
  region            VARCHAR2(12),
  rnn               VARCHAR2(48),
  salary            NUMBER,
  score_date        DATE,
  scored            NUMBER default 0,
  sent_email        DATE,
  sent_sms          DATE,
  sex               VARCHAR2(4),
  udost             VARCHAR2(36),
  udost_enddate     DATE,
  work_date         DATE,
  id_old            NUMBER(32),
  transac_type      NUMBER,
  utm_test          NVARCHAR2(100),
  utm_content       NVARCHAR2(100),
  utm_medium        NVARCHAR2(100),
  utm_name          NVARCHAR2(100),
  utm_source        NVARCHAR2(100),
  utm_term          NVARCHAR2(100),
  order_id          NUMBER,
  mm                NUMBER,
  call_start_time   VARCHAR2(10),
  call_end_time     VARCHAR2(10),
  call_date         DATE
)
tablespace RISK_DATA
  pctfree 10
  initrans 1
  maxtrans 255
  storage
  (
    initial 80K
    next 1M
    minextents 1
    maxextents unlimited
  );

-- Create/Recreate primary, unique and foreign key constraints 
alter table AP_IT.T_LEAD_MAIN3
  add constraint PK_LEAD_MAIN3 primary key (ID)
  using index 
  tablespace RISK_DATA
  pctfree 10
  initrans 2
  maxtrans 255
  storage
  (
    initial 80K
    next 1M
    minextents 1
    maxextents unlimited
  );
alter table AP_IT.T_LEAD_MAIN3
  add foreign key (SOURCE_CODE)
  references AP_IT.T_LEAD_SOURCE (SOURCE_CODE);
alter table AP_IT.T_LEAD_MAIN3
  add foreign key (PRODUCT_CODE)
  references AP_IT.T_LEAD_PRODUCT (PRODUCT_CODE);

CREATE BITMAP INDEX idx_tblleadmain_3
ON AP_IT.T_LEAD_MAIN3 (SCORED) COMPUTE STATISTICS;

查询：

select "AMOUNT_SCORED","ORDER_NUMBER","SCORED" 
from ap_it.t_lead_main3 t 
where t.scored = 1

原表计划

--------------------------------------------------------------
| Id  | Operation         | Name        | Rows  | Cost (%CPU)|
--------------------------------------------------------------
|   0 | SELECT STATEMENT  |             |   573K|  4284   (1)|
|*  1 |  TABLE ACCESS FULL| T_LEAD_MAIN |   573K|  4284   (1)|
--------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter("T"."SCORED"=1)

复制表的计划

    --------------------------------------------------------------------------------
Plan hash value: 2628593030
-------------------------------------------------------------------------------
| Id  | Operation                    | Name              | Rows  | Cost (%CPU)|
-------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |                   |   753K|  1637   (1)|
|   1 |  TABLE ACCESS BY INDEX ROWID | T_LEAD_MAIN3      |   753K|  1637   (1)|
|   2 |   BITMAP CONVERSION TO ROWIDS|                   |       |            |
|*  3 |    BITMAP INDEX SINGLE VALUE | IDX_TBLLEADMAIN_3 |       |            |
-------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   3 - access("T"."SCORED"=1)

Answer 1

你已经回答了这个问题：

之后我创建了我的表的副本并创建了相同的索引...

创建一个表的副本（使用CTAS - create table .. as select ..）产生的不是原始表的完全相同的克隆，而是两个空间分配（例如，如果原始表在删除后包含大量可用空间）和顺序或行（例如使用order by 创建）可能会发生变化。

因此，对于原始表，CBO 为 FULL TABLE SCAN 计算较低的成本，但对于新表（在您使用 CTAS重组之后）位图 indexx 访问是首选。

只有当您使用10053 trace 跟踪您的两个查询时才能获得全部真相，但通常您不应该期望相同（逻辑）数据的优化器行为相同。桌子的物理布局起着至关重要的作用。