怎样在SQL Server中利用子查询优化大表分页的Offset Fetch-SQL-PHP中文网

子查询分页必须将过滤条件下推至子查询内部，确保offset跳过的是已过滤后的行；order by必须置于最外层且字段需直接来自子查询结果集，不可为函数或表达式结果。

怎样在sql server中利用子查询优化大表分页的offset fetch

大表分页慢，常因子查询没做有效过滤，导致外层 OFFSET 实际跳过的是未过滤前的全部行。比如查“已支付订单”，若把 WHERE status = 'paid' 放在外层，子查询会先拉出所有订单再排序编号，OFFSET 10000 就得扫描并丢弃前一万行——哪怕最终只返回10条。

正确做法是把关键过滤条件塞进子查询内部：

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 索引）

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（语法错误）