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字段批量删<script>标签，<code>REPLACE(content, '<script>', '<!-- script removed -->')把8字节替成25字节，原本紧凑存放的页面被迫拆分，binlog体积暴涨3–5倍，从库延迟直接上分钟级。</script>
- 事务中修改行数越多，undo log保留时间越长，MVCC快照压力越大
-
innodb_log_file_size小于256M时，频繁刷盘会卡住整个写入队列 - 默认隔离级别下，未提交事务持续持有行锁，其他连接查
SELECT ... FOR UPDATE会被阻塞
为什么不能靠加索引解决所有问题？
给TEXT字段建普通索引不行（MySQL限制索引长度），前缀索引又不可靠：INDEX(content(100))只索引前100字符，而'old'可能出现在第101位之后，导致WHERE content LIKE '%old%'仍要全表扫。
真正可行的索引策略只有两种：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 用生成列（generated column）+函数索引：如
ALTER TABLE posts ADD COLUMN has_old TINYINT AS (CASE WHEN INSTR(content, 'old') > 0 THEN 1 ELSE 0 END) STORED，再对has_old建索引 - 业务层维护关键词倒排表，把
content中关键子串提取出来存到关联表，用等值查询替代模糊匹配
注意：FULLTEXT索引不适用于REPLACE()场景——它只为MATCH AGAINST服务，无法加速WHERE条件里的子串定位。
大文本批量替换必须分批，但LIMIT在UPDATE里很危险
MySQL 8.0+支持UPDATE ... LIMIT N，但直接写UPDATE t SET c = REPLACE(c,'a','b') WHERE c LIKE '%a%' LIMIT 1000仍有隐患：每次执行都重新扫描全表找前1000个匹配项，第二次执行可能重复处理同一行（因未排序且无游标锚点）。
安全分批的核心是「确定性推进」：
- 优先用主键范围：
WHERE id BETWEEN 10000 AND 19999 AND content LIKE '%a%' - 若主键不连续，用游标式：
WHERE id > 50000 AND content LIKE '%a%' ORDER BY id LIMIT 1000，执行后记录最大id值作为下次起点 - 每次执行前加
SELECT COUNT(*)预估影响行数，超过3000行就拆更小 - 别信
EXPLAIN的rows估算——对LIKE '%x%'它经常报错，实测才准
最麻烦的不是语法写不对，而是替换后字段超长触发截断（比如VARCHAR(255)原存250字节，替换后变260字节），MySQL静默截断不报错，数据就丢了。
