in-list iterator是針對in後面是常量集合的一種處理方法。此時優化器會遍歷目標sql中in後面的常量集合中的每乙個值，然後去做比較，看目標結果集中是否存在和這個值匹配的記錄。如果存在匹配記錄，則這個記錄就會成為該sql的最終返回結果集中的一員；如果不存在匹配記錄，則優化器會繼續遍歷in後面的常量集合中的下乙個值，直到該常量集合遍歷完畢。
關於in-listiterator，有如下幾點需要注意：
（1）in-listiterator是oracletf對目標sql的in後面是常量集合的首選處理方法，它的處理效率通常都會比in-listexpansion高。
in-list expansion/or expansion(in-list expansion又稱為or expansion，兩者等價）是針對in後面是常量集合的另外一種處理方法，它是指優化器會把目標sql中in後面的常量集合拆開，把裡面的每個常量都提出來形成乙個分支，各分支之間用unionall來連線，即in-listexpansion的本質是把帶in的目標sql等價改寫成以unionall連線的各個分支。
in-list expansion的好處是改寫成以unionall連線的分支後，各個分支就可以各自走索引、分割槽修剪(partitionpruning)、表連線等相關的執行計畫而互不干擾。它的壞處是未做in-listexpansion之前優化器只需要解析乙個目標sql並決定其執行計畫，而一旦做了in-listexpansion後優化器就要對等價改寫後的每乙個unionall分支都執行同樣的解析、決定執行計畫的工作，也就是說，等價改寫後的目標sql的解析時間會
隨著unionall分支的遞增而遞增。這意味著當in後面的常量集合所包含的元素數量非常多的時候，做
in-listexpansion僅解析的時間可能就會非常長，這就是in-listiterator通常會比fn-listexpansion的效率高
的原因。正是基於上述原因，做了in-listexpansion的等價改寫sql的執行效率並不一定會比原sql高，這
也就意味著in-listexpansion—定也是基於成本的，即只有當經過in-listexpansion後的等價改寫sql的成
本值小於原sql的成本值時，oracle才會對目標sql執行in-listexpansion。
（1）目標sql的in後面是子查詢而不是常量的集合。
（2）oracle未對目標sql的in後面的子查詢做子查詢展開。
基於Oracle的SQL優化 學習（六）
如何得到真實的執行計畫 得到目標sql的執行計畫，大致有以下四種方式 1 explain plan 命令 2 dbms xplan包 3 sqlplus中的autotrace開關 4 10046事件 除了第四種，其他三種方法都有可能是不准的。判斷乙個sq計畫任務任務是否準確，就要看目標sql是否真正...
基於Oracle的SQL優化 學習（十一）
當繫結變數窺探被啟用後，每當 oracle 以硬解析的方式解析使用了繫結變數的目標 sql 時，此時對應的是軟解析 軟軟解析 即便此時對應繫結變數的具體輸入值和之前硬解析時對應的值不同，orade 也會沿用之前硬解析時所產生的解析樹和執行計畫，而不再重複執行上述 窺探 的動作。繫結變數分級 bind...
sql優化學習記錄
面試被問到了sql優化，回來學習一下，看別人的文章，自己在手動記錄一遍，算是加深印象吧。所謂sql優化，本質上有三種選擇 1 降低目標sql語句的資源消耗 2 並行執行目標sql語句 3 平衡系統的資源消耗 以上的說明比較難理解，還是記錄一些簡單易懂的方法 1 對查詢進行優化，避免全表查詢。2 避免...