分区表不走索引，全表扫描为何效率更高？

lichangzai

--继续缩小范围，仍全表扫描。
SQL> Select   * From TK_TASKINFO_FINISH_DT t Where create_time Between to_date('2011-08-02 01:00:01','yyyy-mm-dd hh24:mi:ss') And to_date('2011-08-02 7:00:01','yyyy-mm-dd hh24:mi:ss');
已选择155行。

执行计划
----------------------------------------------------------
Plan hash value: 2134538773
----------------------------------------------------------------------------------------------------------------
| Id  | Operation              | Name                  | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT       |                       |  2418 |   441K|  2250   (1)| 00:00:27 |       |       |
|   1 |  PARTITION RANGE SINGLE|                       |  2418 |   441K|  2250   (1)| 00:00:27 |     3 |     3 |
|*  2 |   TABLE ACCESS FULL    | TK_TASKINFO_FINISH_DT |  2418 |   441K|  2250   (1)| 00:00:27 |     3 |     3 |
----------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - filter("CREATE_TIME"<=TO_DATE(' 2011-08-02 07:00:01', 'syyyy-mm-dd hh24:mi:ss') AND
              "CREATE_TIME">=TO_DATE(' 2011-08-02 01:00:01', 'syyyy-mm-dd hh24:mi:ss'))

统计信息
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       8157  consistent gets
       8144  physical reads
          0  redo size
      27485  bytes sent via SQL*Net to client
        630  bytes received via SQL*Net from client
         12  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
        155  rows processed

--再次缩小范围，这次终于走索引了
SQL> Select  * From TK_TASKINFO_FINISH_DT t Where create_time Between to_date('2011-08-02 01:00:01','yyyy-mm-dd hh24:mi:ss') And to_date('2011-08-02 6:00:01','yyyy-mm-dd hh24:mi:ss');
已选择119行。

执行计划
----------------------------------------------------------
Plan hash value: 3730079901
----------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                          | Name                  | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
----------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                   |                       |  2015 |   367K|  1984   (0)| 00:00:24 |       |       |
|   1 |  PARTITION RANGE SINGLE            |                       |  2015 |   367K|  1984   (0)| 00:00:24 |     3 |     3 |
|   2 |   TABLE ACCESS BY LOCAL INDEX ROWID| TK_TASKINFO_FINISH_DT |  2015 |   367K|  1984   (0)| 00:00:24 |     3 |     3 |
|*  3 |    INDEX RANGE SCAN                | G_IND_1               |   124 |       |     8   (0)| 00:00:01 |     3 |     3 |
----------------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   3 - access("CREATE_TIME">=TO_DATE(' 2011-08-02 01:00:01', 'syyyy-mm-dd hh24:mi:ss') AND "CREATE_TIME"<=TO_DATE('
              2011-08-02 06:00:01', 'syyyy-mm-dd hh24:mi:ss'))

统计信息
----------------------------------------------------------
          1  recursive calls
          0  db block gets
        125  consistent gets
          0  physical reads
          0  redo size
      21769  bytes sent via SQL*Net to client
        597  bytes received via SQL*Net from client
          9  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
        119  rows processed

看来这查询结果多少是否走索引，经验值有时是不准确的。

lelepapa

其实。。走不走索引是oracle自己的优化器来判断的。代价比全表大为什么要走索引？

ftc007

这个问题其实还是比较直观的，并不是所有查询都值得走索引，若搜索的数据范围落在某个分区中，或大部分数据落在某个分区里，必然走这个PARTITION RANGE SINGLE，其实也不算全表扫描，是分区扫描而已。