我的SQL-Select的效率有些慢，于是用SYS(3054, 12)跟踪了一下，发现全部提示：不可Rushmore优化？！
查询需求相对复杂，无法通过一个Select语句得到，必须将需要分拆开来，借助几个Select的中途结果，一步一步得到最终想要的数据。我发现，虽然用到的几个源DBF，针对查询所涉及的条件过滤字段，全都作好了索引，但VFP9只提示第一个Select是“可完全优化”的，其余的Select，一律提示“不可优化”。
大致步骤是：
第一步：select“表1”，加过滤条件，得到一个子集MyCursor1；
第二步：将“表1”与MyCursor1，再加过滤条件，结合后再得到MyCursor2；
第三步：将“表2”与MyCursor2结合，得到MyCursor3；
第四步：将“表3”与MyCursor3结合，得到MyCursor4；
最后：将MyCursor4过滤，得到最终结果。
结果是，只有第一步是“Rushmore可完全优化”，其余Select，都涉及到临时Cursor，是否因为Cursor无索引的原因，均无法Rushmore优化？甚至连“部分优化”都没有提示。会不会VFP9虽提示“无优化”，实际上，还是能得到某些内部的Rushmore优化呢？
心想，凡涉及临时表的，我要不要一律Select... into cursor XX Readwrite，然后建立好索引，再继续下一步Select呢？或者，有没有好的方法，彻底解决Select中途结果的问题，让Rushmore优化work起来，让程序的效率更高？
[解决办法]
帮助中是这样说的：“当你访问多个表时，SELECT - SQL 查询取代了所有的 Rushmore 优化技术。在 SQL 命令中，Visual FoxPro 决定需要什么来优化一个查询，并为你做这件事。你不需要打开表或索引。如果 SQL 确定它需要索引，它会为自己创建一个临时索引。”
所以你无需 Readwrite 和手动索引。
[解决办法]
本帖最后由 apple_8180 于 2012-11-12 09:24:20 编辑 当你访问单个表时，可以在出现 FOR 子句的任何地方利用 Rushmore 技术。
所以访问单个表时，你可以先建立索引，然后查询时通过 FOR 语句利用 Rushmore 技术，如：
USE CUSTOMERS
INDEX ON UPPER(cu_name) TAG name
在下面的命令不能被优化，因为搜索条件仅基于 cu_name 字段，而不是作为索引的那个表达式：
SELECT * FROM customers WHERE cu_name ="ACME"
相反，你应该用下面的命令创建一个可优化的表达式，因为你搜索的表达式完全与索引表达式相匹配：
SELECT * FROM custoers WHERE UPPER(cu_name) = "ACME"
