MySQL和PostgreSQL的REGEXP_REPLACE行为不同：MySQL默认区分大小写且需参数控制全局替换，PostgreSQL默认局部替换、需'g'标志启用全局；二者均用1清洗手机号最可靠，但须预处理隐藏字符并避免实时计算影响索引性能。0-9 ↩
REGEXP_REPLACE 在 MySQL 和 PostgreSQL 中的行为差异
MySQL 8.0+ 和 PostgreSQL 都支持 REGEXP_REPLACE，但语法和默认行为不同：MySQL 默认区分大小写且不支持 g 标志（全局替换需显式指定），PostgreSQL 则默认全局替换且需用 'g' 标志控制——不加会只换第一个匹配项。
- MySQL 示例：
REGEXP_REPLACE(phone, '[^0-9]', '', 1, 0, 'c')—— 第5参数0表示从位置1开始，第6参数'c'是匹配模式（'c'= case-sensitive） - PostgreSQL 示例：
REGEXP_REPLACE(phone, '[^0-9]', '', 'g')—— 第4参数'g'必须显式传入，否则只替换首处 - SQLite、SQL Server 不原生支持
REGEXP_REPLACE，强行调用会报错function REGEXP_REPLACE does not exist
清洗手机号：只保留数字的正则表达式写法
目标是剔除所有非数字字符（如 +、-、空格、( )、中文括号 等），保留纯 11 位数字。关键在字符类 [^0-9]，它匹配“任意非数字字符”，比逐个罗列更鲁棒。
- 推荐写法：
[^0-9]—— 简洁、覆盖全，包括 Unicode 中的全角数字以外的所有符号 - 避免写法：
[^0-9\uFF10-\uFF19]—— 想兼容全角数字？没必要，手机号输入场景几乎不会出现全角数字；加了反而降低可读性和性能 - 注意边界：
[\D]在部分数据库中不等价于[^0-9]（\D可能匹配 Unicode 字母，而[^0-9]更严格）
实际清洗时容易漏掉的干扰字符
真实业务数据里，手机号常混入不可见字符或特殊分隔符，比如 Excel 导出带的 CHAR(160)（不间断空格）、微信粘贴进来的零宽空格 U+200B、甚至 BOM 头。这些不会被 [^0-9] 漏掉，但可能被肉眼忽略。
- 验证方法：用
LENGTH(phone)和LENGTH(REGEXP_REPLACE(phone, '[^0-9]', ''))对比，差值不为 0 就说明有隐藏字符 - 增强清洗（MySQL）：
REGEXP_REPLACE(TRIM(REPLACE(phone, CHAR(160), '')), '[^0-9]', '')—— 先清空格类，再正则 - PostgreSQL 可用
TRANSLATE(phone, E'\u200b\xA0', '')预处理零宽/不间断空格，再进REGEXP_REPLACE
性能与索引注意事项
REGEXP_REPLACE 是计算型操作，无法走索引。如果清洗后要查重或关联，别在 WHERE 里实时调用，应提前清洗并存到新字段（如 phone_clean），再对该字段建索引。
- 错误做法：
WHERE REGEXP_REPLACE(raw_phone, '[^0-9]', '') = '13812345678'—— 全表扫描 - 正确做法：新增列
ALTER TABLE users ADD COLUMN phone_clean VARCHAR(11)，用UPDATE users SET phone_clean = REGEXP_REPLACE(raw_phone, '[^0-9]', '')填充，再CREATE INDEX idx_phone_clean ON users(phone_clean) - MySQL 8.0+ 支持函数索引：
CREATE INDEX idx_phone_clean ON users((REGEXP_REPLACE(raw_phone, '[^0-9]', '')))，但要注意该索引仅对完全匹配有效，模糊查询仍不加速
86、有些少了 1、或者运营商携号转网导致号段规则失效——这些得靠业务规则补正，REGEXP_REPLACE 只负责把“脏”变“净”。 
