oracle管道化表函数效率高，核心在于流式逐行输出（pipe row）和显式并行支持（parallel_enable），但须严格遵循pipelined声明、返回预建集合类型、末尾空return、调用必套table()、并行需双启用等规则，否则易报错或性能劣化。
oracle pipeline函数不是“自动就快”，它只在你严格按规则写、调用方式对、执行环境配得上的时候，才真正释放流式输出和并行能力。
PIPELINED声明和RETURN类型必须同时到位
缺一不可。只写PIPE ROW()不加PIPELINED关键字，编译直接报PLS-00713；返回类型不是已创建的集合类型（比如RETURN SYS.ODCINUMBERLIST这种系统类型虽能过编译，但不推荐），调用时大概率触发ORA-22905或基数估算失真。
实操要点：
- 先用
CREATE OR REPLACE TYPE建好对象类型和表类型，例如：CREATE OR REPLACE TYPE t_obj AS OBJECT (id NUMBER, val VARCHAR2(100))→CREATE OR REPLACE TYPE t_tab AS TABLE OF t_obj - 函数签名必须是
FUNCTION f(...) RETURN t_tab PIPELINED，不能省略PIPELINED，也不能写成RETURN t_obj或RETURN SYS_REFCURSOR - 函数体里只允许
PIPE ROW(...)输出，禁止任何RETURN t_tab()或RETURN带值语句
调用必须套TABLE()，且参数位置不能错
TABLE(f_pipe(100))是对的；TABLE(f_pipe)(100)或f_pipe(100)直接报错——前者语法不合法，后者触发ORA-22905，因为优化器根本认不出这是个可展开的嵌套表。
常见错误现象：
-
ORA-22905：本质是Oracle无法把返回值映射为合法的“嵌套表项”，多因类型在包内定义（未导出）、用了未授权系统类型，或根本没加TABLE() - 执行计划里
TABLE()节点基数被估成8168（12c+默认值），远高于实际，导致连接顺序错、索引失效 - 如果函数带游标参数（如
REF CURSOR），务必确保上游查询能稳定打开、不被优化器提前物化
并行执行要手动开，且函数内部不能有状态依赖
PARALLEL_ENABLE不是装饰词，它和SQL中的/*+ PARALLEL(4) */是联动开关。只写一个，另一个没配，就还是单线程跑。
实操限制：
- 函数声明里必须显式加上
PARALLEL_ENABLE，例如：FUNCTION f_split(p_str VARCHAR2) RETURN t_tab PIPELINED PARALLEL_ENABLE - 函数体内严禁使用包变量、
DBMS_SESSION.SET_IDENTIFIER、会话级临时表等任何会话绑定状态，否则并行时数据交叉污染 - 若需在管道中记日志或写控制表，必须用
PRAGMA AUTONOMOUS_TRANSACTION封装DML，否则报ORA-14551 - 真实并行度还受
PARALLEL_THREADS_PER_CPU和资源管理器策略压制，别光看hint
流式优势只在“边算边吐”场景下成立
如果你的下游SQL加了WHERE ROWNUM ，或嵌在<code>LEFT JOIN右侧且驱动表很小，Pipeline才能真正节省内存和延迟；反之，如果整个结果集都要落地（比如INSERT /*+ APPEND */ INTO ... SELECT * FROM TABLE(f())），流式优势会被物化动作抵消，甚至因缺乏统计信息拖慢整体执行。
容易被忽略的关键点：
-
PIPE ROW()每次只推一行，缓冲区常驻约1–2行数据，PGA压力恒定；普通集合函数要把全部结果塞进内存再交出，100万行NUMBER可能吃掉几十MB PGA - 异常路径里不能
PIPE ROW()，也不能漏写RETURN（哪怕在EXCEPTION块末尾），否则调用方可能卡住或只拿到部分结果 - 函数末尾的
RETURN必须存在，且不能带任何值——这是硬性语法要求，不是风格建议
