SQL Server中分组汇总后必须在外层显式添加ORDER BY，且排序字段须为SELECT列表中的列或其别名，否则OFFSET FETCH报错；子查询内ORDER BY无效，性能上应避免大偏移量聚合排序。
分组汇总后必须显式加 ORDER BY，否则 OFFSET FETCH 报错
OFFSET FETCH 不能直接作用于 GROUP BY 结果集——SQL Server 要求 ORDER BY 必须出现在最外层，且排序字段必须是 SELECT 列表中明确出现的列（或其别名），不能是聚合表达式以外的原始列。
常见错误写法：SELECT dept, COUNT(*) AS cnt FROM employees GROUP BY dept OFFSET 0 ROWS FETCH NEXT 10 ROWS ONLY;
直接报错：Invalid usage of the option NEXT in the FETCH statement，因为缺 ORDER BY。
- 正确做法：把排序逻辑拉到最外层，且排序字段必须在 SELECT 中可见，例如
ORDER BY cnt DESC或ORDER BY dept - 不能写
ORDER BY COUNT(*)—— 聚合函数在 ORDER BY 中允许，但必须和 SELECT 列表一致；如果 SELECT 用了别名，ORDER BY 就得用别名 - 如果想按“部门人数降序 + 部门名升序”复合排序，写成
ORDER BY cnt DESC, dept ASC即可，无需在 GROUP BY 里重复声明
嵌套查询里 GROUP BY + OFFSET FETCH 容易漏掉外层 ORDER BY
有人会把分组逻辑包进子查询，以为里面排好序就完事了，结果还是报错。比如：
SELECT * FROM (SELECT dept, COUNT(*) cnt FROM employees GROUP BY dept ORDER BY cnt DESC) t OFFSET 0 ROWS FETCH NEXT 5 ROWS ONLY;
这句依然失败——子查询里的 ORDER BY 对外层 OFFSET FETCH 无效，SQL Server 只认最终结果集的排序。
- 必须把
ORDER BY拿出来，放到最外层：SELECT * FROM (SELECT dept, COUNT(*) cnt FROM employees GROUP BY dept) t ORDER BY t.cnt DESC OFFSET 0 ROWS FETCH NEXT 5 ROWS ONLY; - 子查询里可以留
ORDER BY，但它只影响子查询执行计划（比如触发索引扫描），不参与分页排序逻辑 - 如果子查询含 JOIN 或过滤，确保外层
ORDER BY字段在子查询 SELECT 中存在且未被计算破坏（如UPPER(dept)后再按dept排序就失效）
按聚合值排序时，索引无法直接加速，性能要提前评估
GROUP BY 本身不产生物理排序，ORDER BY COUNT(*) 这类操作必然触发 Sort 算子，尤其数据量大时，OFFSET 10000 ROWS 会先算出全部分组再跳过前 10000 行，内存和 CPU 压力陡增。
- 没有针对
COUNT(*)的索引，所以别指望靠索引跳过排序阶段 - 如果业务允许，优先考虑用确定性排序字段替代聚合值，例如按
MAX(last_login)分页，且该字段有索引 - 千万级分组结果下，OFFSET 分页基本不可行；真要分页，得改用游标式（
WHERE last_login + <code>TOP 10）
存储过程传参时，OFFSET/FETCH 不接受表达式，变量需预计算
写分页存储过程时，常想直接写 OFFSET (@page - 1) * @size ROWS，但 SQL Server 不允许。
报错信息通常是：Incorrect syntax near '*' 或 Must declare the scalar variable（取决于上下文）。
- 必须拆成两步：
DECLARE @offset INT = (@page - 1) * @size;，再用OFFSET @offset ROWS -
FETCH NEXT同理，@size可直接用，但FETCH NEXT (@size) ROWS ONLY是非法语法 - 注意
@offset不能为负数，建议加校验：IF @offset
分组汇总分页真正卡点不在语法，而在排序字段是否可索引、OFFSET 是否过大、以及表达式能否被参数化——这些地方一松懈，查十页就超时。
