經測試, 后者比前者要快好幾倍(columnExample經過索引)

2. 在ASP中, 使用GetRows與不使用GetRows而直接用Record來循環調用, 兩者其實有所差別, 下面是測試
調用記錄數: 484

使用GetRows, 然后用數組來顯示, 發現單花在GetRows的運算上花了約620毫秒. 總共花了711毫秒

直接用RecordSet來循環調用, 總共花了931毫秒

所以建議大家使用GetRows, 特別是要顯示很多的返回記錄時, 但是它會占用一部分臨時內存.

在直接使用RecordSet時, 大部分時間是花費在游標的移動上, 大概占了90%以上

3. 關于SQL中Count的想法

近日我對一大型數據庫進行編程, 發現我的一段程序的無論怎么優化數據庫, 怎么優化源程序, 執行完畢至少需要
600毫秒以上, 而別一段只需要100多毫秒. 下面是兩段代碼的條件約束(AgentID已經索引):

1. where AgentID = 0 花了600多毫秒
2. where AgentID > 0 只要100多毫秒

真的是很奇怪, 我開始了尋找花費時間的根源, 一忽兒, 我就找到了原來是Count函數, 它花了將近500毫秒來進行
記錄總數統計, 對數據庫的AgentID的值進行分析, 又發現AgentID的98%的值都是0, 看來符合的記錄越多, Count
進行的時間就會越長.
后來我想想, 不知SQL是否會自動進行反計算, 也就是它先計算不符合的條數, 然后計算符合的而返:
1. where AgentID < 1 因為AgentID最不值是0, 所以用此條件也一樣
最后的時間花費仍是600多毫秒, 沒有任何必進.

所以只有一個解決方案, 那就是手動進行, 如果記錄總數已經知, 則只需要計算不符合條件的記錄, 然后 總數減
去不符記錄即可得到查找記錄的總數目.

下面是幾個Count進行的時間測試:

Count(*) 無條件 返回說共有記錄145539, 費時剛好100毫秒

count(*) where name is not Null and Agent = 0 返回說記錄有145530, 費時431-441毫秒
(name is not null去掉的后只需要執行時間110)

Count(*) where name is not Null 返回記錄共有145539, 費時100-110毫秒

以上的測試AgentID都是允許Null值的情況