为什么分页越往后查询越慢？

wen IT资讯 2026-06-03 241

本文目录导读：

为什么分页越往后查询越慢？

这是一个非常经典且重要的数据库性能问题,分页越往后查询越慢，根本原因不在于“取”数据慢，而在于“找”数据慢。

大多数数据库（如 MySQL）在执行 LIMIT M, N 或 OFFSET M ROWS FETCH NEXT N ROWS ONLY 时，并不是直接跳到第 M 条去取数据，而是先从头数到第 M 条，然后再取 N 条。

核心原因：OFFSET 的“全表扫描”本质

以 SQL 为例：SELECT * FROM table ORDER BY id LIMIT 1000000, 10;

数据库的执行流程通常是：

关键开销：对于第 100 万页（OFFSET 100 万），数据库仍然需要扫描并丢弃前 100 万条记录，随着页数增加，OFFSET 值增大，数据库需要扫描和丢弃的行数呈线性增长，这就是查询越来越慢的直接原因。

即使你只需要最后的 10 条数据，数据库也必须加载前 100 万条记录的索引和部分数据行到内存中，这会消耗大量的磁盘读取时间（尤其是机械硬盘 HDD，随机读取慢）和 CPU 时间（用于解析和跳过行）。

B+ Tree 索引：数据库索引（如 MySQL InnoDB）虽然能快速定位到第一条记录，但从第一条记录开始往后“数”到第 100 万条这个遍历过程，本身就是 O(N) 的复杂度。
回表查询：如果查询的字段不全在索引中（即“非覆盖索引”），每扫描一行索引，数据库可能还需要（大概率）去磁盘上读取对应的完整数据行（回表），这就意味着扫描了 100 万次索引，可能还伴随着 100 万次随机磁盘 I/O 读取数据行。这是性能的天花板。

分页通常伴随着 ORDER BY，如果没有合适的索引，数据库需要对所有数据进行“文件排序”（filesort），这是一个非常昂贵的操作，即使有索引，OFFSET 很大时，排序+跳过的组合也会让数据库做大量无用功。

大多数数据库没有实现“跳过 N 行索引”的优化，它们无法直接跳到第 100 万行，因为它们不知道第 100 万行的物理地址，唯一可靠的方式就是遍历并计数。

如果业务上确实需要支持深度分页,有以下几种主流优化方法：

核心思想：不使用 OFFSET，而是记住上一页最后一条记录的某个唯一标识，然后直接查询“比这个标识大的下 N 条记录”。

适用场景：无限滚动、实时性要求高、数据不经常被物理删除。
SQL 示例（基于主键 id）：
- 第一页：SELECT * FROM table ORDER BY id LIMIT 10;
- 第二页（记录上一页最后一条 id 为 1000）：SELECT * FROM table WHERE id > 1000 ORDER BY id LIMIT 10;
优点：效率恒定，无论翻多少页，数据库都直接从指定位置开始扫描，完全消除了 OFFSET 的开销。速度极快，且稳定。
缺点：
1. 无法直接跳转到任意页（如第 10000 页），因为没有上一页的 id 作为起点。
2. 依赖一个绝对排序且单调递增的列（如自增主键），如果删除了一些记录，页码和 id 会不对等。

核心思想：先在索引（很小的结构）中完成 OFFSET 和 LIMIT 计算，只查出主键 ID，然后再用这些 ID 去回表取完整数据。

SQL 示例：

SELECT * FROM table 
JOIN (SELECT id FROM table ORDER BY id LIMIT 1000000, 10) AS tmp 
ON table.id = tmp.id;

原理：子查询 SELECT id ... 只需要扫描索引即可完成，无需回表，索引树体积小、扫描速度快，取出 10 个 ID 后，再用主键索引直接定位到数据行（只需要 10 次回表）。
结果：原本需要扫描 100 万次索引 + 100 万次回表，变成只需扫描 101 万次索引 + 10 次回表。性能提升巨大。

限制最大页数：比如只允许用户翻到第 500 页，之后提示“数据过多，请使用搜索”，这是产品层面最简单有效的做法。
使用搜索引擎：对于极大量的数据或复杂分词搜索，可以用 Elasticsearch 等搜索引擎，其内部基于 Lucene 的跳表（skip list）机制，对跳页支持更好。

一句话总结：分页越往后越慢，是因为数据库被逼着把前面的数据都翻一遍。不要用 OFFSET 跳过大量行，改用 WHERE id > last_id 的游标方式是最优解。