一般来说使用联合索引比使用多个单独索引要有效很多，甚至有时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博客

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