继上一篇提到的UNION/UNION ALL会影响执行计划，再次碰到一个类似的问题。一个SQL加了DISTINCT跟不加DISTINCT的执行计划完全不同，导致执行时间差了好多倍。
原始的SQL如下所示, (注意DISTINCT)
执行计划如下所示,
这个执行计划最耗时的一步是"BUFFER SORT"执行了6982次。当然这个跟View - V_TEMP_口口_PROP_HIST 有一定关系。不过要知道 IN 子查询的结果集最多是1，因为用了ROWNUM=1. (其实在这个例子中结果集是NULL).
仔细看这个执行计划就会发现优化器是先对V_TEMP_口口_PROP_HIST 进行处理，然后进行过滤IN子查询! 这是个相当不高效的做法 - 注意执行计划中的 ”FILTER“ 操作。
但是当把DISTINCT去掉之后的话，执行计划就会大相径庭。
执行计划如下，
这次看到优化器还用了NL，而不是FILTER. 而且很聪明滴用了IN 子查询作为驱动表，然后跟外围查询做Nested Loop Join. 因为子查询的结果集为NULL，很显然JOIN操作其实也不会执行了，从"STARTS"可以看得很清楚！
有时候真是搞不清楚优化器是怎么生成执行计划的，郁闷... 这得了解优化器的实现机制才能得到答案了，我猜...
不过解决这个SQL的方式很简答了，就是把IN改成普通的表连接方式。”显示“地告诉优化器走表连接，而不是做FILTER操作。