用Oracle 9i全索引扫描快速访问数据

函数索引基础

在Oracle9i之前，全索引扫描只有当创建的索引没有空值时才可以使用，也就是说，Oracle建立索引时必须用一个NOT NULL子句才可以使用该索引。由于Oracle9i支持用函数（function-based）索引实现的唯索索引扫描，这种情况大大改观。

简单回归一下，函数索引是Oracle8的一个重要改进，因为它提供了一种有效的消除无必要长表全扫描的机制，由于函数索引可以在任何查询语句中的WHERE子句中精确复制，Oracle总会用一个索引来匹配上SQL查询的WHERE子句。

现在，我要会用一个student表来举一个简单的例子来解释全索引扫描如何与函数索引一起工作的过程。

创建student表

(student_name varchar2(40), date_of_birth date);

使用这个表，创建与表中所有列相关联的函数索引。在本例中，该函数为initcap（即大写每个单词的首字母）和to_char（即把一个数字变成字符）：

create index whole_student
on student
(initcap(student_name), to_char(date_of_birth,’MM-DD-YY’));

定义完函数索引后，Oracle9i中任何可以引用这些列（column）的SQL语句都可以使用全索引扫描。下面是SQL匹配函数索引的查询例子：

select * from student
where initcap(student_name) = ‘Jones’;
select * from student
where to_char(date_of_birth,’MM-DD=YY’) = ’04-07-85’;

用函数索引来调用全索引扫描

Oracle9i只要可能就会使用函数索引并在函数索引的基础上调用全索引扫描。如果SQL优化器统计结果表明使用全索引扫描的速度将会超过通过索引的b-树访问的速度，那么Oracle9i就会这么做。

下面是用函数索引调用唯索扫描的准则。所有的SQL谓词匹配索引中的列，查询必须从表中返回足够多的行，这样做的目的是为了让代价优化器（cost-based optimizer）来判断全索引扫描是否要比传统的索引访问方法要快。是否调用全索引扫描的决定取决于下面几个参数设置：

代价优化器的适当统计数字——这个计划（schema）最近已经分析过了，而且optimizer_mode参数不能设置为RULE。

索引的并行程度——注意索引的并行程度是独立设置的；索引并没有继承表的并行程度。

optimizer_index_cost_adj的设置——它控制代价优化器是否倾向于全索引扫描。

db_file_multiblock_read_count的设置——这个参数影响到全索引扫描的代价。这个值越高，全索引扫描的代价也就会越“便宜”。

索引的直方图表示——对偏移（skewed）索引，它帮助代价优化器评估查询返回的行数。

Oracle的一个重要提高

在函数索引基础上的快速全索引扫描是Oracle9i的另一个提高性能的途径。当数据库迁移到Oracle9i时，许多数据库自动开始使用这个新的执行计划。不过，当SQL代价优化器决定是否选择全索引扫描时，还要考虑几个因素。Oracle专业人员需要适当设置参数，以确保代价优化器不会用不合适的方式使用快速全索引扫描——这一点需要特别注意。