mysql 8.0.4+才支持regexp_replace，需字符集统一、参数齐全，否则报错或返回null；云数据库还需开启regexp_engine；清洗手机号应先处理char(160)再正则去除非数字；脱敏须锚定边界并加where过滤；性能优化需预存清洗字段并建索引。
REGEXP_REPLACE 在 MySQL 8.0 中能干脏数据清洗，但必须满足三个硬条件：版本 ≥ 8.0.4、字符集统一、参数不缺位；否则直接返回 NULL 或报错 ERROR 1305。
确认 MySQL 版本和函数可用性
执行 SELECT VERSION(); 确认是 8.0.4 或更高——低于这个版本调用 REGEXP_REPLACE 会报 FUNCTION xxx.REGEXP_REPLACE does not exist。不是“不支持”，而是压根没注册进函数表。
- 低版本替代方案只能是多层
REPLACE()嵌套，比如清理括号+空格+短横线：REPLACE(REPLACE(REPLACE(phone, '(', ''), ')', ''), '-', '') - 若用的是云数据库（如阿里云 RDS、腾讯云 CDB），要额外确认是否开启
regexp_engine配置项，默认可能关着 - 执行
SELECT REGEXP_REPLACE('test', 't', 'x');能返回xesx才算真正可用
清洗手机号：只留数字，但得防住隐藏字符
目标是把 (138) 1234-5678、138 1234\u200b5678（含不间断空格 CHAR(160) 或零宽空格 U+200B）变成纯 13812345678。
- 基础写法：
REGEXP_REPLACE(phone, '[^0-9]', '')——[^0-9]能匹配所有非 ASCII 数字字符，包括不可见符，比逐个REPLACE更鲁棒 - 但真实脏数据里常混有
CHAR(160)（Excel 导出常见），MySQL 的正则引擎对它的识别不稳定，建议前置处理：REGEXP_REPLACE(REPLACE(phone, CHAR(160), ' '), '[^0-9]', '') - 验证是否还有残留：对比长度，
LENGTH(phone) != LENGTH(REGEXP_REPLACE(phone, '[^0-9]', ''))为真就说明漏了
替换中间四位手机号为星号：锚定边界才不误伤
别用 ^1[3-9]\d{9}$ 直接全字段替换——字段里带空格或括号就完全不匹配，结果原样返回，你以为脱敏成功了，其实没动。
- 正确写法：
REGEXP_REPLACE(phone, '(^|[^0-9])(1[3-9][0-9]{9})([^0-9]|$)', '\1****\3') -
\1和\3是反向引用，保留原始前缀/后缀（比如空格或括号），避免格式崩坏 - 必须加
WHERE phone REGEXP '1[3-9][0-9]{9}'过滤，否则对NULL或'abc'字段执行，结果还是NULL或原值，但你可能误以为“脱敏失败”
性能陷阱：别在 WHERE 里实时调用 REGEXP_REPLACE
WHERE REGEXP_REPLACE(raw_phone, '[^0-9]', '') = '13812345678' 这种写法等于放弃索引，全表扫描——哪怕你给 raw_phone 建了索引也没用。
- 正确路径是：先用
UPDATE把清洗结果存到新字段phone_clean，再对它建索引 - 批量更新时务必加范围限制，例如：
WHERE id BETWEEN 1000 AND 2000 AND raw_phone REGEXP '[^0-9]'，避免锁表太久 - 如果数据量超百万，考虑分批提交，并监控
max_allowed_packet，嵌套太深可能触发截断
真正难的不是写出正则，而是判断哪些字符该被归为“脏”——比如 + 在国际号码里是合法前缀，在国内却大概率是干扰符；这种业务语义，正则本身无法承载，得靠 WHERE 条件配合人工规则兜底。
