【讨论】请教同一条SQL执行计划不一致的问题

limengjia

同一条SQL语句，只有查询条件不一样，查询返回的结果集都为0，一个走了全表扫描，一个走索引。查看全表扫描的SQL语句：

SQL走全表，产生了2422609个逻辑读，cost为535K
SQL> SELECT URL,YHZH,HFRZY,HFLR,SPURL,TPURL,YPURL,SCSJ,LY,JCSJ
FROM YHXX_HFXX T
WHERE T.URL='http://club.kdnet.net/dispbbs.asp?id=10165509_boardid=1'  2    3  
  4  /
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
SQL> SELECT  /*+index(YHXX_HFXX IDX_YHXX_HFXX_URL)*/
URL,YHZH,HFRZY,HFLR,SPURL,TPURL,YPURL,SCSJ,LY,JCSJ
FROM YHXX_HFXX
WHERE URL='http://club.kdnet.net/dispbbs.asp?id=10165509_boardid=1'  2    3    4  
  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或者sql profile的方法让SQL走索引？谢谢

bell6248

收集一下表的统计信息， 相信CBO， 不要手工指定Hints, 另外， 如下语句结果是如何的？

select count(*), count(distinct url) from yhxx_hfxx

udfrog

url。。。

lastwinner

同2楼，估计是统计信息不准

limengjia

bell6248 发表于 2014-7-1 09:55
收集一下表的统计信息， 相信CBO， 不要手工指定Hints, 另外， 如下语句结果是如何的？

select count(*) ...

我做了表和索引的分析：
exec dbms_stats.gather_table_stats(user,'YHXX_HFXX',cascade=>TRUE);

exec dbms_stats.gather_table_stats(ownname => 'YQJK',tabname => 'YHXX_HFXX',estimate_percent => 10,method_opt => 'for all indexed columns',cascade=>TRUE);

不知道这样的方法对不对

limengjia

lastwinner 发表于 2014-7-1 10:24
同2楼，估计是统计信息不准

SQL基础不好，准备报dataguru怀老师的课程系统学习一下

udfrog

lastwinner 发表于 2014-7-1 10:24
同2楼，估计是统计信息不准

统计信息不准，造成执行计划不正确，倒是很正常，
但是他这个索引范围扫描的基数估计竟然也是917k，就比较奇怪了
怀疑是url这个字段搞的鬼。
做了个试验，和楼主的现象一致。
因为直方图默认只取前32个字节进行统计，而url显然是超长的，截取了前32个字节之后，可能大部分或者所有的值就一样了，这样的方法，无论怎么收集统计信息都是没用的。

limengjia

udfrog 发表于 2014-7-1 10:39
统计信息不准，造成执行计划不正确，倒是很正常，
但是他这个索引范围扫描的基数估计竟然也是917k，就比 ...

牛啊，我把查询条件中前32位改动或者删除1位就走索引了。
那就是说只能用SQL PROFILE绑定咯？

Naldonado

udfrog 发表于 2014-7-1 10:39
统计信息不准，造成执行计划不正确，倒是很正常，
但是他这个索引范围扫描的基数估计竟然也是917k，就比 ...

佩服。我也觉得统计信息好像对的。但是不知道哪里出问题了。活到老，学到老啊！

lastwinner

limengjia 发表于 2014-7-1 10:34
SQL基础不好，准备报dataguru怀老师的课程系统学习一下

提前谢谢支持！