嘿，这个问题我碰过好多次——老旧ERP的DBF文件堆了十几年数据，体积大到离谱，但32位系统能跑其实是当年FoxPro这类DBF驱动的设计巧思：它不会一次性把整个文件塞进内存，而是按需加载记录块，所以哪怕文件几个G，只要不是全量扫描，32位系统也能扛住。言归正传，给你几个在Win10 64位下靠谱的拆分方案，按推荐程度排序：

方案1：用Visual FoxPro（VFP）脚本拆分（最靠谱，原生支持DBF全特性） #

VFP是DBF格式的亲爹，虽然已经停更，但Win10 64位完美兼容32位的VFP程序。步骤如下：

1. 准备环境：装个Visual FoxPro 9.0（或者只装VFP 9.0 Runtime组件，足够用），Win10 64位会自动把它放在Program Files (x86)目录下。
2. 备份原文件！：复制table1.dbf、table1.cdx、table1.fpt到安全文件夹，绝对不能跳过这一步。
3. 打开VFP并独占原表：
   • 启动VFP，在命令窗口输入：

     USE "C:\你的文件路径\table1.dbf" EXCLUSIVE
     

     必须加EXCLUSIVE（独占）才能导出数据，否则会报错。
4. 确定拆分阈值：
   假设你的表有一个记录创建时间的字段（比如create_date），或者自增主键（比如rec_id），先找到分割点：
   • 按日期拆分（取最新10%）：

     SELECT MAX(create_date) FROM (SELECT TOP 10 PERCENT * FROM table1 ORDER BY create_date DESC) AS temp
     

     执行后会得到一个日期，记下来（比如{^2022-01-01}）。
   • 按自增ID拆分：

     SELECT MIN(rec_id) FROM (SELECT TOP 10 PERCENT * FROM table1 ORDER BY rec_id DESC) AS temp
     

     得到最小的ID值（比如100000）。
5. 导出最新10%记录：
   用日期阈值的话：

   SELECT * INTO "C:\目标路径\table1_new.dbf" FROM table1 WHERE create_date >= {^2022-01-01} ORDER BY create_date DESC
   

   用ID阈值的话：

   SELECT * INTO "C:\目标路径\table1_new.dbf" FROM table1 WHERE rec_id >= 100000 ORDER BY rec_id DESC
   

   执行后会自动生成对应的table1_new.cdx（索引）和table1_new.fpt（备注）文件。
6. 导出旧90%记录：
   同样替换阈值条件：

   SELECT * INTO "C:\目标路径\table1_old.dbf" FROM table1 WHERE create_date < {^2022-01-01} ORDER BY create_date ASC
   

7. 验证：分别打开两个新表，检查记录数比例、备注字段（比如长文本、附件）是否正常，索引能不能用。如果索引有问题，在VFP里打开表后执行REINDEX重建即可。

方案2：用64位DBF可视化工具拆分（更简单，适合非技术人员） #

如果不想碰命令行，可以用支持64位的DBF工具，比如DBF Manager 64位版或者DBF Viewer Plus，步骤更直观：

• 打开工具，加载table1.dbf（工具会自动识别关联的cdx和fpt文件）；
• 按日期或ID字段降序排序，选中前10%的记录（工具一般有“选择百分比”的功能）；
• 导出选中记录为新DBF文件，记得勾选“导出复合索引（.cdx）”和“导出备注文件（.fpt）”；
• 剩下的记录同理导出为旧表文件。

关键注意事项 #

• 独占访问：拆分时必须确保ERP系统没有在使用这个DBF文件，否则会出现文件锁定错误；
• 备注文件完整性：一定要确认导出的新表带对应的.fpt文件，否则原表中的备注字段会丢失；
• 索引重建：如果导出后的表索引失效，用VFP的REINDEX命令或者工具里的“重建索引”功能修复。

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