REGEXP_SUBSTR 提取子串的关键在于正确理解 occurrence 和 position 参数：occurrence 指定第几次匹配，position 指定搜索起始位置（重置扫描起点），而非简单跳过字符。
直接说结论：用 REGEXP_SUBSTR 提取子串，关键不是写对正则，而是搞清 occurrence 和 position 的行为差异——多数人栽在这两个参数上。
为什么第一次调用 REGEXP_SUBSTR 总只返回第一个匹配？
因为默认 occurrence = 1，它只找“第 1 次完整匹配”，不是“从头开始贪婪匹配”。比如 REGEXP_SUBSTR('a1b2c3', 'd') 返回 '1'，不是 '123'；想取全部数字得靠循环或改用 REGEXP_REPLACE 配合空替换。
常见错误现象：
- 写
REGEXP_SUBSTR(str, 'd+')以为能提取所有连续数字，结果只拿到第一个数字块 - 误以为
pattern中的量词（如+、*）会自动遍历全文，其实它只控制单次匹配的长度
正确做法：
- 提取“第 N 个匹配项”：显式传入
occurrence，如REGEXP_SUBSTR('17,20,23', '[^,]+', 1, 2)→'20' - 提取“从某位置起的第一次匹配”：调整
position，如REGEXP_SUBSTR('abc123def456', 'd+', 5)从第 5 字符（即'1'）开始搜，返回'123'，而非从开头重搜
REGEXP_SUBSTR 的 position 参数容易被当成“跳过前 N 字符”
它不是简单跳过，而是**重置搜索起点**。Oracle 从指定位置开始重新扫描整个正则模式，且后续匹配（当 occurrence > 1 时）也以该起点为基准计算偏移。
使用场景：
- 跳过前缀再提取：如邮箱
'user@domain.com'，用REGEXP_SUBSTR(email, '[^@]+', INSTR(email, '@') + 1)直接取@后内容，比写INSTR+SUBSTR组合更稳 - 避免重复匹配头部：源串
'aa11bb22'，若用REGEXP_SUBSTR(str, 'd+', 1, 2)，它会在第一次匹配'11'后，从'11'的下一个字符（即b）开始找第二次d+；但若设position = 5，就强制从第 5 位（第一个b）开始找，可能跳过'11'直接命中'22'
性能影响：大文本中设过大 position 值不会跳过扫描，Oracle 仍会从开头校验到该位置才真正开始匹配，所以别指望靠它“加速跳过无关段落”。
提取多个值时，CONNECT BY LEVEL 必须配 REGEXP_COUNT 控制行数
用 CONNECT BY LEVEL 或硬写 <code>LEVEL 是典型错误——前者生成冗余空行，后者可能截断数据。
正确逻辑是：先算出字符串里有多少个匹配项，再生成对应行数。例如拆分逗号串：
SELECT REGEXP_SUBSTR('17,20,23', '[^,]+', 1, LEVEL) AS val
FROM DUAL
CONNECT BY LEVEL <= REGEXP_COUNT('17,20,23', '[^,]+');
注意点：
-
REGEXP_COUNT计算的是“完整匹配次数”，不是分隔符个数，所以用[^,]+而非, - 如果源字段含空元素（如
'17,,23'），[^,]+会跳过空串，需改用([^,]*),?并配合subexpression参数（Oracle 11g+ 支持）或预处理去空 - 在 JOIN 或子查询中嵌套此结构时，
CONNECT BY可能引发 ORA-01436（用户数据循环），务必确保LEVEL上限是确定值（如来自REGEXP_COUNT），而非依赖外部列
区分大小写和特殊字符转义的实际坑
match_parameter 默认是 'c'（区分大小写），但很多人忽略这点，导致 REGEXP_SUBSTR('AbC', 'abc') 返回空——其实应加 'i'。
更隐蔽的问题是字符类里的转义：
-
'[^@]+'表示“非 @ 字符”，但'[^@.]+'中的.在字符类内**不需要转义**，写成'[^@.]+'即可；多写反斜杠反而可能匹配失败 - POSIX 字符类如
[[:digit:]]必须成对出现，[[:digit:]会报错 ORA-12726 - 在 SQL*Plus 或某些 JDBC 驱动中，反斜杠可能被客户端提前吃掉，建议把正则写成双反斜杠
'\d+'或用 q-quoting：q'[\d+]'
最易被忽略的点：Oracle 正则默认不支持 . 匹配换行符。如果字段含 CLOB 且含
，又想用 '.+' 跨行捕获，必须显式加 'n' 参数，否则会停在第一行末尾。
