从你的描述来看，核心问题是Java应用的数据包远小于SQL Developer，导致相同数据量的传输耗时差了一个数量级。下面分几个方向分析并给出解决方案：

1. 最可能的原因：JDBC Fetch Size设置过小 #

这是远程Oracle查询慢最常见的“坑”！

• Oracle JDBC thin驱动默认的fetch size通常只有10行，这意味着每次网络往返只能获取10行数据。60K行就需要6000次往返，大量的网络开销直接导致耗时剧增。
• 而SQL Developer默认的fetch size是5000行（和你测试的5000行耗时数据完全匹配），只需要12次往返，速度自然快很多。

解决方案：在Java代码中显式设置fetch size：

// 普通Statement设置方式
Statement stmt = conn.createStatement();
stmt.setFetchSize(5000); // 可根据网络情况调整为10000等更大的值

// PreparedStatement同理
PreparedStatement pstmt = conn.prepareStatement("select id, name from table_name");
pstmt.setFetchSize(5000);

设置后再测试，你应该能看到耗时大幅下降，同时tcpdump抓包的数据包大小也会明显增大。

2. JDBC驱动对连接串参数的支持问题 #

你在连接串中设置的SDU/TDU和缓冲区参数可能没有生效，原因可能有以下几点：

• 驱动版本限制：旧版本的ojdbc驱动（比如ojdbc7及更早）对连接串中直接设置SDU/TDU的支持不完善，甚至会直接忽略这些参数。建议升级到最新的ojdbc11或ojdbc8版本。
• 参数设置方式错误：部分驱动版本需要通过JVM系统属性来设置SDU/TDU，而不是连接串。可以尝试在启动Java应用时添加以下参数：

  -Doracle.net.SDU=11280 -Doracle.net.TDU=11280 -Doracle.net.send_buf_size=11784 -Doracle.net.recv_buf_size=11784
  

• 服务器端SDU限制：即使客户端设置了SDU，最终生效的SDU是客户端和服务器端设置的最小值。你可以通过查询服务器参数确认当前值：

  SELECT value FROM v$parameter WHERE name = 'sdu_size';
  

  如果服务器的SDU默认是8192，那你设置的11280会被降级到8192，但这也远大于200字节，所以这不是你当前的核心问题。

3. 其他排查方向 #

• 验证网络缓冲区：你设置的SEND_BUF_SIZE和RECV_BUF_SIZE需要操作系统允许生效。比如Linux系统默认的TCP缓冲区可能比你设置的11784大，可以用sysctl net.ipv4.tcp_wmem和sysctl net.ipv4.tcp_rmem查看，如果你的设置小于系统默认值，可能不会实际生效。
• 检查连接复用情况：如果Java应用每次查询都新建连接，会增加TCP握手的额外开销。确保使用连接池（比如HikariCP、Druid）来复用连接，减少不必要的网络交互。

总结 #

优先调整JDBC的fetch size，这几乎肯定能解决你的耗时问题。之后再验证驱动版本和SDU参数的设置，进一步优化传输效率。

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