"DISTINCT" make huge difference

繼上一篇提到的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操做。