语句：
select col1,col2,col3,c0l4,col5
from tab1
where col5 = '1.2.392.200036.9116.2.5.1.48.1215491107.1207119889.188062';


Execution Plan
----------------------------------------------------------
Plan hash value: 2354221835

------------------------------------------------------------------------------------
| Id  | Operation         | Name           | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |                |  1819K|   404M| 55890   (1)| 00:11:11 |
|*  1 |  TABLE ACCESS FULL| tab1           |  1819K|   404M| 55890   (1)| 00:11:11 |
------------------------------------------------------------------------------------

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

   1 - filter("col5"='1.2.392.200036.9116.2.5.1.48.1215491107.1207119889.188062')


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
     253852  consistent gets
     253400  physical reads
          0  redo size
       1724  bytes sent via SQL*Net to client
        465  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

这个表上col5上是由索引的，为啥没有使用？为啥优化器认为表中的记录数是 1819K，而实际上是7688K左右？

PHP code:



COLUMN_NAME   NUM_DISTINCT    DENSITY  NUM_NULLS NUM_BUCKETS LAST_ANAL HISTOGRAM    


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


COL1                 234 .004273504          0           1 08-SEP-08 NONE           


COL2                 261 .003831418          0           1 08-SEP-08 NONE           


COL3             7703194 1.2982E-07          0           1 08-SEP-08 NONE           


COL4                   9 .111111111          0           1 08-SEP-08 NONE           


COL15                  2         .5          0           1 08-SEP-08 NONE           


COL6                   3 .333333333          0           1 08-SEP-08 NONE           


COL7                 217 .004608295          0           1 08-SEP-08 NONE           


COL8                 228 .004385965          0           1 08-SEP-08 NONE           


COL9                   2         .5          0           1 08-SEP-08 NONE           


COL10                  5         .2          0           1 08-SEP-08 NONE           


COL10                 18 .055555556    5337646           1 08-SEP-08 NONE           


COL11                655 .001526718          0           1 08-SEP-08 NONE           


COL12                  1          1          0           1 08-SEP-08 NONE           


COL13                 15 .066666667          0           1 08-SEP-08 NONE           


COL14                 78 .012820513       3956           1 08-SEP-08 NONE           


COL5              800936 .000375375          0         254 08-SEP-08 HEIG

这里有两点值得探讨，为啥自动收集统计信息的时候，col5列使用了254个buckets，而且histogram 是 height balanced方式而不是frequency？

SQL> select count(*) from TAB1;

  COUNT(*)
----------
   7638516

tab1表中记录数

CREATE INDEX IND_TAB1_COL5 ON TAB1
(COL5)
LOGGING
TABLESPACE TEST
PCTFREE    10
INITRANS   2
MAXTRANS   255
STORAGE    (
            INITIAL          64K
            MINEXTENTS       1
            MAXEXTENTS       2147483645
            PCTINCREASE      0
            BUFFER_POOL      DEFAULT
           )
NOPARALLEL;

col5字段上的索引。

表中的统计信息是由oracle 自动根据表中数据变化情况来自动收集的。

SQL> select index_name,num_rows,last_analyzed from user_indexes where table_name='TAB1';

INDEX_NAME                       NUM_ROWS LAST_ANALYZED
------------------------------ ---------- -------------------
COL1                        7953249 2008-09-08 22:08:14
COL5                        7555980 2008-09-08 22:08:20
COL6                        7504441 2008-09-08 22:08:27

SQL> select TABLE_name,num_rows,last_analyzed from user_TABLES where table_name='TAB1';

TABLE_NAME                     NUM_ROWS LAST_ANALYZED
------------------------------ ---------- -------------------
TAB1                        7555980 2008-09-08 22:08:20

以下是数据库版本？

SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
PL/SQL Release 10.2.0.1.0 - Production
CORE    10.2.0.1.0      Production
TNS for Linux: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production

请高手指教？

[ 本帖最后由 duolanshizhe 于 2008-9-11 09:49 编辑 ]

关掉自动收集统计信息,自己收集,这里走全表明显不对了,才1行呢,col5的num_distinct大于254,所以没法用基于频率的,这个字段没必要收集柱状图

关键在于 oracle 自动收集的统计 还存在问题

自己分析一下看看。开个tar问问是不是bug

automation trade-off

QUOTE:

---

原帖由 duolanshizhe 于 2008-9-10 19:46 发表
select col1,col2,col3,c0l4,col5
from tab1
where col5 = '1.2.392.200036.9116.2.5.1.48.1215491107.1207119889.188062';

Execution Plan
----------------------------------------------------------
Plan hash value: 2354221835

------------------------------------------------------------------------------------
| Id  | Operation         | Name           | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |                |  1819K|   404M| 55890   (1)| 00:11:11 |
|*  1 |  TABLE ACCESS FULL| tab1           |  1819K|   404M| 55890   (1)| 00:11:11 |
------------------------------------------------------------------------------------

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

   1 - filter("col5"='1.2.392.200036.9116.2.5.1.48.1215491107.1207119889.188062')


这个表上col5上是由索引的，为啥没有使用？为啥优化器认为表中的记录数是 1819K，而实际上是7688K左右？

---

What if you add hint /*+ cardinality (tab1 7688000) */?

Can you check the miscalculation of cardinality with a 10053 trace? It's not easy to read but it may give a clue.

Yong Huang