分段下载是解决SQL报表大数据量导出问题的有效策略，核心是按批次查询、流式写入文件并分块传输，避免内存溢出与超时。
当SQL报表数据量大时，直接导出容易导致内存溢出、响应超时或前端卡死。分段下载是解决这类问题的有效策略——核心是避免一次性加载全部数据到内存，改为按批次查询、流式写入文件并分块传输。
分段查询：用游标或主键范围切分数据
避免 OFFSET LIMIT 深分页（性能随偏移增大急剧下降），优先采用基于有序主键的范围查询：
- 第一次查：
SELECT * FROM orders WHERE id >= 1 ORDER BY id LIMIT 10000 - 后续每次记录上一批最大
id，如上次末尾 id 是 9999，则下一批：WHERE id > 9999 ORDER BY id LIMIT 10000 - 若无合适数字主键，可用时间字段（如
create_time）+ 唯一索引组合，但需处理同一时间多条数据的情况
流式生成与边查边写
后端不拼接完整 CSV/Excel 字符串，而是建立输出流，每查一批就写一批：
- 使用 JDBC 的
setFetchSize(1000)提示驱动分批拉取（配合数据库游标） - 用
ServletOutputStream或 Spring WebFlux 的Flux<DataBuffer>直接写响应体 - CSV 场景可用 OpenCSV 的
CsvBeanWriter或自定义缓冲写入器，避免全量字符串拼接
前端配合：接受分块响应并合并文件
浏览器原生不支持分块下载合并，需服务端统一处理；但可由前端发起多请求 + Blob 合并（适合可控场景）：
- 服务端提供分段接口：
/report/export?segment=1&size=10000，返回带Content-Range的分片文件 - 前端用
fetch并发拉取多个 segment，用Blob和URL.createObjectURL合并为单个下载链接 - 更稳妥做法：服务端异步生成文件，返回任务 ID，前端轮询下载地址（适合超大报表）
附加保障：超时控制与断点续传
分段过程需防中断导致重复或遗漏：
- 每个分段请求携带唯一 trace_id，服务端记录已成功导出的 range（如 Redis 存
report:123:done_ranges = [1-10000, 10001-20000]） - 导出任务加锁（如分布式锁），防止同一报表被多次触发
- HTTP 响应头设置
Content-Disposition: attachment; filename="report_part_2.csv"，便于调试定位
分段下载不是简单切页，而是查询、传输、存储三环节协同优化。关键在减少内存驻留、规避深分页、利用流式能力。中小规模系统用主键分段 + 流写即可落地；高并发场景建议搭配异步任务队列和临时文件清理机制。
