17370845950

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。