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

创建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专业人员需要适当设置参数，以确保代价优化器不会用不合适的方式使用快速全索引扫描——这一点需要非凡注重。

评论加载中…