阿里云社招一面：数据库中有 1000 万数据的时候怎么分页查询？

今天给大家分享一道阿里云社招面试中的经典问题——如何处理千万级数据的分页查询。这不仅是高频面试题更是实际业务中必须解决的性能难题。下面我会从基础实现到阿里级优化方案逐步拆解这个问题的技术要点。1. 基础方案LIMIT OFFSET的致命缺陷面试官假设订单表有1000万数据如何实现分页查询初级开发者的回答通常是SELECT * FROM orders ORDER BY create_time DESC LIMIT 10 OFFSET 1000000;问题分析全表扫描MySQL需要先读取1000010条记录然后丢弃前100万条性能灾难当OFFSET900万时查询可能需要10秒内存爆炸大偏移量会导致大量临时文件生成Using filesort2. 中级优化子查询索引覆盖进阶方案SELECT * FROM orders WHERE id (SELECT id FROM orders ORDER BY create_time DESC LIMIT 1000000, 1)ORDER BY create_time DESC LIMIT 10;优化原理子查询先通过覆盖索引快速定位到起始ID主查询通过主键ID范围过滤相比OFFSET方案性能提升10倍适用场景数据量在100万-5000万级别必须有合适的索引create_time需建立二级索引3. 阿里级方案游标分页Cursor Pagination面试官期待的答案技术要点无OFFSET通过上一页的最后一条记录作为游标锚点索引友好完美利用(create_time)索引的有序性性能稳定无论查询第1页还是第100万页响应时间都100ms业务适配需要前端配合传递last_record_value不支持随机跳页但符合现代APP无限滚动交互4. 终极方案分库分表二级索引当数据量达到亿级时阿里云实际采用的架构水平分片按订单ID哈希分16个库全局索引表单独维护(user_id, create_time)的映射关系查询流程先查索引表获取目标记录的主键ID再通过ID路由到具体分片查询完整数据