百万级数据分页查询时使用limit为什么会变慢，有哪些优化方法

在处理百万级甚至更大数据量的表时，分页查询是业务开发中非常常见的需求，但是很多开发者会发现，当分页的偏移量越来越大时，原本很快的查询会变得越来越慢，这本质上是limit的工作机制带来的性能问题。

limit分页变慢的原因

我们先看一个常规的分页查询语句：

SELECT * FROM user_table LIMIT 1000000, 10;

这条语句的含义是从user_table表中跳过前1000000条数据，取接下来的10条数据。MySQL执行这条语句时，会先扫描前1000010条数据，然后丢弃前1000000条，只返回最后10条，偏移量越大，需要扫描的无用数据就越多，查询耗时自然就越长。

常见的limit分页优化方法

1. 使用覆盖索引优化

如果查询的字段都包含在索引中，MySQL可以直接从索引中获取数据，不需要回表查询，能大幅减少扫描的数据量。比如我们只需要查询用户的id和名称：

-- 假设在user_name字段上建立了索引
SELECT user_id, user_name FROM user_table LIMIT 1000000, 10;

如果user_id和user_name都在同一个联合索引中，这条查询可以直接走索引覆盖，避免回表带来的性能损耗。

2. 子查询优化（延迟关联）

延迟关联的核心思路是先通过索引查询到需要的主键id，再通过主键id关联原表获取完整数据，减少回表的次数。示例代码如下：

SELECT * FROM user_table t
JOIN (
    SELECT user_id FROM user_table ORDER BY user_id LIMIT 1000000, 10
) tmp ON t.user_id = tmp.user_id;

子查询中只查询主键user_id，利用主键索引快速定位到需要的10个id，再和原表关联获取所有字段，扫描的数据量会远小于直接limit查询。

3. 基于自增主键的分页

如果表的主键是自增的，并且没有删除过数据，我们可以利用主键的范围查询来替代limit偏移量分页，这种方式效率最高。示例代码如下：

-- 假设上一页最后一条数据的id是1000000
SELECT * FROM user_table WHERE user_id > 1000000 ORDER BY user_id LIMIT 10;

这种方式不需要扫描前面的无用数据，直接通过主键索引定位到起始位置，查询速度非常稳定，不会随着数据量增大而变慢。但是这种方式要求主键连续，并且不能用于跳页查询，只适合上一页下一页的场景。

4. 标签记录法

如果需要支持跳页，同时避免大偏移量的问题，可以记录每一页的起始标识，比如按时间排序分页时，记录上一页最后一条数据的时间戳：

-- 上一页最后一条数据的创建时间是2024-01-01 10:00:00
SELECT * FROM user_table WHERE create_time > '2024-01-01 10:00:00' ORDER BY create_time LIMIT 10;

这种方式同样不需要扫描前面的数据，只要排序的字段有索引，查询效率就会很高，不过需要业务层配合记录每一页的标识值。

不同优化方案的选择建议

如果是简单的上一页下一页场景，优先选择基于自增主键或者标签记录法，性能最好；如果需要支持跳页，并且查询字段不多，优先选择覆盖索引+延迟关联的方案；如果查询的字段很多，并且表的数据量极大，建议结合业务需求调整分页逻辑，比如限制最大可查询的页数，避免用户查询过大的偏移量。

limit分页优化MySQL分页覆盖索引子查询分页延迟关联修改时间：2026-06-10 06:15:26