regexp_replace是mysql 8.0+清洗脏数据最直接有效的方案，但需注意：它不支持unicode空格默认匹配，[[:space:]]仅覆盖ascii空白，须显式补充\u3000\u00a0\u200b等；清洗换行需按语义选择清除或转空格；手机号标准化须先提纯再锚点重排；update必须加where条件防全表误更新。
REGEXP_REPLACE 是 MySQL 8.0+ 清洗脏数据最直接有效的内置方案，但必须注意：它不支持 Unicode 空格（如 、 、）的默认匹配，且正则引擎基于 ICU，行为和 PCRE 有细微差异——踩错参数或模式，清洗可能漏掉关键字符，甚至误删内容。
替换不可见字符时为什么 [:space:] 不够用？
MySQL 的 [[:space:]] 只覆盖 ASCII 空白（空格、\t、\n、\r、\f、\v），完全不匹配常见 Unicode 空格：
-
\u3000（中文全角空格）→ 用'[[:space:]]|[\u3000\u00A0\u200B]' -
\u00A0（NO-BREAK SPACE）→ 常见于网页复制粘贴 -
\u200B（ZERO WIDTH SPACE）→ 隐形分隔符，破坏字符串比较
错误写法：REGEXP_REPLACE(col, '[[:space:]]', '') → 漏掉全角空格，清洗后仍报“字段不一致”
正确写法：REGEXP_REPLACE(col, '[[:space:]]|[\u3000\u00A0\u200B]', '')
清洗换行回车要保留语义还是彻底清除？
直接用 REPLACE(REPLACE(col, '\r', ''), '\n', '') 简单粗暴，但 REGEXP_REPLACE 能统一处理并区分场景：
- 彻底清除（适合用户名、手机号等单值字段）：
REGEXP_REPLACE(col, '[\r\n]+', '') - 转为空格（适合地址、描述类字段，避免“北京市海淀区”变成“北京市海淀区”）：
REGEXP_REPLACE(col, '[\r\n]+', ' ') - 只清首尾换行（保留段落结构）：需配合
TRIM+ 正则，不能单靠REGEXP_REPLACE
注意：[\r\n] 在 MySQL 中必须写成字符组，不能写 \s（MySQL 不支持 \s 简写）
手机号格式标准化为什么不能只靠 occurrence 参数？
想把 138-0013-8000、138 0013 8000、13800138000 全部转为 138-0013-8000，不能依赖 occurrence（它只控制第几个匹配项被替换，不是“按组重排”）：
- 先用
REGEXP_REPLACE(col, '[^0-9]', '')提纯数字 → 得到 11 位纯数字 - 再用
REGEXP_REPLACE(col, '^([0-9]{3})([0-9]{4})([0-9]{4})$', '$1-$2-$3')重格式化 - 必须加
^和$锚点，否则可能匹配子串导致错乱
漏锚点的后果：REGEXP_REPLACE('13800138000123', '([0-9]{3})([0-9]{4})([0-9]{4})', '$1-$2-$3') → 返回 138-0013-8000123（只替换了前 11 位，末尾 123 残留）
UPDATE 前必须加 WHERE 条件，否则会静默污染数据
REGEXP_REPLACE 对 NULL 或不匹配的字段返回原值，看似安全，但以下情况极易出事：
- 没加
WHERE col REGEXP '[\r\n\u3000]'→ 百万行表全量 UPDATE，IO 暴涨，主从延迟飙升 - 用
WHERE col LIKE '%\n%'替代正则 →LIKE不识别\n字面量，条件恒假，实际执行全表更新 - 测试时只查了 10 行，上线后才发现某字段含大量
\u200B，但 WHERE 没覆盖 → 清洗失败未报警
安全写法示例：UPDATE user_profile SET phone = REGEXP_REPLACE(phone, '[^0-9]', '') WHERE phone REGEXP '[^0-9]';
真正难的不是写出正则，而是判断哪些字符该留、哪些该杀，以及在 UPDATE 里让正则只动该动的行——Unicode 空格、锚点缺失、WHERE 漏判，这三个点，90% 的线上清洗事故都栽在这儿。
