分页后台实现的核心是结合数据库分页查询与接口设计，合理利用索引和缓存能显著提升大数据量下的分页性能。
大数据量分页如何优化？游标与键集分页实践
当数据量增长到百万级以后，传统分页方式的性能瓶颈会非常明显，多数后台开发人员习惯用 LIMIT OFFSET，COUNT 组合，但偏移量越大，数据库需要扫描的行数越多,响应时间呈指数级增长。
- 传统分页的痛点：
OFFSET导致数据库跳过前面所有行，即使最终只返回一页数据，例如查询第10000页，数据库要扫描100万行，排序后再丢弃，耗时极高。COUNT()扫描全表,在大表上同样低效。 - 游标分页（Cursor-Based）：不依赖偏移量，而是基于上一页最后一条记录的某个唯一字段（通常是自增ID或时间戳）作为筛选条件。
WHERE id > last_id ORDER BY id LIMIT 20，这种方式每次查询都走索引，扫描行数固定,性能稳定。 - 键集分页（Keyset Pagination）：类似游标分页，但可以支持多字段排序。
WHERE (create_time, id) > (last_time, last_id) ORDER BY create_time, id LIMIT 20,需要排序字段上建立联合索引。
实现游标分页的步骤：
- 客户端请求时携带上一页最后一条记录的游标值（如
last_id）。 - 后台根据游标值构建查询条件，利用
>或<操作符。 - 返回当前页数据，并在响应中包含新游标值（通常就是当前页最后一条记录的ID）。
- 前端无需感知游标逻辑,只需传递后端返回的游标值即可。
表格对比：传统分页 vs 游标分页
| 特性 | 传统分页（OFFSET） | 游标分页 |
|---|---|---|
| 性能 | 偏移量越大越慢 | 稳定，与页码无关 |
| 随机跳页 | 支持 | 不支持（只能顺序翻页） |
| 数据一致性 | 插入/删除可能导致数据重复或遗漏 | 受数据变动影响较小 |
| 实现复杂度 | 简单 | 略复杂 |
| 适用场景 | 小型数据量，内部管理后台 | 实时动态数据，如社交动态、评论列表 |
适用场景判断：如果你的后台功能需要用户随意跳转到任意页码（如查询第500页），那么传统分页是唯一选择，但需要配合其他优化手段，如果只是顺序翻页，比如新闻列表、订单流水，游标分页是更优方案，行业共识认为，在数据量超过100万行且需要频繁翻页的场景中,应优先考虑游标分页。
分页插件对比：MyBatis分页与JPA分页哪个好
在Java后台开发中，分页实现通常依赖框架提供的插件或工具，不同插件在性能、灵活性和易用性上存在差异。
- MyBatis 分页方式：
- RowBounds：逻辑分页，一次性查询全部结果，内存中截取，数据量大时极易OOM,不建议使用。
- PageHelper：基于拦截器，自动在SQL后拼接
LIMIT并生成COUNT查询，使用简单，但每个分页查询都会执行两次SQL（一次count，一次data）,高并发下可能成为瓶颈。 - 手动分页：自己编写
LIMIT和COUNT语句，灵活度最高,也最可控。
- JPA（Spring Data JPA）分页：
- 使用
Pageable接口，自动生成分页查询，内部实现同样是LIMIT OFFSET，对复杂查询的支持不够优雅,比如多表关联时可能生成低效SQL。 - 优点是标准统一,适合简单CRUD场景。
- 使用
实用对比
| 插件/方式 | 性能 | 灵活度 | 学习成本 | 适用场景 |
|---|---|---|---|---|
| PageHelper | 中等（额外count） | 高 | 低 | 复杂查询，多条件动态SQL |
| JPA Pageable | 中等（自动生成） | 中 | 低 | 简单单表查询，快速开发 |
| 手动分页 | 最优（可精确控制） | 最高 |
高 | 性能敏感，需要精细优化 |
| RowBounds | 极差（内存分页） | 低 | 低 | 严格禁止在业务中使用 |
选择建议：
- 如果是新项目，查询逻辑简单，推荐使用 JPA + Pageable，开发效率高，配合Spring Boot开箱即用。
- 如果项目已经使用MyBatis，并且查询复杂度高，PageHelper 是比较稳妥的选择，但要注意，当分页查询成为热点时，可以考虑手动优化count查询,比如使用缓存或近似值。
- 场景词示例：当你的后台需要“带条件的分页查询”时，PageHelper 的动态SQL支持更有优势，而JPA则需要编写
Specification或@Query,略显繁琐。
分页查询慢怎么办？从SQL到缓存的优化方案
即使选对了分页方式，数据库压力过大时依然会慢，优化需要从SQL、索引、业务逻辑、缓存几个层面入手。
SQL层面
- 避免
SELECT，只查询必要的字段,减少网络传输和临时表大小。 - 确保
ORDER BY字段有索引，且排序方向一致，如果排序字段是索引前缀，数据库可以避免filesort。 - 延迟关联：先查分页所需的主键，再通过主键关联原表获取其他字段。
SELECT t. FROM table t JOIN (SELECT id FROM table ORDER BY id LIMIT 10000, 20) tmp ON t.id = tmp.id这种方式让子查询先走索引，只扫描主键，再回表获取完整数据,大偏移量下性能提升明显。
索引优化
- 为分页排序字段建立复合索引，
(status, create_time, id),覆盖常见查询条件。 - 游标分页中，确保游标字段有唯一索引,且查询条件能利用索引下推。
业务与缓存
- 总条数统计：如果业务允许，可以缓存总条数，定期更新（如5分钟过期），避免每次查询都执行
COUNT()。 - 热点数据缓存：对于稳定不变的数据，可以考虑将整个分页结果缓存到Redis,但需要设计合理的失效策略。
- 分页与无限滚动：前端场景下，可以改用无限滚动+游标分页，后端不再执行count查询,进一步提升响应速度。
优化步骤参考
- 分析慢查询日志,定位耗时SQL。
- 使用
EXPLAIN检查是否使用索引，有没有using filesort或using temporary。 - 根据查询条件调整索引,必要时改为覆盖索引。
- 如果无法避免大偏移量,考虑切换为游标分页或键集分页。
- 对count查询单独优化,必要时使用缓存或近似值。
分页后台实现常见问题解答
Q: 分页时数据出现重复或丢失，是什么原因？
A: 根本原因是排序字段不唯一，当数据在翻页过程中发生插入或删除，或者排序字段存在重复值，数据库每次查询的排序结果可能不一致，解决方法是在 ORDER BY 中添加一个唯一字段（如主键ID）作为二级排序,保证同一页数据顺序固定。
Q: 分页总条数统计非常慢，有什么办法？
A: 统计慢主要是因为 COUNT() 扫描全表，如果业务对精确度要求不高，可以使用统计信息近似值（如 SHOW TABLE STATUS 中的 Rows 字段，或 EXPLAIN SELECT COUNT() 估算的行数），另一种做法是缓存总条数，并设置合理的过期时间，牺牲实时性换取性能，如果数据量极大且不允许近似值,可以考虑使用独立的计数表或专门的数据仓库。
Q: 分页接口的响应格式如何设计更通用？
A: 推荐返回统一结构：{ "code": 0, "data": { "list": [...], "total": 1000, "page": 1, "pageSize": 20 } }，前端根据 total 和 pageSize 计算总页数，如果使用游标分页，则改为 { "list": [...], "cursor": "next_id", "hasMore": true }，接口设计时应保留扩展字段，如 maxPageSize 限制单次请求上限,防止恶意调用。
分页后台实现的核心思路是：根据数据量和业务场景选择分页模式，优化SQL和索引，并在必要时引入缓存。 无论使用哪种技术栈，理解底层原理才能写出高效、稳定的分页功能。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/%e5%88%86%e9%a1%b5%e5%90%8e%e5%8f%b0%e5%ae%9e%e7%8e%b0%e7%9a%84%e6%a0%b8%e5%bf%83%e5%8e%9f%e7%90%86%e6%98%af%e4%bb%80%e4%b9%88%ef%bc%8c%e5%a6%82%e4%bd%95%e5%ae%9e%e7%8e%b0%ef%bc%9f/
