本文针对 spring jdbc 查询千万级大表时出现的内存溢出与响应挂起问题，提出基于游标分页、行回调处理和键值分页的轻量级优化方案，无需引入 jpa 或复杂框架即可显著提升稳定性和吞吐量。
本文针对 spring jdbc 查询千万级大表时出现的内存溢出与响应挂起问题，提出基于游标分页、行回调处理和键值分页的轻量级优化方案，无需引入 jpa 或复杂框架即可显著提升稳定性和吞吐量。
当使用 NamedParameterJdbcTemplate.query("SELECT * FROM table", rowMapper) 直接加载 1400 万行数据时，应用极易挂起——即使 SQL Server Profiler 显示 SP:StmtCompleted 和 RPC:Completed 已完成，Java 客户端仍无响应。根本原因并非网络或数据库超时，而是 JDBC 驱动将全部结果集缓存至 JVM 堆内存中，同时 RowMapper 为每一行构造完整 Java 对象，导致内存暴涨（数十 GB）、GC 频繁甚至 OOM，最终表现为“假死”。
✅ 推荐方案：避免全量加载，采用流式/分块处理
1. 使用 RowCallbackHandler 实现零内存缓冲的流式处理
该接口不返回集合，而是对每行结果立即执行业务逻辑（如写入文件、发送消息、聚合统计），全程仅保留单行对象引用，内存占用恒定：
jdbcTemplate.query("SELECT id, entity_id, found, ... FROM table ORDER BY id",
(ResultSet rs) -> {
Entity entity = new Entity();
entity.setDatabaseId(rs.getInt("id"));
entity.setEntityId(rs.getString("entity_id"));
entity.setFound(rs.getBoolean("found"));
// ... 其他字段赋值
processEntity(entity); // 立即处理，不累积
});⚠️ 注意：processEntity() 必须是轻量、非阻塞操作；若需批量写入，建议内部维护固定大小缓冲区（如 1000 条）再刷盘。
2. 游标分页（Offset-Limit）：简单可控，适合中小批次
在原 SQL 中添加 LIMIT 和 OFFSET（SQL Server 2012+ 支持 OFFSET ... FETCH NEXT）：
SELECT id, entity_id, found, ... FROM table ORDER BY id OFFSET :offset ROWS FETCH NEXT :pageSize ROWS ONLY
配合循环调用：
int pageSize = 5000;
long offset = 0;
boolean hasMore = true;
while (hasMore) {
List<Entity> batch = jdbcTemplate.query(
"SELECT ... FROM table ORDER BY id OFFSET :offset ROWS FETCH NEXT :pageSize ROWS ONLY",
Map.of("offset", offset, "pageSize", pageSize),
entityRowMapper
);
if (batch.isEmpty()) break;
processBatch(batch);
offset += pageSize;
}⚠️ 注意：OFFSET 在超大表上性能会随偏移量线性下降（如 OFFSET 1000000 需扫描前 100 万行），仅推荐用于总页数可控（< 1000 页）场景。
3. 键值分页（Keyset Pagination）：高性能、无偏移衰减
利用主键（如 id）作为游标，每次查询“大于上一批最大 ID”的下一批数据：
SELECT id, entity_id, found, ... FROM table WHERE id > :lastId ORDER BY id OFFSET 0 ROWS FETCH NEXT 5000 ROWS ONLY
代码示例：
long lastId = 0;
int pageSize = 5000;
while (true) {
List<Entity> batch = jdbcTemplate.query(
"SELECT ... FROM table WHERE id > :lastId ORDER BY id FETCH NEXT :pageSize ROWS ONLY",
Map.of("lastId", lastId, "pageSize", pageSize),
entityRowMapper
);
if (batch.isEmpty()) break;
lastId = batch.get(batch.size() - 1).getDatabaseId(); // 更新游标
processBatch(batch);
}✅ 优势：无 OFFSET 扫描开销，索引可高效定位，响应时间稳定；
✅ 要求：必须有单调递增/有序的索引列（推荐主键或带索引的时间戳字段）。
❌ 为什么不推荐 PagingAndSortingRepository？
Spring Data JPA 的分页底层仍依赖 OFFSET（PageRequest.of(page, size)），且额外引入实体管理、脏检查、一级缓存等开销，每行内存占用比裸 JDBC 高 2–3 倍，反而加剧 OOM 风险。对于 ETL、数据迁移、报表导出等大数据量场景，JPA 是反模式。
? 进阶建议
- 超大规模批处理：直接选用 Spring Batch，其 JdbcCursorItemReader 内置游标流式读取，支持重启、事务分块、监控，专为海量数据设计；
- 只读分析场景：考虑物化视图或定期导出为 Parquet/CSV，避开 OLTP 数据库直查；
- 连接池调优：确保 HikariCP 等连接池 maxLifetime 小于 SQL Server 的 remote login timeout，避免空闲连接被服务端强制关闭导致挂起。
综上，解决大表查询挂起的核心是 切断“全量加载 → 全量映射 → 全量持有”的链路。优先采用 RowCallbackHandler 流式处理；若需分页，务必选择键值分页而非 OFFSET；而 PagingAndSortingRepository 在此场景下不仅无效，还会引入额外负担。
