【每日一摩斯】-Shared Pool優化和Library Cache Latch衝突優化 (1523934.1)-系列2

bisal發表於2013-09-07
優化

下面來談一談系列1中講到的Literal SQL和Shared SQL的比較。


首先是Literal SQL：

在有完整的統計資訊並且SQL語句在predicate（限定條件）中使用具體值時，基於成本的優化器 (CBO)能工作的最好。比較下面

的語句：

SELECT distinct cust_ref FROM orders WHERE total_cost < 10000.0;

和

SELECT distinct cust_ref FROM orders WHERE total_cost < :bindA;

對於第一個語句，CBO可以使用已經收集的histogram來判斷是否使用全表掃描比使用TOTAL_COST列上索引掃描快（假設有索

引的話）。第二個語句CBO並不知道繫結變數":bindA"對應行數的比例，因為該繫結變數沒有一個具體的值以確定執行計劃。

例：":bindA" 可以是 0.0或者99999999999999999.9。

Orders表上兩個不同的執行路徑的響應時間可能會不同，所以當你需要CBO為你選出最好的執行計劃的時候，選用使用literal語句

會更好。在一個典型的Decision Support Systems（決策支援系統）中，重複執行'標準'語句的時候非常少，所以共享一個語句的

機率很小，而且花在Parse上的CPU時間只佔每個語句執行時間的非常小一部分，所以更重要的是給optimizer儘可能詳細的信

息，而不是縮短解析時間。 

這裡補充一下，這要說的其實是繫結變數窺探對執行計劃的影響，繫結變數窺探只在第一次SQL執行硬解析時才會建立，即使後

面資料量有了明顯的改變，但仍舊使用原來的執行計劃，這就可能產生查詢效率的問題，所以繫結變數不是任何時候都會起到好

的作用，需要具體問題具體分析。


Shared SQL：

如果應用使用了literal (無共享) SQL，則會嚴重限制可擴充套件性和生產能力。在對CPU的需求、library cache和shared pool latch的

獲取和釋放次數方面，新SQL語句的parse成本很高。(補充：因為之前說過，這裡會有latch持有的等待。)

比如：僅僅parse一個簡單的語句就可能需要獲取和釋放library cache latch 20或者30次。

除非它是一個臨時的或者不常用的SQL，並且需要讓CBO得到儘可能多的資訊來生成一個好的執行計劃，否則最好讓所有的SQL

是共享的。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7192724/viewspace-772345/，如需轉載，請註明出處，否則將追究法律責任。

相關文章