ResultSet实现原理：按需获取还是预加载？全量查询可行性探讨

这个问题问得很关键，毕竟处理大结果集时，内存溢出是开发者常踩的坑。先给你明确结论：ResultSet的加载机制并非统一标准，它取决于你使用的JDBC驱动实现，以及是否配置了合适的参数。

两种核心加载模式 #

1. 逐行/分批流式获取 #

很多现代JDBC驱动（比如PostgreSQL、新版本MySQL驱动）支持游标式获取：当你调用resultSet.next()时，驱动才会从数据库拉取对应的数据（可能是逐行，也可能按你设置的批次大小批量拉取），不会一次性把整个结果集加载到JVM内存中。

这种场景下，你完全可以直接执行SELECT * FROM MyTable，通过next()逐行处理数据——只要你的程序处理完一行就释放对应资源（比如不把所有行存入集合缓存），内存占用会始终维持在较低水平，不会出现内存爆炸的问题。

要开启这种模式，通常需要两步配置：

• 调用statement.setFetchSize(n)：设置每次从数据库拉取的行数（比如设为1000，驱动会先拉取1000行到本地内存，你遍历完这批后，再自动取下一批）。
• 部分数据库需额外配置连接参数：比如MySQL要在JDBC URL中添加useCursorFetch=true，否则即使设置了fetch size也不会触发游标式获取。

2. 全量加载至内存 #

部分旧版本驱动（比如早期MySQL驱动）或小众数据库驱动，默认会把整个结果集一次性加载到JVM内存中。如果你的表有百万级以上数据，直接执行SELECT *会瞬间占满内存，引发OOM（内存溢出），这就是你需要警惕的「不良影响」。

实操建议 #

• 先查阅你所用JDBC驱动的官方文档，确认其默认的结果集加载行为。
• 做个小测试：找一张数据量较大的表执行SELECT *，观察JVM内存占用变化。如果内存稳定在低位，说明是流式/分批加载；如果内存飙升至很高值，那就是全量加载模式。
• 若为全量加载模式：要么调整驱动配置开启游标式获取，要么改用分页SQL（比如SELECT TOP 100 * FROM MyTable ORDER BY id ASC OFFSET 0）分批次查询处理。

总结：不是不能直接执行SELECT * FROM MyTable，关键看驱动行为和配置是否合理。只要配置得当，直接遍历全表完全可行，无需额外编写分页SQL。

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