怎么处理大结果集

处理大结果集（Large Result Set）的核心思路是：避免一次性把全部数据放进内存，而是边取边处理、分批、流式、异步、可中断。下面按常见场景给你一套实用方案。

一、先把问题拆清楚

大结果集通常带来 3 个问题：

1. 内存爆炸（OOM）
2. 响应慢 / 超时
3. 数据库压力大

所以处理原则：

不一次性加载、不长时间占用连接、不阻塞主线程

二、数据库层：从源头控制

✅ 1. 分页（Pagination）

最常见、最安全

SELECT * FROM orders
ORDER BY id
LIMIT 1000 OFFSET 0;

问题：

• OFFSET 很大时性能差

✅ 推荐：游标分页（Keyset Pagination）

SELECT * FROM orders
WHERE id > :last_id
ORDER BY id
LIMIT 1000;

适合：

• 顺序扫描
• 导出、同步、批处理

✅ 2. 只查需要的字段

避免：

SELECT *

改成：

SELECT id, status, amount FROM orders

✅ 3. 使用数据库游标（游标查询 / 流式查询）

MySQL

-- 服务端游标
DECLARE cur CURSOR FOR SELECT ...

JDBC（流式读取）

PreparedStatement ps = conn.prepareStatement(
    sql, ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY);
ps.setFetchSize(Integer.MIN_VALUE); // 流式

PostgreSQL

DECLARE cur CURSOR FOR SELECT ...
FETCH 1000 FROM cur;

✅ 适合：超大结果集、导出、迁移

三、应用层：边读边处理

✅ 4. 流式处理（Streaming）

不要 List<Entity> 全部接住

❌ 错误示例：

List<Order> list = queryAll(); // 危险

✅ 正确示例（Java Stream / Iterator）：

try (Stream<Order> stream = repository.streamAll()) {
    stream.forEach(this::process);
}

✅ 5. 分批处理（Batch Processing）

最常用、最稳

lastId = 0
while true:
    rows = query(limit 1000, where id > lastId)
    if rows empty:
        break
    process(rows)
    lastId = max id

适合：

• 数据清洗
• 同步
• 对账
• 导入导出

四、导出 / 文件场景

✅ 6. 流式写入文件

避免：

查全量 → 放内存 → 写文件

正确：

查一批 → 写一批 → flush

示例（CSV）：

while (hasNext) {
    List<Row> rows = fetchNext(1000);
    writeToCsv(rows);
}

✅ 不占内存
✅ 可断点续传

五、前端 / API 场景

✅ 7. 分页接口（限流）

GET /orders?page=1&size=100

❌ 禁止：

GET /orders/all

✅ 8. 游标分页 API（推荐）

GET /orders?after=12345&limit=100

返回：

{
  "data": [...],
  "next": "12399"
}

✅ 对前端和数据库都友好

六、特殊场景处理

✅ 9. 异步 + 任务（大数据导出）

流程：

1. 接口只创建任务
2. 后台异步处理
3. 处理完成后通知 / 提供下载

创建任务 → 返回 taskId
后台 worker 分批处理
生成文件 → 上传 OSS

✅ 用户体验好
✅ 可失败重试

✅ 10. 分布式 / 并行处理

适合 超大规模

• 按 ID 范围拆分
• 按时间范围拆分
• 分片并行执行

worker1: id 1–1000000
worker2: id 1000001–2000000

七、常见错误总结

八、快速选择方案

如果你愿意，可以告诉我：

• 用的 数据库（MySQL / PG / Oracle）
• 语言 / 框架
• 是 接口返回 / 导出 / 同步 / 任务

我可以直接给你可落地代码方案。