根本原因是Oracle正则引擎基于POSIX ERE，不支持d等Perl简写、非贪婪量词及命名捕获组，须用[[:digit:]]等兼容写法，且无法处理嵌套结构。
REGEXP_SUBSTR 在 Oracle 里为什么匹配不到预期子串
根本原因通常是正则表达式未适配 Oracle 的 POSIX ERE 实现，而非语法写错了。Oracle 不支持 \d 这类 Perl 风格简写，也不支持非贪婪量词（*?、+?），更不支持命名捕获组。
常见错误现象：REGEXP_SUBSTR('abc123def', '\d+') 返回空 —— 因为 \d 被当字面量处理，实际要写 [0-9]+ 或 [[:digit:]]+。
- 始终用
[[:digit:]]、[[:alpha:]]、[[:alnum:]]替代\d/\w，兼容性更稳 - 想取第一个数字块？写
REGEXP_SUBSTR(col, '[0-9]+', 1, 1)；第 2 个？把最后一个参数改成2 - 第三个参数是起始位置（从 1 开始），默认 1；第四个是 occurrence 次序，不传默认 1；第五个是匹配模式（如
'i'忽略大小写） - 如果源字符串含换行符，而你又想跨行匹配，必须显式加
'n'模式，否则.不匹配换行
解析带分隔符的嵌套结构时 REGEXP_SUBSTR 容易失效
比如解析类似 "key1:value1;key2:{a:1,b:2};key3:value3" 这种半结构化文本 —— REGEXP_SUBSTR 无法处理花括号嵌套层级，它只是线性扫描，没有状态机能力。
使用场景：ETL 中临时清洗日志字段、配置项拼接字符串，但不适用于 JSON/YAML 等真正嵌套格式。
- 单层键值对（无嵌套、无转义）可用：
REGEXP_SUBSTR(str, 'key2:[^;]+')，靠[^;]截断 - 一旦出现
key2:{a:1,b:{c:3}};key3:...，[^;]会在第一个;就停，截不出完整值 - 别硬扛：这种需求要么用 PL/SQL 写循环解析，要么导出后用 Python/Java 做真正解析，SQL 层只做初筛
- 性能上，每多调一次
REGEXP_SUBSTR就多一遍全串扫描，嵌套调用三层以上响应明显变慢
MySQL 8.0+ 的 REGEXP_SUBSTR 和 Oracle 行为差异在哪
MySQL 8.0 引入了 REGEXP_SUBSTR，但参数顺序和默认行为跟 Oracle 不同，直接迁移会出错。
最常踩的坑：MySQL 第 4 个参数是 match_type（如 'c' 区分大小写），而 occurrence 是第 5 个参数；Oracle 则 occurrence 是第 4 个。
- Oracle：
REGEXP_SUBSTR(str, pattern, position, occurrence, match_param) - MySQL：
REGEXP_SUBSTR(str, pattern, position, occurrence, match_type)—— 注意第 4、5 参数角色互换 - MySQL 默认区分大小写，Oracle 默认也是，但 MySQL 的
match_type可选值是'c'/'i'/'m'/'n'/'u'，Oracle 是'i'/'c'/'n'/'x'，'m'（多行模式）在 MySQL 里叫'n' - MySQL 支持
\d和非贪婪量词，Oracle 不支持 —— 所以正则本体也不能无脑复用
替代方案：什么时候该放弃 REGEXP_SUBSTR 改用其他方法
当你要提取的“模式”依赖上下文、计数、或需要回溯判断时，REGEXP_SUBSTR 已经不是瓶颈，而是误用。
典型信号：你开始嵌套三层 REGEXP_SUBSTR，或者用 INSTR + SUBSTR + REGEXP_SUBSTR 混合拼逻辑。
- 固定分隔符且无嵌套？优先用
REGEXP_SUBSTR配合[^|]+类模式，简单可靠 - 需要按顺序取第 N 个字段？Oracle 12c+ 可用
JSON_TABLE把字符串转成行集（先替换成 JSON 格式），比正则更稳 - 要做校验+提取（比如“必须含 2 个 @，且第二个 @ 后必须有 .com”）？拆成
CASE WHEN REGEXP_LIKE(...) THEN REGEXP_SUBSTR(...) END，别塞进一个函数里硬算 - 真正复杂？接受现实：SQL 不是万能胶。导出到应用层处理，反而更可测、可 debug、可加日志
正则能解决的，是边界清晰、形态固定的子串定位；一旦涉及语义判断或状态累积，就该换工具了。
