摘要:Visual FoxPro中的Rushmore技術雖然在一般教程中極少講述,但在實用中卻每有奇效,它也構成了Visual FoxPro獨有的特色。該文從Visual FoxPro之索引、查詢和優化等側面,詳細剖析了Rushmore技術的相關細節,對數據庫開發者有一定的參考和借鑒作用。
關鍵詞:Visual FoxPro;數據庫;Rushmore;優化;索引
中圖分類號:TP311文獻標識碼:A文章編號:1009-3044(2008)32-1034-03
Rushmore Technology Analysis Base on the VFP DBMS
CAO Ying-huai
(Public Security Marine Police Academy, Ningbo 315801, China)
Abstract: Although the Rushmore Technology of VFP been narrated singularly in common teaching material, but it has good effect always in applications, it make up of particular characteristic of VFP. In this paper, analyzing detailedly the detail of rusemore Technology, by index, query, optimize etc of VFP. help to developer of VFP DBMS.
Key words: VFP; DBMS; Rushmore; optimize; query
盡管擁有悠久歷史的Visual FoxPro(簡稱VFP,下同)之Rushmore技術,在一般的教程中極少詳述,但它在實用中卻每有奇效,這也構成了VFP獨有的特色之一。
1 Rushmore技術概述
在數據庫中,傳統的檢索一般是按順序進行的,即從數據表的首記錄開始,逐條比較是否符合條件,直到找到滿足條件的記錄為止。但如果記錄已被索引,就可不按順序來查,可直接定位在符合部分條件的首記錄上,再以該記錄做界于前或后半部分再行搜索,同樣的思路可在后續處理中繼續使用。所以,檢索效率較傳統檢索操作要高得多,這正是Rushmore技術的理論基礎。
Rushmore技術的效果一般隨著數據規模的增加而增加,越是大規模數據、越是復雜的數據,則效果愈發明顯。一般地,凡是帶FOR子句的VFP命令都要做查詢處理,諸如COUNT、LOCATE、SELECT等。所以,Rushmore 技術因使命令執行速度加快,亦被稱之為“優化查詢”技術。這也是VFP在眾多優秀的DBMS(如ORACLE等)領域中始終保持在個人PC上處理擁有數百萬記錄的真正巨大的數據表時,能與巨型機數據庫系統相媲美的真正原因所在。
它之所以稱之為“Rushmore”技術,是緣于發明者在看過Hitchcock的North By Northwest之后的一種靈感,對其所在系統內部某項目名稱的選擇。該技術利用標準的B-樹搜索技術,且完全依賴于傳統的索引類型。當然,因壓縮索引( 即.IDX、.CDX文件)超強的壓縮技術,意味著Rushmore技術擁有更加明顯的優勢。
Rushmore技術看似深奧難懂,但使用起來并不十分困難。一般地,只需將有關的字段建立索引后,執行有FOR子句的命令時,VFP系統便會自動根據索引去查詢符合條件的記錄,甚至無需設主索引。當然若非結構化復合索引,則須在查詢前將索引文件打開。
2 Rushmore技術細節分析
2.1 分析方法與數據說明
為闡述問題方便,使讀者能更清晰地理解分析結果,筆者在測試用的數據表中僅設置了一個字段,字符型,字段寬度為100。表中存儲了記錄11萬條,記錄的平均長度為65個字符,全部非空,且最短的記錄也在45個字符以上,涉及漢字、英文字母和各種常用符號等。
分析中以時間為指標,單位取“毫秒”。為使分析結果穩定、客觀,特在分析用的程序代碼中就針對的命令,先后統計了執行10次的時間結果,最后再取平均值以橫向比較。
2.2 分析用程序代碼設計
考慮VFP中方便用時間來觀察的命令特點,選取了幾個代表性的檢索和統計命令來研究。為此,筆者特意設計了一段VFP程序代碼,通過簡單修改代碼中的關鍵命令,即可通過執行之來觀察不同情況下Rushmore技術的超強效果。下面是COUNT命令的“測試代碼”。
clear
use 數據表
提取統計開始時間
dime time_str(10)
sums = 0
for i=1 to 10
start_t = second()*1000
統計處理過程
count for field_name=;
[數據庫原理與應用教案];
to var_name nooptimize
提取統計結束時間
end_t = second()*1000
time_str(i)=end_t - start_t
? alltrim(str(time_str(i)))
sums = sums + time_str(i)
next i
? [平均為: ]+ alltrim(str(sums/10))
return
其實,只要將上述代碼中的COUNT … 關鍵命令換成諸如LOCATE、SELECT等,即可得到相應命令的Rushmore技術使用效果,鑒于篇幅,在此從略。
2.3 Rushmore技術的優化效果
筆者是在PⅣ2.0G聯想臺式微機上,WindowsXP環境下,通過VFP6.0來測試的。其實,測試的結果數據本身并不重要,但觀察使用Rushmore技術前后的數據對比才是問題的關鍵。
測試效果之對比數據見圖1、2、3所示。
從圖1、2、3不難看出,對于COUNT命令而言,若不建立索引,則無法充分利用Rushmore的優勢,不管是否在命令中設NOOPTIMIZE子句。
對于LOCATE命令而言,不建立索引同樣無法利用Rushmore的優勢,也不管你是否在命令中設NOOPTIMIZE子句。當然,使用了索引之后,則Rushmore技術效果明顯。
VFP中的SQL命令SELECT(無WHERE條件時)不受索引的限制,下例可看出,索引與否效果基本一致。但若設有WHERE條件則區別極大。測試效果之對比數據見圖4、5、6所示。
2.4 有優化潛力的VFP命令匯總
凡是可以攜帶FOR子句的VFP命令,均具有潛在的優化可能。下面羅列了VFP中所有的可使用Rushmore技術的命令。其具體效果本文從略,讀者可參照 “測試代碼”自行觀察之。
SCAN、AVERAGE、BROWSE、CALCULATE、CHANGE、COPYTO、JOIN WITH、SORT TO、SUM、LOCATE、RECALL、LIST、REPLACE、EDIT、COUNT、DISPLAY、REPLACE FROM …、SET FILTER、DELETE、SET DELETED、TOTAL TO
3 基于Rushmore技術的VFP優化設計
VFP中的Rushmore技術,通過查找與篩選表達式左邊相匹配的索引表達式來優化篩選條件。若試圖將索引的標識名與篩選表達式相匹配,則VFP無法通過這種方式優化查詢。即下面的索引在基于Rushmore技術的優化設計中是無效的:
USE數據表
INDEX ON UPPER(select_name) TAG name
SELECT * FROM數據表;
WHERE select_name=[比爾]
正確使用索引的Rushmore技術優化方法是:
SELECT * FROM數據表;
WHERE UPPER(cu_name)=[比爾]
另外,還應避免以: ‘FOR <條件>’或‘ NOT <條件>’ 這樣的形式建立索引表達式,它們也是無法優化。例如:
INDEX ON DELETED() TAG DEL
可進行 Rushmore 優化
INDEX ON NOT DELETED();
TAGNOTDEL
不能優化
特殊情況下,若不想包含被刪除的記錄,可先設置 SET DELETED ON,再建索引,這樣可以加速操作。此外,不要在只有少數離散數據中取值的字段(如邏輯型)上建立索引。
Rushmore技術要求命令之范圍子句必須是ALL或REST。而NEXT或RECORD范圍子句不能使用Rushmore優化機制。因為,默認范圍是ALL,所以,當省略SCOPE子句時,Rushmore 技術是會起作用的?
4 Rushmore技術的優化機制
4.1 Rushmore技術優化前提
Rushmore技術的優化機制可解決檢索操作何時能被優化或不能被優化的問題。因VFP之優化前提是:
“篩選表達式左邊部分” 與 “索引關鍵字表達式” 完全匹配。
所以,只有查找到在索引中使用的精確匹配的表達式,Rushmore技術才能發揮作用并優化該表達式。例如,假設您剛創建一個表,并用如下的命令添加了第一個索引:
USE 數據表
INDEXONUPPER(select_name);
TAGname
在下面的命令中搜索條件只是基于select_name字段,而不是作為索引的那個表達式“UPPER(select_name)”,所以,VFP之Rushmore技術不能優化命令:
SELECT*FROM數據表 ;
WHERE select_name=[VFP]
但下面的命令卻是可優化的:
SELECT*FROM數據表;
WHERE UPPER(select_name)=[vfp]
4.2 VFP組合表達式之優化機制
如果FOR條件中的基本表達式具有優化特征,則用VFP之邏輯運算符“AND、OR 或 NOT”組合之,亦構成可優化的、復雜的FOR子句表達式。表1總結了Rushmore技術中的檢索優化內在規則。
雖然基于Rushmore技術的VFP檢索速度很快,但當表中有較多的索引時,因為,更新數據表或向數據表中輸入數據時VFP需要更新每一個索引,所以操作就會變得稍慢,故一般只需在用于篩選和聯接的數據上建立索引即可。而且,索引也不是建的越多越好。
4.3 基于數據類型的優化分析
在VFP中引入了“日期時間型、整型、雙精度型和貨幣型”四種新的數據類型之后,因這些類型的數據均以二進制數據形式存在磁盤上,故在設計中使用這些數據類型,一來可在從磁盤向內存加載數據或索引時,因一次可以加載更多的有用數據,從而提高程序的性能;二來因不需要做數據轉換,所以數據訪問就更快。這一切均為Rushmore技術提供了更好的優化環境。
一般地,在幾種新的數據類型中,整型數據對速度的影響最大。故要盡量使用整型數據作為主關鍵字和外部關鍵字的值。這樣不僅可得到更小的DBF表文件,亦可得到更小的索引,當然連接速度也就更快了。