OFFSET FETCH 不能直接用于含 GROUP BY 的顶层查询，必须用 CTE 或子查询封装聚合逻辑后在外层排序分页，且外层 ORDER BY 需含确定性字段以避免分页错位。
OFFSET FETCH 不能直接用于 GROUP BY 查询
SQL 标准里，OFFSET FETCH 必须出现在查询的最外层、且该查询不能含 GROUP BY —— 否则会报错，比如 SQL Server 报 "ORDER BY is required for OFFSET and FETCH"，而即使加了 ORDER BY，也常因聚合后结果集无明确排序依据导致行为不稳定。
根本原因是：分组聚合（如 COUNT()、SUM()）输出的是逻辑上“已归并”的行，OFFSET FETCH 是对最终结果集做物理偏移，二者语义层级不同。想“先分组再分页”，得把聚合作为子查询或 CTE 来封装。
用 CTE 或子查询包裹 GROUP BY，再对外层应用 OFFSET FETCH
正确做法是把聚合逻辑放在内层（CTE 或子查询），外层只负责排序和分页。注意三点：
- 外层
ORDER BY必须包含确定性排序字段（推荐用聚合键 + 聚合函数结果，如category, COUNT(*) DESC） - 若聚合键有重复值（如多个 category 值相同），必须补上唯一列（如主键或
ROW_NUMBER() OVER(...)）避免分页错位 - SQL Server 要求外层
ORDER BY与OFFSET FETCH共存；PostgreSQL 支持LIMIT/OFFSET但同样不许在含GROUP BY的顶层直接用
示例（SQL Server）：
WITH grouped AS ( SELECT category, COUNT(*) AS cnt FROM products GROUP BY category ) SELECT category, cnt FROM grouped ORDER BY category, cnt DESC OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY;
分页跳过大量数据时，COUNT(*) OVER() 会拖慢性能
如果还需要返回总记录数（比如实现「共 XX 条」），别在每页都跑 COUNT(*) OVER() —— 它会让引擎重扫全表做窗口计数，尤其在大表分组场景下代价极高。
更务实的做法：
- 单独缓存总分组数（如用物化视图、或定时写入配置表）
- 前端用“下一页是否有数据”代替总数（查第 N 页时多取 1 行，有则说明还有下一页）
- 若必须总数，用
SELECT COUNT(*) FROM (SELECT 1 FROM products GROUP BY category) t，比窗口函数轻量
MySQL 用户注意：8.0+ 才支持 OFFSET FETCH，旧版只能用 LIMIT offset, size
MySQL 在 8.0 前不支持 OFFSET FETCH 语法，且其 LIMIT offset, size 对含 GROUP BY 的查询同样受限：必须确保 ORDER BY 字段在 SELECT 列表中（SQL mode 严格时）。常见报错是 "Expression #1 of ORDER BY clause is not in SELECT list"。
解决方法：
- 显式写出排序字段：
SELECT category, COUNT(*) AS cnt FROM products GROUP BY category ORDER BY category LIMIT 20, 10 - 若用
ORDER BY COUNT(*)，需补别名并在 SELECT 中出现：SELECT category, COUNT(*) AS cnt FROM products GROUP BY category ORDER BY cnt DESC LIMIT 20, 10
分组分页真正的难点不在语法拼接，而在排序键是否稳定、总数统计是否可承受、以及不同数据库对“GROUP BY + 分页”组合的隐式约束。漏掉任意一个，翻到第 100 页时数据就可能重复或丢失。
