REPLACE函数仅支持纯字符串替换，不支持正则；正则替换需用各数据库专用函数，如MySQL 8.0+的REGEXP_REPLACE()、PostgreSQL的REGEXP_REPLACE()（需双反斜杠转义）、SQL Server无原生正则替换。
REPLACE 函数不能处理正则，别被名字骗了
SQL 标准里的 REPLACE 是纯字符串逐字替换，不是正则引擎。你写 REPLACE(column, 'd+', 'X') 会原样报错或静默失败——它根本不认 d 这种语法。MySQL 8.0+、PostgreSQL、SQL Server 各自的正则函数名和行为完全不同，混用必翻车。
- MySQL 5.7 用
REGEXP_REPLACE()（需开启模式匹配支持） - PostgreSQL 用
REGEXP_REPLACE()，但默认区分大小写，且元字符需双反斜杠转义（'\d+'） - SQL Server 2017+ 才有
STRING_SPLIT和TRANSLATE，但没原生正则替换；得靠 CLR 或外部脚本补位 - SQLite 默认不支持正则，除非编译时启用了
ENABLE_REGEXP
MySQL 8.0 批量替换含下划线的字段值
比如把 user_name 字段里所有连续两个下划线 __ 换成单个 _，同时避免误伤单词内的单下划线。这时候不能只靠嵌套 REPLACE，得上正则。
- 用
REGEXP_REPLACE(user_name, '_{2,}', '_')——_{2,}匹配两个及以上下划线 - 注意：MySQL 正则默认是贪婪匹配，
_+也能用，但语义不如_{2,}明确 - 执行前先
SELECT user_name, REGEXP_REPLACE(user_name, '_{2,}', '_') FROM users LIMIT 5验证效果 - UPDATE 时加
WHERE user_name REGEXP '_{2,}'条件，避免全表扫描无谓更新
PostgreSQL 中下划线清理要小心转义和空格
PostgreSQL 的 REGEXP_REPLACE 对空白符敏感，且正则字符串里反斜杠必须写成双份。比如想把开头、结尾或中间多余下划线（含空格夹杂）统一规整为单下划线，容易漏掉边界情况。
- 清洗前后空格+压缩下划线：
REGEXP_REPLACE(TRIM(user_name), '_+', '_', 'g')——'g'参数表示全局替换，否则只换第一个 - 若字段含制表符或换行符，
TRIM不管用，得加TRANSLATE(user_name, E' ', ' ')先转空格再处理 - 正则里写
'_+'就行，不用'\_+'；但写'\s+'表示空白符时，必须双反斜杠 - 性能提示：在大表上跑前，确保
user_name字段有索引，且 WHERE 条件能利用到（比如WHERE user_name ~ '_{2,}'）
别硬扛：复杂替换建议导出后用 Python 处理
当需求变成「把下划线分隔的单词首字母大写，其余小写，再转驼峰」，或者「按业务规则映射特定下划线组合为固定字符串」，SQL 正则很快力不从心。这时候强行写几十层嵌套 REGEXP_REPLACE 不仅难读，还容易因版本差异失效。
- 用
psql -c "COPY (SELECT id, user_name FROM users) TO STDOUT WITH CSV HEADER" > users.csv导出 - Python 脚本里用
re.sub(r'_(w)', lambda m: m.group(1).upper(), s.lower())做驼峰转换，逻辑清晰可控 - 处理完用
pg_copy或mysqlimport回写，比在数据库里调试正则快得多 - 尤其注意 NULL 值、编码（UTF-8）、字段长度限制——导出导入过程比 SQL 替换更容易暴露数据质量问题
^ 或 $ 锚点就能让整批数据格式错乱。 
