[Oracle]變量綁定

　　Parent-Child cursor (父子游標)

　　父游標：只要SQL語句文本相同，它們就對應同一個parent cursor。

　　子游標：在某些情況下，雖然SQL語句的文本相同，但是因為其它因素不同(這些因素可以在視圖V$SQL_SHARED_CURSOR中查看)，導致產生不同的child cursor。(重新生成child cursor，也就意味著一次硬解析)

　　cursor_sharing

　　對于是否使用綁定變量這個問題，最好是交給應用程序決定，在數據庫層面是很難正確判斷。(這也是為什么cursor_sharing參數默認值為exact)

　　但是，有些時候，由于應用程序沒有正確使用綁定變量，導致數據庫性能問題，又因為此時系統已上線，要改應用代碼有很多的阻力(大多都是人為的因素)。為此，Oracle提供了應急(事后補救)方案，可以在數據庫級別強制使用綁定變量。

　　當cursor_sharing=force時，對于只有謂詞條件不一樣的SQL語句，Oracle統統都認為是一樣的。但是這樣會有一個問題，就是可能后續的執行計劃不是最優。為了解決這個問題，可以設置cursor_sharing=similar，這樣如果謂詞條件的變化可能生成不同的執行計劃，Oracle都會進行硬解析(生成child cursor)。

　　但是，設置cursor_sharing=similar要非常小心，因為有很多bug，需要經過充分的測試才能在生產庫上修改。

　　Bind Peeking (變量窺視)

　　從Oracle9i開始，Oracle在第一次解析SQL(hard parse)時，如果SQL上有變量綁定，會查看這個變量的值，以便于更準確的指定執行計劃;但在后續的分析中(soft parse)，將不會理會這個變量的值。

　　適用場景

　　執行計劃幾乎不改變(oltp)

　　大量的并發

　　大量的除謂詞外幾乎相同的SQL。

　　不適用場景

　　執行計劃會隨變量值的變化而改變。

　　少量的SQL(OLAP).

　　ACS (Adaptive Cursor Sharing)

　　Oracle11g用于解決變量綁定帶來的負面影響，通過不斷觀察bind的值，來決定新的SQL是否重用之前的執行計劃，解決綁定變量導致后續執行計劃不變的問題。

　　缺點

　　更多的硬分析

　　產生更多的子游標，需要更多的內存。

　　消耗更多的CPU

　　綁定變量的適用場景

　　適用于OLTP

　　用戶并發很高

　　表中有主鍵

　　操作的數據少

　　執行計劃穩定

　　SQL的重復率高

　　不適用于OLAP

　　執行計劃多變

　　并發用戶少

　　SQL解析對系統性能影響小