大体积DBF文件高效提取方案咨询：现有方法耗时优化需求

我明白你的痛点——三个1.8-2GB的DBF文件，用多次IN子查询加临时表合并的方式确实会因为重复扫描、多次磁盘IO导致速度变慢。下面给你几个针对性的优化方案，能显著提升提取效率：

1. 用带索引的临时表存储匹配项，结合UNION ALL一次性生成结果 #

原方法里每次查询都要重复扫描itemlist，而且生成三个临时表再合并，磁盘开销极大。我们可以先把itemlist的itemcode导入到一个带索引的临时表，然后用UNION ALL一次性合并三个DBF的查询结果，大幅减少IO操作：

* 先创建带唯一索引的临时表，存储需要匹配的itemcode
CREATE CURSOR cur_itemlist (itemcode C(20)) && 替换20为你实际的itemcode字段长度
INDEX ON itemcode TAG idx_itemcode UNIQUE
APPEND FROM itemlist && 或者用SELECT itemcode FROM itemlist INTO CURSOR cur_itemlist READWRITE

* 用UNION ALL一次性查询并生成最终结果表，避免多次临时表操作
SELECT * FROM dfbfile_1 WHERE itemcode IN (SELECT itemcode FROM cur_itemlist) ;
UNION ALL ;
SELECT * FROM dfbfile_2 WHERE itemcode IN (SELECT itemcode FROM cur_itemlist) ;
UNION ALL ;
SELECT * FROM dfbfile_3 WHERE itemcode IN (SELECT itemcode FROM cur_itemlist) ;
INTO TABLE tmp_result

* 后续操作直接使用最终结果表即可
CLOSE DATABASE ALL
USE tmp_result

这里UNION ALL比UNION更快，因为它不需要去重（和你原方法里的APPEND逻辑完全一致），而且一次性生成结果表，只做一次磁盘写入，比三次写入+两次append的开销小得多。

2. 给三个DBF文件的itemcode字段创建索引 #

如果你的dfbfile_1/dfbfile_2/dfbfile_3还没给itemcode建索引，一定要补上！VFP里带索引的字段在做WHERE条件匹配时，会用快速索引查找代替全表扫描，对于几个GB的大文件来说，速度提升非常明显：

* 给每个DBF文件的itemcode创建索引（只需执行一次，之后永久生效）
USE dfbfile_1 EXCLUSIVE
INDEX ON itemcode TAG idx_itemcode
USE dfbfile_2 EXCLUSIVE
INDEX ON itemcode TAG idx_itemcode
USE dfbfile_3 EXCLUSIVE
INDEX ON itemcode TAG idx_itemcode

注意：如果是多用户共享环境，需要确保排他打开文件来创建索引，创建完成后其他用户就能共享使用这个索引了。

3. 额外小技巧：尽量减少临时表的磁盘写入 #

如果你的内存足够，可以把临时表放在内存里（VFP支持内存临时表），比如用IN CURSOR代替INTO TABLE，进一步减少磁盘IO：

SELECT * FROM dfbfile_1 WHERE itemcode IN (SELECT itemcode FROM cur_itemlist) ;
UNION ALL ;
SELECT * FROM dfbfile_2 WHERE itemcode IN (SELECT itemcode FROM cur_itemlist) ;
UNION ALL ;
SELECT * FROM dfbfile_3 WHERE itemcode IN (SELECT itemcode FROM cur_itemlist) ;
INTO CURSOR tmp_result READWRITE

这样结果表会存在内存里，操作速度会更快，之后如果需要持久化再导出到磁盘即可。

内容的提问来源于stack exchange，提问作者Vic