在postgresql的实际使用中，分页查询是非常常见的需求，很多开发者会直接使用limit和offset组合实现分页功能。但当查询的偏移量逐渐增大时，查询耗时会出现明显的上升，这就是深分页带来的性能问题。
postgresql limit分页越查越慢的原因
postgresql使用limit offset进行分页时，执行逻辑是先扫描到offset指定的偏移位置，再返回后续的limit条数据。也就是说，当offset值为10000时，数据库需要先扫描前10000条符合条件的数据，然后丢弃这些数据，再取接下来的10条返回。随着offset数值的增大，需要扫描和丢弃的数据量也会同步增加，自然会导致查询耗时上升。
我们可以通过一个具体的执行计划来看这个问题，假设有一张用户表user_info，表中有100万条数据，且id是主键，我们执行如下查询：
-- 查询第1000页，每页10条数据 SELECT * FROM user_info ORDER BY id LIMIT 10 OFFSET 9990;
这条语句的执行计划会显示，数据库需要先排序后扫描前9990条数据，再取10条，offset越大，扫描的数据量越多，性能损耗越明显。如果查询没有合适的索引支持排序，还会触发全表扫描，性能下降会更严重。
postgresql深分页优化策略
1. 基于索引字段的游标分页
这种方式的核心是利用有序索引字段的连续性，避免使用offset。假设我们还是按照id排序分页，每次查询时记录上一页最后一条数据的id值，下一页查询时直接从这个值之后开始取数据。
比如第一页查询：
-- 第一页，取id最小的10条数据 SELECT * FROM user_info ORDER BY id LIMIT 10;
假设第一页最后一条数据的id是10，那么第二页查询可以写成：
-- 第二页，从id大于10的数据开始取10条 SELECT * FROM user_info WHERE id > 10 ORDER BY id LIMIT 10;
这种方式的优势是查询效率不会随着页数的增加而下降，因为每次查询都是通过索引直接定位到起始位置，不需要扫描前面的冗余数据。但这种方式要求排序字段是唯一且有序的，并且不支持跳页查询，只能逐页往后翻。
2. 延迟关联优化
如果必须要使用offset分页，并且查询的字段较多，或者是关联了多张表的查询，可以使用延迟关联的方式优化。核心思路是先通过索引查询出符合条件的主键id，再根据id关联原表获取完整数据，减少扫描的数据量。
比如原来的深分页查询是：
-- 原始深分页查询，直接查所有字段 SELECT * FROM user_info ORDER BY create_time DESC LIMIT 10 OFFSET 9990;
优化后的延迟关联查询可以写成：
-- 延迟关联优化，先查id再关联原表
SELECT t.* FROM user_info t
JOIN (
SELECT id FROM user_info ORDER BY create_time DESC LIMIT 10 OFFSET 9990
) tmp ON t.id = tmp.id
ORDER BY t.create_time DESC;
如果create_time和id有联合索引，子查询部分可以只通过索引完成，不需要回表查询所有字段，能大幅减少IO消耗，提升查询速度。
3. 业务层面限制分页深度
很多业务场景中，用户其实很少会翻到非常靠后的页码，比如电商商品列表、文章列表等，大部分用户只会查看前几页的内容。可以在业务层面限制最大可查询的页码，比如只允许查询前100页，超过这个范围的请求直接返回空数据或者提示无更多内容。
这种方式不需要修改数据库查询逻辑，从业务侧规避了深分页的问题，适合对分页深度没有硬性要求的场景。
4. 使用物化视图或冗余计数表
如果分页查询的条件相对固定，且数据更新频率不高，可以考虑使用物化视图预先存储分页需要的数据，或者维护一张冗余的计数表，记录每个分页的起始id，查询时直接通过计数表定位到对应的数据范围。
比如我们可以创建一张分页映射表，存储每个页码对应的起始id，查询时先查映射表获取起始id，再用游标分页的方式查询数据，避免计算offset。
不同优化策略的适用场景对比
我们可以通过下面的表格对比不同优化策略的适用场景和优缺点：
| 优化策略 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 游标分页 | 排序字段唯一有序，无需跳页 | 性能稳定，不会随页数增加而下降 | 不支持跳页，依赖排序字段连续性 |
| 延迟关联 | 必须使用offset分页，查询字段多 | 减少IO消耗，提升查询速度 | 仍然需要扫描offset对应的索引数据 |
| 业务限制深度 | 无强制深分页需求，用户很少翻页 | 实现简单，无数据库性能损耗 | 无法满足深分页的业务需求 |
| 物化视图/冗余表 | 查询条件固定，数据更新频率低 | 查询速度极快，适合高频查询 | 维护成本高，数据更新有延迟 |
总结
postgresql的limit分页越查越慢本质是offset机制需要扫描并丢弃大量前置数据导致的，优化深分页问题需要根据实际业务场景选择合适的方案。如果是支持逐页翻页的场景，优先选择游标分页；如果必须使用offset分页，可以尝试延迟关联优化；如果业务允许，限制分页深度是最简单的方案。开发者需要结合数据量、查询频率、业务需求综合选择，才能达到最优的性能效果。
postgresqllimit分页深分页优化offset游标分页修改时间：2026-07-01 15:18:15