PageHelper物理分页原理与亿级数据优化实践

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

在数据密集型的应用开发中，分页查询是最基础也最频繁的操作之一。传统的内存分页（逻辑分页）存在性能瓶颈——它需要先查询全部数据到内存，再进行分片处理。当数据量达到百万级时，这种分页方式会导致严重的内存消耗和响应延迟。

物理分页技术直接从数据库层面截取所需数据片段，而PageHelper正是MyBatis生态中最成熟的物理分页插件。它通过拦截SQL语句，自动改写为数据库特定的分页语法（如MySQL的LIMIT、Oracle的ROWNUM），使得开发者只需关注业务逻辑，无需重复编写分页代码。

我在多个电商和ERP系统中使用PageHelper处理过单表亿级数据的分页，实测查询耗时从秒级降至毫秒级。更重要的是，它的链式调用API与MyBatis无缝集成，三行代码就能实现完整的分页功能。

2. LIMIT关键字的底层原理与数据库差异

2.1 MySQL的LIMIT实现机制

MySQL的LIMIT offset, size语法看似简单，但隐藏着重要的性能陷阱。其工作原理可分为三步：

1. 数据库先执行完整的查询计划获取结果集
2. 根据offset值跳过指定行数（需要临时存储这些被跳过的行）
3. 返回后续的size条记录

当offset值较大时（如LIMIT 1000000, 10），数据库需要先构造百万级的临时结果集，这会导致：

• 大量I/O操作读取数据页
• 占用排序缓冲区(sort_buffer)
• 可能触发临时文件写入

sql复制/* 低效写法 */
SELECT * FROM orders LIMIT 1000000, 10;

/* 优化方案：使用索引覆盖+延迟关联 */
SELECT * FROM orders o 
JOIN (SELECT id FROM orders ORDER BY create_time LIMIT 1000000, 10) tmp
ON o.id = tmp.id;

2.2 不同数据库的分页语法差异

PageHelper的价值在于它封装了这些方言差异：

| 数据库类型 | 原生分页语法 | PageHelper转换策略 |
|-----------