| 网站首页 | 业界新闻 | 小组 | 威客 | 人才 | 下载频道 | 博客 | 代码贴 | 在线编程 | 编程论坛
欢迎加入我们,一同切磋技术
用户名:   
 
密 码:  
共有 2378 人关注过本帖
标题:求助:表索引的排序方式问题
只看楼主 加入收藏
TonyDeng
Rank: 20Rank: 20Rank: 20Rank: 20Rank: 20
等 级:贵宾
威 望:304
帖 子:25859
专家分:48889
注 册:2011-6-22
收藏
得分:0 
Rushmore Query Optimization technology is a data access technique that uses standard Visual FoxPro indexes to optimize access to data. You can use Rushmore with any Visual FoxPro index, including FoxPro 1.x (.idx) indexes, compact (.idx) indexes, and compound (.cdx) indexes.

Both .cdx and compact .idx indexes use a compression technique that produces indexes as small as one-sixth the size of uncompressed old-format indexes. Visual FoxPro can process a compressed index faster because it requires less disk access, and because more of the index can be buffered in memory. Although Rushmore Query Optimization, like other file access techniques, benefits from the smaller size of compact indexes, it also functions very well with indexes in older formats.

When Visual FoxPro processes very large tables on computers with only the minimum amount of RAM, Rushmore might not find sufficient memory to operate. In that case, Visual FoxPro might display a warning message ("Not enough memory for optimization"). Although your program will function correctly and not lose any data, the query will not benefit from Rushmore optimization.

In its simplest form, Rushmore speeds the performance of single-table commands using FOR clauses that specify sets of records in terms of existing indexes. Also, Rushmore can speed the operation of certain commands such as LOCATE and INDEX. For a complete list of optimizable commands, see the next section, "Using Rushmore Query Optimization with Tables."

Visual FoxPro SQL commands use Rushmore as a basic tool in multi-table query optimization, using existing indexes and even creating new ad-hoc indexes to speed queries.


[ 本帖最后由 TonyDeng 于 2014-3-17 20:13 编辑 ]

授人以渔,不授人以鱼。
2014-03-17 20:12
taifu945
Rank: 12Rank: 12Rank: 12
等 级:贵宾
威 望:80
帖 子:1545
专家分:3298
注 册:2012-7-6
收藏
得分:0 
以下是引用TonyDeng在2014-3-17 19:51:18的发言:


對locate for,VFP默認開啟rushmore優化的時候,它會使用索引(被檢索的字段是索引字段時)。查閱一下VFP幫助中rushmore的條目就知道了。很多人以爲SQL的查詢必定比VFP傳統的檢索快,其實就是不明白VFP的rushmore技術才是它速度飛快的殺手鐗,它是用for條件來觸發的。

优化不是在任何时候都能进行的,即使是对索引过的字段进行检索。比如:INDEX ON UPPER(ABC) TAG UPPER_ABC,且使之有效,命令LOCATE FOR ABC="MH370"在执行时将不会被优化,因为被搜索的表达式与索引表达式不匹配。还有:LOCATE FOR "MH370"$ABC也不会被优化;LOCATE FOR ISBLANK(ABC)也不被优化... ...。另外,当内存过小,不足以存放优化记录子集时也不会对命令进行优化。所以,优化是有条件的,并不是开着优化就全部能优化的。而FIND、SEEK就不一样了,它们采用二分法查找,是对INDEX ON后面的表达式所计算出来的值进行查找。仍以INDEX ON UPPER(ABC) TAG UPPER_ABC为例,用SEEK "MH370" ORDER UPPER_ABC命令一定会快过LOCATE FOR ABC="MH370"。
2014-03-17 20:17
TonyDeng
Rank: 20Rank: 20Rank: 20Rank: 20Rank: 20
等 级:贵宾
威 望:304
帖 子:25859
专家分:48889
注 册:2011-6-22
收藏
得分:0 
不能啟動優化的地方,用SQL語法也同樣不能,無論如何,命令都能執行(也就是說不能靠是否執行成功來檢驗),效率衹不過打個折扣而已。另外,VFP的索引是基於二叉樹,不是二分法。

[ 本帖最后由 TonyDeng 于 2014-3-17 20:26 编辑 ]

授人以渔,不授人以鱼。
2014-03-17 20:21
TonyDeng
Rank: 20Rank: 20Rank: 20Rank: 20Rank: 20
等 级:贵宾
威 望:304
帖 子:25859
专家分:48889
注 册:2011-6-22
收藏
得分:0 
能夠啟動快速檢索的字符串比較格式,是基於C的字符串比較法則,它對完全比較(==算符)不能生效,也是這個原因,但當查詢的條件必須使用完全比較的時候,就是不能啟動優化也必須如此查找,否則只能查到不符合要求的數據,等於沒用,也不要以爲SQL的優化就不是基於這個規則的,它在必須執行完全比較的時候,效率也是如此這般,不會有特殊,因爲都是基於C做出來的東西。

授人以渔,不授人以鱼。
2014-03-17 20:25
taifu945
Rank: 12Rank: 12Rank: 12
等 级:贵宾
威 望:80
帖 子:1545
专家分:3298
注 册:2012-7-6
收藏
得分:0 
以下是引用xs591222在2014-3-17 19:18:27的发言:

在 liuxingang28 的“vfp学习、开发漫谈(二)”中找到了答案。
 
在主程序中加入 Set Collate To "Machine" 测试正确了。
 
谢谢!
无需专门用SET COLLATE TO命令,如果想人为指定排序方式,可以在INDEX ON命令中使用“COLLATE 排序方式”子句。
2014-03-17 20:31
TonyDeng
Rank: 20Rank: 20Rank: 20Rank: 20Rank: 20
等 级:贵宾
威 望:304
帖 子:25859
专家分:48889
注 册:2011-6-22
收藏
得分:0 
VFP的rushmore優化,在不生成臨時視圖佔用內存的時候,怎麽都不會比使用SQL查詢佔更多的內存以致出現內存不足的提示,當SQL查詢要使用磁盤作內存交換的時候(在作複雜的多層嵌套查詢時特別容易出現這種問題,除非你用64位SQL Server配64位操作系統加上龐大的物理內存,32位軟件根本是沒用的),它就比不用索引的全盤檢索更慢。

授人以渔,不授人以鱼。
2014-03-17 20:33
快速回复:求助:表索引的排序方式问题
数据加载中...
 
   



关于我们 | 广告合作 | 编程中国 | 清除Cookies | TOP | 手机版

编程中国 版权所有,并保留所有权利。
Powered by Discuz, Processed in 0.017857 second(s), 8 queries.
Copyright©2004-2024, BCCN.NET, All Rights Reserved