是这么一个概念：
打开几个相关的dbf，用SQL语句作了一些简单修改，更新了索引，然后打一个命令：
close all
结果等了5分钟，鼠标漏斗一直转、一直转、一直转……还没转完！
当然，机器比较老旧，AMD上几代的CPU，不过好歹也有16G内存来着。

字段的多少，长度的大小，对文件的大小有一定的影响

这种量级，对DBF来说负担有点重，可能的话，还是用SQLserver吧，效率刚刚的

对于巨大的dbf表，实践证明：

close indexes
*巴拉巴拉，修改一堆的字段值
set index to Mycdx
reindex

VFP参考书上推荐的这一做法，可能是错误的！效率非常非常低！
必须尽可能地保持索引一直打开，让VFP自动去维护、更新索引才行。

[此贴子已经被作者于2022-5-1 16:20编辑过]

企图处理巨大dbf表，是一个“痛苦”的历程。
不过，这也倒逼着我们不断尝试重构算法，尽一切可能去提高运算的效率。
因为要遍历DBF表，获取所需的统计数据，算法Ver 0.1，非常非常慢，大略估算了一下，一天也转不出1%来，全部统计完，理论上，需要100天+！
显然这是相当拙劣的蜗牛工程！
算法Ver 0.2，通过疯狂地添加索引，将速度提高了一些，不过仍需要80天+！
算法Ver 0.3，将一切冗余字段删除，只保留程序所涉及的几个必要字段，如此又将速度提高至70天+！
现在正鼓捣着算法Ver 0.4，希望能将速度提升至50天-罢，唉。
软硬件环境：11代i5/32G/512G SSD/Win11 64bit
记得我说过，VFP是个挺不错的玩具，一遍又一遍地反复重构、优化算法，这本身就是一个有趣的挑战性的智力游戏。

大活还得大数据库干，夏利去跑拉力赛还是差点

确定是啊！不过，这当中还有“学艺不精”方面的因素，影响也是蛮大的。
Ver 0.4刚刚测试了一下，得到一个较能接受的结果，甚至还有点儿“小惊喜”：
若电脑24小时不停开着，理论上，只需31天便能转完！
这已是远超预期：毕竟从100天+，80天+，70天+，……一路打压，直至“三折优惠”！
这买卖估计也就这样啦。
若再想砍价的话……唉，臣妾做不到啊！
决定先转几天试试！权当拷拷机罢。

数据这么大的表，如果是中间数据处理的表，看看可否减少不必要的字段、减少字段宽度，可以提高速度。如果是最终保存数据的表，只能说楼主胆大。另外，若每次真正要处理的只是部分的数据，可通过参数视图，筛选出相关记录进行处理。

确实是中间数据，否则不会企图花上1～４个月时间去折腾它们。
每一次都必须遍历整个数据集，没法分片式筛选出各个子集来处理。
——只能咬牙硬干。

没有结合具体数据结构、运算结果的要求与代码很难给出提高效率的办法。