REPLACE()函数本身不慢，真正拖垮性能的是无索引支撑下的全表扫描与前导通配符匹配；必须通过主键分批、生成列索引或业务倒排表等手段规避全表扫描，避免IO爆炸、锁竞争和日志膨胀。
REPLACE()函数本身不慢，慢的是全表扫描+无索引匹配
真正拖垮性能的不是REPLACE()函数内部逻辑，而是它常被用在没索引支撑的WHERE条件下。比如WHERE content LIKE '%old%'这种前导通配符查询，MySQL无法走索引，只能逐行读取整字段内容、转成字符串、再调用REPLACE()——对TEXT或长VARCHAR字段，每次读取+内存拷贝开销极大。
常见错误现象：执行UPDATE posts SET body = REPLACE(body, 'foo', 'bar') WHERE body LIKE '%foo%'，表有500万行，body平均长度2KB，实际IO量轻松破10GB，还伴随大量临时内存分配和undo log膨胀。
- 字段没索引时，
INSTR(content, 'foo') > 0和LIKE '%foo%'性能几乎一样差 -
REPLACE()对每行都强制触发一次完整字符串扫描，哪怕该行根本不含'foo' - 如果
content是TEXT且启用了外部存储（innodb_large_prefix=ON），还会额外触发LOB页读取
大文本替换时锁粒度与事务日志压力飙升
InnoDB对每一行修改都会生成redo log和undo log。REPLACE()导致字段值变更后，即使只改几个字节，只要新旧值长度不同，就可能触发页分裂或外部LOB更新——这会让单次UPDATE的写放大倍数远超预期。
典型翻车场景：对含HTML的TEXT字段批量删
