不能直接用 REGEXP_SUBSTR 多次拆分长字符串，因其重复扫描源串导致性能断崖下降，且 CLOB 输入会引发 ORA-00932 类型错误；PIPELINED 函数须配合显式创建的自定义集合类型，处理空格、空元素、分隔符特殊字符、越界、UTF-8 多字节截断等细节。
为什么不能直接用 REGEXP_SUBSTR 多次调用拆分长字符串？
因为每次调用 REGEXP_SUBSTR 都要重复扫描整个源字符串，当源串是几万字符的 CLOB、且需提取几十个子项时，性能会断崖式下降。更关键的是：若源字段是 CLOB，REGEXP_SUBSTR(clob_col, ...) 返回值仍是 CLOB，在 JOIN 或 WHERE IN 中直接使用会触发 ORA-00932: inconsistent datatypes —— 这不是语法错，而是类型系统拒绝隐式转换。
PIPELINED 函数必须配合自定义集合类型
Oracle 不允许管道函数直接返回内置类型（如 VARCHAR2 表），必须先声明一个数据库级的嵌套表类型：
CREATE OR REPLACE TYPE str_split_table IS TABLE OF VARCHAR2(4000);
注意三点：
- 类型名
str_split_table必须用CREATE TYPE显式创建，不能只在函数里DECLARE - 元素长度设为
4000是安全上限；若业务确定单段不超过 100 字符，可设小些，减少内存占用 - 该类型可被其他存储过程、SQL 查询复用，但不能存
NULL元素（除非显式允许）
拆分逻辑里必须手动处理首尾空格和空元素
真实业务中，输入常是 'a,, b ,c ' 这类带空段、空格的字符串。管道函数内部不做清洗，下游 SQL 就会多出空行或带空格的值。建议在 PIPE ROW 前加一层过滤：
IF TRIM(substr(...)) IS NOT NULL THEN PIPE ROW(TRIM(substr(...))); END IF;
常见疏漏点：
- 只用
TRIM不够：TRIM(' b ')得到'b'，但TRIM(',')对逗号分隔符无效 —— 分隔符清理得靠INSTR和SUBSTR边界控制 - 若分隔符本身含特殊字符（如
'|'或'~'），INSTR调用要加第四个参数occurrence避免误匹配 - 不检查
v_start越界会导致无限循环（尤其当p_delimiter为空字符串时）
在 SQL 中调用时，TABLE() 包裹不可省略
管道函数不能像普通函数那样直接出现在 SELECT 列表里，必须用 TABLE() 转成行集：
SELECT column_value FROM TABLE(str_split('a,b,c', ','));
关键细节：
-
column_value是 Oracle 对匿名管道结果的默认列名；若需别名，必须用子查询或LATERAL（12c+） - 若原字符串超长（>32767 字节），
VARCHAR2参数会截断，此时必须改用CLOB入参 + 内部转VARCHAR2分段处理，否则丢失尾部数据 - 在
WHERE子句中嵌套调用（如WHERE x IN (SELECT ... FROM TABLE(str_split(...)))）时，Oracle 优化器可能无法有效下推谓词，导致全量拆分后再过滤 —— 此时应提前用WITH子句物化中间结果
实际最易被忽略的是：管道函数返回的每行仍是独立的 VARCHAR2，它不继承源字段的字符集语义。如果原始 CLOB 含 UTF-8 多字节字符（如中文、emoji），而数据库字符集是 AL32UTF8，则 SUBSTR 计算位置时必须用 SUBSTRB 防止截断半个字符 —— 这一点在日志解析、JSON 提取等场景中几乎必然踩坑。
