REGEXP_SUBSTR能解析嵌套结构因支持捕获组及第6参数指定子表达式；必须显式传入subexpression参数（如1、2）才能返回括号内内容，否则仅返全匹配串；处理带转义引号CSV时需用'"((1|"")*)"'配合REGEXP_REPLACE还原；性能差，应避免在WHERE/JOIN中直接使用，优先预计算；11.2.0.2+才支持第6参数，且match_param为空字符串会导致隐式降级。" ↩
REGEXP_SUBSTR 为什么能拆开嵌套结构的字符串
因为它是 oracle 唯一支持正则捕获组（(...)）并可指定返回第几个子表达式结果的字符串函数。普通 substr 或 instr 只能按固定位置切，遇到「字段间用逗号分隔，但字段本身含逗号或引号」这类情况就直接失效。
关键点在于：必须显式传入第 4 个参数（subexpression），否则即使写了括号，也只返回整个匹配串，不是你想要的“括号里那一段”。
-
REGEXP_SUBSTR(str, '(\d+)-(\w+)', 1, 1, NULL, 1)→ 返回第一个(\d+)捕获的内容（如'123'） -
REGEXP_SUBSTR(str, '(\d+)-(\w+)', 1, 1, NULL, 2)→ 返回第二个捕获组（如'abc'） - 漏掉最后一个
1或写成0，结果就是整个'123-abc'，不是子串
解析带引号和转义的 CSV 字符串时怎么写正则
典型场景：字段用双引号包裹，内部双引号用两个双引号表示转义，如 '"Name","O''Connor","2024-01-01"'。这时候不能简单用 "([^"]*)" —— 它会在 O''Connor 的第一个单引号处截断。
正确思路是：匹配「开头双引号 + 非双引号字符或连续两个双引号 + 结尾双引号」，再提取中间部分并替换掉 "" 为 "。
SELECT
REGEXP_REPLACE(
REGEXP_SUBSTR(data, '"(([^"]|"""")*)"', 1, 1, NULL, 1),
'""', '"'
) AS field1,
REGEXP_REPLACE(
REGEXP_SUBSTR(data, '"(([^"]|"""")*)"', 1, 2, NULL, 1),
'""', '"'
) AS field2
FROM (SELECT '"Name","O""Connor","2024-01-01"' AS data FROM DUAL);注意：([^"]|"""")* 中的 |"""" 是“四个双引号”，代表“匹配两个双引号”（Oracle 正则里双引号不转义，所以两个字面量双引号写四次）；外层 REGEXP_REPLACE 是为了还原原始内容。
性能差得明显？别让 REGEXP_SUBSTR 在 WHERE 或 JOIN 条件里反复执行
正则匹配是 CPU 密集型操作，尤其当 subexpression > 1 或正则本身回溯严重时（比如 .* 开头又没锚定），单次执行可能比 INSTR+SUBSTR 慢 5–10 倍。更糟的是，如果在 WHERE 子句中对大表每行都调用它，优化器无法走索引，全表扫描不可避免。
- 优先考虑用
INSTR/SUBSTR拆分已知格式（如固定分隔符、无嵌套） - 若必须用正则，把解析逻辑提到子查询或 CTE 中预计算成列，再在外部查询中引用
- 避免在
ON条件里写REGEXP_SUBSTR(t1.x, ...)=REGEXP_SUBSTR(t2.y, ...)—— 改成先物化解析结果
Oracle 11g 和 12c+ 在 subexpression 参数上的兼容性差异
第 6 个参数（subexpression）是 11.2.0.2 才正式支持的，低于这个版本会报错 ORA-40442: JSON_OBJECT function is not supported in this release（错误码误导，实际是正则子表达式不识别）。12c 起该参数稳定可用，但要注意默认值是 0（即返回完整匹配），不是 1。
如果你不确定环境版本，安全写法是显式写出所有参数，包括 NULL 占位的 match_param：
-- 安全写法（兼容 11.2.0.2+） REGEXP_SUBSTR(str, '(\w+):(\d+)', 1, 1, 'n', 1) <p>-- 危险写法（11g 低版本报错，12c 虽不报错但可能返回整串） REGEXP_SUBSTR(str, '(\w+):(\d+)', 1, 1, '', 1)
真正容易被忽略的，是那个空字符串 '' 作为 match_param 传进去时，Oracle 会把它当作无效值处理，等价于没传，从而触发旧行为 —— 这种隐式降级很难排查。
