子查询分页必须将过滤条件下推至子查询内部，确保OFFSET跳过的是已过滤后的行；ORDER BY必须置于最外层且字段需直接来自子查询结果集，不可为函数或表达式结果。
子查询里必须把过滤条件下推，否则OFFSET跳过的是全表行数
大表分页慢，常因子查询没做有效过滤，导致外层 OFFSET 实际跳过的是未过滤前的全部行。比如查“已支付订单”，若把 WHERE status = 'paid' 放在外层，子查询会先拉出所有订单再排序编号，OFFSET 10000 就得扫描并丢弃前一万行——哪怕最终只返回10条。
正确做法是把关键过滤条件塞进子查询内部：
- JOIN 条件、状态筛选、时间范围等尽量写在子查询的
WHERE或ON中 - 避免在子查询里只写
SELECT *，而应明确投影需要的列（减少内存和网络开销） - 如果子查询含聚合或计算列，确保外层
ORDER BY引用的字段在子查询中是原始列或有对应索引的计算列
ORDER BY 字段必须来自子查询输出，且不能被函数包裹
OFFSET/FETCH 要求最外层 ORDER BY 的字段必须出现在子查询结果集中，且不能是表达式结果。常见翻车点是：子查询里写了 UPPER(name)，外层却按 name 排序——SQL Server 不认这个 name 是可索引列，直接退化为排序临时表。
验证方式很简单：执行子查询本身，看 ORDER BY 那一列是否原样存在、类型一致、未被转换：
- ✅ 正确：
SELECT id, name, created_at FROM orders WHERE status = 'paid'→ 外层ORDER BY created_at DESC - ❌ 错误：
SELECT id, UPPER(name) AS name, created_at FROM ...→ 外层ORDER BY name（UPPER()破坏索引可用性） - ⚠️ 危险：
SELECT id, DATEADD(day, 1, created_at) AS dt FROM ...→ 外层ORDER BY dt（无法走created_at索引）
嵌套层级别超过一层，ORDER BY 必须落在最外层查询
SQL Server 只认最终结果集的排序，子查询甚至 CTE 内部的 ORDER BY 对 OFFSET/FETCH 完全无效。很多人写成这样：
SELECT * FROM ( SELECT id, title FROM posts ORDER BY publish_time DESC ) t OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY;
直接报错：Invalid usage of the option NEXT in the FETCH statement。因为外层没 ORDER BY，子查询里的排序只是“装饰”。
必须把排序提到最外层：
- CTE 方式：
WITH paged AS (SELECT id, title, publish_time FROM posts WHERE published = 1) SELECT * FROM paged ORDER BY publish_time DESC OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY - 子查询方式：
SELECT * FROM (SELECT id, title, publish_time FROM posts WHERE published = 1) t ORDER BY t.publish_time DESC OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY - 注意：子查询别名
t后必须加空格再写ORDER BY，不能连写成tORDER BY（语法错误）
OFFSET 参数不能是表达式，存储过程里要提前算好变量
在存储过程中传参时，OFFSET 和 FETCH 后面只接受变量名或字面量，不支持 (@page - 1) * @size 这类表达式。下面这句会报错：
OFFSET (@page - 1) * @size ROWS
必须拆成两步：
- 先声明并计算偏移量：
DECLARE @offset INT = (@page - 1) * @size; - 再在查询中使用：
OFFSET @offset ROWS FETCH NEXT @size ROWS ONLY - 如果涉及动态 SQL（如拼接
WHERE条件），也要确保@offset和@size是已赋值的变量，而非字符串拼进去
深分页（比如 OFFSET 100000）本身就会导致性能陡降，无论怎么优化子查询，都绕不开索引扫描+跳行的开销。真要支撑百万级偏移，得考虑游标分页或基于上一页末尾值的 keyset 分页——OFFSET 不是万能解药，只是语法糖。
