MySQL 的
GROUP BY查询能否走索引，关键不在于“有没有 GROUP BY”，而在于分组字段是否匹配可用的索引结构，以及是否满足最左前缀原则和无隐式转换等条件。
GROUP BY 能用上索引的前提
MySQL 只有在能**按索引顺序直接扫描并分组**时，才可能避免临时表和文件排序。这要求：
GROUP BY 后的列必须是某个**已存在索引的最左前缀**（例如索引是(a,b,c)，那么
GROUP BY a或
GROUP BY a,b可以，但
GROUP BY b不行） SELECT 中的非聚合字段（如
SELECT a, b, COUNT(*) FROM t GROUP BY a中的
a）必须包含在索引中，否则仍需回表——若只查索引覆盖字段（如
SELECT a, COUNT(*)），可走**覆盖索引**，性能更优 WHERE 条件与 GROUP BY 字段共同作用时，索引需同时支持过滤和分组，例如
WHERE status=1 GROUP BY user_id，理想索引是
(status, user_id)
常见导致索引失效的写法
以下情况即使有索引，MySQL 也大概率退化为 Using temporary + Using filesort：
GROUP BY ABS(id)、
GROUP BY UPPER(name)：对字段做函数操作，破坏索引有序性
GROUP BY id DESC但索引是
KEY idx_id (id ASC)：升序索引无法高效支持降序分组（MySQL 8.0+ 支持降序索引，可建
(id DESC)）
GROUP BY a,b ORDER BY b：分组字段是
(a,b)，但排序字段
b不是最左字段，无法复用索引排序能力 使用了不等于（
!=）、
NOT IN、
IS NULL等范围过大的 WHERE 条件，导致索引选择性差，优化器主动放弃
如何验证 GROUP BY 是否用了索引
执行
EXPLAIN FORMAT=TREE（MySQL 8.0+）或
EXPLAIN查看执行计划： 出现
Using index：说明走了索引扫描（理想） 出现
Using temporary; Using filesort：表示创建了临时表并排序，未走索引分组（需优化） 注意
key列显示实际使用的索引名，
rows值越小越好 配合
SHOW PROFILES或性能模式（performance_schema）观察 Sorting result 和 Creating tmp table 的耗时占比
实用优化建议
不必强求所有 GROUP BY 都走索引，但可通过以下方式提升概率：
为高频 GROUP BY 字段单独建索引，或将其作为复合索引的最左列；例如常查GROUP BY category, status，建
INDEX idx_cat_status (category, status)尽量让 SELECT 列都来自 GROUP BY 字段或聚合函数，避免额外字段触发回表；必要时添加覆盖索引，如
INDEX (a,b) INCLUDE (c)（MySQL 8.0 不原生支持 INCLUDE，可用
(a,b,c)替代） 数据量大且分组结果固定（如统计各状态数量），考虑用汇总表或物化视图（通过定时任务预计算）替代实时 GROUP BY 确认字符集和排序规则一致，避免因
utf8mb4_0900_as_cs和
utf8mb4_general_ci混用导致隐式转换，使索引失效
