group by 先于 limit 执行，即先完成全量分组与聚合，再对结果集限制行数；limit 不作用于中间过程，无法减少聚合计算量。
GROUP BY + LIMIT 的执行顺序决定了它必须先聚合
LIMIT 作用于 GROUP BY 之后的最终结果集，不是中间过程的“提前截断”。这意味着数据库必须先把所有满足 WHERE 条件的行完成分组、计算聚合值（如 COUNT(*)、AVG(price)），生成每组一条记录后，才应用 LIMIT 取前 N 组。哪怕你只想要 3 个分组，只要底层数据有百万行且没索引支撑，就得全量扫描+内存聚合或落盘临时表。
没索引时，MySQL 只能走外部排序（filesort）或临时表
当 GROUP BY 列无有效索引，或索引顺序不匹配（比如索引是 (status, user_id) 却写 GROUP BY user_id），MySQL 就无法利用索引有序性逐组处理。此时优化器会退化为：
- 全表扫描（
type=ALL） - 把所有行读入内存做哈希分组，或触发
Using temporary; Using filesort - 若内存不够（
tmp_table_size和max_heap_table_size不足），直接写磁盘临时表——这就是你看到#sql_*.MYD文件暴涨、磁盘满的原因
EXPLAIN 中 rows 接近总行数、Extra 出现 Using filesort 或 Using temporary，就是典型信号。
视图或子查询里加 LIMIT 并不能缓解主查询的聚合压力
很多人以为“在子查询里 LIMIT 100 再 GROUP BY”就能避免大聚合，但要注意：
- 子查询里的
LIMIT确实能减少输入行数，但前提是子查询本身不触发物化（MySQL 对含GROUP BY的视图默认走DERIVED路径，强制全量物化） - PostgreSQL 更严格：外层
LIMIT基本无法下推到含ORDER BY的视图内部，照样全量排序再截断 - 子查询没
ORDER BY时，LIMIT行为不可预测（InnoDB MVCC 下物理顺序不固定），可能每次取到不同样本，导致聚合结果漂移
真正有效的限制手段不是靠 LIMIT，而是控制聚合输入规模
想让 GROUP BY 快，核心是减少它要处理的原始行数，而不是指望 LIMIT “帮忙剪枝”：
- 确保
WHERE条件能走索引（比如用created_at >= '2026-09-01'而非YEAR(created_at) = 2026） - 给
GROUP BY列建匹配顺序的复合索引，并覆盖常用SELECT字段（如INDEX (category, COUNT(*), AVG(price))不成立，但INDEX (category, price)支持SELECT category, COUNT(*), AVG(price) FROM t GROUP BY category走覆盖索引） - 对超大表，先用主键范围过滤再聚合：
SELECT category, COUNT(*) FROM t WHERE id BETWEEN 10000 AND 20000 GROUP BY category - 业务允许时，改用近似聚合（如 HyperLogLog）或预计算汇总表，避开实时 GROUP BY
最常被忽略的一点：LIMIT 在 GROUP BY 场景里从来不是性能开关，它只是最后的“展示开关”。真正的瓶颈永远在聚合前的数据筛选和索引设计上。
