sql server 不允许 group by 后直接使用 offset fetch，因执行顺序为 group by → having → select → order by → offset → fetch，offset 必须作用于排序后的最终结果集，且 order by 必须在外层显式声明并引用输出列；正确做法是用 cte 或子查询封装聚合逻辑，外层负责排序和分页。
不能直接在 GROUP BY 后写 OFFSET FETCH —— SQL Server 会报错“OFFSET cannot be used with GROUP BY”。 原因不是语法偷懒，而是执行逻辑不允许：GROUP BY 产出的是聚合行，而 OFFSET/FETCH 必须作用于最终排序后的完整结果集，二者阶段不匹配。
为什么 GROUP BY + OFFSET FETCH 会报错
SQL Server 强制执行顺序是 GROUP BY → HAVING → SELECT → ORDER BY → OFFSET → FETCH。如果你把 OFFSET 写在 GROUP BY 后面但没套子查询，解析器根本找不到合法的 ORDER BY 上下文，直接抛出：
Msg 102, Level 15, State 1, Line X<br>Incorrect syntax near 'OFFSET'.
-
ORDER BY必须出现在最外层查询，且排序列必须是输出列（如Department）或明确聚合表达式（如COUNT(*)） - 不能对未出现在
GROUP BY中的原始列排序（比如ORDER BY created_at），除非它也在分组键里 - 漏写
ONLY关键字也会报错：FETCH NEXT 10 ROWS不合法，必须是FETCH NEXT 10 ROWS ONLY
正确做法：用 CTE 或子查询封装 GROUP BY 结果
把聚合逻辑关进内层，外层只负责排序和分页。这是唯一可靠、兼容 SQL Server 2012+ 的方式。
- CTE 更易读，适合多层逻辑；子查询更通用，嵌套视图也支持
-
HAVING过滤必须放在内层（如HAVING COUNT(*) >= 5），放外层会报错或语义错误 - 外层
ORDER BY只能引用 CTE 输出列，例如ORDER BY emp_count DESC，不能写ORDER BY COUNT(*) DESC（该表达式不在输出中） - 示例（查员工数 ≥ 5 的部门，按人数降序取第 2 页，每页 10 条）：
WITH dept_counts AS (<br> SELECT Department, COUNT(*) AS emp_count<br> FROM Employees<br> GROUP BY Department<br> HAVING COUNT(*) >= 5<br>)<br>SELECT Department, emp_count<br>FROM dept_counts<br>ORDER BY emp_count DESC<br>OFFSET 10 ROWS FETCH NEXT 10 ROWS ONLY;
性能陷阱：深分页时 OFFSET 越大越慢
即使加了索引，OFFSET 100000 ROWS 仍要逻辑扫描并跳过前 10 万 + N 行——不是索引 seek，而是 index scan + skip。执行计划里“实际行数”会远高于返回行数。
- 确保
ORDER BY列（如Department）有索引；若还涉及emp_count，考虑覆盖索引：CREATE INDEX ix_dept_count ON Employees(Department) INCLUDE (emp_count) - 避免
ORDER BY UPPER(Department)这类表达式，索引失效 - 查第 500 页？别硬扛
OFFSET。改用键集分页：记下上一页最后的emp_count和Department，用WHERE emp_count @last_dept)+ORDER BY emp_count DESC, Department
真正容易被忽略的不是怎么写，而是忘了检查执行计划里的「实际行数」——它暴露了 OFFSET 背后真实的 I/O 开销。哪怕语法全对，偏移量一大，查询就悄悄变慢。
