下面来谈一谈系列1中讲到的Literal SQL和Shared SQL的比较。
首先是Literal SQL：
在有完整的统计信息并且SQL语句在predicate（限定条件）中使用具体值时，基于成本的优化器 (CBO)能工作的最好。比较下面
的语句：
和
对于第一个语句，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
是共享的。
