關於DSS中的繫結變數

今天itpub論壇上有個帖子討論繫結變數,總結一下.

繫結變數在oltp中的作用眾所周知,為何在DSS中應用不多?

biti:

針對 oltp 型別，頻繁地執行的短小sql，才會考慮解析問題

DSS 中是大查詢，執行的次數少，併發程式少 ，考慮 解析幹嗎？

複雜查詢的含義，我想是指比較大的查詢時間長的，這樣的話解析消耗的資源比例很小，最佳化的重點不在解析上

lihaibolw:

最重要的原因是：
邦定變數會嚴重影響最適合的執行計劃的產生

簡單的例子：
select * from a where a<10;
邦定變數的話，執行計劃都一樣
不邦定的話，oracle會根據表，索引的統計資訊決定是否適用索引。

husthxd:

準確來說是DSS中的查詢與bind var扯不上關係.
解析的時間與查詢的時間相比是九牛一毛,反而會影響執行計劃的生成.

Q:

前面各位說的,好像都是在dss系統中沒有必要進行繫結變數,好像沒有說明如果繫結了變數,會有什麼壞處,我覺得,如果繫結了,也不會有什麼壞處的,為何oracle反而不推薦? 頂多也就是沒有很大意義,這裡不推薦的原因,難道就是你所說的"反而會影響執行計劃的生成" ? 對於dss系統來說,如果繫結變數的時間可以忽略,那麼執行計劃生成的時間為何就不能忽略? 就是因為影響了執行計劃生成的時間,導致oracle不推薦在dss中使用繫結變數?

A:

biti:

不是說影響執行計劃生成時間，而是有可能，產生不同的執行計劃，這才是關鍵！

當然，使用bind var 的收益幾乎忽略不記，那還bind 幹嗎呢？

husthxd:

There could be orders of magnitude difference in the response time between the two execution paths so using the literal statement is preferable if you want CBO to work out the best execution plan for you. This is typical of Decision Support Systems where there may not be any 'standard' statements which are issued repeatedly so the chance of sharing a statement is small. Also the amount of CPU spent on parsing is typically only a small percentage of that used to execute each statement so it is probably more important to give the optimizer as much information as possible than to minimize parse times.

如果sql語句共享的機會不大，parse time跟sql執行時間比較起來可以忽略不計的情況下使用literal sql會是一個較好的選擇，因為可以更快的獲得更好的執行計劃.

piner:

關鍵是，在資料倉儲環境中，
一是語句執行少
二是語句執行時間長
三是語句可能本身就很複雜，變化很多

1、在這樣的條件下，就算繫結，重用率幾乎為0，何苦。
2、不繫結，硬分析也不至於幾秒吧（木跟言），當然也有幾秒的（很少），不過這樣的語句執行時間也很長了，必要性也沒有
3、繫結變數的確可能影響執行計劃，因為peeking問題，第一次的執行計劃可能就是錯誤的，導致後來的計劃都錯誤，得不償失