setfetchsize对全表查询无效是因驱动默认不启用服务器端游标，需按数据库配置对应参数（如mysql加usecursorfetch=true、postgresql用声明式游标）并验证日志或抓包确认生效。

setfetchsize 为什么对全表查询没效果

很多同学调大 setFetchSize 后发现全表扫描速度几乎不变，甚至更慢——这不是 bug，是 JDBC 驱动和数据库的默认行为在“背锅”。MySQL 的 Connector/J 默认把 setFetchSize 当作提示（hint），不强制分批拉取；PostgreSQL 驱动则只在声明式游标（Statement 设置 ResultSet.TYPE_FORWARD_ONLY + CONCUR_READ_ONLY）下才真正启用服务器端游标。

• Oracle 需要显式开启游标：连接 URL 加 defaultRowPrefetch=50 或调用 setFetchSize(50) + 使用 TYPE_FORWARD_ONLY
• MySQL 8.0+ 要配合 useCursorFetch=true 连接参数，否则 setFetchSize 被忽略
• SQL Server 的 sendStringParametersAsUnicode=false 可能干扰 fetch 行为，需一并检查

怎么验证 setFetchSize 真正生效了

光看代码里写了 setFetchSize(1000) 没用，得确认数据是不是真按批次从服务端吐出来的。最直接的方式是抓包或开数据库日志：

• PostgreSQL：打开 log_statement = 'all'，查日志里是否出现 DECLARE ... CURSOR 和后续 FETCH 1000
• MySQL：启用 general_log，观察执行 SELECT 后是否只有一条语句记录（说明未启游标），还是有反复的 mysql_stmt_fetch 调用（说明生效）
• Java 层加 java.sql.DriverManager.setLogWriter（仅部分驱动支持）或用 P6Spy 代理 DataSource 查实际网络往返次数

fetchSize 设太大反而拖慢的原因

setFetchSize 不是越大越好。设成 10000，看似减少往返，但可能触发内存溢出、GC 停顿，或让数据库锁住更多行/页。

• ResultSet 会缓存整批结果在 JVM 堆里，超大 fetchSize 容易 OOM，尤其字段多、含 BLOB
• PostgreSQL 游标默认不 hold，大 fetchSize 会让事务长时间占用连接和共享缓冲区
• MySQL 在 useCursorFetch=true 下，fetchSize 超过 max_allowed_packet 会直接报错：Packets larger than max_allowed_packet are not allowed
• 实测建议值：50–500，具体看单行大小；超过 2KB/行时，优先考虑 100 以下

替代方案：什么时候该放弃 setFetchSize

当你要处理千万级结果且必须流式消费时，setFetchSize 往往只是“半吊子优化”。它依赖驱动实现、数据库配置、JVM 内存，稳定性差。

• 真正可控的做法是手动分页：用 WHERE id > ? ORDER BY id LIMIT N，配合应用层状态维护
• PostgreSQL 推荐 cursor + FETCH FORWARD N 显式控制，比 JDBC 自动游标更透明
• MySQL 8.0+ 可用窗口函数 + ROW_NUMBER() 分块，避免 OFFSET 性能退化
• 如果只是导出数据，用数据库原生命令（mysqldump --skip-extended-insert、pg_dump --inserts）比 JDBC 更稳更快

驱动差异、事务隔离级别、连接池回收策略，都会让 setFetchSize 的表现飘忽不定。别把它当成银弹，先确认你的数据库和驱动到底支不支持、配没配对，再谈调多少。