mysql的replace()是大小写敏感的纯字符串全局替换函数，不支持正则、无边界匹配，需配合where精准限定、null预处理及字符集统一，误用易致过度替换。
UPDATE 语句中直接用 REPLACE() 替换字段值
MySQL 的 REPLACE() 是纯字符串函数，不支持正则、不区分大小写（默认）、也不管字段类型——只要能转成字符串就参与替换。它在 UPDATE 里最常用，语法就是：SET 字段 = REPLACE(字段, '旧子串', '新子串')。
常见错误是漏掉 WHERE 条件，导致全表误改；或者没加引号把字段名当字符串字面量；还有人误以为 REPLACE() 能按位置替换（其实不能，那是 INSERT() 函数干的）。
- 必须用单引号包裹待替换的字符串，比如
'http:'，不能写成http: - 建议在
WHERE中加前置校验，例如WHERE 字段 LIKE '%http:%'或WHERE INSTR(字段, 'http:') > 0，避免无意义执行 -
REPLACE()是全量替换，哪怕子串重叠也会反复处理（如REPLACE('aaaa', 'aa', 'x')→'xx'），这点和 PHP 的str_replace()行为一致
为什么不能用 REPLACE() 做大小写敏感或正则替换
REPLACE() 没有大小写开关参数，也不接受正则表达式。它只做“逐字节/字符等长匹配 + 全局替换”，底层不走 collation 规则判断，而是依赖字段当前的字符集和排序规则（collation）做原始字节比较。所以如果字段是 utf8mb4_0900_as_cs（大小写敏感），REPLACE(name, 'abc', 'xyz') 就不会匹配 'ABC'；但如果是默认的 utf8mb4_0900_ai_ci，就可能意外命中。
想精准控制大小写或用模式（比如“替换所有以 img/ 开头的路径”），就得绕开 REPLACE()：
- 用
REGEXP_REPLACE()（MySQL 8.0.4+ 才支持），例如：REGEXP_REPLACE(url, '^https?://([^/]+)/', 'https://cdn.$1/') - 低版本只能拼
CASE WHEN+ 多个REPLACE()组合，或导出后用脚本处理 - 注意
REGEXP_REPLACE()默认也受 collation 影响，必要时显式加BINARY修饰，如BINARY url REGEXP '...'
REPLACE() 对非字符串字段的隐式转换风险
MySQL 允许对数字、日期甚至 JSON 字段调用 REPLACE()，但它会先强制转成字符串再替换。这个过程容易丢精度或引发意外格式变化。
比如字段是 DECIMAL(10,2) 存着 12345.67，执行 REPLACE(price, '12', '99') 后变成 99345.67 —— 看似合理，但如果原值是 12.34，结果就变成 99.34，逻辑已错乱。
- 日期字段如
DATE被转成'2026-04-10'格式，替换'-'可能破坏合法性（如替换成'.'后无法被 MySQL 识别为有效日期） - JSON 字段虽然能转字符串，但替换后大概率 JSON 格式损坏，后续
JSON_VALID()检查失败 - 稳妥做法：先
CAST(字段 AS CHAR)显式转字符串，再替换，最后看是否需要回转；但多数场景应避免在非文本字段上用REPLACE()
批量替换前务必验证 SQL 并备份关键数据
REPLACE() 在 UPDATE 中一旦执行就不可逆（除非有 binlog 或备份）。线上操作最常踩的坑不是语法错，而是范围失控。
比如想把所有 '/old-api/' 换成 '/v2/'，但字段里混着 '/old-api-key' 或 'my-old-api-endpoint'，一并被改掉就坏了。
- 执行前先用
SELECT验证效果：SELECT id, url, REPLACE(url, '/old-api/', '/v2/') AS new_url FROM t WHERE url LIKE '%/old-api/%' LIMIT 5; - 生产环境必须加
WHERE限定范围，宁可多写几个条件，也不要依赖“应该只有这些” - 涉及核心表，优先用
mysqldump导出对应表或加START TRANSACTION包裹（确保引擎支持事务）
真正难的从来不是怎么写那条 REPLACE()，而是确认“这一串字符，在这个上下文里，只该被这么换”。
