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 个值）即使没索引，分组本身开销也不大；高基数字段（如
检查是否真的用了索引分组：看 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。
