1. 在SQL中, 如果選擇某字段不為空的記錄有兩種寫法
where columnExample <> ''
或者是
where columnExample is not null

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

2. 在ASP中, 使用GetRows與不使用GetRows而直接用Record來循環(huán)調(diào)用, 兩者其實(shí)有所差別, 下面是測試
調(diào)用記錄數(shù): 484

使用GetRows, 然后用數(shù)組來顯示, 發(fā)現(xiàn)單花在GetRows的運(yùn)算上花了約620毫秒. 總共花了711毫秒

直接用RecordSet來循環(huán)調(diào)用, 總共花了931毫秒

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

在直接使用RecordSet時(shí), 大部分時(shí)間是花費(fèi)在游標(biāo)的移動上, 大概占了90%以上

3. 關(guān)于SQL中Count的想法

近日我對一大型數(shù)據(jù)庫進(jìn)行編程, 發(fā)現(xiàn)我的一段程序的無論怎么優(yōu)化數(shù)據(jù)庫, 怎么優(yōu)化源程序, 執(zhí)行完畢至少需要
600毫秒以上, 而別一段只需要100多毫秒. 下面是兩段代碼的條件約束(AgentID已經(jīng)索引):

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

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

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

下面是幾個(gè)Count進(jìn)行的時(shí)間測試:

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

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

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

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