分页查询性能差的核心在于数据库需扫描并跳过前N行，游标分页（基于主键/唯一索引）可避免此问题；覆盖索引、延迟关联及限制深分页是关键优化手段。
分页查询性能差，核心问题不在 LIMIT 和 OFFSET 本身，而在于数据库要先扫描并跳过前 N 行才能拿到目标数据。当偏移量（OFFSET）很大时，比如 OFFSET 1000000，MySQL 或 PostgreSQL 往往需要遍历上百万行索引或数据页，即使只取 20 条，也极耗资源。
用主键/唯一索引做游标分页（推荐）
替代 OFFSET 的本质思路是：不“跳过”，而是“从上一页末尾继续”。前提是排序字段有唯一性（如自增 id、时间戳+id 组合）且已建索引。
- 第一页查：
SELECT id, name, created_at FROM orders ORDER BY id DESC LIMIT 20 - 第二页查（假设上页最后 id 是 98765）：
SELECT id, name, created_at FROM orders WHERE id - 避免使用
WHERE id ，防止重复或漏数据；确保 WHERE 条件能命中索引
覆盖索引减少回表
如果 SELECT 字段较多，但排序和过滤字段有限，可建立覆盖索引，让查询只走索引不查数据行。
- 例如按
status, created_at分页查订单：SELECT id, status, created_at, amount FROM orders WHERE status = 'paid' ORDER BY created_at DESC LIMIT 20 OFFSET 10000 - 创建联合索引：
INDEX idx_status_ctime (status, created_at, id, amount)—— 把 SELECT 中的非排序字段也包含进去 - 这样 MySQL 可直接从索引中取出全部所需字段，避免回表读取聚簇索引
延迟关联（适用于大 OFFSET 场景）
当必须用 OFFSET（如后台管理需跳转任意页），可先用子查询快速定位主键，再关联原表取全字段。
- 慢写法：
SELECT * FROM users ORDER BY id LIMIT 10000, 20 - 优化后：
SELECT u.* FROM users u INNER JOIN (SELECT id FROM users ORDER BY id LIMIT 10000, 20) t ON u.id = t.id - 子查询只查 id（索引覆盖），速度快；外层再通过主键回表，比全字段扫描高效得多
避免深分页 + 合理限制前端页码
用户翻到第 500 页大概率不是刚需，而是搜索不准或筛选太宽。与其硬扛性能，不如主动干预：
- 后端对 OFFSET > 10000 的请求直接返回错误或提示“请调整筛选条件”
- 前端禁用“跳转到第 N 页”输入框，改用“加载更多”或“上一页/下一页”按钮
- 结合搜索与筛选（如按时间范围、状态、关键词）大幅缩小结果集，让分页天然落在浅层
不复杂但容易忽略：分页优化不是调个参数的事，关键是把“基于位置”的思维转向“基于值”的思维——用数据本身的有序性代替机械跳数。
