oracle pipelined table function 的核心优势是“可控的流式响应”，它通过 pipe row() 边计算边返回行，避免全量内存收集；必须用 table() 包装调用以供优化器识别并下推谓词，且需显式声明 parallel_enable 才支持真正并行。
Oracle Pipelined Table Function 的核心优势不是“快”，而是“可控的流式响应”——它让 PL/SQL 逻辑能嵌入 SQL 执行计划，边算边吐行，避免全量构造集合对象带来的内存峰值和延迟。
为什么不能直接用 RETURN TABLE OF + COLLECT？
普通函数返回 TABLE OF 类型时，必须先收集全部结果到内存（比如用 COLLECT INTO），再一次性返回。对百万级结果，这会触发 PGA 内存暴涨、甚至 ORA-04030；而 Pipelined 函数每调一次 PIPE ROW() 就向 SQL 引擎推送一行，上游查询（如 SELECT ... FROM TABLE(f())）可立即开始过滤、连接、分页——不用等函数执行完。
- 典型场景：大表导出接口、ETL 中间转换、实时日志流解析
- 错误写法：
RETURN t_tab();或RETURN my_collection;→ 编译报 PLS-00372 - 正确写法：只用
PIPE ROW(...)，末尾必须是空RETURN;
TABLE() 包装不是可选项，是执行计划识别的关键
Oracle 优化器靠 TABLE() 这个语法标记识别“这是一个可展开的嵌套表源”，从而决定是否下推谓词、是否启用并行、是否物化中间结果。缺了它，函数返回值在 SQL 层就是黑盒，SELECT * FROM f_pipe(100) 直接报 ORA-22905。
- 正确调用：
SELECT * FROM TABLE(f_pipe(100)) - 常见错位：
SELECT * FROM TABLE(f_pipe)(100)→ 参数位置错，语法不通过 - 性能影响：没
TABLE()，优化器无法做基数估算，常把结果集估成默认 8168 行，导致连接顺序错、索引失效
Pipelined + PARALLEL_ENABLE 才真正释放并行能力
只加 PIPELINED 不等于自动并行。必须显式声明 PARALLEL_ENABLE，且 SQL 中配 /*+ PARALLEL(4) */ hint，两者缺一不可。否则即使数据源支持并行，函数体仍在单线程里串行执行。
- 函数签名必须含：
FUNCTION f(...) RETURN t_tab PIPELINED PARALLEL_ENABLE - 体内严禁包变量、会话级临时表、
DBMS_SESSION.SET_IDENTIFIER—— 并行时状态会交叉污染 - 若需写日志或控制表，DML 必须用
PRAGMA AUTONOMOUS_TRANSACTION封装，否则报 ORA-14551
容易被忽略的硬性限制
这些不是建议，是编译期强制拦截：一旦出现，函数直接创建失败。
-
COMMIT、ROLLBACK、CREATE TABLE等 DDL/DML → 报 ORA-14551 或 PLS-00703 - 在
EXCEPTION块中写PIPE ROW()→ Oracle 明确禁止，运行时报错 - 返回类型用系统内置集合（如
SYS.ODCIVARCHAR2LIST）→ 虽能编译，但调用时易触发 ORA-22905，因类型未导出或权限不足 - 对象类型和表类型必须在 Schema 级创建（
CREATE OR REPLACE TYPE），不能藏在包内
