group by后直接加limit只能限制分组数量而非每组记录数，因其执行顺序在group by之后、作用于聚合后的结果集；需配合order by实现可控分页，或用窗口函数实现每组取前n条。
GROUP BY 后直接加 LIMIT 为什么不行
因为 SQL 执行顺序是 FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT，LIMIT 在最后执行，它截的是最终结果行数，不是“每组取前 N 条”。如果你写 SELECT a, COUNT(*) FROM t GROUP BY a LIMIT 10，得到的是任意 10 个分组，不是某组内前 10 条记录——这根本不是你想要的“对聚合结果分页”。
想分页看“前 10 个分组”，用子查询套一层
这是最常见也最稳妥的做法：先完成 GROUP BY 和排序，再对外层结果应用 LIMIT 和 OFFSET。
比如查销量 Top 10 的商品类别：
SELECT category, SUM(sales) AS total_sales FROM orders GROUP BY category ORDER BY total_sales DESC LIMIT 10 OFFSET 0;
注意点：
-
ORDER BY必须明确写在GROUP BY之后、LIMIT之前，否则排序不可靠 -
OFFSET是分页关键：OFFSET 20表示跳过前 20 行（即第 3 页，每页 10 条） - MySQL 8.0+、PostgreSQL、SQL Server 都支持这种写法；SQLite 也支持，但旧版可能不支持
OFFSET
想“每组内取前 N 条原始记录”，得用窗口函数
这其实是另一个常见误解：用户说“对 GROUP BY 结果 LIMIT”，实际想要的是“按某字段分组后，每组取最新/最高分的 3 条原始数据”。这时候不能靠 GROUP BY + LIMIT，必须用 ROW_NUMBER() 等窗口函数。
例如：每个部门薪资最高的 2 名员工
SELECT dept, name, salary
FROM (
SELECT dept, name, salary,
ROW_NUMBER() OVER (PARTITION BY dept ORDER BY salary DESC) AS rn
FROM employees
) ranked
WHERE rn
<p>关键区别：</p>
-
PARTITION BY dept对应GROUP BY dept的逻辑分组 -
ROW_NUMBER()给每组内记录编号，不是聚合值 - 外层
WHERE rn 才是真正的“每组取前 2 条” - MySQL 8.0+、PostgreSQL、SQL Server 支持；MySQL 5.7 及更早版本不支持窗口函数，只能用变量模拟（易出错且不可靠）
性能陷阱：GROUP BY + LIMIT 在大数据量下容易慢
即使语法正确，如果表有千万级数据、分组键基数高（比如 GROUP BY user_id），GROUP BY 本身就要全量扫描+哈希聚合，LIMIT 完全无法提前终止这个过程——它只裁剪最终结果集，不减少中间计算量。
优化思路：
- 确保
GROUP BY字段上有索引（尤其是复合索引，含ORDER BY字段） - 避免在
GROUP BY后用非索引字段ORDER BY，否则触发 filesort - 如果只是要“近似 Top N”，可考虑采样或预聚合表（如每天跑一次汇总到
summary_daily） - PostgreSQL 用户可留意
enable_hashagg = off在某些场景下配合索引能更快返回前几行，但需实测
分页偏移越大（比如 OFFSET 100000），性能越差——这不是语法问题，是关系数据库的固有限制。真要深分页，得换方案，比如用游标（WHERE id > last_seen_id）替代 OFFSET。
