Java后端分页不能只靠limit和offset，因大数据量时offset越大数据库扫描行数越多、性能断崖下降；应优先用游标分页（基于唯一排序字段），慎用Pageable默认offset、PageHelper危险配置，并统一前后端分页参数校验规则。
Java后端分页为什么不能只靠 limit 和 offset
因为数据量大时，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(*)
Spring Data JPA 的 Pageable 怎么用才不踩坑
Pageable 默认生成 OFFSET 查询，看似简洁，实则隐藏性能风险。它适合小数据量或前端只允许“下一页/上一页”（即游标式交互）的场景，但默认不提供游标能力。
关键点：
立即学习“Java免费学习笔记（深入）”；
-
PageRequest.of(0, 20)生成的是offset=0；PageRequest.of(4999, 20)就是offset=99980—— 千万别在高并发列表接口里这么用 - 想用游标，得自己实现
Pageable子类，或改用org.springframework.data.domain.CursorPageable（Spring Data 3.2+ 新增，需搭配ReactiveCrudRepository） - 如果坚持用
Page<T>，至少把totalElements设为 -1（禁用总数统计），避免自动触发COUNT(*)查询
MyBatis 分页插件（PageHelper）的三个危险配置
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 < 1 || size < 1 || size > 100) throw new IllegalArgumentException() - 禁止前端传负数
size或极大page（如page=9999999），可在网关层用 Spring Cloud Gateway 的RequestBodyPredicateFactory拦截 - 游标分页时，前端应传
cursor=123456（上一页末条主键值），后端必须校验该cursor是否存在于当前排序规则下（例如先查SELECT id FROM table WHERE id = ?）
分页不是套个工具就完事，核心在于理解数据规模、访问模式和一致性要求。游标适用于流式浏览，传统页码适用于管理后台的精确跳转——选错方案，优化再细也扛不住数据量增长。
