OFFSET FETCH 在大数据量下越来越慢，因为其本质是顺序扫描并跳过前N行，而非直接定位，导致I/O与CPU开销随offset线性增长，即使有索引也无法规避该过程。
OFFSET FETCH 在大数据量下为什么越来越慢
因为 OFFSET 不是“跳到第 N 行”，而是“从头开始数，跳过前 N 行”。哪怕你只要第 100001 条，SQL Server 也得把前面 10 万条全扫描、排序、计数一遍。索引再好，也挡不住这种顺序位移式扫描。
常见错误现象：OFFSET 100000 ROWS FETCH NEXT 20 ROWS ONLY 耗时突然从 50ms 涨到 2s+；配合 ORDER BY created_at（非主键、无索引）时更卡，甚至超时。
- 必须有
ORDER BY，且排序字段最好为主键或带覆盖索引的列 - 页码越大，耗时几乎线性增长——翻到 page=5000 基本不可用
- 不适用于导出、后台报表、用户手动输入页码等场景
ROW_NUMBER() 分页不是性能银弹，关键在索引和写法
很多人以为换用 ROW_NUMBER() 就能解决卡顿，结果发现更慢了。问题不在函数本身，而在执行路径：如果 ORDER BY id 没索引，或者查询列太多导致无法走覆盖索引，数据库照样要全表扫描+内存排序。
正确写法示例（SQL Server）：
SELECT id, name, status
FROM (
SELECT id, name, status,
ROW_NUMBER() OVER (ORDER BY id) AS rn
FROM orders WITH (NOLOCK)
) t
WHERE rn BETWEEN 100001 AND 100020;
- 确保
ORDER BY字段（如id）上有索引，最好是聚集索引 - 外层
WHERE必须用BETWEEN或>= AND ，不能写成rn = @target单值（优化器无法推导范围） - 避免在子查询里查 *，只选真正需要的列，否则覆盖索引失效，触发回表
真正有效的替代方案：游标分页（Keyset Pagination）
如果你能接受“只能上下翻页、不能跳页”，WHERE id 这种方式比 ROW_NUMBER() 和 OFFSET 都快一个数量级——因为它直接利用索引范围扫描，完全绕过排序编号过程。
适用前提很明确：
- 排序字段（如
id或created_at）必须有唯一、非空、已建索引 - 复合排序（如
ORDER BY status, created_at）时，WHERE要写成WHERE (status, created_at) - 前端必须禁掉页码输入框，只提供“下一页”按钮，并把上一页最后一条的
id传回来
典型错误：用 created_at 分页但没处理时间重复问题，导致漏数据或重复——此时必须加二级排序字段（如 id）保证唯一性。
什么时候该坚持用 OFFSET FETCH
不是所有场景都要淘汰 OFFSET。它在 SQL Server 2012+ 上语法简洁、语义清晰，且对小偏移量（OFFSET ）其实足够快。
- 前端下拉加载前 10–20 页（比如 feed 流），用户几乎不会翻到第 100 页
- 后台任务中固定取前几批（如每批 1000 条做异步处理），偏移量可控
- 表数据量小（ORDER BY 字段有强索引时，
OFFSET反而比ROW_NUMBER()执行计划更稳定
最容易被忽略的一点：即使你用了 ROW_NUMBER()，如果排序字段没有索引，SQL Server 仍可能选择哈希匹配或溢出到 tempdb 排序——这时候慢的不是分页逻辑，是底层缺失的索引设计。
