OFFSET引发SQL查询性能问题的原因及大偏移分页优化方法

数据老陈

2026-6-18

为什么OFFSET会导致性能损耗？

很多人会误解OFFSET的执行逻辑：数据库执行OFFSET时，并不是直接跳过指定行数，而是必须先扫描并遍历所有被跳过的行，才能定位到目标数据的起始位置。

比如你给出的第一个查询：

SELECT id, CHARACTER_LENGTH(polygon_data)
FROM polygon_data
LIMIT 10 OFFSET 1;

数据库实际会先读取前2行数据，丢弃第1行后返回剩下的10行。如果偏移量增大到10000，数据库就得先扫描10001行数据，再扔掉前10000行——偏移量越大，需要扫描的行数就越多，性能自然随偏移量增长急剧下降。

而第二个查询：

SELECT id, CHARACTER_LENGTH(polygon_data)
FROM polygon_data
WHERE id = 9;

因为id通常是主键（自带唯一索引），数据库可以通过索引直接定位到目标行，无需扫描其他无关数据，所以执行速度快得多。

大偏移量分页的优化方案

键集分页（基于上一页边界值查询）：这是优化深分页最有效的方式。放弃使用OFFSET，而是以上一页最后一条数据的唯一标识（如id、时间戳）作为筛选条件，直接定位下一页的起始位置。
示例：假设上一页最后一条数据的id是100，下一页的查询语句可以写成：
```
SELECT id, CHARACTER_LENGTH(polygon_data)
FROM polygon_data
WHERE id > 100
LIMIT 10;
```
这种方式利用索引直接定位目标范围，完全避免了扫描大量前置数据，性能不会随分页深度下降。
给排序/筛选字段添加索引：如果你的查询包含ORDER BY子句，必须确保排序字段有对应的索引。没有索引的话，数据库会先对全表数据进行排序，再执行OFFSET操作，性能损耗会进一步放大。
使用覆盖索引：如果查询涉及的所有字段（筛选、排序、返回字段）都包含在某个索引中，数据库可以直接从索引读取数据，无需回表查询原表数据，能大幅提升查询效率。针对你的查询，可以创建如下覆盖索引：
```
CREATE INDEX idx_polygon_id_data ON polygon_data(id, polygon_data);
```
限制深分页访问：如果业务场景允许，尽量限制用户访问过于靠后的分页（比如只开放前100页），或者通过搜索、筛选功能引导用户缩小数据范围，减少需要分页处理的数据量。
预计算或缓存分页结果：对于更新频率较低的数据，可以提前计算好分页的边界值，或者直接缓存分页结果，避免每次查询都重复执行扫描和计算。

内容的提问来源于stack exchange，提问作者random guy