请教：为什么使用分区表以后查询比以前还慢了呢

gunduziqu

CREATE TABLE D_NIPPOU_DETAIL
(
    KAISYA_CD VARCHAR2 (4) NOT NULL ,
    POST_CD VARCHAR2 (10) NOT NULL ,
    TANTOU_CD VARCHAR2 (6) NOT NULL ,
    GYOUMU_DATE DATE NOT NULL ,
    GYOUMU_CD VARCHAR2 (2) NOT NULL ,
    GYOUMU_LARGE_DIV_CD VARCHAR2 (2) NOT NULL ,
    GYOUMU_MIDDLE_DIV_CD VARCHAR2 (2) NOT NULL ,
    GYOUMU_SMALL_DIV_CD VARCHAR2 (2) NOT NULL ,
    KENSU NUMBER (5),
    SISYA_BLK_CD VARCHAR2 (3),
    APP_DATE DATE,
    APP_TANTOU_CD VARCHAR2 (6),
    UPD_DATE DATE,
    UPD_TANTOU_CD VARCHAR2 (6),
    LOGICAL_DEL_FLG CHAR (1),
    LOGICAL_DEL_DATE DATE,
    DEL_TANTOU_CD VARCHAR2 (6)
)
TABLESPACE HCAS_DATA
;

ALTER TABLE D_NIPPOU_DETAIL ADD  CONSTRAINT D_NIPPOU_DETAIL_IDX0 PRIMARY KEY
(
    KAISYA_CD,
    POST_CD,
    TANTOU_CD,
    GYOUMU_DATE,
    GYOUMU_CD,
    GYOUMU_LARGE_DIV_CD,
    GYOUMU_MIDDLE_DIV_CD,
        GYOUMU_SMALL_DIV_CD
)
USING INDEX TABLESPACE HCAS_IDX
;

gunduziqu

为什么分区后不使用索引呢
都是同样的索引D_NIPPOU_DETAIL_IDX0
怎么一分区就不使用了呢

blue_prince

最初由 blue_prince 发布
[B]建议你在GYOUMU_DATE 创建一个索引，然后再看一下查询效果。 [/B]

wwllzpz

最初由 gunduziqu 发布
[B]为什么分区后不使用索引呢
都是同样的索引D_NIPPOU_DETAIL_IDX0
怎么一分区就不使用了呢 [/B]

分析表和索引

gunduziqu

在GYOUMU_DATE 创建一个索引(也是分区的)，然后查询效果还是比未分区的表的速度慢很多
分区：
経過: 00:01:38.07

実行計画
----------------------------------------------------------
Plan hash value: 2518634925

------------------------------------------------------------------------------------------------------------------------
--

| Id  | Operation                          | Name                | Rows  | Bytes | Cost (%CPU)| Time  | Pstart| Pstop
|

------------------------------------------------------------------------------------------------------------------------
--

|   0 | SELECT STATEMENT                   |                     | 37651 |  2720K|   948   (1)| 00:00:12 |       |
|

|   1 |  PARTITION RANGE SINGLE            |                     | 37651 |  2720K|   948   (1)| 00:00:12 |   KEY |   KEY
|

|   2 |   TABLE ACCESS BY LOCAL INDEX ROWID| D_NIPPOU_DETAIL     | 37651 |  2720K|   948   (1)| 00:00:12 |   KEY |   KEY
|

|*  3 |    INDEX RANGE SCAN                | D_NIPPOU_DETAIL_001 | 12550 |       |   103   (1)| 00:00:02 |   KEY |   KEY
|

------------------------------------------------------------------------------------------------------------------------
--


Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access("GYOUMU_DATE"=TO_DATE('20050801'))


統計
----------------------------------------------------------
          1  recursive calls
          0  db block gets
       7796  consistent gets
        200  physical reads
          0  redo size
    2589931  bytes sent via SQL*Net to client
      36729  bytes received via SQL*Net from client
       3306  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      49574  rows processed

SQL>未分区：
経過: 00:00:15.45

実行計画
----------------------------------------------------------
Plan hash value: 2246260284

----------------------------------------------------------------------------------------------------
| Id  | Operation                   | Name                 | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |                      | 38684 |  2719K| 44294   (1)| 00:08:52 |
|   1 |  TABLE ACCESS BY INDEX ROWID| D_NIPPOU_DETAIL      | 38684 |  2719K| 44294   (1)| 00:08:52 |
|*  2 |   INDEX SKIP SCAN           | D_NIPPOU_DETAIL_IDX0 | 38684 |       | 42097   (1)| 00:08:26 |
----------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("GYOUMU_DATE"=TO_DATE('20050801'))
       filter("GYOUMU_DATE"=TO_DATE('20050801'))


統計
----------------------------------------------------------
          1  recursive calls
          0  db block gets
      20575  consistent gets
          0  physical reads
          0  redo size
    4250179  bytes sent via SQL*Net to client
      36729  bytes received via SQL*Net from client
       3306  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      49574  rows processed

gunduziqu

分析表和索引之后还是不能使用D_NIPPOU_DETAIL_IDX0索引

blue_prince

逻辑读已经降下来了，执行时间长我想主要是物理读的开销，你再执行一次速度就应该会有大幅改观。将GYOUMU_DATE"=TO_DATE('20050801'))改为GYOUMU_DATE"=TO_DATE('20050801:00:00:00'))，把时分秒也加上，试试，这样应该就不会走index range scan了，不过我不清楚你的的数据时分秒是否有存储。另外你可以加个HINT强制走索引看一下效果。要不断比较分析。

gunduziqu

select /*+INDEX(D_NIPPOU_DETAIL_IDX0)*/ * from D_NIPPOU_DETAIL where GYOUMU_DATE = to_date(20050601);

这样怎么还是不使用索引D_NIPPOU_DETAIL_IDX0

wwllzpz

这样
select /*+INDEX(D_NIPPOU_DETAIL  D_NIPPOU_DETAIL_IDX0)*/ * from D_NIPPOU_DETAIL where GYOUMU_DATE = to_date(20050601);
你分区完的索引是不是D_NIPPOU_DETAIL_IDX0，我分区完的执行计划怎么使用了D_NIPPOU_DETAIL_001 索引

gunduziqu

最初由 wwllzpz 发布
[B]这样
select /*+INDEX(D_NIPPOU_DETAIL  D_NIPPOU_DETAIL_IDX0)*/ * from D_NIPPOU_DETAIL where GYOUMU_DATE = to_date(20050601);
你分区完的索引是不是D_NIPPOU_DETAIL_IDX0，我分区完的执行计划怎么使用了D_NIPPOU_DETAIL_001 索引 [/B]

**********************************************************
D_NIPPOU_DETAIL_001 这个你是怎么弄出来的，按照我的代码不应该有这个索引的