Oracle数据库11g新特性：自适应游标与SQL计划管理

核心提示： 在此示例中，<StateCode> 在概念上被称为绑定变量，Oracle数据库11g新特性：自适应游标与SQL计划管理(2)，该变量是将在执行期间传递的值的占位符，绑定变量的表示格式为 ：VariableName，且索引扫描将非常昂贵，因此这是一次正确的操作，如下所示：wher

在此示例中，<StateCode> 在概念上被称为绑定变量，该变量是将在执行期间传递的值的占位符。绑定变量的表示格式为 ：VariableName，如下所示：

where state_code = :state_code

如果您的代码中不含有绑定变量，而是使用 where state_code = 'CT' 等对文字值的引用，您可以通过指定一个初始化参数将所有文字强制转换成绑定变量：

cursor_sharing = force

该参数将导致语句 where state_code = 'CT' 被重新编写为 where state_code = "：SYS_0001"，其中 SYS_0001 是系统生成的变量名。此方法将使这些语句变成相同的语句。

绑定变量的问题

既然绑定变量如此有效，我们为什么不一直使用这种变量呢？我们不是拥有一种灵丹妙药 — cursor_sharing — 可以将所有糟糕的代码转换成可共享的语句吗？（那些已经熟悉其中理由（尤其是绑定观察概念）的读者可以直接跳至“自适应游标”一节。）

假设 STATE_CODE 列有一个索引。该列中的值如下所示：

select state_code, count(1)
from customers
group by state_code;
ST　 COUNT(1)
-- ----------
NY　　 994901
CT　　　 5099

如您所见，数据出现了严重的偏差；大约 5% 的行中含有 'CT'，而其余的行中含有 'NY'.考虑到各州的人口数量，得到这种结果不足为奇。现在，让我们看一看为之前显示的查询生成了哪种类型的执行计划：

　　SQL> set autot traceonly explain
SQL> select * from customers where state_code = 'NY' and times_purchased > 3
　2　/
　　Execution Plan
----------------------------------------------------------
Plan hash value: 2008213504
　　-------------------------------------------------------------------------------
| Id　| Operation　　　　 | Name　　　| Rows　| Bytes | Cost (%CPU)| Time　　 |
-------------------------------------------------------------------------------
|　 0 | SELECT STATEMENT　|　　　　　 |　 895K|　　26M|　1532　 (9)| 00:00:19 |
|*　1 |　TABLE ACCESS FULL| CUSTOMERS |　 895K|　　26M|　1532　 (9)| 00:00:19 |
-------------------------------------------------------------------------------
　　Predicate Information (identified by operation id):
---------------------------------------------------
　　 1 - filter("TIMES_PURCHASED">3 AND "STATE_CODE"='NY')

该查询执行了一次全表扫描 － 由于该查询返回 95％ 的行，且索引扫描将非常昂贵，因此这是一次正确的操作。现在，使用 'CT' 执行同一个查询：