regexp_substr配合connect by是轻量且兼容10g+的字符串拆分首选方案；需用regexp_count或length-replace计算层级上限以防循环或性能问题，并预处理空格，但不支持引号包裹字段。
直接用 REGEXP_SUBSTR 配合 CONNECT BY 是最轻量、兼容性最好（10g+）、无需额外对象的方案；但必须手动控制层级上限，否则可能因数据异常导致 ORA-01436: connect by loop 或性能崩塌。
REGEXP_SUBSTR + CONNECT BY 拆分字符串（推荐首选）
这是纯 SQL 方式，不依赖任何自定义类型或函数，适合一次性查询或视图封装。
-
REGEXP_SUBSTR(str, '[^,]+', 1, level)中的[^,]+表示“一个或多个非逗号字符”，能天然跳过空字段（如'AA,,CC'中间那个空串不会被返回） -
LEVEL的上限不能硬写死，要用REGEXP_COUNT(str, ',') + 1（11g+）或退化为LENGTH(str) - LENGTH(REPLACE(str, ',', '')) + 1（10g 兼容） - 如果原始字符串含首尾空格或多余空白（如
' AA , BB , CC '），先用TRIM和REPLACE清洗，否则REGEXP_SUBSTR会把空格当作值的一部分 - 不支持引号包裹字段（如
'A,"B,C",D'），这种结构必须上JSON_TABLE（12.2+）或 PL/SQL 解析
示例：
SELECT REGEXP_SUBSTR('AA,BB,CC', '[^,]+', 1, LEVEL) AS val
FROM DUAL
CONNECT BY LEVEL <h3>自定义 pipelined 函数 split（需创建对象，但更可控）</h3><p>当你需要复用、处理空元素、保留空白、或做预处理（如去重、trim）时，<code>pipelined function</code> 是更工程化的选择。注意它要求你有 <code>CREATE TYPE</code> 和 <code>CREATE FUNCTION</code> 权限。</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill4996" title="Crypto Sniper Oracle"><img
src="https://img.php.cn/upload/skill/000/000/081/179031080953882.jpg" alt="Crypto Sniper Oracle" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill4996" title="Crypto Sniper Oracle" class="overflowclass">Crypto Sniper Oracle</a>
<p class="overflowclass">机构级量化市场预言机，提供订单簿失衡（OBI）、VWAP分析、自动化报告及Telegram预警。</p>
</div>
<a rel="nofollow" href="/xiazai/skill4996" title="Crypto Sniper Oracle" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
- 必须先建一个集合类型，比如
CREATE OR REPLACE TYPE str_list AS TABLE OF VARCHAR2(4000); - 函数体里用
INSTR+SUBSTR循环切分，比正则更稳定，也更容易加逻辑（例如跳过空串、trim 每项） - 调用时必须包在
TABLE()中，如SELECT * FROM TABLE(split('a,b,c')); - Oracle 12c+ 可用
APEX_STRING.SPLIT替代（若 APEX 已安装），但它返回apex_t_varchar2，不是标准 SQL 集合类型，跨环境迁移需留意
XMLTABLE / JSON_TABLE（高版本可选，但有代价）
Oracle 11gR2+ 支持 XMLTABLE，12.2+ 支持 JSON_TABLE，它们语义清晰、能处理嵌套结构，但实际开销明显高于正则方案。
-
XMLTABLE要先把字符串转成 XML 格式（如拼成<r><v>AA</v><v>BB</v></r>），涉及字符串拼接和 XML 解析，对长字符串或高频调用不友好 -
JSON_TABLE要求输入是合法 JSON 数组（如["AA","BB","CC"]），得先用REPLACE+''''手动构造，容易出错；且 JSON 解析在 12.1 中性能较差，12.2 后优化明显 - 二者都绕不开权限与配置问题：比如
XMLTABLE在某些 RAC 环境下需额外授权XS$NULL相关角色
常见坑：空元素、超长字符串、递归失控
几乎所有方案都会在这些边界点翻车，尤其当数据来自外部接口或用户输入时。
-
CONNECT BY无上限时，若传入空字符串''或全是逗号',,,'，LEVEL 会触发无限循环 → 必须用 <code>GREATEST(1, ...)包一层 -
REGEXP_SUBSTR对超长字符串（>4000 字节）可能截断，因为默认VARCHAR2上限；改用CLOB输入时需确保函数签名支持，且REGEXP_COUNT不接受 CLOB（12cR1+ 才支持） - 空元素（
'A,,C'）在正则方案中被跳过，但业务可能要求返回NULL占位 → 此时只能用自定义函数，在循环中显式PIPE ROW(NULL) - 别在
WHERE子句里直接调用拆分函数（如WHERE col IN (SELECT * FROM TABLE(split(:input)))），这会导致优化器无法估算行数，极易走错执行计划
真正难的从来不是“怎么拆”，而是“怎么安全地、可预测地拆”——尤其是当字符串长度、分隔符数量、空值模式全不可控时，正则方案的简洁性反而成了双刃剑。
