現象：一條SQL的運行突然變得很慢。

select uidTable.column_value, first_name||' '||last_name,
company, job_title, upper(member_level), upper(service_value)
from (select * from table(select cast(multiset
(select b from bbb)as Taaa) from dual)) uidTable,member
where uidTable.column_value = member.login_id(+) and
member.site='alibaba' and member.site='test';
 

原因：經檢查錯誤得原因是用戶增加了一個條件member.site=test,造成連接的順序變化了，原來的驅動表是uidTable(最多1024條記錄），現在變成了member表做驅動(600W條）。所以這條語句變得特別慢。

但是既然是外連接，為什么連接的順序會改變呢？因為外連接的連接順序不是由COST決定的，而是由連接的條件決定的。發現執行計劃如下：

-------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost |
------------------------------------------------
| 0 | SELECT STATEMENT | | 1018 | 72278 | 8155 |
| 1 | NESTED LOOPS | | 1018 | 72278 | 8155 |
| 2 | VIEW | | 4072 | 69224 | 11 |
| 3 | COLLECTION ITERATOR SUBQUERY FETCH| | | | |
| 4 | TABLE access FULL | DUAL | 4072 | | 11 |
| 5 | TABLE ACCESS FULL | BBB | 41 | 287 | 2 |
| 6 | TABLE ACCESS BY INDEX ROWID | MEMBER | 1 | 54 | 2 |
|* 7 | INDEX UNIQUE SCAN | MEMBER_SITE_LID_PK | 4 | | 1 |
-------------------------------------------------
 

大家要問：“為什么根本就沒有執行外連接呢？”問題出在member.site='test'這個條件上，因為對外連接的表加了條件，造成外連接失效。改為member.site(+)='test'后，問題徹底解決。

---------------------------------
| Id | Operation | Name | Rows | Bytes | Cost |
-----------------------------------------------------
| 0 | SELECT STATEMENT | | 1018 | 72278 | 8155 |
| 1 | NESTED LOOPS | | 1018 | 72278 | 8155 |
| 2 | VIEW | | 4072 | 69224 | 11 |
| 3 | COLLECTION ITERATOR SUBQUERY FETCH| | | | |
| 4 | TABLE ACCESS FULL | DUAL | 4072 | | 11 |
| 5 | TABLE ACCESS FULL | BBB | 41 | 287 | 2 |
| 6 | TABLE ACCESS BY INDEX ROWID | MEMBER | 1 | 54 | 2 |
|* 7 | INDEX UNIQUE SCAN | MEMBER_SITE_LID_PK | 4 | | 1 |
-----------------------------------------------------