比方说：
update 地址汇总表 SET 已处理 = .t. , 联系地址 = strtran(联系地址, trim(地址更新表.旧串), trim(地址更新表.新串)) from 地址更新表 WHERE 联系地址 like "%"+trim(地址更新表.旧串)+"%" .and. ! 已处理
大意是，地址定期更新时，凡带有“向阳西路”的，统一更换为“爱麦斯西路”，“明水区”的，统一更换为“高新区”。“地址更新表.dbf”中保存对应表：

旧串, 新串
"向阳西路", "爱麦斯西路"
"明水区", "高新区"
...

where条件若为like、like()或者atcc()，当数据表较大，达到10W+甚至更多记录时，运行起来会狠慢。
索引“联系地址”、“旧串”等字段，好像并不管用。

REPLACE 命令不行吗

replace也根本无任何速度优势啊，一样一样的：

select B
use 地址汇总表
select A
use 地址更新表
scan
    * select A
    lcOldStr = trim(A.旧串)
    lcNewStr = trim(A.新串)
    select B
    replace 已处理 with .t. , 联系地址 with strtran(联系地址, lcOldStr, lcNewStr) for atcc(lcOldStr, 联系地址)>0 .and. ! 已处理
endscan

印象中只有左/右包含可以有效利用索引，这种全包含用不上
不过，把 已处理 放在 地址 like ... 前面显然没坏处

[此贴子已经被作者于2023-3-20 10:25编辑过]

地址格式不规范有可能产生的结果。
地址应该是一个完整数据（具有唯一性），不能说A包含了XXX就是B的地址，这样就带有不确定性，这样修改的结果也有可能是不对的。

区县，街道改名很常见，一个县区上千个单位，手工一个一个修改也不是不行，实际上ZF部门也是这么样做的，不然要那么些公务员干哈

不要用其中含XXX新旧对照表，最好用完整的新旧地址对照表来修改，这样一次扫描对照就可以。

新旧地址对照表应该也是人工生成，平时及时修改地址的应该也没多少功夫，主要是根据新旧地址对照表来修改总地址数据要准确高效。

有地址编码库就更好，数据处理只认编码，地址文本只作显示用。

如果（地址更新表.旧串）这个字段的值是唯一，恐怕再无任何办法。
如果（地址更新表.旧串）这个字段的值不唯一，那将有可能 join 出来一个超级大的结果集，也许这才是 Update 慢的主要原因。