ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 更新统计值前后select count(*),第一次走索引,第二次不走,这是为何?

更新统计值前后select count(*),第一次走索引,第二次不走,这是为何?

原创 Linux操作系统 作者:woshiyiziyu 时间:2011-01-27 20:25:45 0 删除 编辑
第一次没有对表D010INC进行统计值更新的时候,select count(*) 走了索引D010INC~0,但是令人奇怪的是执行计划的列Rows下面的值是1,跑了16分钟才跑完。
SQL> set autotrace on
SQL> select count(*) from SAPSR3.D010INC;

  COUNT(*)
----------
  14169040

Elapsed: 00:16:06.59

Execution Plan
----------------------------------------------------------
Plan hash value: 3633007648

----------------------------------------------------------------------
| Id  | Operation        | Name      | Rows  | Cost (%CPU)| Time     |
----------------------------------------------------------------------
|   0 | SELECT STATEMENT |           |     1 |     0   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE  |           |     1 |            |          |
|   2 |   INDEX FULL SCAN| D010INC~0 |     1 |     0   (0)| 00:00:01 |
----------------------------------------------------------------------


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
     236536  consistent gets
     235954  physical reads
          0  redo size
        518  bytes sent via SQL*Net to client
        487  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed
第二次在更新了表D010INC的统计值之后,select count(*) 不走索引了,改为全表扫描,而且执行计划的列Rows下面的值变成了14M,只花了47秒就跑完了,这是为何?
SQL> set autotrace on;
SQL> select count(*) from SAPSR3.D010INC;

  COUNT(*)
----------
  14176215

Elapsed: 00:00:47.69

Execution Plan
----------------------------------------------------------
Plan hash value: 4007038410

----------------------------------------------------------------------
| Id  | Operation          | Name    | Rows  | Cost (%CPU)| Time     |
----------------------------------------------------------------------
|   0 | SELECT STATEMENT   |         |     1 | 34940   (1)| 00:07:00 |
|   1 |  SORT AGGREGATE    |         |     1 |            |          |
|   2 |   TABLE ACCESS FULL| D010INC |    14M| 34940   (1)| 00:07:00 |
----------------------------------------------------------------------


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
     132947  consistent gets
     126768  physical reads
     378360  redo size
        518  bytes sent via SQL*Net to client
        487  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

相关信息:
数据库版本:oracle 10.2.0.4

表D010INC和索引D010INC~0都是SAP的标准表。

索引D010INC~0的DDL语句
SQL> set pages 0
SQL> set long 1000000
SQL> select dbms_metadata.get_ddl('INDEX','D010INC~0','SAPSR3') from DUAL;

  CREATE UNIQUE INDEX "SAPSR3"."D010INC~0" ON "SAPSR3"."D010INC" ("MASTER", "
INCLUDE")
  PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
  STORAGE(INITIAL 16384 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2
147483645
  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
  TABLESPACE "PSAPSR3701"


表D010INC的DDL语句
SQL> select dbms_metadata.get_ddl('TABLE','D010INC','SAPSR3') from DUAL;

  CREATE TABLE "SAPSR3"."D010INC"
   (    "MASTER" VARCHAR2(120) DEFAULT ' ' NOT NULL ENABLE,
        "INCLUDE" VARCHAR2(120) DEFAULT ' ' NOT NULL ENABLE
   ) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS
LOGGING
  STORAGE(INITIAL 16384 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 21474836
45
  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
  TABLESPACE "PSAPSR3701"

另外想问一下索引D010INC~0有没有意义?因为表D010INC只有两个字段。求解。

[ 本帖最后由 woshiyiziyu 于 2011-1-27 20:29 编辑 ]

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/15434882/viewspace-734664/,如需转载,请注明出处,否则将追究法律责任。

下一篇: SAP 版本查看方法
请登录后发表评论 登录
全部评论

注册时间:2009-07-21

  • 博文量
    37
  • 访问量
    111059