首先你要搞清楚是加载结果数据显示慢，还是统计过程慢。原因的可能性有许多，要逐个隔离分析和排查。

[ 本帖最后由 TonyDeng 于 2014-8-22 10:31 编辑 ]

先在本地count一次看执行时间多少，不要显示数据。

试试这样
SELE ('sfsjdata')
SET ORDER TO sfcbq
IF SEEK(YYsfcbq)
    COUNT REST to recnoall WHILE sfcbq=YYsfcbq
    thisform.text3.value=recnoall
ENDIF

SELE ('sfsjdata')
SET ORDER TO sfcbq
如果sfcbq字段是索引键
可先 seek YYsfcbq
再 do while sfcbq=YYsfcbq 循环体内统计，这样就不用扫描好多记录。

劝楼主另开蹊径。如果只抓住这一张表的范围，只在一张 dbf表上做文章，恐怕真正彻底解决的好办法可能不存在吧。（个人意见）。这是由单张 dbf 大容量的性质所决定的。实际上，不管对这张表怎样的想办法，都改变不了巨量单表变慢的属性。日子还长着呢，必须要想出长久之法才行。否则，可别使程序就此而止。办法有2个，（1）分表。具体如何分，看个人需要。如果按时间段分，当按时间段查询时，很多分表就根本不用访问，大大提高速度。再就是，查询若干个分表，比查询一个整体大表也快得多。（2）假如能把此大表放在 SQL SERVER 中。（4楼意见），可能会解决根本问题。因为此表变成了一个可膨胀的，带有搜索引擎的，使用时间戳的，有堆栈数据集的,端口访问的表。动用了微软的尖端技术。vfp 与 server 2014， 目前仍然是无缝连接。使用的容易程度和使用DBC没多大的两样。

楼主虽然打开了表索引，但表索引却没有起到任何作用。对于海量数据使用索引是必须的，代码优化如下：

SELE sfsjdata        && 对于字符常量使用名称表达式，本身就是“画蛇添足”
SET ORDER TO sfcbq
seek yysfcbq         && 定位到满足条件的首记录
count rest to recnoall while sfcbq = YYsfcbq    && 统计满足条件的记录数，注意这里的条件是“WHILE”
thisform.text3.value=recnoall
GO TOP
IF !EOF()
   thisform.text2.value=RECN()
ENDI
thisform.mygrid1.refresh
thisform.mygrid1.setfocus()