GROUP BY隐含排序是因为其底层需数据按分组字段有序才能高效聚合，故优化器在索引无法保证顺序时自动触发filesort；MySQL 8.0起取消该隐式行为，仅当分组字段有合适索引时才自然有序。
GROUP BY 为什么隐含排序，又为何触发 Filesort
MySQL 的 GROUP BY 本质是「先排序、再分组」——它依赖数据按分组字段有序排列，才能线性扫描完成聚合。所以即使你没写 ORDER BY，只要优化器判定当前索引不能保证分组字段的物理顺序，就会悄悄启用排序步骤，表现为 Using filesort。
典型诱因是：分组字段未出现在索引最左前缀，或被 WHERE 中的范围条件（如 created_at > '2025-01-01'）截断了索引连续性。
- 索引
(status, user_id)，查询WHERE status = 1 GROUP BY user_id→ ✅ 可用，user_id是等值过滤后的紧邻字段 - 索引
(status, created_at, user_id)，查询WHERE status = 1 AND created_at > '2025-01-01' GROUP BY user_id→ ❌user_id在范围条件后，索引无法保证其有序性 - 索引
(user_id)，查询GROUP BY status→ ❌ 完全不匹配最左前缀
GROUP BY + ORDER BY 共存时，一个索引够吗
不够，而且别强求。当 GROUP BY a ORDER BY b 中 a ≠ b，尤其 b 是非分组字段或计算列时，MySQL 通常无法复用同一索引同时满足分组有序性和最终输出排序要求。
例如：SELECT department, COUNT(*) FROM employees GROUP BY department ORDER BY hire_date DESC —— 即使有 (department, hire_date) 索引，优化器也大概率放弃用它做最终排序，因为分组阶段已按 department 扫描，hire_date 的原始顺序在聚合后已丢失。
- 若必须按
hire_date排序输出，优先考虑在聚合结果上加二级排序（即应用层或子查询），而非硬塞进索引 -
GROUP BY a ORDER BY a才真正能靠单索引(a)吃透，此时分组和输出排序完全一致 - MySQL 8.0+ 支持降序索引（
INDEX (a ASC, b DESC)），但仅对ORDER BY有效，对GROUP BY无额外增益
如何验证索引是否真被用于 GROUP BY 排序
别只看 key 列，重点盯 Extra 和 rows：
-
Extra出现Using temporary; Using filesort→ 明确失败：既建了临时表，又额外排序 -
Extra只有Using temporary→ 分组走了索引，但后续可能因ORDER BY或SELECT *触发回表或二次排序 -
rows值远大于实际分组数（比如查出 5 个部门却显示rows=100000）→ 索引未被用于跳过扫描，只是做了简单过滤 - 执行
ANALYZE TABLE employees更新统计信息，有时优化器会因此改选正确索引
覆盖索引对 GROUP BY 的真实价值在哪
覆盖索引的核心价值不是“避免 filesort”，而是“避免临时表”。当 SELECT 字段、GROUP BY 字段、WHERE 条件字段全部被一个索引包含，MySQL 就能直接遍历索引完成分组，无需回主键树捞数据，也不必建磁盘临时表。
但注意：覆盖索引不自动解决 ORDER BY 问题。例如：SELECT department, COUNT(*) FROM employees WHERE status = 1 GROUP BY department，建索引 (status, department) 就足够；但如果加了 ORDER BY created_at，这个索引依然无效。
- 优先级永远是：先让
GROUP BY走索引（确保分组字段在最左且连续），再考虑把SELECT字段加进去构成覆盖 - 别为
ORDER BY强行往索引末尾堆字段，尤其是当排序字段与分组逻辑无关时 -
ORDER BY NULL是个冷门但有效的开关：显式告诉优化器“我不需要输出排序”，可消除不必要的Using filesort
EXPLAIN 看不出全貌，得结合 FORMAT=JSON 里的 used_key_parts 和实际执行时间交叉验证。 
