基礎：
從oracle9i，開始的bind peeking
（但是使用繫結變數有乙個不好的地方，就是對於訪問具有傾斜的列，可能使用錯誤的執行計畫。
當sql第一次執行的時候，優化器會根據繫結變數來確定執行計畫（如果存在柱狀圖）。bind peeking只有當該sql第一次執行的時候，進行hard parse的時候才進行，第二次呼叫該sql，就不會再次進行bind peeking。這種情況下，就存在另外乙個風險，如果某個列的傾斜性很厲害，那麼使用bind peeking就是不安全的，因為不同的引數代入，只能走第一次執行時的執行計畫，那麼執行計畫就像擲色子一樣，要靠運氣了。碰到這種情況，應用就不應該使用繫結變數，而應該改為直接值了。
bind peeking對於使用繫結變數的情況下，選擇較優的執行計畫有一定的作用
bind peeking只有在存在柱狀圖的情況下才能工作
bind peeking只在做hard parse的時候才產生，隨後的執行如果不需要hard parse就不會進行bind peeking，這種情況和cursor_sharing無關
由於以上原因，使用繫結變數的時候可以有效的減少parse
對於使用不同繫結變數執行計畫應該不同的情況，建議不要使用繫結變數，否則可能會產生隨機的執行計畫（硬分析後的所有執行都使用第乙個執行計畫，執行計畫和第一次執行的引數有關）
oracle11g提供新的特性自適應游標共享(adaptive cursor sharing),對於乙個同樣繫結變數的sql可以有多個執行計畫，從而達到動態優化執行計畫的作用（
現在最簡單的方法： 可以直接查詢v$sql_plan表；
要強調的一點，sqlplus中開啟autotrace看到的執行計畫實際上是用explain plan 命令得到的，explain plan 命令不會進行bind peeking。應該通過v$sql_plan檢視sql的真實的執行計畫。
（
oracle如何看執行計畫
文章寫的不錯,原文請看 另外，最近公司舉行sql優化大賽，下面是自己的一些總結 1.首先要理解sql的意圖，這樣才能等價的改寫出sql 2.要保證執行的正確性 比如這次的left join，還有上次的建立序列 3.建立索引是第一步，建立索引後要考慮索引能否被用到 執行計畫是否走所建的索引，索引欄位上...
mysql執行計畫看必會（explain講解）
explain會看到的資訊我經常看的的是id，type，rows這幾個1 id表示查詢中執行select子句或操作表的順序，id執行順序從大到小，即id越大越先被執行，如果id相同，則從上到下 2 select type表示查詢中每個select子句的型別 簡單 or 複雜 1 查詢中不包含子查詢或...
看MSSQL的執行計畫,學習集合操作
有資料表company,跟products表,分別是企業表跟產品表,每個企業有0個或多個產品,現在需要選出有產品的企業,sql查詢如下 select username,id from company as t where t.attproperty 00000000000000001000 and ...