结论：对上百万行全量处理，应启用JDBC流式读取（setFetchSize(Integer.MIN_VALUE)），而非LIMIT OFFSET；后者深分页性能差且不缓解内存压力。
MySQL大结果集查崩内存\_用stream还是LIMIT OFFSET？
直接说结论：对上百万行以上结果做全量处理，LIMIT OFFSET分页在深分页时会越来越慢且不解决内存问题；真正缓解OOM的，是服务端启用流式读取（如JDBC的setFetchSize(Integer.MIN_VALUE)），让数据边拉边处理，不攒在JVM堆里。
常见错误现象：java.lang.OutOfMemoryError: Java heap space出现在执行SELECT * FROM huge_table之后，哪怕只查100万行——因为默认JDBC把整张结果集一次性加载进内存。
-
LIMIT OFFSET适合前端分页展示，不适合后端批量导出或ETL；OFFSET越大，MySQL越要扫描前面所有行，性能断崖式下跌 - 流式读取要求MySQL连接参数开启
useCursorFetch=true，且ResultSet必须用TYPE_FORWARD_ONLY+CONCUR_READ_ONLY - MyBatis默认关闭流式，需显式配置
fetchSize="-2147483648"（即Integer.MIN_VALUE）并禁用autoMappingBehavior等可能触发全量映射的行为
Java JDBC启用流式查询\_关键三步不能漏
不是设了fetchSize就自动流式。MySQL驱动（8.0+）和JDBC规范有隐含前提，漏一步就会退化成全量加载。
- 连接URL必须带
useCursorFetch=true，例如：jdbc:mysql://localhost:3306/db?useCursorFetch=true - 创建
Statement时指定类型：conn.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY) - 执行前调用
statement.setFetchSize(Integer.MIN_VALUE)；用1000或-1都不行——只有Integer.MIN_VALUE才触发服务器端游标
容易踩的坑：PreparedStatement在预编译阶段若未绑定参数就调用setFetchSize，部分驱动版本会静默忽略；务必在executeQuery()之前设置。
MyBatis里怎么安全流式查大数据？
MyBatis封装太深，很多配置会暗中破坏流式行为。核心原则：关掉自动映射、禁用二级缓存、不用@Select注解里的动态SQL拼接。
- XML中写死SQL，用
<select fetchSize="-2147483648">属性（注意不是字符串"-2147483648"，MyBatis会转成int） - Mapper接口方法返回
void，用ResultHandler逐条处理：mapper.selectBigData(new ResultHandler<Record>() { ... }) - 绝对不要在该查询上启用
@Options(useCache = true)或<cache/>，否则MyBatis会试图缓存全部结果
性能影响：流式下网络往返次数不变，但JVM堆内存占用从GB级降到KB级；缺点是无法随机访问结果行，只能顺序遍历一次。
为什么mysqldump不会OOM，而你的Java程序会？
因为mysqldump底层用了MySQL C API的mysql_use_result()模式（对应JDBC的流式），而绝大多数Java ORM默认走mysql_store_result()（全量缓存）。这不是语言问题，是客户端协议使用方式问题。
- 验证是否真流式：抓包看TCP流，流式查询会在收到首行后立刻开始返回后续行；非流式则长时间无响应，然后一股脑发完
- MySQL服务端参数
max_allowed_packet要大于单行最大长度，否则流式过程中遇到超长字段仍会中断 - Docker或K8s环境下，应用容器内存限制（如
-m 512m）比JVM堆设置更早触发OOM Killer，得同步调大
最常被忽略的一点：流式只解决“读取端”内存压力，如果业务逻辑里又把每行塞进一个ArrayList，等于白搭。数据流进来，就得流出去——写文件、发MQ、存另一个库，别囤。
