ResultSet行数与fetchSize不匹配时Oracle查询卡顿求助

这问题我之前帮团队排查过好几次，太典型了！咱们一步步拆解：

为什么会出现卡顿？ #

你遇到的卡顿是ojdbc8驱动处理ResultSet末尾数据的默认行为导致的：

• 当你设置fetchSize=20000时，驱动会按20000行的批次从Oracle数据库拉取数据，前几个完整批次（比如40000行=2×20000）能快速返回，因为是批量预取。
• 但当剩余行数不足一个完整批次时（比如53000行剩下的13000行），驱动会触发一次额外的"收尾"请求——它需要确认数据库端是否还有更多数据，这个过程和批量预取的逻辑不同：可能涉及数据库游标的状态检查、额外的网络往返，甚至驱动内部的阻塞等待，所以会出现20-25秒的卡顿。
• 而当总行数恰好是fetchSize的整数倍时，驱动拉完最后一批后能直接判断游标已耗尽，不需要额外确认，自然就没有卡顿。

解决方法（按推荐程度排序） #

1. 改用流式获取（最推荐，彻底解决卡顿） #

把fetchSize设置为Integer.MIN_VALUE，这会让Oracle驱动切换为流式获取模式，每次只按需拉取少量数据，从根源上避免末尾的额外确认开销。修改你的代码：

Statement stmt = conn.createStatement();
stmt.setFetchSize(Integer.MIN_VALUE); // 关键修改
ResultSet rs = stmt.execute(sql);
// 后续遍历逻辑不变

注意：这种模式要求Statement是默认的TYPE_FORWARD_ONLY, CONCUR_READ_ONLY（你的代码刚好符合），而且不能对ResultSet做前后滚动操作，完全适配你当前的遍历场景。

2. 减小fetchSize缓解卡顿 #

如果不想用流式模式，可以尝试把fetchSize从20000降到5000或10000。这样末尾剩余的行数更少，额外请求的开销也会大幅降低，卡顿时间会明显缩短。不过这只是缓解，不能彻底消除。

3. 使用Oracle特定API优化（耦合驱动，谨慎用） #

如果你的代码只需要兼容Oracle数据库，可以把Statement强转为OracleStatement，通过Oracle专属API关闭末尾的额外检查：

OracleStatement oracleStmt = (OracleStatement) conn.createStatement();
oracleStmt.setRowPrefetch(20000);
oracleStmt.setFetchSize(20000);
oracleStmt.setExecuteBatch(0); // 关闭额外的收尾检查
ResultSet rs = oracleStmt.execute(sql);

这种方式能保留大批次预取的效率，同时避免卡顿，但代码会和ojdbc绑定，迁移到其他数据库时需要修改。

4. 动态调整fetchSize（适合数据量稳定的场景） #

先通过SELECT COUNT(*) FROM ...提前获取总行数，然后把fetchSize设置为能整除总行数的数值（比如总行数53000，就设为13250），这样每次拉取都是完整批次，不会触发末尾的额外请求。不过这种方式需要多一次查询，适合数据量变化不大的场景。

我自己用方法一解决过几乎一样的问题，卡顿直接消失，你可以先试试这个！

内容的提问来源于stack exchange，提问作者EdXX