是，性能问题常因调用getClob()后用getSubString全量加载；应改用getCharacterStream()流式读取，避免内存暴涨和GC压力。
Oracle CLOB读取慢，是不是用了 getClob() 再转字符串？
绝大多数性能问题出在这里：调用 getClob() 得到 java.sql.Clob 对象后，再用 clob.getSubString(1, (int) clob.length()) 强制加载全文到内存——这会把整个 CLOB 拷贝成 String，不仅吃内存，还触发 GC 压力，尤其当 CLOB 超过几 MB 时，响应直接卡住。
真正高效的做法是绕过 Clob 接口，直接用 Oracle 特有的流式读取能力：
- 对大文本（>4KB），优先用
getCharacterStream()获取Reader，边读边处理，不缓存全文 - 若必须转字符串且确定内容小（getString() —— Oracle JDBC 驱动对
getString()有内部优化，比getClob().getSubString()快 3–5 倍 - 确认驱动版本 ≥
21.10.0.0.0（对应 Oracle DB 21c），旧版（如 19c 驱动）对getCharacterStream()的流缓冲控制较弱，容易退化为全量加载
为什么 setFetchSize(1) 反而让 CLOB 更慢？
这是个典型误解。setFetchSize() 控制的是 ResultSet 行级预取，和 CLOB 数据传输无关。Oracle 的 CLOB 实际通过 LOB Locator 传递，真实数据是在你调用 getXXX() 时才按需从服务器拉取。设小的 fetchSize 不仅无效，还会增加网络 round-trip 次数（尤其批量查多行带 CLOB 时）。
正确做法是：
立即学习“Java免费学习笔记（深入）”；
- 保持默认
fetchSize（通常 10–100，由驱动决定） - 在
PreparedStatement上显式启用流式读取：ps.setFetchSize(Integer.MIN_VALUE)（仅对 Oracle 驱动有效，表示“逐行流式获取”，避免 ResultSet 缓存整批 LOB locator） - 确保连接 URL 包含
defaultRowPrefetch=100和oracle.jdbc.useFetchSizeWithLongColumn=true（后者关键，否则 CLOB 列会被忽略 fetchSize）
Java17 + Oracle JDBC 下，Reader 流没关导致连接泄漏
getCharacterStream() 返回的 Reader 底层绑定了数据库连接资源，但很多人以为 ResultSet 关闭后它自动释放——错。Oracle JDBC 的 OracleClobReader 在 close() 前会一直持有 LOB locator，不关就会累积等待，最终触发 ORA-01000: maximum open cursors exceeded。
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
安全写法必须用 try-with-resources：
try (Reader reader = rs.getCharacterStream("content");
BufferedReader br = new BufferedReader(reader)) {
String line;
while ((line = br.readLine()) != null) {
// 处理单行，不累积全文
}
} // reader 和 br 自动 close，释放 locator
注意：不要用 rs.getString("content") 后再做 new StringReader(...) ——这又回到内存全量加载的老路。
要不要用 oracle.sql.CLOB？
直接 cast 成 oracle.sql.CLOB 是 Oracle 私有 API，Java17 默认模块系统会报 IllegalAccessError（除非加 --add-opens java.base/java.lang=ALL-UNNAMED）。而且它提供的 getAsciiStream() / getCharacterStream() 和标准 JDBC 接口行为一致，并无额外优势。
结论：别碰 oracle.sql.*，坚持用 ResultSet.getCharacterStream() 或 getString()，兼容性、可维护性、模块化都更稳。
真正难的是权衡——流式读适合解析/转发场景，getString() 适合校验/短文本提取；一旦业务需要随机访问 CLOB 片段（比如取中间 100 字符），就得接受一次 getSubString() 的代价，这时候提前评估 CLOB 平均长度比调优代码更重要。
