使用綁定變量可以減少SQL PARSE，但是使用綁定變量有一個不好的地方，就是對于訪

問具有傾斜的列，可能使用錯誤的執行計劃。在Oracle 9i之前，如果WHERE 條件里面全

部使用綁定變量，那么只能使用固定的選擇性參數來確定執行計劃。

=操作和>=操作的選擇性為5%，范圍掃描的選擇性為25%。缺省值的方式可能生成不好的執

行計劃。所以Oracle 9i就出現了一個新的技術，bind peeking。什么是bind peeking呢

？當SQL第一次執行的時候，優化器會根據綁定變量來確定執行計劃（如果存在柱狀圖）

。BIND PEEKING只有當該SQL第一次執行的時候，進行HARD PARSE的時候才進行，第二次

調用該SQL，就不會再次進行BIND PEEKING。這種情況下，就存在另外一個風險，如果某

個列的傾斜性很厲害，那么使用BIND PEEKING就是不安全的，因為不同的參數代入，只能

走第一次執行時的執行計劃，那么執行計劃就像擲色子一樣，要靠運氣了。碰到這種情況

，應用就不應該使用綁定變量，而應該改為直接值了。
這時可以使用刷新一下共享池alter system flush shared_pool;
或者alter session set "_optim_peek_user_binds"=false;

我們可以通過隱含的參數來調整數據庫默認的bind peeking行為：

_OPTIM_PEEK_USER_BINDS。 如果我們想關閉Bind Variable Peeking，我們可以設置該參

數為 False 即可。

SQL>alter session set "_optim_peek_user_binds"=false

使用了Bind Var能提高性能主要是因為這樣做可以盡量避免不必要的硬分析(Hard Parse)

而節約了時間，同時節約了大量的CPU資源。

當一個Client提交一條Sql給Oracle后，Oracle 首先會對其進行解析(Parse)，然后

將解析結果提交給優化器(Optimiser)來進行優化而取得Oracle認為的最優的Query Plan

，然后再按照這個最優的Plan來執行這個Sql語句(當然在這之中如果只需要軟解析的話會

少部分步驟)。

當Oracle接到 Client提交的Sql后會首先在共享池(Shared Pool)里面去查找是否有之前

已經解析好的與剛接到的這一個Sql完全相同的Sql(注意這里說的是完全相同，既要求語

句上的字符級別的完全相同，又要求涉及的對象也必須完全相同)。當發現有相同的以后

解析器就不再對新的Sql在此解析而直接用之前解析好的結果了。這里就節約了解析時間

以及解析時候消耗的CPU資源。尤其是在OLTP中運行著的大量的短小Sql，效果就會比較明

顯了。因為一條兩條Sql的時間可能不會有多少感覺，但是當量大了以后就會有比較明顯

的感覺了。

但是，使用綁定變量的一個缺點是，給出的執行計劃并不一定就是SQL在真正應用程序里

所使用的執行計劃。這時我們就可以通過 event 10053 事件來查看。

總結

以上是生活随笔為你收集整理的oracle中bind peeking问题的解决方法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。