MySQL OFFSET越大越慢的根本原因是其需逐行扫描跳过前N行，InnoDB无法直接定位第N+1行；应优先用游标分页替代，确保ORDER BY字段有索引，并避免深度分页。
MySQL OFFSET 越大越慢的根本原因
不是 LIMIT 本身慢，是 OFFSET 强制数据库跳过前 N 行——哪怕你只要 1 条，它也得先扫描、计数、丢弃那 N 行。InnoDB 没有“直接跳到第 100001 行”的索引能力，只能靠主键或索引顺序挨个数。
常见错误现象：SELECT * FROM orders ORDER BY created_at DESC LIMIT 10 OFFSET 100000 响应从 20ms 暴涨到 2s+；EXPLAIN 显示 rows 字段远大于实际返回行数。
- 必须确保
ORDER BY字段有有效索引（比如created_at单独索引或联合索引最左前缀） - 避免在
WHERE条件里用非索引字段过滤后再分页，否则索引失效，OFFSET 成为全表扫描加速器 - 如果业务允许，把
OFFSET换成游标（cursor-based pagination），用上一页最后一条的created_at和id作为下一页起点
PostgreSQL 中 cursor 分页怎么写才不翻车
PostgreSQL 支持 WHERE (col1, col2) > (val1, val2) 这种“行级比较”，是真正高效的游标分页基础。但必须注意字段顺序、NULL 处理和唯一性保障。
使用场景：后台列表无限滚动、API 分页接口、避免因数据插入导致的重复或漏读。
-
ORDER BY created_at DESC, id DESC对应的游标条件必须写成WHERE (created_at, id) （注意方向一致） - 所有参与游标的字段都不能为
NULL，否则(a, b) > (NULL, 1)结果不确定；建表时加NOT NULL约束或用COALESCE预处理 - 强烈建议把主键（如
id）加入游标组合，防止created_at重复时排序不稳定
SQL Server 的 OFFSET FETCH 性能陷阱
OFFSET ... FETCH NEXT 看似标准，但在 SQL Server 2012+ 中，如果没配对使用 ORDER BY 的确定性排序，执行计划可能退化成堆扫描，甚至返回乱序结果。
参数差异：OFFSET 0 ROWS FETCH NEXT 20 ROWS ONLY 是合法起点，但 OFFSET 为变量时（如 @offset），SQL Server 有时无法复用执行计划，导致编译开销上升。
- 必须保证
ORDER BY子句包含足够唯一性的列组合，例如ORDER BY updated_at DESC, id DESC - 避免用
OFFSET @page * @size动态算偏移量——改用游标模式，传入上一页末尾的updated_at和id - 如果实在要用 OFFSET，考虑加
OPTION (RECOMPILE)让每次生成适配参数的执行计划（仅限参数变化频繁且数据分布不均时）
为什么不能只靠加索引解决深分页
加索引能缓解，但治标不治本。比如给 status, created_at 加联合索引，WHERE status = 'paid' ORDER BY created_at DESC LIMIT 10 OFFSET 50000 仍可能慢——因为索引只能快速定位 status = 'paid' 的块，但 OFFSET 还是要在这些块里逐行跳。
性能影响：当满足条件的数据占表比例高（比如 30%），索引扫描 + 跳行成本 ≈ 全表扫描；更糟的是，这种查询容易挤占 buffer pool，拖慢其他查询。
- 优先评估是否真需要“跳到第 500 页”——多数产品场景下，用户根本不会翻那么深，后端可限制
OFFSET最大值（如 2000）并返回空结果 - 对导出类需求，改用主键范围分片：先
SELECT MIN(id), MAX(id) FROM table，再按每 10000 条切分WHERE id BETWEEN ? AND ? - 搜索类分页，把深度分页交给 Elasticsearch 或类似引擎，SQL 只负责精准 ID 拉取
游标分页的边界情况最易被忽略：时间字段精度不足（秒级 created_at 在高并发下大量重复）、时钟回拨、跨库时区不一致——这些都会让游标“跳空”或“重复”。上线前一定用真实写入压力测一遍游标连续性。
