前言
在我们的日常开发中,经常会遇到分页查询接口的性能问题。
该接口访问前面几页很快,越往后翻页,接口返回速度越慢。
今天跟大家一起聊聊千万级大表如何高效的做分页查询,希望对你会有所帮助。
1.千万级大表分页为什么性能差?
核心痛点:当千万级别的订单大表需要查询limit 9999990,10时:
SELECT * FROM orders
ORDER BY create_time DESC
LIMIT 9999990,10;在分库分表环境下:
- 每个分片需扫描前9999990条
- 归并节点需处理分片数 × 1000万数据
- 内存溢出风险高达90%

真实案例:某电商订单查询事故
在128分片的订单表上执行深度分页,实际扫描了128 × 1000万 = 12.8亿行数据,导致数据库集群OOM!
2.深分页的常见解决方案
方案1:游标分页(最优解)
原理:基于有序字段的连续分页
public PageResult<Order> queryOrders(String lastCursor, int size) {
if (lastCursor == null) {
return orderDao.firstPage(size);
}
return orderDao.nextPage(lastCursor, size);
}SQL优化:
/* 首次查询 */
SELECT * FROM orders
ORDERBYidDESC
LIMIT10;
/* 后续查询 */
SELECT * FROM orders
WHEREid < ?lastId
ORDERBYidDESC
LIMIT10;性能对比:

方案2:覆盖索引+延迟关联
适用场景:需要跳页的非连续查询
三步优化法:

SQL实现:
/* 传统写法(全表扫描) */
SELECT * FROM orders ORDERBY create_time DESCLIMIT9999990,10;
/* 优化写法 */
SELECT * FROM orders
WHEREidIN (
SELECTidFROM orders
ORDERBY create_time DESC
LIMIT9999990,10-- 仅扫描索引
);执行计划对比:

方案3:全局二级索引
架构设计:

Java实现:
public List<Order> queryByPage(int page, int size) {
// 1. 查询全局索引
PositionRange range = indexService.locate(page, size);
// 2. 分片并行查询
Map<ShardKey, Future<List<Order>>> futures = new HashMap<>();
for (Shard shard : shards) {
futures.put(shard.key, executor.submit(() ->
shard.query(range.startId, range.endId)
);
}
// 3. 结果归并
List<Order> result = new ArrayList<>();
for (Future<List<Order>> future : futures.values()) {
result.addAll(future.get());
}
return result;
}方案4:基因分片法
解决分页字段与分片键不一致问题:
// 订单ID注入用户基因
long userId = 123456;
long orderId = (userId % 1024) << 54 | snowflake.nextId();查询优化:
SELECT * FROM orders
WHERE user_id = 123456
ORDER BY create_time DESC
LIMIT 9999990,10; 通过user_id路由到同一分片,避免跨分片查询
方案5:冷热分离 + ES同步
架构设计:

查询示例:
SearchRequest request = new SearchRequest("orders_index");
request.source().sort(SortBuilders.fieldSort("create_time").order(SortOrder.DESC));
request.source().from(9999990).size(10);
SearchResponse response = client.search(request, RequestOptions.DEFAULT);ES分页原理:通过search_after实现深度分页
"search_after": [lastOrderId, lastCreateTime]
方案6:业务折衷方案
1. 最大页数限制
public PageResult query(int page, int size) {
if (page > MAX_PAGE) {
throw new BusinessException("最多查询前" + MAX_PAGE + "页");
}
// ...
}2. 跳页转搜索

3.如何做性能优化?
3.1 索引设计黄金法则

3.2 分页查询检查清单
public void validateQuery(PageQuery query) {
if (query.getPage() > 1000 && !query.isAdmin()) {
throw new PermissionException("非管理员禁止深度分页");
}
if (query.getSize() > 100) {
query.setSize(100); // 强制限制每页数量
}
}3.3 分页监控指标

3.4 性能压测对比

测试环境:阿里云 PolarDB-X 32核128GB × 8节点
总结
单体阶段
limit offset, size + 索引优化
分库分表初期
游标分页 + 最大页数限制
百万级数据
二级索引归并 + 异步构建
千万级数据
ES/Canal准实时搜索
亿级高并发
分布式游标服务 + 状态持久化
分页方案选型表:

记住:没有完美的方案,只有最适合业务场景的权衡。
没有最好的方案,只有最适合场景的设计。