浅谈VFP中的RUSHMORE技术

摘要：本文在Visual FoxPro中用实例验证不同情况下使用RushMore技术对查询速度的影响，讨论这项技术的基本特点，并根据其特点提出优化程序结构的方法，以达到加快数据访问的目的。

关键词：RushMore技术；VFP；索引

中图分类号：TP311.13 文献标识码：A

数据查询是数据库技术非常重要的一个部分，数据查询速度的快慢直接影响到程序的执行效率。在VFP中引入索引的概念来解决大型数据库中数据查询问题，RushMore技术是VFP中的一种数据查询技术，它利用索引优化对数据的访问。使用RushMore技术，对一些复杂的表操作时比不使用这项技术要快成百上千倍，因此，能否正确运用这种技术对程序的执行效率有着意想不到的作用。

1 RushMore技术实例耗时分析

既然RushMore技术在VFP中有着如此重要的作用，那它是如何加快数据查询的呢？它在所有的情况下都可以随意使用吗？下面，我们利用以下程序对其做一个简单测试。

首先，建立一个名字为jilu.dbf的表，该表有一个字段“数据 c（10）”，并根据字段“数据”建立一个名为“jilu”的索引。再建立并执行如下程序prog1.prg：

use jilu index jilu

for jiluhao=1 to 900000

append blank

replace 数据 with “Visual”

endfor

go 99

replace数据with“FoxPro”

go 34555

replace数据with “FoxPro”

go 75678

replace 数据 with “FoxPro”

该程序的作用是向新建立的jilu表中添加90万条数据为“Visual”的记录，并把其中的第99、34555、75678条记录中的数据更改为“FoxPro”。

1.1 在有索引的表中使用RushMore技术

现在，首先确保jilu表已经打开并且在当前正在使用的工作区中，然后建立并执行如下程序prog2.prg：

set optimize off

ks=second（）

display all for 数据=“FoxPro”

js=second（）

? “不使用RushMore技术时，程序用时：”+str（js-ks，5，3）+“秒”

set optimize on

ks=second（）

display all for 数据=“FoxPro”

js=second（）

? “使用RushMore技术时，程序用时：”+str（js-ks，5，3）+“秒”

在这个程序中用变量“ks”记录查询开始的时间，用变量“js”记录查询结束的时间，然后用表达式“js-ks”计算在查询三个数据为“FoxPro”的记录时所需要的耗时量。程序中分别用Set Optimize On和Set Optimize Off开启和关闭RushMore技术，最终屏幕上会分别显示出在这两种情况下程序查找三条“FoxPro”数据所需的时间。表1为五次实验结果，从该表中我们可以发现当开启RushMore技术时耗时量平均值为0.003秒，而关闭RushMore技术时耗时量平均值为3.373秒。很明显，在有索引的普通表中开启了RushMore技术后查询速度能够快上千倍。

1.2 在没有索引的表中使用RushMore技术

现在，将jilu表中的索引jilu删除后再次执行程序prog2.prg，实验结果如表2所示：开启RushMore技术时耗时量平均值为3.280秒，而关闭RushMore技术时耗时量平均值为3.337秒。从实验结果中可以发现在没有索引的普通表中开启RushMore技术几乎没有加快数据的查询速度，因此，在没有索引的表中，RushMore对程序效率没有明显的优化效果。

1.3 在SQL语句中使用RushMore技术

重新为jilu表建立一个索引，然后再建立并执行如下程序prog3.prg：

set safety off

set optimize off

ks=second（）

select * from jilu where 数据=“FoxPro” into table temp

js=second（） &&记录操作结束时间

? “不使用RushMore技术时，程序用时：”+str（js-ks，5，3）+“秒”

set optimize on

ks=second（）

select * from jilu where 数据=“FoxPro” into table temp1

js=second（）

? “使用RushMore技术时，程序用时：”+str（js-ks，5，3）+“秒”

set safety on

表3为五次实验结果，在该表中发现当开启RushMore技术时耗时量平均值为0.002秒，而关闭RushMore技术时耗时量平均值也为0.002秒。若再次把索引删除，会得到和表2差不多的实验结果。因此在简单的SQL语句中，是否开启RushMore对查询的速度也没有多大影响。

2 RushMore技术的特点

从上面的几个试验中我们发现在VFP的非SQL命令中，RushMore技术对命令的优化是基于VFP中索引的，它能根据条件表达式自动选择索引，以提高数据查询的速度，弥补VFP不能自动选择索引的缺陷。

2.1 RushMore优化原理

RushMore技术是一种数据存取技术，它允许成组的记录很有效的被存取，在速度上可与经过索引的单一记录存取相比较，它使VFP能够在PC机上处理含有数百万个记录的真正巨大的表，在速度上能够和大型机数据库系统相媲美。

RushMore利用标准的FoxPro B-树索引，并且不需要任何新类型的文件或者索引。它可以利用VFP的标准索引、压缩索引，复合或结构化索引。压缩索引所产生的索引文件的大小只相当于原来索引的六分之一大小。由于压缩索引文件实际上更小，因而它们能被更快速地单独处理。这就意味着，处理它们需要更少的磁盘存取，并且更大部分的索引可以保留在VFP内存缓冲区中。虽然在理论上，复合或结构索引与压缩索引使用同样的压缩技术与方法，但实际上压缩索引比复合或结构索引操作还是稍快一些。所以，随着数据库的增大，使用压缩索引可获得较快的速度。RushMore不仅仅充分受益于空间更小的压缩式索引，对原来的索引格式也同样有效。当程序执行了一条应用RushMore的命令时，它会立即与匹配的记录组合在一起，再由该命令去操作这一组记录，显然，它是将大型数据库变成了一个小数据库，对小数据库的操作当然就会更快。

2.2 RushMore优化原则

RushMore并不是对所有非SQL命令都能提高查询效率。在NEXT、RECORD、ALL、REST四个范围子句中，它只对ALL和REST有优化效果；对于条件语句FOR和WHILE，它只对FOR语句优化；在使用NOT条件创建索引时不能优化；在使用了惟一索引（UNIQUE）时不能优化；在内存很小的计算机上处理数据量很大的表时，RushMore可能会找不到足够的内存，也是不能优化的。

2.3 组合表达式的RushMore优化原则

在简单的语句中，VFP能根据优化原则自动选择关闭还是开启RushMore。但是，实际案例中我们常常需要在FOR语句中使用AND、OR或NOT这三个逻辑操作符组成逻辑表达式来提高数据的检索。那么在各种可优化或不可优化有表达式组合中，整个优化结果是什么呢？表4给出了组合表达式的各种优化结果。

从表4中可以看出在很多情况下，组合表达式的结果是不能被优化的。当这些组合表达式再次组合成更加复杂的表达式时这些全部可优化、部分可优化或不可优化的组合表达式会有一个什么样的优化结果呢？表5列出了这些优化种类的结果。

2.4 RushMore技术的优化方法

从优化规则表中我们可以看出不同的表达式组合中优化情况都不尽相同，在VFP中只要潜在可优化的命令中的FOR子句表达式不能被RushMore优化，RushMore就被自动禁止。但在少数情况下，VFP自动选择的RushMore却不能够加快数据查询。譬如说，如果程序中的潜在可优化的命令修改了FOR子句中的索引关键字，RushMore的记录集就已经过时了，这时，就应当禁止RushMore以保证获得表的最新的信息。

所以在特定时刻，我们可以用Set Optimize Off命令或NOOPTIMIZE子句对当前命令关闭RushMore功能，使程序运行效率达到一个最优化的效果。

3 结束语

综上所述，虽然VFP能够自动开启或关闭RushMore技术来提高查询速度，但并不是每次都能得到一个最优化的结果，我们应该从实践全局性来考虑整个程序的执行过程，在不同地方人为地开启或关闭RushMore去获得一个最佳的优化结果。

参考文献

[1]萨师煊，王珊.数据库系统概论[M].北京：高等教育出版社，1997．

[2]王利.全国计算机等级考试二级教程――VFP程序设计[M].北京：高等教育出版社，2005.

[3]张洪举.Visual FoxPro程序设计参考手册[M].北京：人民邮电出版社，2004．