REPLACE()是SQL标准字符串替换函数，必须配合UPDATE才能修改数据；单独SELECT仅预览效果。三参数缺一不可，第二参数不能为NULL，否则整行返回NULL；区分大小写取决于排序规则；含单引号需转义为两个单引号；MySQL中勿与REPLACE INTO混淆；PostgreSQL 9.6+才原生支持，旧版需用regexp_replace()；务必加WHERE条件防全表误改；嵌套替换存在二次污染风险；执行前须验证字段长度防静默截断。
UPDATE 中用 REPLACE 函数做字符串批量替换
直接说结论：REPLACE() 是 SQL 标准函数，但必须配合 UPDATE 使用才能真正修改数据；单独 SELECT REPLACE(...) 只是查看效果，不改原表。
常见错误是写完 SELECT REPLACE(col, 'old', 'new') 觉得“替换了”，结果查表发现没变——因为没执行 UPDATE。
-
REPLACE(col, 'from_str', 'to_str')三个参数缺一不可，第二个参数不能为NULL，否则整行返回NULL - 区分大小写行为取决于字段的排序规则（collation），例如 MySQL 中
utf8mb4_0900_as_cs区分，utf8mb4_general_ci不区分 - 如果要替换的内容含单引号（如
O'Connor），SQL 字符串里必须写成两个单引号：'O''Connor'
MySQL 和 PostgreSQL 的 REPLACE 用法差异
MySQL 的 REPLACE() 是字符串函数，和 REPLACE INTO 完全无关——后者是插入/覆盖语句，别混淆。
PostgreSQL 同样支持 REPLACE(str, from, to)，但注意：它从 9.6 版本才加入，旧版本需用 translate() 或正则 regexp_replace() 替代。
- MySQL 示例：
UPDATE users SET email = REPLACE(email, '@gmail.com', '@googlemail.com'); - PostgreSQL 示例（9.6+）：
UPDATE logs SET message = REPLACE(message, 'ERR:', 'ERROR:'); - PostgreSQL 旧版替代：
UPDATE logs SET message = regexp_replace(message, '^ERR:', 'ERROR:', 'g');
WHERE 条件必须加，否则全表误伤
没加 WHERE 的 UPDATE ... REPLACE() 会扫全表，哪怕只有一行匹配，其他行也会被无意义地重写一次（可能触发更新时间戳、触发器、主从延迟）。
- 安全写法永远带条件：
UPDATE posts SET content = REPLACE(content, '<b>', '<strong>') WHERE content LIKE '%<b>%';</b></strong></b> - 想确认影响行数？先用
SELECT COUNT(*) FROM table WHERE col LIKE '%old%'; - 生产环境建议加
LIMIT 1000（MySQL 支持，PostgreSQL 需用 CTE 或子查询模拟）防止锁表太久
嵌套 REPLACE 或多次更新时的顺序陷阱
REPLACE() 是逐字符扫描、非重叠替换，且不回溯。比如 REPLACE('aaa', 'aa', 'x') 结果是 'xa'（先替前两个 a 得 'xa'，剩下一个 a 不再匹配）。
若需多步替换（如把 A→B，再把 B→C），直接嵌套 REPLACE(REPLACE(col, 'A', 'B'), 'B', 'C') 会导致第一次替换出的 B 被二次替换——这不是 bug，是设计如此。
- 真要避免二次污染，拆成两条独立
UPDATE，中间用WHERE精确限定范围 - 或者用临时标记符过渡：
REPLACE(REPLACE(col, 'A', '___TEMP___'), '___TEMP___', 'C')（前提是原数据不含该标记） - 更稳妥的做法：用正则（如 PostgreSQL
regexp_replace）或应用层处理，逻辑更可控
REPLACE 不会报错截断，但超长部分会被静默丢弃（取决于 SQL 模式）。 
