offset fetch 必须与最外层 order by 配合使用，子查询中的 order by 无效；排序字段需为原始可索引列，join 分页需联合索引；offset/fetch 参数仅支持变量或字面量，不可为表达式。
OFFSET FETCH 必须和 ORDER BY 一起用，嵌套查询也不例外
嵌套查询里加 OFFSET FETCH 不是语法错误，但容易漏掉最外层的 ORDER BY。SQL Server 不允许在没有排序的上下文中使用 FETCH，哪怕子查询里写了 ORDER BY 也不行——它只认最终结果集的排序。常见错误是这样写：
SELECT * FROM ( SELECT id, name FROM users WHERE status = 1 ORDER BY created_at DESC ) t OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY;
运行直接报错：Invalid usage of the option NEXT in the FETCH statement。因为外层没 ORDER BY，子查询里的 ORDER BY 在这里只是“无效装饰”，不参与最终排序。
正确写法必须把 ORDER BY 拉到最外层：
SELECT * FROM ( SELECT id, name, created_at FROM users WHERE status = 1 ) t ORDER BY t.created_at DESC OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY;
嵌套查询中 ORDER BY 字段必须可索引，否则性能崩得比单层还快
嵌套查询常用来加过滤、聚合或 JOIN，但一旦引入 OFFSET，排序字段的索引有效性就更敏感了。如果子查询输出列不包含排序依据，或者排序字段在子查询里被函数处理（比如 ORDER BY YEAR(created_at)），SQL Server 就无法利用索引，只能全表扫描+临时排序。
- 错误示例：子查询里用了
SELECT id, UPPER(name) AS name，外层却按name排序——UPPER()破坏索引可用性 - 正确做法：确保外层
ORDER BY的字段，在子查询中是原始列或有对应计算列索引 - 特别注意：JOIN 后的排序字段，索引必须覆盖 JOIN 条件 + 排序字段，例如
orders JOIN customers ON orders.cust_id = customers.id，若按customers.name分页，就得建IX_orders_cust_name联合索引
嵌套查询传参时，OFFSET 和 FETCH 的变量不能是表达式
在存储过程中用嵌套查询分页，OFFSET 和 FETCH 后面只接受变量名或字面量，不接受表达式。下面这句会报错：
OFFSET (@page_index - 1) * @page_size ROWS
必须拆成先算变量再引用：
DECLARE @offset INT = (@page_index - 1) * @page_size; SELECT * FROM (SELECT id, title FROM posts WHERE published = 1) t ORDER BY t.id DESC OFFSET @offset ROWS FETCH NEXT @page_size ROWS ONLY;
还要注意两点：
-
@offset不能为负数，否则运行时报错；建议加校验：IF @offset -
@page_size必须 ≥ 1，且建议上限控制（如 ≤ 100），防用户传入超大值导致内存溢出 - 所有变量声明类型要匹配，
@offset用BIGINT更安全，避免INT溢出（比如@page_index = 2147483648）
深分页嵌套查询比单表还慢？不是写法问题，是 B+ 树物理限制
嵌套查询本身不增加分页开销，但会让 SQL Server 更难优化执行计划。当 OFFSET 很大（比如 50000），引擎仍要从索引根节点开始逐层遍历、计数跳过——嵌套层越多，中间结果集越不可预测，统计信息越不准，越容易选错执行路径。
典型表现：
- 执行计划里出现大量
Index Spool或Table Scan，即使子查询字段都有索引 - 第 1 页 15ms，第 1000 页飙升到 2s+，且 CPU 使用率持续拉满
- 加
OPTION (RECOMPILE)也无改善，说明不是参数嗅探问题
这时候换方案比调 SQL 更有效：
- 改游标分页：记录上一页最后一条的
(created_at, id)，下一页查WHERE (created_at, id) ，嵌套查询里也能用，但必须确保该条件能走联合索引 - 缓存总数和关键页数据：后台任务预生成第 1/10/50/100 页的 ID 列表，前端翻页直接查缓存
- 拒绝任意跳页：在存储过程开头加硬限制，
IF @page_index > 500 THROW 50000, 'Page out of range', 1
嵌套查询加 OFFSET FETCH 看似灵活，但每多一层逻辑，就越依赖执行计划稳定性。真正压测过的分页，往往回归到“简单子查询 + 强制索引提示 + 游标替代”这套组合拳。
