PageHelper：MyBatis物理分页原理与实践指南

1. PageHelper技术概述：MyBatis物理分页的利器

第一次接触PageHelper是在2016年一个电商后台管理系统的开发中。当时系统需要处理百万级商品数据的列表展示，前端要求实现"真分页"——也就是每次翻页都从数据库实时查询，而不是一次性加载全部数据。尝试了几种分页方案后，PageHelper以其近乎零配置的接入方式和出色的性能表现，成为了团队最终的选择。

PageHelper本质上是一个MyBatis的物理分页插件，它的核心价值在于将开发人员从繁琐的分页SQL编写中解放出来。在没有使用PageHelper之前，我们需要在每个Mapper.xml中手动编写类似LIMIT #{offset}, #{pageSize}这样的SQL片段，不仅重复劳动，而且容易出错。PageHelper通过拦截器机制，自动将简单的查询语句转换为带有分页参数的标准SQL，这对提升开发效率有着显著效果。

物理分页 vs 逻辑分页：物理分页是通过SQL语句直接在数据库层面限制返回结果（如MySQL的LIMIT），而逻辑分页是先查询全部数据到内存中再进行分片。大数据量场景下，物理分页的性能优势非常明显。

2. 核心原理与实现机制

2.1 拦截器工作机制

PageHelper的实现基于MyBatis的插件机制，具体来说是通过实现Interceptor接口来拦截Executor的query方法。当你在代码中调用PageHelper.startPage()方法时，它会将分页参数存入ThreadLocal中。后续执行SQL时，拦截器会检测当前线程是否存在分页参数，如果存在就会对原始SQL进行改写。

以MySQL为例，一个简单的查询语句：

sql复制SELECT * FROM products WHERE category_id = 1

会被自动改写为：

sql复制SELECT * FROM products WHERE category_id = 1 LIMIT 0, 10

这个改写过程不是简单的字符串拼接，而是通过JSqlParser对SQL进行语法分析后进行的结构化修改，因此能够正确处理各种复杂SQL语句。

2.2 分页参数传递流程

1. 参数设置阶段：调用PageHelper.startPage(pageNum, pageSize)时，参数会被封装到Page对象并存入ThreadLocal
2. SQL执行阶段：MyBatis执行查询前，PageInterceptor会检查ThreadLocal并获取分页参数
3. SQL改写阶段：根据数据库方言（Dialect）将原始SQL改写为分页SQL
4. 总数查询阶段：自动执行COUNT查询获取总记录数（默认行为）
5. 资源清理阶段：查询结束后自动清除ThreadLocal中的分页参数

2.3 支持的多数据库实现

PageHelper通过Dialect抽象来支持多种数据库，主要包括：

• MySQL
• Oracle
• PostgreSQL
• SQLServer