这一点确实我没想到，很具性价比的顺序调整建议！非常感谢！



join这个关键词，振聋发聩，我得好好思考一下！非常感谢！

第一版实在太慢，确实“旧串”不唯一；不过后来无意中我也发觉到了，第二版重新做了一个unique旧串表，然而速度并未有实质性提升。
仍是巨慢。哪怕换一台最新i7电脑32G内存，也没多少改善，得到的印象，近乎是当年586/2G的速度。

replace 看什么状况，如下数据状态，对VFP来说应该是神速了。

CREATE CURSOR 地址汇总表 (地址 v(240))
INSERT INTO 地址汇总表 VALUES ("地址1")
INSERT INTO 地址汇总表 VALUES ("地址2")
INSERT INTO 地址汇总表 VALUES ("地址3")
INSERT INTO 地址汇总表 VALUES ("地址4")
INSERT INTO 地址汇总表 VALUES ("地址5")
CREATE CURSOR 地址更新表 (旧地址 v(240), 新地址 v(240))
INSERT INTO 地址更新表 VALUES ("地址1","地址111")
INSERT INTO 地址更新表 VALUES ("地址3","地址333")
INSERT INTO 地址更新表 VALUES ("地址5","地址555")
INDEX on 旧地址 TAG tag_地址
SELECT 地址汇总表
SET RELATION TO 地址 INTO "地址更新表"
REPLACE 地址 WITH 地址更新表.新地址 FOR FOUND("地址更新表")
SELECT * FROM 地址汇总表

用编码就更可靠准确
CREATE CURSOR 地址汇总表 (编码 c(6), 地址 v(240))
INSERT INTO 地址汇总表 VALUES ("100001","地址1")
INSERT INTO 地址汇总表 VALUES ("100002","地址2")
INSERT INTO 地址汇总表 VALUES ("100003","地址3")
INSERT INTO 地址汇总表 VALUES ("100004","地址4")
INSERT INTO 地址汇总表 VALUES ("100005","地址5")
CREATE CURSOR 地址更新表 (编码 c(6), 旧地址 v(240), 新地址 v(240))
INSERT INTO 地址更新表 VALUES ("100001","地址1","地址111")
INSERT INTO 地址更新表 VALUES ("100003","地址3","地址333")
INSERT INTO 地址更新表 VALUES ("100005","地址5","地址555")
INDEX on 编码 TAG tag_编码
SELECT 地址汇总表
SET RELATION TO 编码 INTO "地址更新表"
REPLACE 地址 WITH 地址更新表.新地址 FOR FOUND("地址更新表")
SELECT * FROM 地址汇总表

又不是天天改的，慢一点没什么。
难道吃饱没事做，天天去改啊

你改成 Select Count(1) from a,b Where 就知道了命中多少记录可以。

设A表地址串有行 a+c, a+b, a+c, a+d 共4行记录，设B表有行a,b,c,d，虽然B表不重复。但你这个 Where 产生的 join 结果会命中16行记录。

对条件中的字段建索引

若不想费时费力去构造SQL语句，那么转用VFP的“土话”——用Replace替代——有时候确实是非常高效，非常优异的，速度快出不仅仅是一个量级，而是“指数级”！

如果单打独斗 Replace 未必都会输给 SELECT - SQL、UPDATE - SQL，是“土枪”还是“洋炮”，有兴趣的可以测试一下。

不用试了，100% 被 SQL 秒，我都有案例了我只是实在懒得动，几分种变成几百毫秒。
要如何对数据转换才能发挥出 SQL 最大性能这需要稍微动一下心思，而且是不改原表结构也不改变结果输出的情况下，仅在运算时对数据行列转换。

说的是“未必都会”输。
案例也只能说明某种情况。
SQL命令只是集成化高，相对解释语言来说，命令集成化越高运行效率越高，所谓的“一句搞定”就是这意思。
但集成化越高灵活性就越低，SQL命令对一些“复杂度”较高的问题，效率就显得不那么高，甚至不好处理。
“100% 被 SQL 秒”，这个“100%”的说法是不是对这个问题的理解出偏了。

replace 要想发挥出最高性能，表关系是少不了。
SQL 就亲民很多了，原则上是：宁可什么都不做都不可多建索引。直到程序跑不动了，再去想办法。


二者完全适合不一样的应用场景，理论上并没有 PK 的机会。