MySQL用REPLACE()函数最直接，但仅支持全量精确替换；PostgreSQL可用REGEXP_REPLACE()实现正则替换；SQL Server需结合STUFF()与CHARINDEX()处理位置替换；三者均需注意字符集、长度截断及事务安全。
MySQL 用 REPLACE() 函数最直接
MySQL 没有正则替换的原生 UPDATE 语法，REPLACE(str, from_str, to_str) 是唯一可靠、可批量执行的字符串替换函数。它区分大小写，且是**全量替换**（不是只换第一次），但不支持通配或模糊匹配。
常见错误是误以为它能处理子串位置或条件替换，比如想“只替换开头的 http://”，结果把字段里所有 http:// 都干掉了。这时候得组合 CONCAT() + LEFT() 或正则判断，不能硬套 REPLACE()。
- 安全做法：先用
SELECT id, content, REPLACE(content, '旧文本', '新文本') AS new_content FROM table WHERE content LIKE '%旧文本%';预览效果 - 执行前务必备份，或在事务中操作：
BEGIN; UPDATE table SET content = REPLACE(content, 'abc', 'xyz') WHERE id IN (1,2,3); SELECT ROW_COUNT(); ROLLBACK; - 注意 NULL 值：如果
content是 NULL，REPLACE(content, ...)结果仍是 NULL，不会报错但可能不符合预期
PostgreSQL 要用 REPLACE() 或 REGEXP_REPLACE()
PostgreSQL 同样提供 REPLACE()，行为和 MySQL 一致；但它额外支持 REGEXP_REPLACE()，这才是真正灵活的批量替换工具——能限定位置、次数、大小写、分组引用。
典型踩坑点：默认开启大小写敏感，想全局替换却漏了 'g' 标志（global）或 'i'（ignore case），结果只改了第一个或大小写不匹配的项。
- 简单替换：
UPDATE table SET content = REPLACE(content, 'foo', 'bar'); - 正则替换（如只换行首的
http://）：UPDATE table SET content = REGEXP_REPLACE(content, '^http://', 'https://', 'g'); -
REGEXP_REPLACE()第四个参数必须显式传，常用组合是'gi'（全局+忽略大小写），空字符串或缺失会按默认（仅首次+敏感）处理
SQL Server 的 REPLACE() 和 STUFF() 分工明确
SQL Server 的 REPLACE() 和 MySQL/PG 一样，但遇到“只替换第 N 次出现”或“基于位置替换”时，得切到 STUFF() + CHARINDEX() 组合。很多人卡在这一步，硬写多层 REPLACE() 导致逻辑错乱。
例如想把第三个逗号改成分号，REPLACE() 完全无能为力，必须定位位置再覆盖。
- 基础替换：
UPDATE table SET content = REPLACE(content, N'旧', N'新');（注意 Unicode 字符串加N''） - 定位替换（如把第二个斜杠后的内容清空）：
UPDATE table SET content = STUFF(content, CHARINDEX('/', content, CHARINDEX('/', content) + 1) + 1, LEN(content), ''); - 性能提示：含大量
CHARINDEX()嵌套的语句在大数据量下很慢，建议先加索引或拆成两步（先查出 ID 和位置，再 UPDATE）
通用陷阱：字符集、长度截断与事务边界
所有数据库批量替换都绕不开这三件事：源字段是否含多字节字符（如 emoji、中文）、目标字符串是否超长导致被截断、UPDATE 是否跨事务造成部分成功部分失败。
最容易被忽略的是字段定义长度——比如 VARCHAR(50) 字段，原内容是 'hello'，替换成 'hello world! this is long...'，超出部分直接被静默截断，日志里还不报错。
- 检查字段长度：
SELECT character_maximum_length FROM information_schema.columns WHERE table_name='table' AND column_name='content'; - 确认字符集：MySQL 中
utf8mb4下 emoji 占 4 字节，REPLACE()计算长度时按字符数，不是字节数，但存储层可能因ROW_FORMAT=COMPACT截断 - 大表慎用单条 UPDATE：超过百万行建议分批，用
WHERE id BETWEEN x AND y控制每次更新量，避免锁表太久
