分页查询怎么优化

发布时间：2026-10-14 11:16:04 来源：亿速云阅读：95 作者：小樊栏目：数据库

分页查询在数据量大、页码越深时性能容易急剧下降，核心思路是避免 OFFSET 深度扫描 + 减少不必要的数据处理。下面按常见场景给你一套优化方案。

一、最常见的坑：深分页慢

SELECT * FROM orders
ORDER BY id
LIMIT 1000000, 20;

问题：

数据库要先扫描 1000020 行，再丢弃前 1000000 行
越往后越慢

二、推荐优化方案

✅ 1. 游标分页（Cursor / Keyset Pagination）⭐⭐⭐⭐⭐

最适合无限滚动、下一页场景

SELECT * FROM orders
WHERE id > 1000000
ORDER BY id
LIMIT 20;

优点：

利用索引，直接定位
时间复杂度接近 O(1)
深页也很快

缺点：

不支持“跳到第 N 页”
排序字段必须稳定（如主键、时间戳）

✅ 2. 延迟关联（Covering Index + JOIN）

适合必须保留 LIMIT offset, size 的场景

SELECT a.*
FROM orders a
JOIN (
  SELECT id
  FROM orders
  ORDER BY id
  LIMIT 1000000, 20
) b ON a.id = b.id;

原理：

子查询只查索引字段（id）
主表只回表 20 行

✅ 3. 业务层限制最大页数

例如：

最多查前 100 页
超过提示“请缩小筛选条件”

这是成本最低、最常用的方案。

✅ 4. 预计算 / 冗余表

适合报表、统计分析：

定时任务生成分页结果表
或 Elasticsearch / ClickHouse 专门做分页查询

✅ 5. 合理利用索引

分页 SQL 必须：

ORDER BY 的列有索引
WHERE + ORDER BY 能走同一个索引

❌ 错误示例：

ORDER BY create_time DESC, id DESC
-- 但索引只有 (create_time)

✅ 正确：

INDEX(create_time, id)

三、不同数据库的小贴士

MySQL

避免 SELECT *
优先 Keyset 分页
深分页用延迟关联

PostgreSQL

支持 WHERE id > ?
可使用 FETCH NEXT 20 ROWS ONLY

Elasticsearch

search_after 代替 from + size
from 超过 10000 会报错

四、如何选择？

场景	推荐
前端翻页（下一页）	游标分页
后台管理（跳页）	延迟关联 + 限制页数
大数据量统计	预计算 / ES
实时性要求高	索引优化

如果你愿意，可以告诉我：

用的什么数据库
表结构 & 索引
是否支持“只能下一页”

我可以直接帮你写最优分页 SQL。

向AI问一下细节