为何过大的JDBC fetch size会损害系统性能？

很多人会疑惑：如果查询结果只有10k行，把fetch size设成1M，一次性把所有数据拉回来不就完了，能有什么问题？其实这里的关键是，fetch size不只是控制“拉多少行”，还会影响数据库、网络和应用端的资源分配逻辑，具体原因如下：

• 数据库端的冗余内存占用：数据库会根据你设置的fetch size预先分配内存缓冲区，用来准备要传输的数据。哪怕实际只有10k行，它还是会留出能装下1M行的内存空间——这部分内存本来可以给其他查询用，现在被浪费了，会挤压整体资源，拖慢数据库的处理速度。

• 网络传输的额外损耗：大数据包在网络传输时更容易被分片，还可能因为丢包触发重传。就算你只有10k行，过大的fetch size会让数据库尝试把所有数据打包成超大的数据包发送，反而不如用适中的批次传输稳定高效。

• 应用端的内存压力：JDBC驱动接收数据时，会按照fetch size的大小初始化内存结构。设成1M的话，哪怕实际只有10k行数据，驱动依然会开辟对应大小的内存空间，这会造成不必要的内存占用，甚至导致GC频繁运行，拖慢应用。

• 数据库执行计划的误判：有些数据库会根据fetch size调整查询策略。如果看到你设了1M的fetch size，可能会误以为要处理超大量数据，从而选择适合批量处理的执行计划（比如放弃索引走全表扫描），但这种计划对10k行的小结果集来说反而更慢。

说白了，fetch size的最优值是匹配实际结果集大小和系统资源的平衡点，不是越大越好——哪怕实际行数比设置值小，过高的配置依然会在各个环节带来不必要的资源消耗。

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