SQL报表查询大结果集慢的核心在于全量加载，应改用游标分页（如WHERE created_at > '...' ORDER BY created_at LIMIT 100）或流式查询（设fetchSize、禁用缓存、边读边写），并配合精简字段、优化索引及物化汇总表。
SQL报表查询大结果集慢，核心问题不在SQL本身，而在一次性拉取全部数据再交给应用处理。解决方向很明确：避免全量加载，改用分页或流式查询，让数据“边查边用”。
分页查询：按需加载，减轻内存和网络压力
适用于用户需要浏览、筛选或导出部分数据的场景（比如后台管理列表页）。关键不是简单加 LIMIT OFFSET，而是优化分页逻辑。
- 慎用 OFFSET：OFFSET 越大，数据库仍需扫描前面所有行，性能急剧下降。100万行中取第99万条，MySQL 可能要遍历99万行再丢弃。
-
推荐游标分页（Cursor-based Pagination）：用上一页最后一条记录的排序字段值（如 created_at、id）作为下一页起点，配合 WHERE + ORDER BY + LIMIT。例如：
SELECT * FROM orders WHERE created_at > '2024-05-01 10:20:00' ORDER BY created_at LIMIT 100; - 索引必须覆盖排序+过滤字段：否则游标分页也会变慢。比如用 created_at 分页，就要有 (created_at) 或 (created_at, id) 的联合索引。
流式查询：适合导出、聚合、ETL 类场景
当报表需生成 Excel、CSV 或做服务端聚合统计时，不应把百万行全 load 到 JVM 内存，而应让 JDBC 按需读取、逐批处理。
- 设置 Statement 的 fetchSize：例如 MySQL Connector/J 中设 statement.setFetchSize(Integer.MIN_VALUE) 启用流式；PostgreSQL 用 setFetchSize(1000) 并确保在事务内、不使用 LIMIT。
- 禁用自动提交 & 关闭 ResultSet 缓存：流式依赖数据库连接持续拉取，需保持连接打开，且不能调用 rs.last()、rs.getRowCount() 等触发全量加载的方法。
- 应用层配合边读边写：比如查出一行就写入 OutputStream，或累积千行做一次聚合，避免堆内存暴涨。
其他关键配合项
单靠分页或流式还不够，几个常被忽略但影响巨大的点：
- SQL 本身是否必要查这么多字段？报表若只展示时间、金额、状态，就别 SELECT *；多余字段增加网络传输、序列化开销，还可能让执行计划走错索引。
- 是否有未生效的索引？EXPLAIN 看执行计划是否走了预期索引；WHERE 条件含函数（如 DATE(create_time) = '2024-05-01'）会让索引失效，应改用范围查询。
- 考虑物化汇总表或预计算：日活/月销类报表，可每天凌晨跑定时任务把结果存到 summary_order_daily 表，查询直接走小表，响应从秒级降到毫秒级。
不复杂但容易忽略：分页解决交互体验，流式解决资源瓶颈，两者选哪个，取决于你的报表用途——人看的，优先游标分页；机器用的（导出、同步、分析），优先流式查询。
