面对MyBatis处理千万级数据表的分页难题，核心解法并非优化SQL本身，而是通过“延迟关联”或“游标分页”策略，将全表扫描转化为索引覆盖扫描，从而在毫秒级完成响应。
当数据量突破千万大关,传统的LIMIToffset,size分页机制会遭遇严重的性能瓶颈，随着偏移量offset的增加，数据库需要读取并丢弃大量无效数据，导致查询时间呈线性甚至指数级增长，对于后端开发人员而言，这不仅是代码效率问题，更是系统稳定性的生死线，业内专家指出，在高并发场景下，这种“深分页”问题往往是导致数据库CPU飙升、连接池耗尽的根本原因，掌握针对海量数据的快速分页技巧，已成为现代Java后端开发的必备技能。
要解决问题,首先得看清痛点，很多开发者习惯直接使用MyBatis的<select>配合LIMIT，这在数据量小时毫无压力，但一旦进入千万级区间，问题便暴露无遗。
当用户翻到第1000页,每页10条数据时，SQL大致如下：
数据库引擎在执行这条语句时,必须先扫描前9990条记录，将它们全部加载到内存中，然后丢弃前9990条，只保留最后10条返回给应用层，这个过程涉及大量的IO操作和CPU计算，据统计，随着偏移量的增加，查询耗时显著上升，当偏移量达到百万级别时，响应时间可能从几毫秒恶化至数秒甚至超时。
更糟糕的情况发生在没有合适索引或索引选择性低的时候,如果LIMIT前的排序字段未建立索引，或者索引无法覆盖查询所需的所有字段，数据库将不得不进行全表扫描，在千万级数据表上，全表扫描意味着读取数GB甚至数十GB的数据，这对任何关系型数据库都是灾难性的。
解决这一问题的思路主要有两种：一是优化SQL逻辑，利用索引加速；二是改变分页策略，避免深偏移，以下是两种经过生产环境验证的高效方案。
这是最经典且兼容性最好的方案,其核心思想是“先查主键，再查详情”。
第一步：利用索引获取主键ID
首先执行一个只包含主键ID和排序字段的查询，并利用索引快速定位到起始位置。
由于create_time和id通常建有联合索引，这一步查询非常快，因为它只需要读取索引树，无需回表。
第二步：根据ID列表查询完整数据
拿到ID列表后，再通过IN查询获取完整的订单详情。
这种方式将一次昂贵的深分页查询,拆解为两次轻量级的查询，第一次查询利用索引快速跳过大量数据，第二次查询通过主键聚簇索引直接定位数据，避免了回表带来的随机IO开销。
这种方案特别适用于MyBatis千万数据表查询优化场景，它不依赖数据库的特殊功能，MySQL、PostgreSQL等主流数据库均支持，在大多数电商订单、日志系统中，这种“主键先行”的策略能将查询速度提升10倍以上。
对于实时性要求极高、数据持续增长的场景，游标分页是更优雅的选择，它不依赖偏移量，而是基于上一次查询的最后一条记录的位置。
不再使用LIMIToffset,size，而是使用WHEREcolumn>last_valueLIMITsize。
在实际开发中,很多团队使用MyBatisPlus等框架，其内置的分页插件PaginationInterceptor默认也是基于LIMIT的，面对千万数据，必须对插件进行定制或切换策略。
在分页组件中,通常会自动执行SELECTCOUNT()FROMtable，在千万级数据表中，如果表没有合适的统计信息或索引，
COUNT()可能非常慢。
EXPLAIN语句中的rows字段进行近似估算，或者在特定条件下返回固定总数。无论采用何种分页策略,索引都是性能的基石。
(create_time,user_id)，排序必须包含create_time。ORDERBYYEAR(create_time)，这会导致索引失效。对于千万级数据,直接COUNT()往往耗时过长，建议采用异步更新缓存总数的方式，或者在后台管理系统中，如果不需要精确到个位数，可以使用近似值，若必须精确，可考虑使用专门的分析型数据库（如ClickHouse）来同步统计数据，而非在主业务数据库中硬扛。
不支持,游标分页是基于“当前位置”的连续读取，无法直接计算第N页的数据，如果业务强需求是“跳转到第500页”，则必须使用传统的延迟关联方案，或者在游标分页的基础上，结合延迟关联技术实现“跳转”功能，但这会牺牲部分性能。
最佳实践是在Service层封装逻辑：先调用Mapper查询ID列表，再调用Mapper根据ID列表查询实体对象，注意使用IN查询时，参数列表不宜过长，建议分批处理（如每批1000个ID），以防止SQL语句过长导致解析性能下降或数据库连接异常。
微信 
电话 
QQ