OFFSET FETCH 在 SQL Server 2022 中可用但仅在排序字段有合适索引且 OFFSET 值较小时高效；必须与最外层 ORDER BY 配合使用，排序字段需为原始列并覆盖 JOIN 条件，OFFSET 参数须为变量或字面量，深度分页应改用键集分页。
SQL Server 2022 中 OFFSET FETCH 能用，但“高效”只在特定条件下成立——排序字段必须有合适索引，且 OFFSET 值不能过大；否则它会扫描并丢弃大量行，性能随偏移量线性下降。
OFFSET FETCH 必须和最外层 ORDER BY 一起用
子查询或视图里写 ORDER BY 没用，SQL Server 只认最终结果集的排序。漏掉外层 ORDER BY 会直接报错：The OFFSET clause is invalid。
- 错误写法：子查询里排了序，外层没
ORDER BY—— 语法通不过 - 正确写法：把
ORDER BY明确放在最外层，且字段必须是子查询输出列的原始列（不能是函数处理后的，比如UPPER(name)） - 嵌套查询中若涉及
JOIN，排序字段的索引需覆盖连接条件 + 排序列，例如IX_orders_customer_id_created_at
OFFSET 参数不能是表达式，变量要先计算
OFFSET 和 FETCH 后面只接受变量名或字面量，不支持运行时计算表达式。直接写 OFFSET (@page - 1) * @size ROWS 会报语法错误。
- 必须提前算好偏移量：
DECLARE @offset INT = (@page - 1) * @size; - 再在查询中引用：
OFFSET @offset ROWS FETCH NEXT @size ROWS ONLY - 存储过程中建议加参数校验，避免
@offset为负数（SQL Server 允许负值但行为未定义）
深度分页（OFFSET > 10万）时性能急剧恶化
数据库必须按排序顺序逐行扫描、跳过前 N 行，中间所有行都参与排序和丢弃。这不是 bug，是物理分页的固有代价。
- 确保
ORDER BY字段有高效索引，例如CREATE INDEX idx_list ON t (status, created_at, id)（复合索引顺序要匹配查询中的等值条件 + 排序方向） - 超过 5 万行偏移后，应切换为键集分页（
WHERE created_at ），而非继续增大 <code>OFFSET - 需要总页数？别用
COUNT(*) OVER()，它强制全表扫描；改用两步：单独查COUNT(*)（走覆盖索引），再执行分页主查
视图里不能写 OFFSET FETCH
SQL Server 视图定义不支持 OFFSET 或 FETCH，编译阶段就拒绝——因为它们属于执行末端裁剪操作，破坏视图“可组合”语义。
- 视图只能做数据投影和过滤，排序和分页必须由外部查询显式添加
- 如果需要参数化分页（如传入页码），用内联表值函数（ITVF）替代视图，例如
dbo.fn_PagedProducts(@PageNumber, @PageSize) - 调用视图分页时，务必保证
ORDER BY字段有索引且非空，否则分页结果可能因排序不稳定而重复或丢失
真正容易被忽略的是：OFFSET/FETCH 的“高效”完全依赖确定性排序 + 索引下推能力。一旦排序字段上缺失索引、被函数包裹、或参与 JOIN 后无法下推，它就退化成全表扫描+内存排序——此时比 ROW_NUMBER() 还慢，因为后者至少能配合索引做部分优化。
