因为条件是随机组合的，建联合索引的话，它的前导索引不一定会有值，在这种情况下oracle它自己在数据量稍大的情况下它不会去调用的·因为我试过了·······朋友还有别的招不

@不会代码的椰子: 是不是在过滤中出现了like '%开头的语句'

保证没有····你稍等会···我把sql发你

@刘宏玺: 发你短消息了，帮忙看看，谢谢

@不会代码的椰子: 

你要是保证没有like '%开头的语句'的话

还有一种优化方法

你不是a和bjoin吗

a的过滤条件加在查询a的子查询上

b的过滤条件加在查询b的子查询上

像这种

select * from 

(select * from a where a.1 = '' or a.2 = '') as a

left join 

(select * from b where b.1 = '' or b.2 = '') as b

on a.x = b.x

这样在join的时候形成的笛卡尔积就会小很多了，效率也会上来

@刘宏玺: 听起来好像有道理。。。但是我个人认为哈，这么写和where感觉是一样的，where也是两张便先过滤再join的····我还是先试试···

@不会代码的椰子: 不一样的，只有join的条件才先进行过滤，剩余的数据先做笛卡尔积，再做where，这样做肯定会提高效率的，而且过滤条件越多，查询越快，否则就是过滤条件越多，查询相对要慢一点

@刘宏玺: 哦···我不懂····然后建索引的问题还是没有解决···因为a表条件是随机组合的这次可能只有条件1下次可能是条件2和3，这样的话它不会走联合索引的

@不会代码的椰子: 那就每个查询字段单独建索引，这样效果虽然不是特别好，但是很有用

@刘宏玺: 但是单独建索引它执行计划会出现这么一条 TABLE ACCESS BY INDEX ROWID  这一条会很花时间

@刘宏玺:刘宏玺，再问你个问题我用组合索引中的某一列的条件去查询的时候，如果是输入的数据库中已有的数据比如“123456”就很快，如果当前数据库中没有“123456”这个数据那么你用它作为条件去查就十分慢跟没建索引似的 

@不会代码的椰子: 对啊，没有命中了，就会慢了

@刘宏玺: 好吧，谢谢啦。