一次HASH JION過慢優化（2）

原創 轉載請注明出處

可以看到進行了笛卡爾集，再HASH JION的時候使用了過多的臨時表空間用于存儲HASH值，達到了2.6M。

而笛卡爾集是test1和test2做的。其實我們是有連接配接條件的，連接配接條件是

filter("A"."test"="B"."test" AND "A"."test1" I

              OR "A"."test2"="B"."test3")

但是優化器沒有這樣使用，而是先做了笛卡爾集然後再做了HASH JION然後把連接配接條件做為了過濾條件。

是以解決問題的關鍵在于讓優化器先做連接配接條件再HASH JION。

是以我改寫了以上片段如下：

其實就是用use_concat提示來告訴執行計劃用UNION ALL的方式來代替OR

（

USE_CONCAT

The USE_CONCAT hint forces combined OR conditions in the WHERE clause of a query to be transformed into a compound query using the UNION ALL set operator. Generally, this transformation occurs only if the cost of the query using the concatenations is cheaper than the cost without them.

The USE_CONCAT hint disables IN-list processing and OR-expands all disjunctions, including IN-lists.

）

最後修改完的語句如下，這個語句運作時間不到3秒。

SELECT  *

  FROM (SELECT row_.*, rownum rownum_

          FROM (select *

                  from (select  /*+  use_concat */  a.payrefdate,

                               ..................

                        union all

                       ..............

                        ............)

 WHERE rownum_ > 0;

現在非常快了。