今天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问题，第一次的执行计划可能就是错误的，导致后来的计划都错误，得不偿失