先说一个常见的坑：聚合查询做完 GROUP BY 之后，想直接加 OFFSET FETCH 分页——数据库大概率直接甩你一脸错误，或者更隐蔽地返回错乱数据。这并不是语法上的小问题，而是 SQL 执行顺序的硬约束。
来看核心原因：SQL 的执行顺序是 GROUP BY → HA VING → SELECT → ORDER BY → OFFSET → FETCH。如果你在 GROUP BY 阶段就试图放 OFFSET，或者干脆漏掉 ORDER BY，SQL Server 会直接报类似 Invalid usage of the option NEXT 或者 ORDER BY is required 的错误。还有一种更隐蔽的情况：ORDER BY 引用了聚合表达式（比如 ORDER BY SUM(amount)），但外层 SELECT 没给这个表达式起别名——那排序依据在逻辑上“不可见”，同样会报错。
聚合后分页的正确姿势：子查询 / CTE 封装
最通用也最稳妥的方案，兼容 SQL Server 2012+、PostgreSQL、Oracle 12c+：把聚合结果先用子查询或 CTE 包一层，外层再做排序和分页。
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, category OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY;
- 子查询必须带别名（比如
AS grouped），否则 SQL Server 会报Incorrect syntax near 'OFFSET'。 ORDER BY一定要引用外层的列名（total_sales），不能直接写原始表达式（SUM(amount)）。- 建议加二级排序（比如
category），避免相同total_sales值导致分页结果不稳定——翻页时前后不一致就尴尬了。
兼容老版本或复杂排序：用 ROW_NUMBER()
如果你还在用 SQL Server 2005/2008，或者需要按多个聚合指标组合排序（例如先按 COUNT(*) 降序，再按 A VG(price) 升序），那 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 COUNT(*) DESC, SUM(amount) DESC
) AS rn
FROM orders
GROUP BY category
) AS ranked
WHERE rn BETWEEN 21 AND 30
ORDER BY rn;
ROW_NUMBER()的OVER子句里可以自由组合聚合表达式，灵活性远高于OFFSET FETCH。- 注意外层
WHERE过滤的是行号，不是原始数据；而且必须保留ORDER BY rn来保证输出顺序。 - 性能上，
ROW_NUMBER()会为全量聚合结果编号，数据量大时比OFFSET FETCH更消耗内存——不过对于大多数业务场景，这点代价可以接受。
真正容易翻车的点：语义一致性
语法写对了，不等于分页就可靠。聚合分页真正的难点不在语法，而在数据的变化：
- 前端翻页时，如果后台有实时数据变更（比如新订单插入、销售额更新），两次请求之间聚合值变了，排序位置就会动，导致某些
category被跳过或重复。 OFFSET分页本质是“基于位置”，不是“基于内容”。要稳定分页，要么配合快照隔离级别（SNAPSHOT ISOLATION），要么在应用层缓存聚合结果。- 如果聚合字段基数很低（比如总共只有 5 个
category），你OFFSET 20会直接返回空集，但错误不明显——得靠业务逻辑校验页码合法性，或者提前判断总页数。
总之，聚合后分页的核心就三步：先聚合，再排序，最后截取。别走捷径，用子查询或 CTE 包一层，顺手加上二级排序，分页结果就稳了。
