OFFSET越大查询越慢是因数据库需扫描offset+size行再丢弃前offset行；索引仅加速起点定位，无法跳过扫描；应改用基于排序键的游标分页替代。
OFFSET 越大，查询越慢不是错觉
MySQL 和 PostgreSQL 里用 LIMIT offset, size 做分页，当 offset 超过几万行，响应时间会陡增。这不是数据库“卡”，而是它真得从头扫 offset + size 行数据，再丢掉前 offset 行——索引只能加速定位起点，但无法跳过扫描。
常见错误现象：SELECT * FROM orders ORDER BY created_at DESC LIMIT 100000, 20 执行要 2 秒以上，而 LIMIT 0, 20 只要 5ms。
- 适用场景：后台管理列表翻到很深页码（比如第 5000 页），或导出中间段数据
- 别依赖
OFFSET做深分页，尤其在高并发读场景下 - 如果必须用，确保
ORDER BY字段有覆盖索引，且不包含SELECT *中的非索引列（避免回表放大扫描代价）
用游标分页替代 OFFSET（推荐方案）
游标分页本质是“记住上一页最后一条的排序键值”，下一页直接查 WHERE sort_key 。它绕开偏移量扫描，性能稳定，且天然支持无状态服务部署。
使用场景：API 分页（如 /api/items?cursor=12345&limit=20）、实时 feed 流、审计日志滚动加载。
- MySQL 示例：
SELECT * FROM events WHERE id （假设 <code>id是主键且递增） - PostgreSQL 注意：如果排序字段有重复值（如多个记录
created_at相同），必须加唯一辅助字段（如id）做二级排序：ORDER BY created_at DESC, id DESC - 前端需保存并透传上一页末尾的完整游标值（多个字段时拼成字符串或 base64 编码），不能只传单个 ID
WHERE + ORDER BY + LIMIT 组合必须走索引
即使不用 OFFSET，如果 WHERE 条件没走索引，或者 ORDER BY 字段不在索引中，查询仍可能全表扫描——游标分页也救不了。
常见错误现象：执行 EXPLAIN 显示 type=ALL 或 Extra 里有 Using filesort 或 Using temporary。
- 复合索引顺序很重要：先写
WHERE等值条件字段，再写ORDER BY字段，最后可选SELECT需要的其他字段（覆盖索引） - 例如：查询
WHERE status = 'paid' ORDER BY created_at DESC，应建索引：INDEX(status, created_at)，而非INDEX(created_at, status) - 避免在
WHERE中对字段做函数操作，如WHERE DATE(created_at) = '2024-01-01'会让索引失效
count(*) 总数统计和分页其实是两回事
用户点“第 100 页”时，后端常顺手查个 COUNT(*) 回去显示“共 23489 条”。但这个总数对用户体验几乎无用，却可能拖垮整个查询——尤其当表有千万级数据时，COUNT(*) 在 InnoDB 里是逐行计数。
使用场景：管理后台需要精确总数；用户搜索结果页显示“找到约 X 条”即可满足大部分需求。
- 线上接口建议放弃精确总数，改用估算：
SHOW TABLE STATUS LIKE 'orders'查rows字段（误差可能达 40%） - 如果业务强依赖总数，考虑异步更新统计表，或用物化视图（PG 12+）/汇总表定期刷新
- 不要在分页 SQL 里套子查询算总数，例如
SELECT *, (SELECT COUNT(*) FROM t) AS total FROM t LIMIT ...—— 每页都重算一遍
游标分页看着多一步处理，但省下的不只是响应时间，还有数据库连接和缓冲池压力。最容易被忽略的是游标值的构造逻辑——当排序依据是联合字段、含 NULL、或来自 JOIN 结果时，游标必须能唯一标识一行，否则会出现漏数据或重复。
