【IT168 技术文档】今天开发人员让我优化一个sql：

Select Item.*
From Item Item
Where Item.Item_Id in (15056, 14697);

　　这个item表很大，sql执行起来很慢。

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=12795 Card=2 Bytes=1
316)

1 0 TABLE ACCESS (FULL) OF 'ITEM' (Cost=12795 Card=2 Bytes=131
6)



Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
134234 consistent gets
26568 physical reads
2184 redo size
3336 bytes sent via SQL*Net to client
503 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
2 rows processed

　　在这个例子中，item_id是item表的主键。这里慢的原因是in操作不能用到索引，做全表扫描，但为什么不能用索引呢？

　　实际上，oracle在处理in的时候是转换成or进行处理的，如：

　　a in (1,2)相当于 a=1 or a=2

　　而对于b*tree索引来说，对于or操作是不会用到索引的。知道原因，下面就要找出解决方法了。

　　方法一、从b*tree索引着手

　　这种方法就是想办法让查询可以走b*tree索引。要走btree索引，就要去掉or操作，所以把查询改成一个等价的sql：

SQL> Select Item.* From Item Item Where Item.Item_Id in (14697)
2 union all
3 Select Item.* From Item Item Where Item.Item_Id in (15056);


Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=6 Card=2 Bytes=1316)
1 0 UNION-ALL
2 1 TABLE ACCESS (BY INDEX ROWID) OF 'ITEM' (Cost=3 Card=1 B
ytes=658)

3 2 INDEX (UNIQUE SCAN) OF 'PK_ITEM' (UNIQUE) (Cost=2 Card
=1)

4 1 TABLE ACCESS (BY INDEX ROWID) OF 'ITEM' (Cost=3 Card=1 B
ytes=658)

5 4 INDEX (UNIQUE SCAN) OF 'PK_ITEM' (UNIQUE) (Cost=2 Card
=1)


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

　　从输出结果可以看出，sql已经可以有索引了，效率也得到大幅提高。但这种办法有缺陷：
如果in list的个数不确定，且如果in list较多的话，拼sql都是一个问题。我这个应用就是这种情况。