Java下一页_Java实现分页功能的多种技术方案_网络技术

Java后端分页不能只靠limit和offset，因大数据量时offset越大数据库扫描行数越多、性能断崖下降；应优先用游标分页（基于唯一排序字段），慎用Pageable默认offset、PageHelper危险配置，并统一前后端分页参数校验规则。

因为数据量大时，offset 越大，数据库扫描行数越多，性能断崖式下降。比如 SELECT * FROM user LIMIT 20 OFFSET 100000，MySQL 仍需遍历前 100020 行才能返回最后 20 条。

真实业务中，用户翻到第 5000 页（offset=100000）很常见，尤其在后台管理或导出场景。这时必须换策略。

用游标分页（cursor-based pagination）：依赖排序字段唯一值（如 id 或 create_time），每次请求传上一页最后一条的 id，查 WHERE id > ? LIMIT 20
避免 ORDER BY RAND() 或模糊字段排序，否则游标无法稳定定位
若必须支持任意页码跳转（如输入“第 872 页”），可配合缓存预热 + 分页元信息（总条数、页数）+ 后台异步计算，但不要在每次请求都 COUNT(*)

Pageable 默认生成 OFFSET 查询，看似简洁，实则隐藏性能风险。它适合小数据量或前端只允许“下一页/上一页”（即游标式交互）的场景，但默认不提供游标能力。

关键点：

PageRequest.of(0, 20) 生成的是 offset=0；PageRequest.of(4999, 20) 就是 offset=99980 —— 千万别在高并发列表接口里这么用
想用游标，得自己实现 Pageable 子类，或改用 org.springframework.data.domain.CursorPageable（Spring Data 3.2+ 新增，需搭配 ReactiveCrudRepository）
如果坚持用 Page，至少把 totalElements 设为 -1（禁用总数统计），避免自动触发 COUNT(*) 查询

PageHelper 是最常用的 MyBatis 分页方案，但它有三个默认行为极易引发线上问题：

reasonable=true：开启后，页码超出范围会自动修正为最后一页 —— 前端可能收不到空列表，误以为还有数据
supportMethodsArguments=true：若方法参数没加 @Param("page")，插件可能错匹配参数，导致分页失效或 SQL 错误
未配置 autoRuntimeDialect=true 时，多数据源环境下可能复用错误方言（如 MySQL 分页语句被发给 PostgreSQL）

推荐最小安全配置：

pagehelper:
  helper-dialect: mysql
  reasonable: false
  support-methods-arguments: true
  auto-runtime-dialect: true

前后端对“第一页是 0 还是 1”、“每页最大条数是否有限制”经常不一致，导致越界查询或空响应。

统一建议：

前端传 page=1（从 1 开始）、size=20；后端校验：if (page 100) throw new IllegalArgumentException()
禁止前端传负数 size 或极大 page（如 page=9999999），可在网关层用 Spring Cloud Gateway 的 RequestBodyPredicateFactory 拦截
游标分页时，前端应传 cursor=123456（上一页末条主键值），后端必须校验该 cursor 是否存在于当前排序规则下（例如先查 SELECT id FROM table WHERE id = ?）

分页不是套个工具就完事，核心在于理解数据规模、访问模式和一致性要求。游标适用于流式浏览，传统页码适用于管理后台的精确跳转——选错方案，优化再细也扛不住数据量增长。