MySQL默认用POSIX BRE不支持+?量词，需用[:space:]；PostgreSQL用ERE支持s+但需加'g'标志；两者均不支持uXXXX，中文匹配MySQL 8.0.22+才支持[u4e00-u9fff]，PostgreSQL推荐p{Han}（需ICU）。
REGEXP_REPLACE 在 MySQL 和 PostgreSQL 中的行为差异
MySQL 8.0+ 和 PostgreSQL 的 REGEXP_REPLACE 看似同名，实则语法和默认行为不同，直接复制代码大概率报错。MySQL 默认使用 POSIX BRE（基本正则），不支持 +、? 等量词，除非开启 REGEXP_LIKE 兼容模式；PostgreSQL 默认用 ERE（扩展正则），支持更丰富的语法，但需注意转义规则。
常见错误现象：ERROR 3687 (HY000): Invalid regular expression（MySQL）或 ERROR: invalid regular expression（PostgreSQL），多因用了对方才支持的元字符。
- MySQL 中想匹配一个或多个空白符，得写
'[[:space:]]+'，不能直接用'\s+' - PostgreSQL 中
'\s+'可用，但若字段含换行符且想全局替换，必须加'g'标志（如REGEXP_REPLACE(col, '\s+', ' ', 'g')） - 两者都不支持
uXXXXUnicode 写法，中文字符建议用字面量或[u4e00-u9fff]类范围（PostgreSQL 支持，MySQL 8.0.22+ 才支持）
清洗常见特殊字符的典型正则模式
不是所有“特殊字符”都该一刀切删掉。比如邮箱里的 @、URL 中的 / 是合法符号，盲目替换会破坏数据。优先按业务场景定义“需清洗”的字符集。
实用示例（PostgreSQL）：
SELECT REGEXP_REPLACE( 'user@domain.com | 电话：138-xxx-xxxx', '[^a-zA-Z0-9@._-+ ]', -- 保留字母、数字、@ . _ - + 和空格 '', 'g' );
对应 MySQL（8.0+）：
SELECT REGEXP_REPLACE( 'user@domain.com | 电话：138-xxx-xxxx', '[^a-zA-Z0-9@._\-+[:space:]]', '' );
-
[:space:]比\s更兼容 MySQL；PostgreSQL 中两者等价 - 连字符
-必须放在字符类末尾或开头，否则会被解释为范围符（如[a-z-]安全，[a-z-0-9]会报错） - 点号
.在字符类内无需转义，但+、*、?在 MySQL 字符类外也不支持，别硬套 PCRE 习惯
性能陷阱：别在大表上无索引跑 REGEXP_REPLACE
REGEXP_REPLACE 是逐行计算函数，无法利用索引加速。对千万级表执行 UPDATE 或 SELECT，可能卡住数分钟甚至超时。
- 先用
WHERE col REGEXP '[^a-zA-Z0-9]'（MySQL）或WHERE col ~ '[^a-zA-Z0-9]'（PostgreSQL）缩小扫描范围 - 避免在 ORDER BY 或 GROUP BY 中嵌套该函数——会导致全表计算后再排序
- 如果只是清理入库前的数据，优先在应用层（Python/Java）做，数据库只存清洗后结果
中文与 Emoji 的边界情况处理
纯 ASCII 正则表达式对中文和 Emoji 基本无效。比如 [^a-zA-Z0-9] 会把所有汉字、标点、Emoji 全干掉，而你可能只想剔除「※★◆」这类装饰符号。
- MySQL 8.0.22+ 支持
[u4e00-u9fff]匹配中文，但需确认 collation 是utf8mb4_0900_as_cs级别 - PostgreSQL 推荐用 Unicode 属性类：
'\p{Han}'（汉字）、'\p{Emoji}'（Emoji），但需启用 ICU 支持（编译时配置） - 更稳妥的做法是白名单：明确列出要保留的符号，如
[a-zA-Z0-9u4e00-u9fff，。！？；：""''（）【】《》、 ]
真正难的不是写对正则，而是厘清业务中“什么是脏、什么是净”。一个电商 SKU 编码里的括号可能是合法分隔符，而用户昵称里的括号大概率该删——得看字段语义，不是看字符本身。
