应改用键集分页，即基于排序字段值（如id > last_id）过滤查询，避免offset线性扫描；辅以覆盖索引、延迟关联和混合分页策略提升大数据量下分页性能。
如果您在 PostgreSQL 中执行大偏移量的分页查询（如 OFFSET 100000 LIMIT 20），查询响应明显变慢，则很可能是由于数据库需扫描并丢弃大量前置行，即使走索引也无法避免回表判断可见性。以下是解决此问题的步骤：
一、改用键集分页（游标分页）
该方法规避 OFFSET 的线性扫描开销，基于排序字段的确定值进行条件过滤，每次仅检索“下一页所需范围”，不依赖行位置，性能稳定且可扩展。
1、确保排序字段具备高选择性、严格单调（如主键 id 或带时序唯一性的 created_at）、且已建立复合索引（含排序字段及查询所需列）。
2、首次查询获取第一页数据，并记录最后一条记录的排序字段值（例如 last_id = 150000）。
3、后续查询使用 WHERE 条件替代 OFFSET：SELECT * FROM users WHERE id > 150000 ORDER BY id LIMIT 20。
4、若需上翻页，可缓存前一页最小值，或改用反向查询：SELECT * FROM users WHERE id 149981 ORDER BY id DESC LIMIT 20，再反转结果集。
二、延迟关联优化（适用于 JOIN 场景）
当分页涉及多表 JOIN 时，直接对 JOIN 结果使用 LIMIT/OFFSET 会导致中间结果集膨胀、重复扫描；延迟关联先定位主表 ID 子集，再按需补全关联字段，大幅减少 I/O 和内存开销。
1、编写子查询仅获取主表分页所需的主键（如 user_id），按排序字段排序并应用 LIMIT/OFFSET：SELECT user_id FROM users ORDER BY user_id LIMIT 20 OFFSET 100000。
2、将该子查询作为派生表，与原表或关联表进行 INNER JOIN：SELECT u.*, o.order_no FROM users u INNER JOIN orders o ON u.user_id = o.user_id WHERE u.user_id IN ( SELECT user_id FROM users ORDER BY user_id LIMIT 20 OFFSET 100000 )。
3、为提升子查询效率，确保 users 表的排序字段（如 user_id）上有高效索引，且无 WHERE 过滤条件导致索引失效。
三、混合分页策略（小偏移保留 OFFSET，大偏移自动切换）
兼顾管理后台跳页需求与深分页性能，在业务层实现阈值控制：低偏移量维持简单 OFFSET/LIMIT，超过设定页码后强制转为键集分页，并隐藏“跳转至指定页”入口，仅提供“下一页”导航。
1、设定阈值（如 page_size = 20，max_offset_page = 100），对应最大 OFFSET 值为 1980（即 (100 − 1) × 20）。
2、当前页码 ≤ 100 时，生成标准 SQL：SELECT * FROM products ORDER BY id LIMIT 20 OFFSET 当前偏移值。
3、当前页码 > 100 时，拒绝接收任意 page_number 参数，仅接受上一页返回的游标值（如 cursor_id = 123456），生成 WHERE id > 123456 ORDER BY id LIMIT 20。
4、前端在页码 > 100 后禁用页码输入框，仅显示“下一页”按钮，并携带服务端返回的游标参数发起请求。
四、启用索引只扫描（Index Only Scan）并维护可见性映射
当查询仅涉及索引列且表中多数页面为“clean”（无死亡元组）时，PostgreSQL 可跳过回表检查可见性，显著加速大 OFFSET 场景下的索引扫描。
1、确认查询语句不包含非索引列（如 SELECT id, name FROM t WHERE ... ORDER BY id，需确保 name 已包含在索引中）。
2、创建覆盖索引：CREATE INDEX idx_covering ON t (id) INCLUDE (name)；或使用多列索引：CREATE INDEX idx_id_name ON t (id, name)。
3、定期执行 VACUUM ANALYZE t，确保 visibility map 更新完整，使 index only scan 能识别 clean pages。
4、验证是否命中索引只扫描：运行 EXPLAIN (ANALYZE, BUFFERS) 查询，观察执行计划中是否出现 “Index Only Scan”，且 “Heap Fetches” 为 0。
