摘要：今天给大家分享一道阿里云社招面试中的经典问题——如何处理千万级数据的分页查询。这不仅是高频面试题，更是实际业务中必须解决的性能难题。下面我会从基础实现到阿里级优化方案，逐步拆解这个问题的技术要点。
今天给大家分享一道阿里云社招面试中的经典问题——如何处理千万级数据的分页查询。这不仅是高频面试题，更是实际业务中必须解决的性能难题。下面我会从基础实现到阿里级优化方案，逐步拆解这个问题的技术要点。
一、基础方案：LIMIT OFFSET的致命缺陷
面试官："假设订单表有1000万数据，如何实现分页查询？"
初级开发者的回答通常是：
SELECT * FROM orders ORDER BY create_time DESC LIMIT 10 OFFSET 1000000;问题分析：
1、全表扫描
MySQL需要先读取1000010条记录，然后丢弃前100万条
2、性能灾难
当OFFSET=900万时，查询可能需要10秒+
3、内存爆炸
大偏移量会导致大量临时文件生成（Using filesort）
二、中级优化：子查询+索引覆盖
进阶方案：
SELECT * FROM orders WHERE id优化原理：
1、子查询先通过覆盖索引快速定位到起始ID
2、主查询通过主键ID范围过滤
3、相比OFFSET方案，性能提升10倍+
适用场景：
数据量在100万-5000万级别
必须有合适的索引（create_time需建立二级索引）
三、阿里级方案：游标分页（Cursor Pagination）
面试官期待的答案：
-- 第一页SELECT * FROM orders WHERE create_time技术要点：
1、无OFFSET
通过上一页的最后一条记录作为游标锚点
2、索引友好
完美利用(create_time)索引的有序性
3、性能稳定
无论查询第1页还是第100万页，响应时间都
业务适配：
需要前端配合传递last_record_value不支持随机跳页（但符合现代APP无限滚动交互）四、终极方案：分库分表+二级索引
当数据量达到亿级时，阿里云实际采用的架构：
1、水平分片
按订单ID哈希分16个库
2、全局索引表
单独维护(user_id, create_time)的映射关系
3、查询流程
先查索引表获取目标记录的主键ID
再通过ID路由到具体分片查询完整数据
// 伪代码示例List ids = indexTable.query("WHERE user_id=? ORDER BY create_time DESC", userId);List orders = shardingService.batchGetByIds(ids);五、面试加分项：异常情况处理
有经验的候选人会补充：
1、深分页保护
当游标超过阈值时，触发异步导出
2、数据一致性
如何处理新增数据导致的分页跳动（采用稳定字段如ID而非时间）
3、缓存策略
热门查询结果预加载到Redis
六、总结：分页优化的技术演进
面试建议：回答时要展示出对问题理解的深度和广度，从简单方案引出复杂场景的解决方案，这正是阿里面试官最看重的技术纵深能力。
大家在实际业务中如何处理大数据分页？欢迎在评论区分享你的实战经验！
来源：dbaplus社群一点号
