group by后limit“随机”返回几组，是因为limit作用于无序的分组结果集，而group by本身不保证顺序；必须显式添加order by（且仅能引用select中的分组列或聚合字段）才能控制返回哪几组。
GROUP BY 后 LIMIT 为什么总“随机”返回几组
因为 LIMIT 作用的是 GROUP BY 聚合后的结果集，而这个结果集本身没有顺序保证。数据库不会自动按分组列、主键或插入顺序排列分组结果——哪怕你写 GROUP BY id，也不等于“按 id 排序输出”。执行顺序是 GROUP BY → ORDER BY → LIMIT，中间缺了 ORDER BY，LIMIT 就只能从一堆无序的组里随便抓几条。
常见错误现象：
-
SELECT category, COUNT(*) FROM products GROUP BY category LIMIT 3本意是取销量 Top 3，实际每次跑都可能返回不同三个 category - 加了
ORDER BY COUNT(*) DESC却没加二级排序字段，当多个 category 的 COUNT 相同时，LIMIT 返回哪几组仍不可控
ORDER BY 必须引用 SELECT 中出现的字段
在 GROUP BY 查询中，ORDER BY 只能用 SELECT 列表里的内容（包括别名），不能引用原始表中未被选中的字段。比如下面这句会报错：
SELECT category, COUNT(*) FROM products GROUP BY category ORDER BY created_at DESC;
因为 created_at 没出现在 SELECT 中，也不属于分组列或聚合函数结果。MySQL 5.7+ 开启 only_full_group_by 后尤其严格。
正确做法：
- 想按“每个 category 最早创建时间”排序 → 写
ORDER BY MIN(created_at) - 想按“首次出现顺序”模拟 → 用
ORDER BY MIN(id)或MIN(created_at) - 需要稳定排序 → 在
ORDER BY末尾追加唯一字段，如ORDER BY COUNT(*) DESC, category（前提是 category 唯一）或ORDER BY COUNT(*) DESC, MIN(id)
LIMIT 出现在 GROUP BY 前面直接语法报错
MySQL 不允许把 LIMIT 放在 GROUP BY 中间或之前。语句结构必须严格遵循：SELECT → FROM → WHERE → GROUP BY → HAVING → ORDER BY → LIMIT。写成这样会触发 ERROR 1064：
SELECT category, COUNT(*) FROM products LIMIT 5 GROUP BY category;
如果真想“先取部分数据再分组”，得用子查询：
SELECT category, COUNT(*) FROM (SELECT * FROM products LIMIT 1000) AS tmp GROUP BY category;
但注意：子查询里没 ORDER BY 时，LIMIT 1000 行为不可预测——InnoDB 不保证物理存储顺序，所以这个“前1000行”每次可能都不一样。
分页查分组结果时 OFFSET 容易失效
写 LIMIT 10,5 查第 2 页，前提是分组总数 ≥15。如果只有 12 个 category，LIMIT 10,5 就返回空——这不是 bug，是设计如此。更麻烦的是，分组数随数据实时变化，昨天有 15 组，今天删了两组，同一页就突然变空或跳变。
比 OFFSET 更稳的做法：
- 游标分页：记录上一页最后一个
category值，下一页查WHERE category > 'last_seen' ORDER BY category LIMIT 5 - 避免大 offset：像
LIMIT 10000,20这种，MySQL 仍要扫描前 10000 组结果，性能差 - 如果必须用 offset，务必和
ORDER BY绑定，且二级字段要唯一，否则 offset 的语义根本不确定
最常被忽略的一点：分组后排序依据只能是聚合值或分组列，没法直接按“每组里某条明细记录的字段”排序——那种需求得换窗口函数，而不是硬塞 ORDER BY。
