VFP 愛用者社區

liangszpt · 註冊時間: 2004-11-18 文章: 263 來自: 广东省深圳市 第 1 樓

给客户的系统，数据（DBC、DBF）放在服务器上的共享目录使用。
以前的程序员，使用大量的SQL-SELECT方法，经用户使用一段时间，数据变大后（其实也不是很大，42M），现在严重影响速度。以下是其中一个举例：
Select UNIQ_NO, QTY_BAL, FCY_PURBAL, BAS_PURBAL, DOC_DATE
From X:\Server\Data\IC!ICTXNH
Into Cursor CurICTXNH
Where ITEM_CODE=lcItemCode And
UNIT_CODE=lcUnit_Code And
QTY>0
Order by DOC_DATE

我在COMMAND WINDOWS试过，如果连续执行两次，在第一次时会很慢，第二次会很快（基本上无感觉）。为什么会这样的呢？开始时以为第一次执行完后，ICTXNH这个TABLE已经打开了，所以第二次会快。
但我试过，如果自己USE这个ICTXNH先，再执行SELECT，一样是慢。
感觉就是第一执行它慢，以后的就快。
一直听说Rushmore会令到查询很快，我要怎么做才可以令这个SELECT，和第二次执行一样快呢？
因为旧程式里面，太多这样的SELECT了。

syntech · 發表於: 星期二十一月 04, 2008 4:49 pm 文章主題:

簡單的說,WHERE 條件不滿足 RUSHMORE的條件,或是變成 TABLE SCAN (必須從第一筆讀到最後一筆才有結果)的條件,
這樣的SQL命令就會很慢.

HELP 有滿足 RUSHMORE的條件的規則.太多,懶的貼上來

liangszpt · 發表於: 星期二十一月 04, 2008 5:57 pm 文章主題:

如果WHERE的条件是一个已存在的INDEX,SELECT会自动的引用它吗?

marvin · 註冊時間: 2004-06-01 文章: 321 第 4 樓

> SELECT会自动的引用它吗?

當然

syntech · 發表於: 星期三十一月 05, 2008 8:31 am 文章主題:

如果沒有適當的INDEX,SELECT執行時會自己建,這也是變慢的原因

liangszpt · 發表於: 星期三十一月 05, 2008 10:08 am 文章主題:

syntech · 發表於: 星期三十一月 05, 2008 10:33 am 文章主題:

最佳化 Rushmore 運算式
Rushmore 技術取決於 FOR 子句或 SQL WHERE 子句中是否出現基本可最佳化運算式。一個基本可最佳化運算式可以是整個運算式，也可以是運算式的一部份。您也可以對基本運算式進行各種組合構成複雜的可最佳化運算式。

建立基本可最佳化運算式
基本可最佳化運算式一般是下面兩種型式：

eIndex relOp eExp

－或者－

eExpr relOp eIndex

基本可最佳化運算式具有以下特點：

eIndex 必須精確地符合用以構造索引的運算式，且不包含別名。

eExpr 是任意運算式，可以包含變數和其他不相關聯的資料表格中的欄位。

relOp 是下列關係運算子之一：<、>、=、<=、>=、<>、#、== 或 !=。您也可以使用 ISNULL( )、BETWEEN( ) 或 INLIST( ) 函數。（或與它們相對應的 SQL 命令，例如 IS NULL 命令，等等）。
您可以以下面兩種格式使用 BETWEEN( ) 或 INLIST( ) 函數︰

eIndex BETWEEN(eIndex, eExpr, eExpr)

－或者－

eExpr INLIST(eIndex, eExpr)

附註 Rushmore 技術無法最佳化 ISBLANK( ) 和 EMPTY( )。

如果您建立了 firstname、custno、UPPER(lastname) 和 hiredate 索引，那麼下列運算式都是可最佳化的。

firstname = "Fred"
custno >= 1000
UPPER(lastname) = "SMITH"
hiredate < {^1997-12-30}

最佳化運算式可以包含具有某一特定值的變數和函數。例如，對於 addr 索引，如果執行了 STORE 'WASHINGTON AVENUE' TO cVar 命令，那麼下列敘述也是基本可最佳化運算式：

ADDR = cVar
ADDR = SUBSTR(cVar,8,3)

深入瞭解何時查詢是最佳化的
瞭解查詢何時能被最佳化或無法被最佳化是很重要的。Visual FoxPro 要求過濾條件運算式左邊的部份必須與索引鍵值運算式完全相符合。這時，Rushmore 才能最佳化這個運算式。

例如，假設您剛建立一個資料表格，並用如下的命令新增了第一個索引︰

USE CUSTOMERS
INDEX ON UPPER(cu_name) TAG name

在下面的命令中搜尋條件只是根據 cu_name 欄位，而不是作為索引的那個運算式（UPPER(cu_name)），所以，無法最佳化這個命令，︰

SELECT * FROM customers WHERE cu_name ="ACME"

相反，您應該用下面的命令建立一個可最佳化的運算式，因為您搜尋的運算式完全與索引運算式相符合︰

SELECT * FROM customers WHERE UPPER(cu_name) = "ACME"

秘訣要確定所使用的 Rushmore 最佳化的程度，可呼叫 SYS(3054) 命令。

組合基本可最佳化運算式
如果 FOR 運算式具有基本可最佳化運算式的各種特性，那麼可以在 FOR 子句或 WHERE 子句基礎上組合簡單或複雜運算式以提高資料檢索速度。

基本運算式可能是可最佳化的，您可以使用 AND、OR 或 NOT 邏輯運算子組合這些基本運算式，以構成可最佳化的複雜 FOR 子句運算式。組合可最佳化基本運算式所得到的運算式是全部可最佳化的。如果有一個或多個基本運算式是不可最佳化的，那麼複雜運算式可能部份可最佳化，或者根本不可最佳化。

由基本可最佳化或不可最佳化運算式組合的運算式是全部可最佳化、部份可最佳化，還是根本不可最佳化的。

syntech · 發表於: 星期三十一月 05, 2008 10:37 am 文章主題:

另外, RUSHMORE 不是神.
即便滿足了條件,也作了RUSHMORE 加速,
但是不見得能達到你想要的速度

liangszpt · 發表於: 星期三十一月 05, 2008 10:42 am 文章主題:

ckp6250 · 註冊時間: 2004-07-30 文章: 1645 第 10 樓

有些時候 , 拆成二次或多次查詢，反而可能更快
Select UNIQ_NO, QTY_BAL, FCY_PURBAL, BAS_PURBAL, DOC_DATE
From X:\Server\Data\IC!ICTXNH
Where ITEM_CODE=lcItemCode
Into Cursor CurICTXNH_1

Select * From CurICTXNH_1
Where UNIT_CODE=lcUnit_Code And
QTY>0
Order by DOC_DATE
Into Cursor CurICTXNH

重點在於，有建索引檔的和沒建索引檔的，分開來查，試看看吧

richshih · 註冊時間: 2007-10-11 文章: 153 第 11 樓

EMPTY()無法RUSHMORE
請問WHERE EMPTY(FIELD1)該如何改寫程式才能RUSHMORE

syntech · 發表於: 星期三十一月 05, 2008 1:14 pm 文章主題:

幫轉 fox_cat 兄意見:

============
案主希望select第一次與第二次一樣快:

如:select * from custom

第一次之前DRAM-buffer裡沒有任何custom.dbf的資料,縱使有use custom也只有數K的資料,所以第一次之select必需把custom的相關資料及cdx幾乎完全讀入,再透過rushmore規則選出來.
第一次之後DRAM-buffer裡幾乎已有所有select要用的custom的資料,所以第二,三.. .次應該是一樣快.

liangszpt · 發表於: 星期三十一月 05, 2008 2:40 pm 文章主題:

现在的问题是我已按RUSHMORE的要求,建立了INDEX,然后使用
select * from icstock where item_code='aaa'

但它却没有使用,得到以下的结果.
Rushmore optimization level for table ictxnh: none

是否我还没有注意些什么而导致这样的结果。

nelsonchuang · 發表於: 星期三十一月 05, 2008 3:04 pm 文章主題:

黑猫白猫，如果很急，為什麼不先試試ckp6250的建議呢?

syntech · 發表於: 星期三十一月 05, 2008 3:37 pm 文章主題:

+1

其實這也是找出哪個條件不符合 RUSHMORE 的方式