聚合后不能直接分页，必须先用子查询或CTE封装聚合结果，再在外层加ORDER BY + OFFSET + FETCH；因SQL执行顺序为GROUP BY→HAVING→SELECT→ORDER BY→OFFSET→FETCH，且ORDER BY必须引用输出列或明确聚合表达式。
聚合后不能直接分页，必须先完成聚合再排序，否则 OFFSET FETCH 会报错或结果错乱。
为什么聚合后直接加 OFFSET FETCH 会失败
SQL 执行顺序是：GROUP BY → HAVING → SELECT → ORDER BY → OFFSET → FETCH。但很多初学者误写成在 GROUP BY 子句里就带 OFFSET，或者漏掉 ORDER BY —— 这会导致 “Invalid usage of the option NEXT in the FETCH statement” 或 “ORDER BY is required in a query containing OFFSET” 错误。
更隐蔽的问题是：聚合字段若未出现在 ORDER BY 中（比如只按 SUM(sales) 排序，但没写明该表达式），SQL Server 会拒绝执行，因为排序依据不明确。
- 必须把聚合结果封装成子查询或 CTE，再在外层加
ORDER BY+OFFSET+FETCH -
ORDER BY字段必须是最终输出列，或明确的聚合表达式（如ORDER BY COUNT(*) DESC） - 不能对未聚合的原始列排序（如
ORDER BY order_id），除非它也在GROUP BY列表中
正确写法：用子查询包裹 GROUP BY 结果
这是最稳妥、兼容性最好的方式，适用于 SQL Server 2012+：
SELECT category, total_sales, order_count
FROM (
SELECT
category,
SUM(amount) AS total_sales,
COUNT(*) AS order_count
FROM orders
GROUP BY category
) AS grouped
ORDER BY total_sales DESC
OFFSET 20 ROWS
FETCH NEXT 10 ROWS ONLY;
注意点：
- 子查询必须有别名（如
AS grouped），否则 SQL Server 报错Incorrect syntax near 'OFFSET' -
ORDER BY必须引用外层查询的列名（total_sales），不能写SUM(amount) - 如果
category有重复聚合值，建议加二级排序（如ORDER BY total_sales DESC, category）保证分页稳定性
替代方案：用 ROW_NUMBER() 处理复杂聚合排序
当需要按多个聚合指标组合排序、或需支持 SQL Server 2005/2008 时，ROW_NUMBER() 更灵活：
SELECT category, total_sales, order_count
FROM (
SELECT
category,
SUM(amount) AS total_sales,
COUNT(*) AS order_count,
ROW_NUMBER() OVER (ORDER BY SUM(amount) DESC, COUNT(*) DESC) AS rn
FROM orders
GROUP BY category
) AS ranked
WHERE rn BETWEEN 21 AND 30;
优势和风险：
- 可直接在窗口函数里写聚合表达式（
SUM(amount)），不用提前物化 - 但全量聚合 + 全量编号，内存和 IO 开销比
OFFSET/FETCH高，尤其分组数大时 - 若分组键本身无索引，
GROUP BY阶段就可能成为瓶颈，此时加索引比换分页语法更有效
容易被忽略的性能陷阱
聚合分页真正的瓶颈往往不在分页语法本身，而在聚合阶段：
- 没给
GROUP BY字段建索引 → 每次分页都触发全表扫描 - 聚合字段含大量 NULL 或低基数（如只有 3 个
category）→ 分组后只剩几行，但OFFSET 100000仍要跳过大量空页 - 在
HAVING过滤前就做分页 → 错失提前剪枝机会；应优先用HAVING COUNT(*) > 10缩小结果集，再分页 - 返回宽聚合结果（如
STRING_AGG(product_name, ',')）→ 拉高内存占用，拖慢FETCH前的排序阶段
真正要优化的，是让聚合结果集尽可能小、尽可能快，而不是纠结 OFFSET 和 ROW_NUMBER() 谁快 5ms —— 前者慢 100ms，后者快 5ms 也没意义。
