GROUP BY 性能差通常因索引未对齐：EXPLAIN 中 type 为 ALL/index 或 Extra 出现 Using temporary/Using filesort 即表示索引失效；需确保 GROUP BY 字段为索引最左前缀，WHERE 条件与之共用同一索引且顺序匹配，SELECT 非分组列应被覆盖索引包含，ORDER BY 若含聚合字段则无法避免 filesort。
GROUP BY 没走索引？先看执行计划里的 type 和 Extra
MySQL 对 GROUP BY 的优化依赖是否能复用索引做排序+去重，而不是先扫描再内存分组。最直接的判断方式是 EXPLAIN 结果里：type 不能是 ALL 或 index（全索引扫描），Extra 里不能出现 Using temporary 或 Using filesort——这两个意味着 MySQL 放弃了索引加速，转而建临时表、排序分组，性能断崖下跌。
常见错误现象：明明给 user_id 加了索引，SELECT user_id, COUNT(*) FROM orders GROUP BY user_id 还很慢。原因往往是索引没覆盖查询字段，或 WHERE 条件破坏了索引有序性。
- 确保
GROUP BY字段是索引的最左前缀，例如索引是(user_id, status)，那GROUP BY user_id可用，但GROUP BY status不可用 - 如果带
WHERE，条件字段也得落在同一索引上，且顺序要匹配，比如WHERE status = 'paid' GROUP BY user_id，索引应为(status, user_id)而非(user_id, status) - 避免在
GROUP BY字段上用函数或表达式，如GROUP BY DATE(created_at)会强制失效索引
聚合字段也要进索引？看是否需要 SELECT 非分组列
如果 SELECT 里除了分组字段还有其他列（比如 SELECT user_id, MAX(created_at), AVG(amount)），MySQL 默认要求这些列必须“功能依赖”于 GROUP BY 字段，否则报错（ONLY_FULL_GROUP_BY 开启时）。但即使不报错，想避免 Using temporary，就得让这些列也包含在索引中——不是可选，是刚需。
使用场景：统计每个用户的最新订单时间、总金额、订单数。这时索引最好定义为 (user_id, created_at, amount)，让所有 SELECT 字段都被覆盖，MySQL 就能只扫索引完成全部聚合，不用回表、不建临时表。
- 索引列顺序很重要：分组字段放最左，然后是
MAX()/MIN()依赖的字段（需有序），最后是求和/计数类字段（顺序影响小） -
COUNT(*)和COUNT(非空列)在覆盖索引下性能一致；但COUNT(可能为 NULL 的列)仍需判空，无法完全跳过行数据 - 别盲目加宽索引——
(user_id, created_at, amount, product_id, remark)这种五列索引会显著拖慢写入，且缓存效率低
ORDER BY + GROUP BY 混用时，索引设计容易漏掉排序需求
很多人只盯着 GROUP BY 建索引，却忘了后面还跟了个 ORDER BY。例如 GROUP BY user_id ORDER BY COUNT(*) DESC，此时 MySQL 无法用同一个索引同时满足分组和最终排序，大概率触发 Using filesort。
性能影响明显：10 万行数据分组后排序，Using filesort 可能比纯索引分组慢 3–5 倍，尤其结果集大时内存不够还会写磁盘。
- 如果业务允许，把排序逻辑提到应用层（查出
user_id, COUNT(*)后用代码排序），避开 SQL 层二次排序 - 若必须 SQL 排序，且排序字段是聚合结果（如
COUNT(*)），索引无法优化——因为聚合值不存在于原始索引中，只能接受Using filesort - 但如果排序字段是分组字段本身，比如
GROUP BY user_id ORDER BY user_id DESC，那原索引(user_id)就能复用，Extra里不会出现Using filesort
小结果集用 SQL_CALC_FOUND_ROWS？早该停用了
以前有人习惯在分页聚合查询里加 SQL_CALC_FOUND_ROWS，以为能省一次 COUNT(*) 全表扫描。实际上从 MySQL 8.0.17 开始它已被移除，5.7 里也已标记为废弃。更关键的是：它对 GROUP BY 查询完全无效——FOUND_ROWS() 返回的是分组前的原始行数，不是分组后的桶数量。
正确做法就一个：单独跑 SELECT COUNT(DISTINCT user_id) FROM orders WHERE ...，并确保这个语句也能走索引（比如用 (user_id) 索引配合 WHERE 条件）。
- 不要试图用
SELECT COUNT(*) FROM (SELECT 1 FROM orders GROUP BY user_id) t——子查询的GROUP BY依然会触发临时表，性能更差 - 如果分组维度固定且变化少（比如只有几十个
status值），可考虑用ENUM或冗余计数字段 + 触发器维护，绕过实时聚合 - 注意
DISTINCT和GROUP BY在索引利用上几乎等价，优化思路完全一致
真正卡住性能的，往往不是 GROUP BY 语法本身，而是索引没对齐分组字段、WHERE 条件、SELECT 列三者的联合访问模式。调一条慢查询，EXPLAIN 看一眼 Extra，比翻十页文档更快。
