group by 慢因默认触发 using temporary 和 using filesort，主因是分组字段无索引或 select 含非分组/非聚合字段；需建合适联合索引（如 where+group by+order by 字段顺序）、用 any_value、sql_big_result 或窗口函数优化。
GROUP BY 执行时为什么慢？先看执行计划里的 Using filesort 和 Using temporary
MySQL 对 GROUP BY 的默认实现，常会触发临时表（Using temporary）和文件排序（Using filesort），尤其当分组字段没索引、或 SELECT 列包含非分组/非聚合字段时。这不是 bug，是语义强制：SQL 标准要求 GROUP BY 后的 SELECT 列必须函数依赖于分组键，否则 MySQL 5.7+ 严格模式下直接报错 ERROR 1055。
- 检查执行计划：
EXPLAIN SELECT ... GROUP BY ...，重点看Extra列是否出现Using temporary; Using filesort - 避免
SELECT *或混用非分组字段（如SELECT name, COUNT(*) FROM t GROUP BY dept_id中name未被聚合也未在GROUP BY中） - 若业务真需某一分组内的任意值，显式用
ANY_VALUE(name)，并确保该字段有索引支撑后续过滤
ORDER BY + GROUP BY 一起用，索引怎么建才不白搭？
当 SQL 同时含 GROUP BY a 和 ORDER BY b，MySQL 无法复用同一个索引同时满足两者——除非 b 是 a 的后缀列（即联合索引顺序为 (a, b)）。否则，GROUP BY 可能走 (a) 索引完成分组，但 ORDER BY b 仍要回表或排序。
- 最优索引策略：建
(a, b)联合索引，且确保SELECT中所有非聚合字段都来自该索引覆盖范围（避免回表） - 如果
ORDER BY是降序（ORDER BY b DESC），MySQL 8.0+ 支持在索引中定义方向（INDEX idx(a, b DESC)），5.7 及以前只能全升序，降序会失效Using filesort - 注意：WHERE 条件字段应放在联合索引最左侧，例如
WHERE status=1 GROUP BY a ORDER BY b，索引应为(status, a, b)
用 SQL_BIG_RESULT 提示强制走磁盘临时表反而更快？
当分组结果集很大（比如千万级唯一分组值），内存临时表（tmp_table_size 限制）频繁撑爆转成磁盘表，此时 MySQL 默认行为可能反复创建销毁内存表。加 SQL_BIG_RESULT 提示会跳过内存试探，直接用磁盘临时表 + 排序算法，反而更稳定。
- 适用场景：
GROUP BY后预计行数远大于tmp_table_size / avg_row_length，且服务器磁盘 I/O 压力可控 - 写法：
SELECT SQL_BIG_RESULT COUNT(*), dept_id FROM t GROUP BY dept_id - 副作用：绕过内存优化路径，小结果集反而变慢；需配合
sort_buffer_size调优排序性能
替代方案：用窗口函数或物化视图绕开 GROUP BY 性能瓶颈
MySQL 8.0+ 支持窗口函数，某些场景可把「先分组再取 Top N」逻辑改写为 ROW_NUMBER() OVER (PARTITION BY x ORDER BY y)，避免中间临时表。而对高频聚合查询，用 CREATE TABLE AS SELECT ... GROUP BY 预计算 + 定期刷新，比实时聚合更可靠。
- 例如：原查询
SELECT dept_id, MAX(salary) FROM emp GROUP BY dept_id ORDER BY MAX(salary) DESC LIMIT 10，可改用窗口函数避免排序全部分组结果 - 物化聚合表需注意数据一致性：用触发器、Flink CDC 或定时任务同步源表变更，不要依赖应用层双写
- MySQL 8.0.23+ 支持不可见索引，可先建索引验证效果，再决定是否启用
GROUP BY）、或没意识到 ORDER BY 和 GROUP BY 的索引需求本质冲突。先看 EXPLAIN，再动索引，最后才考虑提示或重构。 
