学习《Oracle 9i10g编程艺术》的笔记 (五)

 1.尽可能地使用绑定变量 不用开关CURSOR_SHARING=FORCE 
如果你愿意，这个特性会实现一个自动绑定器（auto-binder）。
如果有一个查询编写为SELECT * from EMP WHERE EMPNO = 1234，自动绑定器会悄无声息地把它改写成
SELECT * from EMP WHERE EMPNO = :x。这确实能动态地大大减少硬解析数，并减少前面讨论的库闩等待
时间——但是（凡事总有个“但是”），它可能有一些副作用。游标共享的一个常见副作用如下所示：
ops$tkyte@ORA10G> select /* TAG */ substr( username, 1, 1 )
2 from all_users au1
3 where rownum = 1;
S
-
B
ops$tkyte@ORA10G> alter session set cursor_sharing=force;
Session altered.
ops$tkyte@ORA10G> select /* TAG */ substr( username, 1, 1 )
2 from all_users au2
3 where rownum = 1;
SUBSTR(USERNAME,1,1)
这里到底发生了什么？为什么到第二个查询时SQL*Plus 报告的列突然变得这么大？要知道，这还是
同一个查询呀！如果查看一下游标共享设置为我们做了些什么，原因就会很清楚了（还会明白其他一些问
题）：
游标共享会删除查询中的信息。它找到每一个直接量（literal），包括内置求子串函数（substr）的
参数，直接量就是我们使用的常量。它把这些直接量从查询中删除，并代之以绑定变量。SQL 引擎再也不
知道这个列是长度为1 的子串，它的长度是不确定的。另外，可以看到where rownum = 1 现在也已经绑定。
看上去似乎不错；不过，优化器把一个重要的信息也一并删除了。它不知道“这个查询将获取一行”；现在
只认为“这个查询将返回前N 行，而N 可能是任何值”。实际上，如果加上SQL_TRACE=TRUE 后再运行这些
查询，你会发现每个查询使用的查询计划都不同，它们完成的工作量也大相径庭。考虑以下查询：
------------------------------
B
ops$tkyte@ORA10G> select sql_text from v$sql
2 where sql_text like 'select /* TAG */ %';
SQL_TEXT
-------------------------------------------------------------------------------
select /* TAG */ substr( username, 1, 1 ) from all_users au1 where rownum = 1
select /* TAG */ substr( username, :"SYS_B_0", :"SYS_B_1" ) from all_users au2 where
rownum = :"SYS_B_2"
select /* TAG */ substr( username, 1, 1 )
from all_users au1
where rownu