REGEXP_REPLACE提取纯数字常失败，因它默认替换匹配内容而非提取；正确做法是替换所有非数字字符，且需注意数据库版本兼容性、全局参数及全角数字处理。
REGEXP_REPLACE 提取纯数字为什么常失败
直接用 REGEXP_REPLACE 想“只留下数字”却得到空字符串或原样返回，根本原因是正则逻辑反了：这个函数默认是「替换匹配到的内容」，不是「提取匹配到的内容」。你得让它把「非数字字符全干掉」，而不是试图“选中数字再保留”。
- 常见错误写法：
REGEXP_REPLACE(col, '[^0-9]', '')看似合理，但注意：Oracle 和 MySQL 8.0+ 支持，而 MySQL 5.7 及更早版本压根不支持REGEXP_REPLACE - PostgreSQL 要用
REGEXP_REPLACE(col, '[^0-9]', '', 'g')，漏掉第四个参数'g'就只替换第一个非数字字符 - SQL Server 完全没原生
REGEXP_REPLACE，强行用会报错Invalid function name 'REGEXP_REPLACE'
MySQL 5.7 怎么安全提取纯数字
别硬上正则，用字符串函数组合更稳。核心思路是：逐个检查字符是否为数字，拼起来。
- 用
SUBSTRING+ASCII判断单字节字符（适用于 ASCII 数字 0–9） - 典型安全写法：
SELECT TRIM(BOTH FROM REGEXP_REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(col,'a',''),'b',''),'c',''),'d',''),'e',''),'f',''),'g',''),'h',''),'i',''),'j','')),'[^0-9]','')) AS digits FROM t;—— 这只是示意，实际别这么嵌套，维护性灾难 - 真实推荐：升级到 MySQL 8.0+，或改用应用层清洗（Python/Java 处理更可控）
Oracle 中 REGEXP_REPLACE 提取数字的坑点
Oracle 的 REGEXP_REPLACE 功能强，但默认行为容易误导：它不自动全局替换，且空字符串处理敏感。
- 必须显式加
'g'参数，否则只处理第一个匹配项：REGEXP_REPLACE(col, '[^0-9]', '', 1, 0, 'g')—— 第5个参数0表示替换全部，第6个'g'是关键 - 如果字段含中文、emoji 或全角数字（如‘１２３’），
[^0-9]不会匹配它们，结果仍是原值；需扩展为[^[:digit:]]或手动补全 Unicode 范围 - 性能提示：在 WHERE 或 JOIN 条件里用
REGEXP_REPLACE会导致索引失效，别在大表上直接 SELECT + 正则清洗后查
跨数据库兼容的底线方案
真要写一次 SQL 跑多个库，就别碰正则。用最朴素的字符判断逻辑，虽然啰嗦但能跑。
- 对每个位置用
SUBSTR(col, n, 1)取出单字符，再用CASE WHEN ASCII(...) BETWEEN 48 AND 57 THEN ... END判断是否为 0–9 - 最大长度预估好（比如最多 20 位），手写 20 层
CASE拼接，生成新字段 —— 难看，但 Oracle/MySQL/SQL Server 都认 - 更现实的选择：把清洗逻辑下推到应用代码，SQL 只负责原始数据拉取；数据库不是文本处理器
真正难的不是写出正则，而是搞清目标库版本、字符集、字段实际内容分布——比如一个字段看着像电话号，结果混了分机号里的字母和括号，还夹着换行符。这些细节不摸清楚，正则再漂亮也白搭。
