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

下面来谈一谈系列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

是共享的。