1. 分页技术：为什么需要它？
在实际业务场景中，数据量大是常态。比如电商平台的商品列表、社交媒体的动态流、企业后台的订单记录，动辄成千上万条数据，直接一次性加载会引发性能问题甚至系统崩溃。分页技术通过对数据进行切片化处理，有效平衡用户体验与系统负载。
以常见的接口请求为例，用户期望的交互模式是：
客户端传递页码和每页条数
服务端返回对应页码的数据片段
同时告知总数以支持页码跳转
这看似简单的要求，后端实现却可能踩到多个技术坑点。MyBatis生态中，PageHelper作为明星级分页插件，是解决这类问题的首选方案，而当遇到特殊场景时，自定义分页则会展示其独特价值。
2. PageHelper完整使用手册
2.1 环境准备（Spring Boot技术栈）
2.2 配置详解
# application.yml配置参数
pagehelper:
helper-dialect: mysql # 指定数据库方言
reasonable: true # 页码溢出自动修正（超过最大页返回最后一页）
support-methods-arguments: true # 支持接口参数直接传递分页参数
params: count=countSql # 结果统计模式配置
2.3 基础查询示例
// Service层分页查询实现
public PageInfo
// 魔法语句触发分页（需紧跟查询语句）
PageHelper.startPage(pageNum, pageSize);
List
return new PageInfo<>(users);
}
// Controller层接口示例
@GetMapping("/users")
public Result getUserList(
@RequestParam(defaultValue = "1") Integer pageNum,
@RequestParam(defaultValue = "10") Integer pageSize) {
return Result.success(userService.listUsers(pageNum, pageSize));
}
2.4 复杂查询场景
// 多表关联分页示例
public PageInfo
PageHelper.startPage(page, 20)
.setOrderBy("create_time DESC"); // 动态排序控制
List
return new PageInfo<>(list);
}
3. 自定义分页深度实践
3.1 何时需要自定义分页？
需要兼容特殊分页格式（如游标分页）
分页逻辑需要深度集成业务规则
处理超高并发场景的优化需求
3.2 实现原理与完整代码
3.2.1 分页参数封装
// 统一分页请求参数基类
public class PageParam {
private Integer pageNum = 1; // 当前页码
private Integer pageSize = 10; // 每页条数
private String sortField; // 排序字段
private SortOrder sortOrder; // 排序方向枚举
// 逻辑校验方法
public void validate() {
if(pageSize > 100) {
throw new BusinessException("单页数据量超限");
}
}
}
3.2.2 MyBatis拦截器实现
@Intercepts(@Signature(type = Executor.class,
method = "query",
args = {MappedStatement.class, Object.class,
RowBounds.class, ResultHandler.class}))
public class CustomPageInterceptor implements Interceptor {
// 拦截逻辑处理
@Override
public Object intercept(Invocation invocation) throws Throwable {
Object parameter = invocation.getArgs()[1];
if (parameter instanceof PageParam) {
PageParam pageParam = (PageParam)parameter;
// 执行分页SQL重写逻辑
rewriteQuerySql(invocation, pageParam);
}
return invocation.proceed();
}
// SQL改写核心方法（示例简写）
private void rewriteQuerySql(Invocation invocation,
PageParam param) {
BoundSql boundSql = ((MappedStatement)invocation.getArgs()[0])
.getBoundSql(param);
String newSql = boundSql.getSql()
+ " LIMIT " + param.getOffset()
+ "," + param.getPageSize();
// 通过反射修改SQL语句
Field field = boundSql.getClass().getDeclaredField("sql");
field.setAccessible(true);
field.set(boundSql, newSql);
}
}
3.3 分页结果封装
// 统一分页响应结构
public class PageResult
private List
private Long total; // 总记录数
private Integer currentPage; // 当前页码
private Boolean hasNext; // 是否存在下一页
// 构造方法封装计算逻辑
public PageResult(List
this.records = records;
this.total = total;
this.currentPage = param.getPageNum();
this.hasNext = total > param.getPageNum() * param.getPageSize();
}
}
4. 核心技术对比分析
4.1 PageHelper核心优势
零学习成本：API简单直观，仅需一行代码即可实现分页
智能方言适配：支持12种主流数据库自动识别
丰富扩展能力：支持排序控制、count优化等高级特性
开源社区活跃：GitHub标星超过5k，问题响应及时
4.2 自定义分页存在价值
性能极致优化：可针对特定SQL做索引优化
灵活游标支持：实现基于最后ID的分页模式
安全管控增强：添加业务层数据权限过滤
协议格式定制：适配移动端特殊分页格式要求
5. 生产注意事项
5.1 PageHelper使用陷阱
线程污染风险：分页设置必须与当前请求严格绑定
嵌套查询问题：子查询中的分页可能被意外触发
COUNT性能：复杂关联查询建议手动优化count语句
5.2 自定义分页关键点
事务边界控制：分页查询与count查询保持原子性
SQL注入防护：排序字段必须白名单校验
偏移量计算优化：大数据量分页采用索引覆盖方案
6. 典型应用场景指南
6.1 PageHelper理想场景
后台管理系统表格分页
移动端瀑布流分页（需配合回收机制）
常规列表接口开发
6.2 自定义分页必选场景
千万级数据深度分页优化
需要结合Redis缓存的分页逻辑
基于地理位置的多维度排序分页
需要数据权限过滤的分页查询
7. 技术选型决策树
通过以下流程图帮助决策：
是否要求快速实现 → 选PageHelper
是否需要深度性能优化 → 选自定义
是否有特殊协议要求 → 选自定义+二次封装
8. 总结与展望
分页虽小，却承载着系统性能与用户体验的微妙平衡。PageHelper作为开箱即用的解决方案，适合80%的常规场景；而自定义分页则为复杂需求提供了灵活扩展的可能。随着分布式数据库的普及，未来的分页技术可能更深度集成到数据库访问层，例如TiDB的Region分片机制，将分页逻辑下推到存储引擎层，这将是值得持续关注的技术趋势。