分页查询怎么优化才好

发布时间：2026-09-03 08:59:44 来源：亿速云阅读：92 作者：小樊栏目：数据库

分页查询（尤其是“深分页”）在数据库量大时很容易变慢，核心思路是避免扫描并丢弃大量已无关的数据。下面按常见场景和优化手段系统讲一下。

一、最经典问题：LIMIT 深分页慢

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

为什么慢？

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

二、最优解：游标分页（Keyset / Seek 分页）✅

原理

记住上一页最后一条的“位置”，从那里开始查

-- 上一页最后一条 id = 1000000
SELECT * FROM order
WHERE id > 1000000
ORDER BY id
LIMIT 20;

优点

✅ 不扫描历史数据
✅ 性能稳定（O(1) 级别）
✅ 适合无限滚动、Feed 流

注意

排序字段必须唯一 / 稳定
多字段排序要组合条件：

WHERE (create_time, id) > ('2024-01-01', 100)
ORDER BY create_time, id
LIMIT 20;

三、覆盖索引 + 延迟关联（常见优化）

如果必须用 LIMIT offset：

SELECT * FROM order
JOIN (
  SELECT id FROM order
  ORDER BY create_time
  LIMIT 1000000, 20
) t USING(id);

原理

子查询只查 索引（覆盖索引）
主表只回表 20 条

✅ 比直接 SELECT * 快很多

四、业务层优化（非常重要）

1️⃣ 不允许跳页

只支持“上一页 / 下一页”
直接用游标分页

2️⃣ 限制最大页数

最多查前 100 页

很多电商、搜索都是这么干的

3️⃣ 预计算 / 冗余表

热数据放 ES
排行榜用物化视图
日志类用时序数据库

五、不同数据库的小技巧

MySQL

用 ORDER BY + INDEX
避免 ORDER BY RAND()

PostgreSQL

WHERE id > :last_id
ORDER BY id
FETCH NEXT 20 ROWS ONLY;

ES

search_after
不要用 from + size 深翻

六、怎么选？

场景	推荐方案
移动端 Feed	游标分页
管理后台	限制页数
报表导出	游标 / 分批
搜索引擎	ES search_after
必须跳页	覆盖索引 + 延迟关联

七、一句话总结

不要“跳过数据”，要“记住位置”

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

用的什么数据库
表结构和索引
是否必须跳页

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

向AI问一下细节