企业官网建设流程全解析

1. Oracle 里没有 split，这件事到底卡在哪

如果你从 MySQL、PostgreSQL 或者 Java/Python 转过来写 Oracle，第一件让你愣住的事大概率就是：Oracle 没有内置的 split 函数。MySQL 有SUBSTRING_INDEX，PostgreSQL 有string_to_array和regexp_split_to_table，而 Oracle 直到今天，标准 SQL 层面依然没有给你一个开箱即用的「把'a,b,c'拆成三行」的函数。

这个痛点在实际工作里非常具体。比如数据清洗场景：上游系统把多个标签塞进一个VARCHAR2字段，用逗号拼成'华东,华南,华北'，你要做报表按区域聚合，就必须先把它拆成多行；再比如配置表里存了'1|2|3|5'这种 ID 列表，你要 join 回主表查明细，也得先拆。没有 split，很多人第一反应是写个循环 +INSTR+SUBSTR，但一旦要「在 SQL 里直接当表用」，循环就不好使了。

Oracle 提供了两条正统路线来解决这个问题：PL/SQL 管道化表函数（Pipelined Table Function）和REF CURSOR。前者能让你像查表一样SELECT * FROM TABLE(split(...))，而且边算边返回；后者适合把结果集整体交给调用方（比如存储过程、外部程序）去消费。这篇就围绕这两种方式，给你可以直接复制粘贴的 DDL、测试 SQL 和结果验证步骤，并且对比一下它们在数据清洗和报表场景下的表现差异。

适合谁看：正在写 Oracle 存储过程/ETL 的数据工程师、被「字符串拆行」卡过的后端开发、以及需要给报表做维度展开的 BI 同学。目标很明确——一次性把拆分逻辑跑通，并且知道什么时候该用管道化、什么时候该用 REF CURSOR。

顺带说一句，写这类 PL/SQL 代码时，我习惯用 AI 工具帮忙生成初稿和检查边界条件（比如空串、连续分隔符、末尾分隔符），而统一走一个 Key/API 通道会省掉很多切换成本，这个后面第 2 节会讲怎么接。

2. 前置准备：类型定义与 TaoToken 统一接入

2.1 先建集合类型，这是管道化函数的返回载体

管道化表函数必须返回一个集合类型，所以第一步不是写函数，而是先定义类型。这是很多人第一次写就报ORA-00902: invalid datatype的根源——函数签名里用了一个还没创建的类型。

-- 定义行类型（可选，单列时可直接用 VARCHAR2 集合） CREATE OR REPLACE TYPE strsplit_type IS TABLE OF VARCHAR2(4000); /

如果你拆出来的每一段还需要带上序号（比如做排名、定位原始位置），可以定义一个对象类型：

CREATE OR REPLACE TYPE strsplit_row AS OBJECT ( idx NUMBER, val VARCHAR2(4000) ); / CREATE OR REPLACE TYPE strsplit_tab IS TABLE OF strsplit_row; /

单列场景用strsplit_type就够了，多列（带序号）用strsplit_tab。建议两个都建，后面按需选。

2.2 用 TaoToken 统一 Key/API 通道辅助生成与校验代码

写 PL/SQL 拆分函数时，边界条件特别多：空字符串、连续分隔符'a,,b'、末尾分隔符'a,b,'、分隔符是多字符'||'、输入是 CLOB 超长文本……靠人脑一个个想容易漏。我的做法是让 AI 工具先按我的约束生成一版，再自己跑测试用例验证。

这里涉及一个实际工程问题：如果你同时用多个 AI 工具（一个写代码、一个查文档、一个做代码审查），每个都要单独配 Key、单独管额度，很烦。TaoToken 提供的是统一的 Key 和 API 通道，把模型对话、代码生成、文档查询收敛到一个入口，省掉多平台切换。

接入方式很简单，官网入口在 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 基址是 https://taotoken.net/api （这个不加 UTM）。具体操作路径：

• 想直接对话验证模型能力，走模型对话：https://taotoken.net/models?utm_source=taotoken_aicg_blog_end&utm_content=model_chat&utm_campaign=rewrite
• 长期写代码、跑 Agent 任务，用 Coding Plan 更划算：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding_plan&utm_campaign=rewrite
• 生成和管理 Key 在控制台：https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_content=console&utm_campaign=rewrite
• 直接创建 API Key：https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api_keys&utm_campaign=rewrite
• 接入文档（含各语言 SDK 示例）：https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite
• 如果你用 Claude Code 这类编码工具，Anthropic 兼容接入说明在这里：https://taotoken.net/claudecode-anthropic?utm_source=taotoken_aicg_blog_end&utm_content=claudecode&utm_campaign=rewrite

注意：TaoToken 是 AI 模型的统一接入通道，和 Oracle 数据库本身没有关系。它的作用是帮你更顺地调用 AI 来生成/校验 PL/SQL 代码，别把它当成数据库中间件。

拿到 Key 之后，你可以在本地脚本里调用 API，把「生成 split 函数」和「生成测试用例」两件事一起交给模型，然后自己复制到 SQL Developer 或 sqlplus 里跑。这样比纯手写快，也比纯靠 AI 靠谱——因为最终验证还是在数据库里。

3. 可复制配置：管道化表函数与 REF CURSOR 两套实现

3.1 管道化表函数版本（推荐，边算边返回）

这是最常用的写法，核心是PIPELINED关键字 +PIPE ROW逐行输出 + 结尾空RETURN。它最大的好处是不需要等整个集合构建完才返回，对于大字符串或需要嵌套在复杂 SQL 里的场景，内存和响应都更友好。

CREATE OR REPLACE FUNCTION strsplit( p_value VARCHAR2, p_split VARCHAR2 := ',' ) RETURN strsplit_type PIPELINED IS v_idx INTEGER; v_str VARCHAR2(4000); v_rest VARCHAR2(4000) := p_value; v_sep_len INTEGER := LENGTH(p_split); BEGIN -- 空输入直接返回空集合 IF p_value IS NULL THEN RETURN; END IF; LOOP v_idx := INSTR(v_rest, p_split); EXIT WHEN v_idx = 0; v_str := SUBSTR(v_rest, 1, v_idx - 1); PIPE ROW(v_str); v_rest := SUBSTR(v_rest, v_idx + v_sep_len); END LOOP; -- 最后一段（没有分隔符的尾部） PIPE ROW(v_rest); RETURN; END strsplit; /

调用方式就是把它当表查：

SELECT COLUMN_VALUE AS seg FROM TABLE(strsplit('华东,华南,华北,西南'));

结果：

SEG ---- 华东 华南 华北 西南

如果你需要带序号，用对象类型版本：

CREATE OR REPLACE FUNCTION strsplit_idx( p_value VARCHAR2, p_split VARCHAR2 := ',' ) RETURN strsplit_tab PIPELINED IS v_idx INTEGER; v_rest VARCHAR2(4000) := p_value; v_sep_len INTEGER := LENGTH(p_split); v_pos NUMBER := 0; BEGIN IF p_value IS NULL THEN RETURN; END IF; LOOP v_idx := INSTR(v_rest, p_split); EXIT WHEN v_idx = 0; v_pos := v_pos + 1; PIPE ROW(strsplit_row(v_pos, SUBSTR(v_rest, 1, v_idx - 1))); v_rest := SUBSTR(v_rest, v_idx + v_sep_len); END LOOP; v_pos := v_pos + 1; PIPE ROW(strsplit_row(v_pos, v_rest)); RETURN; END strsplit_idx; /

调用：

SELECT t.idx, t.val FROM TABLE(strsplit_idx('A|B|C', '|')) t ORDER BY t.idx;

3.2 REF CURSOR 版本（适合整体交给调用方）

REF CURSOR 的思路完全不同：它不逐行 PIPE，而是把整个结果集「具体化」后通过游标变量返回。适合存储过程内部把结果集交给上层程序（比如 Java 的CallableStatement拿ResultSet）去遍历。

CREATE OR REPLACE PROCEDURE strsplit_rc( p_value IN VARCHAR2, p_split IN VARCHAR2 DEFAULT ',', p_cursor OUT SYS_REFCURSOR ) IS v_idx INTEGER; v_rest VARCHAR2(4000) := p_value; v_sep_len INTEGER := LENGTH(p_split); BEGIN OPEN p_cursor FOR SELECT REGEXP_SUBSTR(p_value, '[^' || p_split || ']+', 1, LEVEL) AS seg FROM DUAL CONNECT BY LEVEL <= REGEXP_COUNT(p_value, '[' || p_split || ']') + 1; END strsplit_rc; /

注意：上面这个 REF CURSOR 版本用了REGEXP_SUBSTR+CONNECT BY的经典写法，代码短，但分隔符是正则元字符（比如|、.、*）时需要转义，否则会拆错。生产环境建议对p_split做一次转义处理，或者干脆用循环 +PIPE ROW的管道化版本更稳。

调用 REF CURSOR 需要在 PL/SQL 块里：

DECLARE v_cur SYS_REFCURSOR; v_seg VARCHAR2(4000); BEGIN strsplit_rc('10,20,30,40', ',', v_cur); LOOP FETCH v_cur INTO v_seg; EXIT WHEN v_cur%NOTFOUND; DBMS_OUTPUT.PUT_LINE('段: ' || v_seg); END LOOP; CLOSE v_cur; END; /

3.3 两套方案参数与特性对照

4. 验证请求与成功结果：跑通拆分逻辑

4.1 基础验证：单行拆分

SELECT COLUMN_VALUE AS seg FROM TABLE(strsplit('apple,banana,cherry'));

预期输出三行：apple、banana、cherry。如果只出来一行apple,banana,cherry，说明INSTR没找到分隔符，检查p_split是不是传成了全角逗号。

4.2 边界验证：空串、连续分隔符、末尾分隔符

-- 连续分隔符 SELECT COLUMN_VALUE FROM TABLE(strsplit('a,,b')); -- 末尾分隔符 SELECT COLUMN_VALUE FROM TABLE(strsplit('a,b,')); -- 空输入 SELECT COLUMN_VALUE FROM TABLE(strsplit(''));

'a,,b'会拆出a、空串、b三段，这是符合预期的——空段代表「两个分隔符之间没有内容」。如果你业务上要过滤空段，在调用处加WHERE COLUMN_VALUE IS NOT NULL即可。'a,b,'会拆出a、b、空串，同理。

4.3 报表场景验证：把拆分结果 join 回主表

假设有一张订单标签表：

CREATE TABLE order_tags ( order_id NUMBER, tags VARCHAR2(200) ); INSERT INTO order_tags VALUES (1001, '华东,华南'); INSERT INTO order_tags VALUES (1002, '华北'); INSERT INTO order_tags VALUES (1003, '华东,西南,华北'); COMMIT;

现在要按区域统计订单数：

SELECT t.region, COUNT(DISTINCT o.order_id) AS order_cnt FROM order_tags o, TABLE(strsplit(o.tags, ',')) t WHERE t.COLUMN_VALUE IS NOT NULL GROUP BY t.COLUMN_VALUE ORDER BY order_cnt DESC;

预期结果：

REGION ORDER_CNT ------ --------- 华东 2 华北 2 华南 1 西南 1

这一步跑通，说明你的拆分函数已经能真正嵌入报表 SQL 了。这也是管道化表函数相比 REF CURSOR 最大的优势——它能出现在FROM子句里，和普通表一样 join。

4.4 用 AI 辅助校验边界用例

我一般会把上面这些测试用例丢给 AI，让它再补充几个我没想到的：比如分隔符是'||'多字符、输入含中文全角逗号、输入长度接近 4000 边界。通过 TaoToken 的模型对话入口（https://taotoken.net/models?utm_source=taotoken_aicg_blog_end&utm_content=model_chat&utm_campaign=rewrite ）可以直接问，让它生成对应的测试 SQL，然后我复制到数据库里跑。这样比自己闷头想快很多，而且能覆盖到一些冷门边界。

5. 本篇常见错排查

5.1 ORA-00902: invalid datatype

函数签名里引用了还没创建的类型。解决顺序：先CREATE TYPE strsplit_type，再CREATE FUNCTION。如果类型已经存在但报错，检查是不是建在了别的 schema 下，需要加 schema 前缀或授权。

5.2 ORA-22905: cannot access rows from a non-nested table item

在TABLE()里传了一个不是集合类型的表达式。常见原因是函数返回类型写成了VARCHAR2而不是集合类型，或者忘了加PIPELINED。检查函数RETURN子句必须是strsplit_type这类集合类型。

5.3 拆分结果少了最后一段

循环里EXIT WHEN v_idx = 0之后忘了PIPE ROW(v_rest)。因为最后一次INSTR返回 0 时，v_rest里还留着最后一段没输出。这是新手最常踩的坑，务必在RETURN前补上。

5.4 分隔符是多字符时拆错位

SUBSTR(v_rest, v_idx + 1)这种写法只适合单字符分隔符。如果分隔符是'||'或'--'，必须用v_idx + LENGTH(p_split)。上面给的函数里已经用了v_sep_len，照抄即可。

5.5 REF CURSOR 版本遇到正则元字符报错或拆错

REGEXP_SUBSTR里如果p_split是|、.、*、+这类字符，会被当成正则语法。要么对分隔符做转义（REGEXP_REPLACE(p_split, '([.*+?^${}()|\[\]\\])', '\\\1')），要么直接用管道化版本绕开正则。

5.6 输入超过 4000 字符被截断

VARCHAR2(4000)是 SQL 层上限。如果输入可能是 CLOB，需要把函数参数和变量改成 CLOB，并用DBMS_LOB.SUBSTR分段处理。这个场景比较复杂，建议单独写一个 CLOB 版本，别硬套上面的函数。

5.7 权限问题：ORA-01031 insufficient privileges

CREATE TYPE和CREATE FUNCTION需要相应权限。如果是在只读账号下测试，找 DBA 授权，或者在你自己的 schema 下建。另外TABLE()调用管道化函数时，执行用户需要对函数有EXECUTE权限。

6. 该用哪个：场景化选择与接入建议

回到最初的问题——Oracle 没有 split，但你有两条路。报表拆行、ETL 展开、需要 join 的场景，一律用管道化表函数，因为它能进FROM子句，而且边算边返回，大结果集不炸内存。存储过程输出结果集给外部程序消费的场景，用 REF CURSOR，代码短，程序端拿ResultSet直接遍历。

性能上，管道化表函数在「结果集大 + 调用方只取前几行」时优势明显，因为它不需要全部具体化；REF CURSOR 在结果集小、调用方要一次性拿全时反而更简单。实测下来，几千行以内的拆分两者差距不大，上万行时管道化的内存优势就出来了。

写这类函数时，边界条件（空串、连续分隔符、末尾分隔符、多字符分隔符、CLOB）是最容易翻车的地方。我的习惯是先用 AI 生成一版带完整边界处理的代码，再自己跑测试用例验证。如果你也想把「生成代码 + 校验代码 + 查文档」收敛到一个通道，可以从 API Keys 页面（https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api_keys&utm_campaign=rewrite ）拿一个 Key，接入文档在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite ，里面有各语言的调用示例。长期写 PL/SQL 和 Agent 任务的话，Coding Plan（https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding_plan&utm_campaign=rewrite ）会比按次调用更省。

最后留一个实用技巧：把strsplit函数建在一个公共 schema 下，然后给业务账号授EXECUTE权限，这样全库都能复用，不用每个 schema 建一遍。测试用例建议固化成一张test_cases表，每次改函数后跑一遍回归，比手动敲 SQL 靠谱得多。