GROUP BY 不一定强制触发临时表和文件排序，但无合适索引时会默认排序再分组，导致 Using temporary 和 Using filesort；应建最左前缀索引、加 ORDER BY NULL 禁用隐式排序，并确保索引覆盖 GROUP BY 和 ORDER BY 字段顺序。
GROUP BY 会强制触发临时表和文件排序吗？
不一定，但绝大多数情况下会。MySQL 在执行 GROUP BY 时，默认行为是先排序再分组（哪怕你没写 ORDER BY），尤其当没有合适索引覆盖 GROUP BY 字段时，就会建临时表 + 使用 filesort。这是性能杀手。
实操建议：
- 确保
GROUP BY的字段有单独索引，或作为联合索引的最左前缀（例如GROUP BY user_id, status，索引应为(user_id, status)，不能是(status, user_id)） - 加
ORDER BY NULL显式禁止隐式排序：SELECT user_id, COUNT(*) FROM orders GROUP BY user_id ORDER BY NULL—— 这能跳过排序阶段，前提是业务真不需要结果有序 - 用
EXPLAIN看Extra列：出现Using temporary; Using filesort就说明索引没生效
ORDER BY 走索引的前提条件是什么？
不是“有索引就行”，而是必须满足“索引顺序 = ORDER BY 顺序 + WHERE 条件过滤后剩余字段的最左匹配”。稍有偏差，filesort 就来了。
常见错误现象：
- WHERE 用了
LIKE '%abc'—— 索引失效，后续ORDER BY无法复用 -
ORDER BY a ASC, b DESC，但索引是(a, b)（默认都是 ASC）—— MySQL 8.0+ 支持混合方向索引，但 5.7 及以前直接退化为filesort - SELECT 中有非索引字段，且
ORDER BY字段不在索引覆盖范围内 —— 即使排序字段本身有索引，也可能因回表代价高而放弃索引
验证方式：EXPLAIN SELECT ... ORDER BY ...，看 key 是否命中、Extra 是否含 Using index（覆盖索引）或 Using filesort
GROUP BY 和 ORDER BY 能共用一个索引吗？
可以，但条件苛刻：索引必须同时满足两者的最左前缀要求，且字段顺序需一致。例如 GROUP BY a, b ORDER BY a, b 可以用索引 (a, b)；但 GROUP BY a ORDER BY b 就不行 —— 分组和排序维度不重合，大概率触发双排序。
实操建议：
- 优先按
GROUP BY字段设计索引，因为它的代价通常更高（涉及聚合计算 + 去重） - 如果必须同时支持，把高频共现的字段按顺序放进联合索引，比如
(region, category, sale_date)同时支撑GROUP BY region, category和ORDER BY region, category, sale_date - 避免在
GROUP BY后加无意义的ORDER BY：MySQL 默认按分组键排序，显式写ORDER BY region不增加效果，反而可能干扰优化器选择索引
为什么加了索引，EXPLAIN 还显示 Using temporary？
因为索引只解决“找数据快”，不解决“内存里聚合”这件事。Using temporary 表示 MySQL 需要建内部临时表存中间分组结果，常见于以下情况：
- SELECT 列包含非分组字段且没用聚合函数，比如
SELECT name, COUNT(*) FROM users GROUP BY dept_id（name不在GROUP BY里也不聚合）—— 这属于 SQL 语义错误，5.7+ 默认报错，低版本会随机取值并强制建临时表 - 分组字段存在大量重复值，MySQL 认为哈希分组（hash group by）更优，但内存不足时仍会落盘成临时表
- 使用了
DISTINCT、窗口函数、或HAVING中带复杂表达式，导致优化器放弃松散索引扫描（loose index scan）
关键点：索引能消除 Using filesort，但消除不了 Using temporary —— 后者更多取决于查询结构是否符合松散索引扫描条件，以及 tmp_table_size / max_heap_table_size 配置是否足够大
