联合索引多执行计划的影响一例

    一般来说使用联合索引比使用多个单独索引要有效很多，甚至有时2种情况的执行计划天差地远。

   今天就遇到了这么个情况：

           库里有个SQL执行相当慢，CPU COST极高，估算的TIME有10多分钟。SQL如下

select   count(1)  from article where site in (22)  and   type >= 0;

很简单的一条SQL，CBO居然给出的计划

SELECT STATEMENT, GOAL = ALL_ROWS  

SORT AGGREGATE  

VIEW              index$_join$_002 

   HASH JOIN   

   
    INDEX FAST FULL SCAN       ARTICLE_SITE 

    INDEX FAST FULL SCAN      ARTICLE_TYPE

CBO选择了分别走2个索引，然后对2个索引做了HASH JOIN 然后再生成视图，之所以这样选择是为了避开2次回表扫描 table scan by rowid...   ，但当数据量很大的时候，HASH JOIN 很明显会使用到大量的TEMP表空间，导致大量的IO操作。

这种情况如果在SITE和TYPE上创建联合索引，主动的避开了回表扫描，执行计划就会产生天翻地覆的变化

SELECT STATEMENT, GOAL = ALL_ROWS   
 SORT AGGREGATE    
  INDEX RANGE SCAN     ARTICLE_COMP 

直接一个范围扫描就解决问题，执行速度大幅度提高，重要的是避免了DISK IO的操作，TIME从10多分钟下降到了几秒。

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

转载于:http://blog.itpub.net/13351439/viewspace-445564/