PIPELINED函数只能在SQL中通过TABLE()调用，Java无法直接调用，因其返回类型为SQL集合类型且JDBC不支持callable statement接收管道流；正确方式是执行SELECT * FROM TABLE(f(?))并配合fetch size分批消费结果集。
pipelined 函数本身不直接暴露给 java，java 端无法“调用”它——它必须被包装成 sql 查询的一部分，由 oracle 数据库执行并流式返回结果。真正起效的环节在数据库层，java 只负责消费已管道化的结果集。
为什么 Java 里不能直接调用 PIPELINED 函数？
PIPELINED 函数是 Oracle PL/SQL 层的特性，返回类型必须是 SQL 用户定义的集合类型（如 TABLE OF xxx），且只能在 SQL 上下文中通过 TABLE() 操作符使用。JDBC 驱动不支持将函数作为独立 callable statement 调用并接收其管道流；它只认标准的 SELECT * FROM TABLE(f(...)) 这类语句。
Java 正确集成方式：用 SELECT FROM TABLE() + 流式 ResultSet
关键不是“Java 调用函数”，而是让 Java 发起一条能触发管道执行的 SQL，并利用 JDBC 的流式能力避免全量缓存：
- 确保 Oracle JDBC driver 版本 ≥ 12.1（推荐 21c+），启用隐式流式读取（默认开启）
- SQL 必须写成
SELECT * FROM TABLE(my_pipelined_func(?))，不能用CALL或{? = call ...} - 设置
Statement.setFetchSize(100)（非setFetchSize(Integer.MIN_VALUE)），让 JDBC 分批拉取管道输出的 chunk，而非等全部生成完再交 ResultSet - 务必关闭自动提交（
conn.setAutoCommit(false)），否则PIPE ROW过程中若含自治事务（PRAGMA AUTONOMOUS_TRANSACTION），可能因事务边界混乱报ORA-14551
常见错误：Java 侧误判为“慢”，实际是数据库配置没跟上
即使 SQL 写对了，Java 查得慢，问题往往不在 Java 本身：
-
PARALLEL_ENABLE声明写了，但数据库没开并行：检查PARALLEL_THREADS_PER_CPU是否 > 0，且用户有PARALLEL_QUERY权限 - 函数体内用了包变量或
DBMS_SESSION.SET_IDENTIFIER：并行时会交叉污染，导致数据错乱或 ORA-06502，Java 收到脏数据后逻辑崩溃 - 管道函数返回的自定义类型（如
typ_array_target）未在 schema 级创建，而是仅在包内声明：JDBC 无法解析类型，抛ORA-21700: object does not exist - Java 使用了 Hibernate/JPA 的
@NamedNativeQuery并启用了二级缓存：管道函数结果不该缓存，需显式禁用缓存（query.setHint("org.hibernate.cacheable", false)）
最易被忽略的点：管道函数的“流”在 Java 里只体现为 fetch size 控制，不是真正的异步流
JDBC ResultSet 的“流式”本质仍是阻塞式分批拉取，PIPELINED 的价值在于 Oracle 内部不攒全量内存、可边算边发。Java 侧唯一能做的就是别用 rs.next() 一口气遍历完再处理，而应边取边转 DTO、边写文件或边推消息——否则和普通查询无异。真正决定报表快慢的，是函数体是否规避了临时表、是否用了 BULK COLLECT + FORALL、是否把 IO 密集操作（如 UTL_FILE）移出了管道循环。这些，全在 PL/SQL 里，不在 Java 里。
立即学习“Java免费学习笔记（深入）”；
