MySQL默认区分大小写且不支持g标志，需显式指定匹配模式；PostgreSQL默认不区分大小写且必须加'g'才全局替换，参数顺序和Unicode支持也不同。
REGEXP_REPLACE 在 MySQL 和 PostgreSQL 中的行为差异
MySQL 8.0+ 和 PostgreSQL 都支持 REGEXP_REPLACE，但语法和默认行为不同：MySQL 默认区分大小写且不支持 i 标志（需用 COLLATE utf8mb4_0900_as_cs 控制），PostgreSQL 默认不区分大小写，且必须显式加 'g' 标志才能全局替换。
- MySQL 示例（删除所有非 ASCII 字符）：
REGEXP_REPLACE(col, '[^\x00-\x7F]', '') - PostgreSQL 示例（同效果）：
REGEXP_REPLACE(col, '[^\x00-\x7F]', '', 'g') - MySQL 若想忽略大小写匹配字母，得靠字符集，比如
col COLLATE utf8mb4_0900_as_cs不起作用，应改用[a-zA-Z]显式写全
清洗常见异常字符的正则模式
真正容易出错的不是函数调用，而是正则表达式本身写错边界或遗漏 Unicode 类别。比如想删“不可见控制字符”，只写 [ - - ] 会漏掉 UTF-8 编码的零宽空格（u200B）、软连字符（u00AD）等。
- 安全兜底方案（MySQL）：
REGEXP_REPLACE(col, '[[:cntrl:]]|[\u200B-\u200F\u202A-\u202E\u2060-\u206F\uFEFF]', '')（注意：MySQL 8.0.30+ 才支持\u形式 Unicode 码点） - 更兼容写法（适用于旧版 MySQL）：
REGEXP_REPLACE(col, '[\x00-\x08\x0B\x0C\x0E-\x1F\x7F]', '')，再额外用REPLACE处理已知零宽字符 - PostgreSQL 可直接用 Unicode 属性：
REGEXP_REPLACE(col, '\p{C}', '', 'g')（\p{C}匹配所有 Unicode 控制字符）
性能陷阱：别在 WHERE 或 JOIN 条件里用 REGEXP_REPLACE
对大表执行 REGEXP_REPLACE 时，如果放在 WHERE 子句中做条件过滤（比如 WHERE REGEXP_REPLACE(name, '[^a-z]', '') = 'john'），会导致全表扫描——因为无法使用索引。即使你给 name 加了索引也没用。
- 正确做法：把清洗逻辑移到应用层，或建生成列（MySQL 5.7+ 支持）：
ALTER TABLE users ADD COLUMN name_clean VARCHAR(100) GENERATED ALWAYS AS (REGEXP_REPLACE(name, '[^a-z]', '')) STORED;，再对name_clean建索引 - 临时清洗导出数据没问题，但线上查询务必避免在条件中实时计算
- PostgreSQL 可建函数索引：
CREATE INDEX idx_users_name_clean ON users (REGEXP_REPLACE(name, '[^a-z]', '', 'g'));，但要注意该索引只对完全相同的正则参数有效
测试异常字符是否真被清掉？别只看 SELECT 结果
很多用户执行 SELECT REGEXP_REPLACE(col, ..., '') 看起来“干净”就以为成功了，但实际可能残留不可见字符。MySQL Workbench、psql 等客户端默认不显示控制字符，导致误判。
- 验证方法：用
HEX()（MySQL）或encode(col::bytea, 'hex')（PostgreSQL）查看原始字节 - 例如，零宽空格
u200B的 UTF-8 编码是E2808B，如果清洗后结果里还出现这段十六进制，说明没清干净 - 生产环境建议加断言检查：
SELECT COUNT(*) FROM t WHERE col REGEXP '[[:cntrl:]]|\u200B';，确认清洗前后的残余数量
真正麻烦的不是写对一条正则，而是得同时考虑数据库版本、字符集、索引策略和验证手段——少盯住其中一环，上线后就可能遇到查不到数据、排序错乱或慢查询报警。
