《实战：如何优雅处理百万级数据的分页查询——2025年最新解决方案》文/某大厂架构组首席工程师

一、问题场景还原

上周团队接手了一个电商订单系统的重构，遇到经典难题：历史订单表1.2亿条数据，用户翻到第5000页时接口超时。DBA监控显示，当offset值超过10万时，查询耗时从50ms暴涨到4.2秒1。这不是简单的加索引能解决的——因为即便使用覆盖索引，深分页带来的随机I/O开销依然无法避免。

---

二、分页方案选型对比

方案1：传统LIMIT分页

sql

SELECT * FROM orders 
WHERE user_id=123 
ORDER BY create_time DESC 
LIMIT 10 OFFSET 100000;  

痛点：

• OFFSET本质是逐条扫描并丢弃前10万条记录
• 页数越深，EXPLAIN中的rows值呈指数增长1
• 数据更新会导致重复/丢失（如第2页查询期间新增了数据）

方案2：游标分页（Cursor-based）

sql

SELECT * FROM orders 
WHERE user_id=123 AND id > 100000 
ORDER BY id ASC 
LIMIT 10;  

优势：

• 通过WHERE条件直