Oracle 19c管道化表函数提升数据转换吞吐量
在Oracle19c中，使用管道化表函数需满足四重约束：必须创建显式集合类型，函数体内仅用PIPEROW输出，调用时套用TABLE()函数，并行执行需同时启用PARALLEL_ENABLE和SQL提示。违反这些约束将导致性能退化或执行错误。
管道化表函数（Pipelined Table Function）在Oracle 19c中并非天然具备高性能，必须严格满足四项约束条件，才能实现流式输出与并行执行。否则，性能可能低于普通函数。
必须先建好集合类型，不能直接用系统内置类型
Oracle要求PIPELINED函数的返回值必须是显式创建的集合类型（TABLE OF）。不建议直接使用SYS.ODCIVARCHAR2LIST或SYS.ODCINUMBERLIST等系统类型——虽然编译通过，但调用时可能报ORA-22905错误，或导致优化器基数估算严重失真（默认猜测为8168行，与实际数据量相差巨大）。
- 先创建对象类型：
CREATE OR REPLACE TYPE t_row AS OBJECT (id NUMBER, name VARCHAR2(100)) - 再创建表类型：
CREATE OR REPLACE TYPE t_rows AS TABLE OF t_row - 函数签名必须为：
FUNCTION f_transform(p_limit IN NUMBER) RETURN t_rows PIPELINED
函数体里只能使用PIPE ROW()，不能返回RETURN值
函数体内禁止使用带值的RETURN语句，也不允许先构造好集合再一次性返回（例如RETURN t_rows(...)）。一旦出现此类写法，编译时直接报PLS-00713（未声明为PIPELINED却使用了PIPE ROW），或运行时出现ORA-14551（无法在查询中执行DML）。
- 正确写法：循环中每处理一行，使用
PIPE ROW(t_row(...)) - 错误写法：
RETURN t_rows(...)、RETURN后跟空括号、RETURN NULL - 末尾必须保留一个无参数的
RETURN（不带任何值），否则PL/SQL编译失败
调用必须使用TABLE()，且参数位置不能错
直接写f_transform(1000)属于非法操作——优化器无法识别该返回值结构，立即报ORA-22905。必须使用TABLE(f_transform(1000))包裹，且参数需在括号内紧贴函数名。
- 正确：
SELECT * FROM TABLE(f_transform(1000)) - 错误：
SELECT * FROM TABLE(f_transform)(1000)（语法不合法） - 错误：
SELECT * FROM f_transform(1000)（触发ORA-22905） - 如果函数参数是
REF CURSOR，需确保上游游标稳定打开，避免被优化器提前物化
要并行就得双启用：PARALLEL_ENABLE + SQL提示
PARALLEL_ENABLE并非装饰性参数，它与SQL层的并行提示必须联动。仅配置其中一项，函数仍以单线程运行。
- 函数声明必须包含：
FUNCTION f_split(...) RETURN t_rows PIPELINED PARALLEL_ENABLE - SQL调用必须添加提示：
SELECT /*+ PARALLEL(4) */ * FROM TABLE(f_split(...)) - 函数体内严禁使用包变量、会话级临时表、
DBMS_SESSION.SET_IDENTIFIER等状态绑定操作，否则并行时数据交叉污染，导致结果错乱 - 若需记录日志或写入控制表，必须使用
PRAGMA AUTONOMOUS_TRANSACTION封装DML操作
真正制约吞吐量的因素，往往不是数据量本身，而是类型未导出、TABLE()遗漏、并行开关仅开启一半，或函数内部使用了会话变量——这些环节一旦出错，流式输出将退化为全量构造集合，性能反而比普通函数更差。