mysql 8.0.4+ 才原生支持 regexp_replace，必须确保三参数 str、pattern、replacement 齐全，中文需统一字符集，手机号脱敏推荐用边界锚定正则，换行符处理需显式指定 match_type='c' 并用 [ ]+。
REGEXP_REPLACE 在 MySQL 8.0+ 中怎么写才不报错
MySQL 的 REGEXP_REPLACE 是个“娇气”的函数——版本不对、模式写错、参数顺序乱，立刻返回 NULL 或直接报错 ERROR 1305 (42000): FUNCTION xxx.REGEXP_REPLACE does not exist。
它只在 MySQL 8.0.4+ 原生支持；低版本必须用 REPLACE 嵌套或自定义函数替代。确认版本后，注意三个参数缺一不可：REGEXP_REPLACE(str, pattern, replacement[, position[, occurrence[, match_type]])，其中后三个是可选，但漏掉前三个就一定挂。
- 常见错误：把
replacement写成正则捕获组语法但没加$1引用，结果原样输出（不是报错，更难排查） - 匹配中文或 Unicode 字符时，
str和pattern字符集必须一致，否则空匹配或乱码；建议显式用COLLATE utf8mb4_0900_as_cs -
match_type值为'c'（大小写敏感）或'i'（忽略），不传默认是'c'，别想当然认为像 Python 默认忽略
替换手机号中间四位为星号的正确写法
这是最常被搜的问题，但很多人写的正则要么太宽泛（误伤身份证、订单号），要么太死板（只匹配 11 位、忽略 199/166 等新号段）。
真正稳妥的做法是锚定边界 + 明确号段范围 + 保留原始空格/括号格式：
SELECT REGEXP_REPLACE(
phone,
'(^|[^0-9])(1[3-9][0-9]{9})([^0-9]|$)',
'\1****\3'
) AS masked_phone
FROM users;
说明： 和 是反向引用，确保前后非数字字符（如空格、括号）不丢失；1[3-9][0-9]{9} 覆盖所有国内主流 11 位手机号，比 ^1[3-9]d{9}$ 更适应脏数据场景。
- 别用
^1[3-9]\d{9}$直接全量替换——字段里带空格或短横线就完全不匹配 - 如果要批量更新，先用
WHERE phone REGEXP '1[3-9][0-9]{9}'过滤，避免对 NULL 或非手机号字段执行无意义替换 - 性能提示：该函数无法使用索引，大数据量慎用于 WHERE 条件中
为什么 REGEXP_REPLACE 处理换行符总是失效
因为 MySQL 默认的正则引擎（ICU）把 \n 当作字面量，而不是换行控制符；[
] 也常不生效——根本原因是匹配模式默认不开启多行模式（match_type 不含 'm'）。
想真正删掉字段里的回车、换行、制表符，得组合使用：
SELECT REGEXP_REPLACE( content, '[ ]+', ' ', 1, 0, 'c' ) AS cleaned FROM logs;
-
[ ]+比\s+更安全，后者在 MySQL 中可能匹配到全角空格等意外字符 - 第四个参数
position设为1表示从开头找；第五个occurrence为0表示全局替换（不是只换第一个） - 如果字段含大量 CRLF（Windows 风格），单独加一条
REGEXP_REPLACE(..., ' ', ' ')预处理更稳
PostgreSQL 和 MySQL 的 REGEXP_REPLACE 差异在哪
名字一样，行为差很多：PostgreSQL 的 regexp_replace() 默认贪婪、支持 g 标志控制全局，而 MySQL 没有标志位，靠 occurrence=0 实现；PG 支持反向引用 \1，MySQL 用 $1 ——混用必出错。
迁移 SQL 时最容易栽在这儿：
- MySQL 中
REGEXP_REPLACE('a-b-c', '-', '$1', 1, 0)→ 错！$1没有捕获组，结果是字面量$1 - PostgreSQL 中
regexp_replace('a-b-c', '([a-z])-([a-z])', '\1\2', 'g')→ 正确；MySQL 必须写成REGEXP_REPLACE('a-b-c', '([a-z])-([a-z])', '\1\2')，且不能加'g' - MySQL 不支持
POSIX字符类如[:digit:]，得用[0-9]；PG 两者都认
跨数据库写清洗逻辑时，别图省事复用同一段正则表达式——哪怕看起来一样，也可能在某个引擎里静默失败。
