在ITPUB 上看到一个帖子 http://www.itpub.net/thread-1875212-1-1.html

同一条SQL语句，只有查询条件不一样，查询返回的结果集都为0，一个走了全表扫描，一个走索引。查看全表扫描的SQL语句：
SQL走全表，产生了2422609个逻辑读，cost为535K
SQL> SELECT URL,YHZH,HFRZY,HFLR,SPURL,TPURL,YPURL,SCSJ,LY,JCSJ FROM YHXX_HFXX T 
2       WHERE T.URL=‘http://club.kdnet.net/dispbbs.asp?id=10165509_boardid=1‘   
3        /
no rows selected

Execution Plan
----------------------------------------------------------
Plan hash value: 2068618995
-------------------------------------------------------------------------------
| Id  | Operation         | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |           |   917K|   266M|   535K  (1)| 01:47:05 |
|*  1 |  TABLE ACCESS FULL| YHXX_HFXX |   917K|   266M|   535K  (1)| 01:47:05 |
-------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter("T"."URL"=‘http://club.kdnet.net/dispbbs.asp?id=10165509_b oardid=1‘)
             
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
    2422609  consistent gets
          3  physical reads
       5520  redo size
        880  bytes sent via SQL*Net to client
        458  bytes received via SQL*Net from client
          1  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          0  rows processed

强制HINT使用索引，产生4个逻辑读，但是cost比全表扫描高：643K --显然这个计划才是最好的，但是为什么cost会这么高呢？下面会分析.

SQL> SELECT  /*+index(YHXX_HFXX IDX_YHXX_HFXX_URL)*/
2       URL,YHZH,HFRZY,HFLR,SPURL,TPURL,YPURL,SCSJ,LY,JCSJ
3       FROM YHXX_HFXX 
4      WHERE URL=‘http://club.kdnet.net/dispbbs.asp?id=10165509_boardid=1‘  

5       /
no rows selected

Execution Plan
----------------------------------------------------------
Plan hash value: 518948569
-------------------------------------------------------------------------------------------------
| Id  | Operation                   | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |                   |   917K|   266M|   643K  (1)| 02:08:48 |
|   1 |  TABLE ACCESS BY INDEX ROWID| YHXX_HFXX         |   917K|   266M|   643K  (1)| 02:08:48 |
|*  2 |   INDEX RANGE SCAN          | IDX_YHXX_HFXX_URL |   917K|       | 10735   (1)| 00:02:09 |
-------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("URL"=‘http://club.kdnet.net/dispbbs.asp?id=10165509_boardid=1‘)

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

这里最奇怪的地方是当我们强制用hint的时候，虽然也走了索引，但是执行计划显示的estimated rows居然是917K和全部扫描一样多！

那就意味着优化器根据统计信息推断出里面所有的行的URL字段和where 条件里的URL=‘http://club.kdnet.net/dispbbs.asp?id=10165509_boardid=1‘ 值完全相同.这显然不可能。

这里我们注意到URL这个字符串值很长，在有直方图信息的时候，estimated row 首先考虑直方图信息，而且直方图只会取前32个字符生产一个浮点数，用这个浮

点数来计算直方图的统计信息。所以如果URL字段收集了直方图信息，并且URL的前32位完全相同，那么以为着在直方图统计的时候，会认为它们是一样的。

这里URL的前32都是“http://club.kdnet.net/dispbbs.as”，里面所有数据的URL都是针对同一个地址不同的id，这样就被认为是完全一样的了。

那么Oracle就认为数据要全部选出来，当然这种情况下扫描表是最好的了。因为选了第一个计划。

解决方案: 删除直方图统计信息

exec dbms_stats.gather_table_stats(ownname => ‘YQJK‘,tabname => ‘YHXX_HFXX‘,estimate_percent => 10,method_opt=>‘for columns  URL size 1‘,cascade=>TRUE) ;

删除直方图信息请参考 http://www.cnblogs.com/princessd8251/articles/3855707.html