面对MyBatis处理千万级数据表的分页难题，核心解法并非优化SQL本身，而是通过“延迟关联”或“游标分页”策略，将全表扫描转化为索引覆盖扫描，从而在毫秒级完成响应。
当数据量突破千万大关,传统的LIMIT offset, size分页机制会遭遇严重的性能瓶颈，随着偏移量offset的增加，数据库需要读取并丢弃大量无效数据，导致查询时间呈线性甚至指数级增长，对于后端开发人员而言，这不仅是代码效率问题，更是系统稳定性的生死线，业内专家指出，在高并发场景下，这种“深分页”问题往往是导致数据库CPU飙升、连接池耗尽的根本原因，掌握针对海量数据的快速分页技巧，已成为现代Java后端开发的必备技能。
为什么传统分页在千万数据面前失效
要解决问题,首先得看清痛点，很多开发者习惯直接使用MyBatis的<select>配合LIMIT，这在数据量小时毫无压力，但一旦进入千万级区间，问题便暴露无遗。
深分页的性能陷阱
当用户翻到第1000页,每页10条数据时，SQL大致如下：
SELECT FROM orders LIMIT 9990, 10;
数据库引擎在执行这条语句时,必须先扫描前9990条记录，将它们全部加载到内存中，然后丢弃前9990条，只保留最后10条返回给应用层，这个过程涉及大量的IO操作和CPU计算，据统计，随着偏移量的增加，查询耗时显著上升，当偏移量达到百万级别时，响应时间可能从几毫秒恶化至数秒甚至超时。
索引失效与全表扫描
更糟糕的情况发生在没有合适索引或索引选择性低的时候,如果LIMIT前的排序字段未建立索引，或者索引无法覆盖查询所需的所有字段，数据库将不得不进行全表扫描，在千万级数据表上，全表扫描意味着读取数GB甚至数十GB的数据，这对任何关系型数据库都是灾难性的。
MyBatis千万数据表快速分页实战方案
解决这一问题的思路主要有两种：一是优化SQL逻辑，利用索引加速；二是改变分页策略，避免深偏移，以下是两种经过生产环境验证的高效方案。
延迟关联（Seek Method）
这是最经典且兼容性最好的方案,其核心思想是“先查主键，再查详情”。
具体实施步骤
-
第一步：利用索引获取主键ID
首先执行一个只包含主键ID和排序字段的查询，并利用索引快速定位到起始位置。<select id="selectIdsByPage" resultType="Long"> SELECT id FROM orders ORDER BY create_time DESC, id DESC LIMIT #{offset}, #{pageSize} </select>由于
create_time和id通常建有联合索引，这一步查询非常快，因为它只需要读取索引树，无需回表。 -
第二步：根据ID列表查询完整数据
拿到ID列表后，再通过IN查询获取完整的订单详情。<select id="selectOrdersByIds" resultType="Order"> SELECT FROM orders WHERE id IN <foreach collection="idList" item="id" open="(" separator="," close=")"> #{id} </foreach> </select>这种方式将一次昂贵的深分页查询,拆解为两次轻量级的查询，第一次查询利用索引快速跳过大量数据，第二次查询通过主键聚簇索引直接定位数据，避免了回表带来的随机IO开销。
适用场景与优势
这种方案特别适用于MyBatis千万数据表查询优化场景，它不依赖数据库的特殊功能，MySQL、PostgreSQL等主流数据库均支持，在大多数电商订单、日志系统中，这种“主键先行”的策略能将查询速度提升10倍以上。
游标分页（Keyset Pagination）
对于实时性要求极高、数据持续增长的场景，游标分页是更优雅的选择，它不依赖偏移量，而是基于上一次查询的最后一条记录的位置。
实现逻辑
不再使用LIMIT offset, size，而是使用WHERE column > last_value LIMIT size。
<select id="selectOrdersByCursor" resultType="Order">
SELECT FROM orders
WHERE create_time < #{lastCreateTime}
OR (create_time = #{lastCreateTime} AND id < #{lastId})
ORDER BY create_time DESC, id DESC
LIMIT #{pageSize}
</select>
优势分析
- 性能恒定：无论翻到第几页，查询时间都保持稳定，因为每次只读取固定数量的索引节点。
- 适合无限滚动：非常适合前端“加载更多”或“无限滚动”的交互模式，避免了传统分页中“第1页到第1000页”的跳跃式体验。
- 数据一致性：在数据插入频繁的场景下，传统分页可能出现数据重复或遗漏，而游标分页基于物理位置，能更好地保证数据完整性。
方案对比：延迟关联 vs 游标分页
| 特性 | 延迟关联 (Seek Method) | 游标分页 (Keyset Pagination) |
|---|---|---|
| 查询复杂度 | 中等（需两次查询） | 低（单次查询） |
| 性能表现 | 随页码增加略有波动，但远低于传统分页 | 恒定，与页码无关 |
| 适用场景 | 需要显示总页数、支持任意页跳转 | 无限滚动、新闻流、实时数据 |
| 实现难度 | 低，MyBatis原生支持 | 中，需维护状态（last_value） |
| 总页数计算 | 容易（COUNT()） |
困难（需近似估算） |
进阶优化：MyBatis Plus与分页插件的正确姿势
在实际开发中,很多团队使用MyBatis Plus等框架，其内置的分页插件PaginationInterceptor默认也是基于LIMIT的，面对千万数据，必须对插件进行定制或切换策略。
避免COUNT查询的性能黑洞
在分页组件中,通常会自动执行SELECT COUNT() FROM table，在千万级数据表中，如果表没有合适的统计信息或索引，
COUNT()可能非常慢。
- 缓存总数
对于非实时性要求极高的后台管理系统，可以将总数缓存到Redis中，定期更新。 - 近似估算
如果业务允许，可以使用EXPLAIN语句中的rows字段进行近似估算，或者在特定条件下返回固定总数。 - 禁用COUNT
在无限滚动或仅展示“是否有更多数据”的场景下，直接禁用COUNT查询，只返回当前页数据。
索引设计的黄金法则
无论采用何种分页策略,索引都是性能的基石。
- 覆盖索引：确保查询所需的字段都在索引中，避免回表，上述延迟关联方案中，只查询ID，完美利用主键索引。
- 最左前缀原则：如果排序字段是复合索引，必须遵循最左前缀原则，索引
(create_time, user_id)，排序必须包含create_time。 - 避免函数操作：不要在WHERE或ORDER BY中对索引字段使用函数，如
ORDER BY YEAR(create_time)，这会导致索引失效。
常见问题解答
MyBatis如何处理千万级数据分页的总记录数统计？
对于千万级数据,直接COUNT()往往耗时过长，建议采用异步更新缓存总数的方式，或者在后台管理系统中，如果不需要精确到个位数，可以使用近似值，若必须精确，可考虑使用专门的分析型数据库（如ClickHouse）来同步统计数据，而非在主业务数据库中硬扛。
游标分页是否支持前端跳转到任意页？
不支持,游标分页是基于“当前位置”的连续读取，无法直接计算第N页的数据，如果业务强需求是“跳转到第500页”，则必须使用传统的延迟关联方案，或者在游标分页的基础上，结合延迟关联技术实现“跳转”功能，但这会牺牲部分性能。
在MyBatis中实现延迟关联分页的最佳实践是什么？
最佳实践是在Service层封装逻辑：先调用Mapper查询ID列表，再调用Mapper根据ID列表查询实体对象，注意使用IN查询时，参数列表不宜过长，建议分批处理（如每批1000个ID），以防止SQL语句过长导致解析性能下降或数据库连接异常。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/414533.html
