MyBatis分页陷阱：从RowBounds内存泄漏到高效分页实战
那天凌晨三点，我被刺耳的手机警报惊醒。监控系统显示生产环境某核心服务内存占用突破90%，随后迅速触发OOM崩溃。紧急回滚后排查发现，罪魁祸首竟是团队新人提交的一段使用MyBatis RowBounds的"优化"代码。这次事故让我彻底明白：在数据分页这个看似简单的场景里，藏着足以摧毁系统的魔鬼细节。
1. RowBounds分页背后的致命逻辑
很多开发者第一次接触MyBatis分页时，都会被RowBounds的简洁API所吸引——不需要修改SQL语句，只需在方法参数中传入一个包含offset和limit的对象，就能轻松实现分页效果。但这种便利背后隐藏着惊人的内存消耗机制。
1.1 逻辑分页的运作原理
RowBounds实现的是典型的逻辑分页（Client-side Paging），其工作流程可分为三个阶段：
- 全量数据加载：执行原始SQL（不带LIMIT）获取所有匹配记录
- 内存游标定位：通过JDBC ResultSet的absolute()或循环next()跳过offset条记录
- 结果集截取：从当前位置开始读取limit条数据存入内存列表
// 典型的问题用法示例 public List<User> findUsers(RowBounds rowBounds) { return sqlSession.selectList("com.example.mapper.UserMapper.findAll", null, rowBounds); } // Mapper中的原始SQL <select id="findAll" resultType="User"> SELECT * FROM users WHERE status = 'ACTIVE' <!-- 没有LIMIT子句 --> </select>当表中有100万条ACTIVE用户时，这100万条记录会全部加载到JVM内存中，而最终返回的可能只是前10条。
1.2 内存消耗的数学模型
假设我们处理一个包含200万条记录的表，每条记录平均占用1KB存储空间，比较不同分页方式的内存消耗：
| 分页方式 | 第1页(0-20) | 第100页(1980-2000) | 内存峰值 |
|---|---|---|---|
| RowBounds | 20KB | 2GB | 2GB |
| SQL LIMIT | 20KB | 20KB | 20KB |
| Keyset分页 | 20KB | 20KB | 20KB |
这个简单的计算揭示了一个可怕的事实：使用RowBounds翻到靠后的页码时，内存消耗会随着offset值线性增长。当处理百万级数据时，很容易就会突破JVM堆内存限制。
关键发现：RowBounds的内存消耗公式为
总消耗 ≈ 平均行大小 × 符合条件的总行数，与具体访问的页码无关
2. 物理分页的进阶实践
与危险的逻辑分页相对，物理分页（Server-side Paging）通过在数据库层面过滤数据，从根本上解决了内存问题。以下是几种经过实战检验的实现方案。
2.1 原生LIMIT方案
最直接的改造方式是在SQL中明确添加LIMIT子句：
<select id="findByPage" resultType="User"> SELECT * FROM users WHERE status = 'ACTIVE' ORDER BY create_time DESC LIMIT #{offset}, #{pageSize} </select>这种方案需要注意两个关键点：
- 参数计算安全：确保offset和pageSize经过校验，防止SQL注入
- 排序稳定性：必须指定ORDER BY以保证分页结果一致性
2.2 高性能Keyset分页
对于超大数据集（千万级+），传统LIMIT分页会出现深度翻页性能问题。这时可以采用基于索引的Keyset分页：
-- 第一页 SELECT * FROM users WHERE status = 'ACTIVE' ORDER BY id DESC LIMIT 20; -- 后续页面（假设上一页最后一条记录的id是12345） SELECT * FROM users WHERE status = 'ACTIVE' AND id < 12345 ORDER BY id DESC LIMIT 20;Keyset分页的优势体现在：
- 不受页码影响，性能恒定
- 无内存溢出风险
- 适合无限滚动场景
2.3 MyBatis-Plus分页插件
对于使用MyBatis-Plus的项目，其内置的分页插件提供了开箱即用的安全分页：
// 配置拦截器 @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } // 使用示例 Page<User> page = new Page<>(1, 20); Page<User> result = userMapper.selectPage(page, Wrappers.<User>query().eq("status", "ACTIVE"));该插件会自动将分页参数转换为数据库方言的物理分页语句，同时提供总数统计等便捷功能。
3. 分页性能优化实战技巧
即使正确使用了物理分页，面对海量数据时仍可能遇到性能瓶颈。以下是我们在千万级用户系统中验证过的优化方案。
3.1 覆盖索引优化
对于复杂查询，确保分页操作能够利用覆盖索引：
-- 低效查询 SELECT * FROM orders WHERE user_id = 100 AND status = 'PAID' ORDER BY create_time DESC LIMIT 0, 20; -- 优化后的索引设计 ALTER TABLE orders ADD INDEX idx_paging (user_id, status, create_time, id); -- 优化后的查询（通过延迟关联减少回表） SELECT o.* FROM orders o JOIN ( SELECT id FROM orders WHERE user_id = 100 AND status = 'PAID' ORDER BY create_time DESC LIMIT 0, 20 ) tmp ON o.id = tmp.id;3.2 分页缓存策略
对于高频访问的前几页数据，可以使用多级缓存：
// 伪代码示例：结合本地缓存与Redis public Page<User> getUsers(int page) { String cacheKey = "users:page:" + page; Page<User> result = localCache.get(cacheKey); if (result == null) { result = redisTemplate.opsForValue().get(cacheKey); if (result == null) { result = userMapper.selectPage(new Page<>(page, 20)); redisTemplate.opsForValue().set(cacheKey, result, 5, TimeUnit.MINUTES); } localCache.put(cacheKey, result); } return result; }3.3 分页查询的监控指标
建立完善的分页监控体系，可以提前发现潜在问题：
| 指标名称 | 监控目标 | 告警阈值 |
|---|---|---|
| query.page.size | 单页记录数 | > 100条 |
| query.page.offset | 最大翻页偏移量 | > 10000 |
| query.page.duration | 分页查询耗时 | > 500ms |
| memory.result.set.size | 结果集内存占用 | > 10MB |
在Spring Boot中可以通过Micrometer轻松实现这些指标的采集：
@Repository public class UserMapper { private final MeterRegistry meterRegistry; public List<User> findByPage(int offset, int size) { Timer.Sample sample = Timer.start(); List<User> result = sqlSession.selectList(...); sample.stop(meterRegistry.timer("db.query.page")); meterRegistry.summary("db.result.set.size").record(result.size()); return result; } }4. 分页方案选型决策树
面对不同的业务场景，没有放之四海而皆准的分页方案。我们总结出以下决策流程帮助开发者做出合理选择：
数据量评估
- <1万条：RowBounds（需确保不会增长）
- 1万-100万：SQL LIMIT
100万：Keyset分页
访问模式分析
- 随机跳页：需配合缓存
- 顺序浏览：Keyset最佳
- 导出全部：流式处理
一致性要求
- 强一致：实时分页查询
- 最终一致：预计算分片
特殊场景处理
- 多表关联：考虑物化视图
- 复杂过滤：使用搜索引擎
graph TD A[开始分页设计] --> B{数据量} B -->|小数据量| C[RowBounds] B -->|中等数据量| D[SQL LIMIT] B -->|大数据量| E[Keyset分页] C --> F{是否允许全量加载} D --> G{是否需要跳页} E --> H{是否顺序访问} F -->|否| D G -->|是| I[增加缓存层] H -->|是| J[持续优化]（注：实际项目中应删除mermaid图表，此处仅为说明决策逻辑）
在一次电商大促前的压力测试中，我们通过将商品列表的分页方式从RowBounds迁移到Keyset分页，使系统在相同硬件配置下支持的QPS从200提升到1500+。这充分证明了正确分页方案对系统性能的决定性影响。
分页看似只是CRUD中的一个简单功能，但其中蕴含的技术深度足以区分出初级与高级开发者。记住：任何不假思索直接使用RowBounds的行为，都是在给自己的系统埋下定时炸弹。
