经测试, 后者比前者要快好几倍(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值的情况