OFFSET FETCH 不能直接用于 GROUP BY 结果集，必须用 CTE 或子查询包裹分组查询，外层再加 ORDER BY 和 OFFSET/FETCH；HAVING 过滤须在内层，ORDER BY 列需有索引以保障分页性能。
OFFSET FETCH 不能直接用于 GROUP BY 结果集
你无法在 GROUP BY 后直接写 OFFSET 和 FETCH，SQL Server 会报错："OFFSET cannot be used with GROUP BY"。这是因为 OFFSET/FETCH 是 ORDER BY 的从属子句，而 GROUP BY 查询的逻辑结果是聚合行，不是原始行序列；分页操作必须作用于最终排序后的完整结果集，而非中间聚合态。
想对分组结果分页？必须用 CTE 或子查询包裹
正确做法是把 GROUP BY 查询作为内层，外层再加 ORDER BY + OFFSET/FETCH。例如统计每个部门员工数并分页显示：
WITH dept_counts AS ( SELECT Department, COUNT(*) AS emp_count FROM Employees GROUP BY Department ) SELECT Department, emp_count FROM dept_counts ORDER BY Department OFFSET 0 ROWS FETCH NEXT 10 ROWS ONLY;
-
GROUP BY必须在 CTE 或子查询中完成，不能出现在最外层 -
ORDER BY必须作用于外层结果，且排序列必须来自dept_counts（如Department），不能是原始表字段 - 如果要按计数降序分页，就把
ORDER BY emp_count DESC
分组后分页性能差？关键在 ORDER BY 列是否有索引
CTE 包裹后看似解决了语法问题，但性能可能陡降——尤其当分组结果很大时，OFFSET 1000 ROWS 仍需扫描并跳过前 1000 行聚合结果。这时瓶颈不在分组本身，而在外层排序的物理实现：
- 确保
ORDER BY所用列（如上面的Department）上有索引，最好是覆盖索引（含emp_count） - 避免在
ORDER BY中使用表达式或函数，比如ORDER BY UPPER(Department)会导致索引失效 - 如果分组键基数高（如百万级唯一值），且只查前几页，可以接受；但若常查深页（如第 500 页），应考虑改用键集分页（记录上一页最大
Department值，用WHERE Department > @last_dept替代OFFSET）
带 HAVING 的分组分页，过滤顺序不能错
如果你需要先过滤分组结果（比如只看员工数 ≥ 5 的部门），HAVING 必须放在 CTE 内部，而不是外层：
WITH dept_counts AS ( SELECT Department, COUNT(*) AS emp_count FROM Employees GROUP BY Department HAVING COUNT(*) >= 5 -- ✅ 正确：在聚合后过滤 ) SELECT Department, emp_count FROM dept_counts ORDER BY emp_count DESC OFFSET 0 ROWS FETCH NEXT 10 ROWS ONLY;
若把 HAVING 条件挪到外层 WHERE，会报错或语义错误——因为 emp_count 是聚合列，外层无法直接引用未在 GROUP BY 中出现的原始列做条件，更无法对聚合别名做 WHERE 过滤。
真正麻烦的是：分组结果集不可预测大小，OFFSET 跳过的“行”是聚合后的逻辑行，和原始数据量无直接换算关系；调试时容易误以为页码对应原始表偏移，其实完全不是一回事。
