如何得到真實的執行計畫
得到目標sql的執行計畫，大致有以下四種方式：
1、explain plan 命令
2、dbms_xplan包
3、sqlplus中的autotrace開關
4、10046事件
除了第四種，其他三種方法都有可能是不准的。判斷乙個sq計畫任務任務是否準確，就要看目標sql是否真正被執行。
對使用第一種方法（即使用 explain plan 命令）得到的執行計畫而言，因為此時目標 sql 並沒有被實際執行，所以用該方法得到的執行計畫有可能是不准的，尤其是在日標 sql 包含繫結變數時．在預設開啟繫結變最窺探（ bind peeking ）的情況下，對含繫結變裡的目標 sql 使用 explain plan 得到的執行計畫只是乙個半成品，oracle在隨後對該 sql 的繫結變數進行窺探後就得到了這些繫結變數具體的值，此時oracle很可能會對上述半成品的執行計畫做調整，一旦做了調整，使用 explain plan 命令得到的執行計畫就不准了。
第二種方法包裡含有四種方式，第一種方式是用於檢視explain plan命令得到的目標sql的執行計畫，顯然是不準確的。所以如下方式：
select * from table(dbms_xplan.display_cursor(null,null,'advanced'));
select * from table(dbms_xplan.display_cursor('sql_id/hash_value',child_cursor_number,'advanced'));
select * from table(dbms_xplan.display_awr('sql_id')); --用於已經被age out 出shared pool的情況
第三種方法（即使sqlplus中的autotrace開關）而言，你可以選執行如下三種方式中的一種來幵啟autotrace開關：
set autotrace on (可以簡寫為 set autot on):
set autotrace traceonly (可以簡寫為 set autot trace);
set autotrace traceonly explain (可以 簡寫為 set autot trace exp );
上述三種方式中，當使用set autotrace on和set autotrace traceonly時，目標sql都已經被實際執行過了，正是因為被實際執行過,所以在set autotrace on和set autotrace traceonly的情況下我們能看到到目標sql的實際資源消耗情況，當使用set autot trace exp，如果執行的是select語句，則該select語句並沒有被oracle實際執行，但如果執行的是dml語句，情況況就不一樣了，此時的dml語句是會被oracle實際執行的.
如果目標sql的執行計畫還在shared pool中，那就可以以使用指令碼display_cursor_9i.sql和儲存過程printsql來得到其真實的執行計畫和資源消耗情況，兩個檔案的位址是：
如果目標sql的執行計畫已經被age out出shared pool，可以執行
dbms_xplan.display_awr或者使用awr sql報告和statspack sql報告來得到歷史執行計畫
和資源消耗。
基於Oracle的SQL優化 學習（十一）
當繫結變數窺探被啟用後，每當 oracle 以硬解析的方式解析使用了繫結變數的目標 sql 時，此時對應的是軟解析 軟軟解析 即便此時對應繫結變數的具體輸入值和之前硬解析時對應的值不同，orade 也會沿用之前硬解析時所產生的解析樹和執行計畫，而不再重複執行上述 窺探 的動作。繫結變數分級 bind...
基於Oracle的SQL優化 學習（十七）
in list iterator是針對in後面是常量集合的一種處理方法。此時優化器會遍歷目標sql中in後面的常量集合中的每乙個值，然後去做比較，看目標結果集中是否存在和這個值匹配的記錄。如果存在匹配記錄，則這個記錄就會成為該sql的最終返回結果集中的一員 如果不存在匹配記錄，則優化器會繼續遍歷in...
sql優化學習記錄
面試被問到了sql優化，回來學習一下，看別人的文章，自己在手動記錄一遍，算是加深印象吧。所謂sql優化，本質上有三種選擇 1 降低目標sql語句的資源消耗 2 並行執行目標sql語句 3 平衡系統的資源消耗 以上的說明比較難理解，還是記錄一些簡單易懂的方法 1 對查詢進行優化，避免全表查詢。2 避免...