Oracle直方图导致SQL不走索引.
在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
郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。