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

核心提示： 优化程序选择对 CUSTOMERS 表进行全表扫描，当我们仅搜索 CT（其数量只占记录总数的 5％）时，Oracle数据库11g新特性：自适应游标与SQL计划管理(4)，难道不应该使用索引吗？是什么原因使优化程序选择全表扫描而非索引扫描呢？答案是一种称为绑定观察 的现象，先前，数据库会对其

优化程序选择对 CUSTOMERS 表进行全表扫描。当我们仅搜索 CT（其数量只占记录总数的 5％）时，难道不应该使用索引吗？是什么原因使优化程序选择全表扫描而非索引扫描呢？

答案是一种称为绑定观察 的现象。先前，当您使用设置为 'NY' 的绑定变量值运行该查询时，优化程序必须为查询的第一次运行进行艰难的分析。在这样做的同时，优化程序观察绑定变量来确定为其分配的值。该值是 'NY'.由于 'NY' 的数量大约占总行数的 95%，优化程序选择了全表扫描（与预期的情况相同）。另外，它还冻结了查询的计划。接下来，当我们使用设置为 'CT' 的变量值运行同一个查询时，优化程序不会重新计算计划，而是使用了与之前相同的计划，即使该计划不是满足目标的最佳方案。如果您在查询中使用了文字值 'CT' 而非绑定变量，那么优化程序会选择正确的计划。

因此，如您所见，尽管绑定变量在大多数情况下都非常有效，当值的选择性将显著影响计划时（正如在此示例中，值 'CT' 和 'NY' 的选择性分别为 5％ 和 95％），绑定变量并不可靠。如果数据分布均匀，所有值的选择性几乎相同，执行计划将保持不便。因此，聪明的 SQL 编码人员将会选择在何时打破使用绑定变量的基本准则，改用文字值。

自适应游标

但如果您没有很多聪明的编码人员，或者没有时间重新编写这些语句，该怎么办？Oracle 是否提供了一些智能的替代方案？

是这样的。使用 Oracle 数据库 11g，游标突然拥有了一种新的智能。不是在执行查询的时候盲目使用已缓存的执行计划，而是在绑定变量的值更改时，根据实际情况确定是否需要重新计算计划。如果游标中含有绑定变量，数据库会对其进行观察，确定传递给变量的值的类型以及是否需要重新计算计划。如果需要重新计算计划，则游标标记为 "Bind-Sensitive".