GROUP BY字段必须是索引最左前缀；否则触发Using temporary或filesort，性能骤降。需确保分组字段顺序与索引最左前缀一致，覆盖WHERE和GROUP BY，避免函数、非前缀ORDER BY，并通过EXPLAIN的Extra字段验证索引是否真正生效。
GROUP BY 字段必须是索引的最左前缀
MySQL 的 GROUP BY 能走索引的前提，是分组字段构成的列顺序与某个现有索引的最左前缀完全一致。比如有复合索引 INDEX idx_user_status_time (user_id, status, created_at)，那么 GROUP BY user_id 或 GROUP BY user_id, status 可以用上索引；但 GROUP BY status 或 GROUP BY created_at 就不行——哪怕字段在索引里，位置不对也不生效。
常见错误现象：EXPLAIN 显示 type: ALL 或 Using temporary; Using filesort，说明 MySQL 正在回表或建临时表排序分组，性能会断崖式下降。
- 只对单字段分组时，优先建单列索引（比复合索引更轻量）
- 如果同时有
WHERE和GROUP BY，优先让索引覆盖两者，例如WHERE user_id = ? GROUP BY status，适合建INDEX(user_id, status) - 避免在
GROUP BY中使用函数或表达式，如GROUP BY DATE(created_at)会直接失效索引
ORDER BY + GROUP BY 混用时索引必须包含全部字段
当查询同时含 GROUP BY 和 ORDER BY，且二者字段不完全相同时，MySQL 很可能放弃索引分组，转而用临时表+排序。只有当 ORDER BY 字段是 GROUP BY 字段的**后缀子集**，且顺序一致，才可能复用索引。
例如：索引为 INDEX(a, b, c)，查询写成 GROUP BY a, b ORDER BY a, b, c —— 可走索引；但写成 GROUP BY a, b ORDER BY c 就不行，因为 c 不在分组键开头，无法保证分组内有序。
- 如果不需要显式排序，加
ORDER BY NULL显式关闭排序，避免额外filesort - 若业务真要按非分组字段排序，考虑先分组生成中间结果（如 CTE 或临时表），再对外层排序
-
SQL_MODE含ONLY_FULL_GROUP_BY时，SELECT列必须在GROUP BY中出现或被聚合函数包裹，否则报错，这和索引无关但常一起踩坑
用 DISTINCT 替代简单 GROUP BY？不一定更快
很多人以为 SELECT DISTINCT col FROM t 和 SELECT col FROM t GROUP BY col 等价且后者更重，其实优化器在多数场景下会把二者等价重写。关键看执行计划是否走索引，而不是语法表面。
真正影响性能的是字段基数、是否需要回表、以及是否有覆盖索引。比如 SELECT DISTINCT name FROM users，若 name 无索引，两者都会全表扫描；若已有 INDEX(name)，则都可走索引并避免临时表。
- 不要为了“看起来简洁”强行换
DISTINCT，逻辑等价时执行计划通常一致 - 如果
GROUP BY后还带AGGREGATE（如COUNT(*)、MAX(time)），那就不能用DISTINCT替代 - 低基数字段（如
status只有 3 个值）即使没索引，分组本身开销也不大；高基数字段（如email）没索引就会严重拖慢
检查是否真的用了索引分组：看 Extra 字段
判断 GROUP BY 是否高效，唯一可靠方式是看 EXPLAIN FORMAT=TRADITIONAL 输出里的 Extra 字段：
EXPLAIN SELECT user_id, COUNT(*) FROM orders GROUP BY user_id;
理想情况是 Extra 为空，或仅含 Using index；一旦出现以下任一内容，说明索引未被有效利用：
-
Using temporary：MySQL 创建了内部临时表存分组中间结果 -
Using filesort：需要额外排序步骤，哪怕只是分组后按主键排 -
Using where; Using index是好现象，表示索引覆盖且条件下推成功
注意：key 字段显示用了哪个索引，但不等于分组过程就高效——重点盯 Extra，不是 key。
