Oracle 11g小结果集场景下ResultSet.next()偶发耗时过长问题咨询

1. Oracle执行计划不稳定 #

Oracle 11g默认开启绑定变量窥探特性，首次执行SQL时会根据当时的入参生成执行计划并缓存。如果后续入参对应的数据分布差异极大，数据库仍然复用旧的执行计划，就会出现执行效率暴跌的情况。
你遇到的仅0/1行结果集时触发慢查询的特征完全匹配该问题：多数情况下SQL走索引快速返回结果，偶发走错执行计划触发全表扫描，扫描完成后才确认结果只有0/1行，最终表现为耗时极长但无报错正常返回。
可通过抓取Oracle慢查询日志，对比慢SQL和正常执行同SQL的执行计划差异确认该问题。

2. JDBC网络配置缺失 #

你的代码没有配置任何网络、查询超时参数，Oracle JDBC默认未开启TCP保活机制，如果服务端和客户端之间的防火墙、负载均衡设备切断了长期空闲的连接，JDBC层会触发TCP重传逻辑，默认TCP重传间隔长、次数多，就会出现数百秒的等待，重传成功后代码可继续执行。
另外Oracle JDBC默认的fetchSize为10，当结果集行数小于10时，JDBC会等待服务端返回更多数据包直到超时，也会偶发触发长等待。
可通过添加以下配置验证：

• 调用cs.setQueryTimeout()设置查询超时时间
• 调用connection.setNetworkTimeout()设置网络超时时间
• 获取ResultSet后手动设置rs.setFetchSize(100)（可根据业务实际结果集大小调整）

3. 资源释放逻辑缺陷 #

你当前的CallableStatement、Connection关闭逻辑写在try块内部，且finally块为空，一旦遍历ResultSet过程中抛出异常，连接和语句对象都不会被关闭，会直接导致连接泄漏。当连接池资源耗尽后，应用会等待连接池释放资源，外部表现就类似rs.next()卡住。
建议将资源释放逻辑移到finally块，或者使用Java 7+提供的try-with-resources语法自动释放资源，避免连接泄漏。

4. 数据库服务端资源争用 #

偶发的表/行锁、IO/CPU峰值、undo/redo资源争用都会导致游标结果返回延迟，可通过查看Oracle AWR报告对应慢请求时间点的实例负载、锁等待情况确认该类问题。

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