1. 连接共享文件的访问原理，是直接访问远程的数据，还是把数据下载到本地查询？

希望大神帮忙解析下连接共享文件的访问原理，和影响速度的因素，我想针对性做些优化，现在系统慢的无法忍受，谢谢

我的系统情况： 系统有两个重要的表，由于历史原因，表的字段有 60 多个，数据会逐月增加，每个月至少 7 万条数据，现在 DBF 文件有 700 M 大小，索引文件 100 M 大小

主要是涉及查询这两张表的功能在远程客户端上查询非常的慢，查询操作基本 2-3分钟，使用本地数据库，只需要 4-8 秒

影响因素有很多，硬件和软件方面都有，泛泛而谈没有针对性，解决方案与需求有关。

若要彻底解决问题，必须重新进行数据库设计。你现在的数据表就超过了700M，别忘了：VFP的单个数据表不能超过2G的限制。这样发展下去，用不了多久你的系统将彻底瘫痪。可考虑当前数据表仅保存本年度的数据，年末时，将数据移动到历史库。历史库按年份划分，每年一个。

共享文件夹就当成本地一个磁盘驱动器使用。
个人认为，数据量大时，DBF文件最好能分类保存，如按年或月分文件存放，对配置低的电脑能否高效运行尤为重要，免得数据在内存与磁盘间频繁交换耗费大量时间。

楼主的设计方式，导致出这样的结局是必然的。后期导致程序瘫痪无法再用，也是可能的。建议赶快用多表分流方式，解决还来得及。

建议升级到SQL server

关键在网路上跑的数据有多少，那是由查询需求决定的，你若真的查出有那么多的数据，用啥Server都是那么慢，若如此，则把变化相对静止的数据转存在本地是一个解决方案。总之，一切要根据实际需求而定。

本地4-8秒，在我看来，这个算法是相当低效了，不可忍受，才700M的规模而已，就这么慢。

表的字段设计有60多个，这现象就不正常——但最关键的不是字段数量，而是单条记录的长度。要在不影响原本运行正确的情况下提升效率，可以考虑把这个表分割，即将所有涉及索引的字段分离出来单独成表，减少体积，查询时就对这个表操作，得到结果后再映射出对应的详细数据。当然，这方案要看你系统的具体情况而定，还是泛泛而谈。不过，这楼主怎么似乎是一闪梅（没）啊？

集中和分布，三十年河东，三十年河西，没有固定的。