管道化表函数是返回集合类型的函数，必须用TABLE()调用、不能直接执行，不支持事务控制，需配合INSERT /+ APPEND /、NOLOGGING及PARALLEL_ENABLE等机制实现高性能流式处理。
管道化表函数（pipelined 函数）不是“用来写存储过程”的，而是用来替代存储过程中低效的中间集合操作——它本身是函数，不能直接 CALL 或 EXECUTE，但能被 SELECT 驱动、流式返回、避免内存堆积。真正在高性能场景下起作用的，是把它和游标、批量处理、并行提示组合使用。
为什么不能把 pipelined 函数当存储过程用
pipelined 函数必须返回一个集合类型（如 typ_array_target），且只能在 FROM 子句中以 TABLE(...) 形式调用；它没有 OUT 参数，不支持事务控制（COMMIT/ROLLBACK 会报错），也不能单独执行。常见误用是试图在存储过程中 SELECT * FROM TABLE(pipe_target(...)) 再插入目标表——这看似可行，但若没加 /*+ APPEND */ 或没关日志，性能反而比直插更差。
- 函数体内不能出现
COMMIT、ROLLBACK、DDL，否则编译失败 - 调用时若未配合
BULK COLLECT INTO或直接嵌入INSERT /*+ APPEND */，Oracle 会走常规单行插入路径 - 返回集合类型必须提前定义（
OBJECT+TABLE OF），且字段顺序、精度需与目标表严格对齐，否则隐式转换引发性能抖动
真正高效的组合写法：pipelined + INSERT /*+ APPEND */ + NOLOGGING
核心思路是让数据“不落地、不缓存、不记日志”地从源流到目标。典型结构是：游标取源数据 → 管道函数逐批转换 → 插入语句直接消费管道结果。关键点不在函数本身，而在调用端的 hint 和表属性。
- 目标表必须启用
NOLOGGING（或会话级ALTER SESSION SET FORCE LOGGING = FALSE），否则/*+ APPEND */失效 -
INSERT /*+ APPEND */ INTO t_target SELECT * FROM TABLE(pipe_target(CURSOR(SELECT ... FROM t_ss_normal)))—— 这里CURSOR(...)是必须的，否则pipe_target接收不到游标参数 - 管道函数内部用
PIPE ROW(...)每次只发一条或小批量（如 100 行），避免大集合撑爆 PGA；不要用COLLECT先攒全量再PIPE - 如果源表超大，加
/*+ PARALLEL(t_ss_normal, 4) */提示，并确保函数声明含PARALLEL_ENABLE
容易被忽略的兼容性陷阱
Oracle 版本差异直接影响能否开并行或是否自动优化管道流。11gR2 之后才稳定支持 PARTITION 子句 + PARALLEL_ENABLE 组合；而 12c 起，PIPE ROW 在自治事务中会报 ORA-14551（无法在查询中执行 DML）。这些不是语法错误，而是运行时才暴露。
- 函数声明必须显式写
PARTITION p_source_data BY HASH(owner)才能真正并行，光写PARALLEL_ENABLE不够 - 若源游标含
ROWNUM或分析函数（如ROW_NUMBER()），管道函数可能因排序依赖导致无法并行 - 客户端工具（如 PL/SQL Developer）默认关闭
DBMS_OUTPUT，但管道函数调试依赖它输出中间状态，需手动开启
最常卡住的地方不是函数怎么写，而是调用它的那条 INSERT 是否真正走 direct-path、是否触发并行、是否被其他会话锁住目标表——这些得看 V$SESSION_LONGOPS 和执行计划里的 LOAD AS SELECT 操作符，而不是函数体里有没有 PIPE ROW。
