GROUP BY 慢主要因未触发松散索引扫描，导致使用临时表或文件排序；需满足单表、最左前缀索引、无非等值WHERE、仅用MIN/MAX/COUNT(*)等条件。
GROUP BY 为什么慢？先看执行计划里有没有 Using filesort 或 Using temporary
MySQL 对 GROUP BY 的优化依赖是否能走索引扫描，而不是回表或临时表。如果 EXPLAIN 输出里出现 Using filesort 或 Using temporary，基本说明没走松散索引扫描（Loose Index Scan），而是用了紧凑索引扫描（Tight Index Scan）——也就是逐行读、再聚合，I/O 和 CPU 开销都大。
松散索引扫描不是“开关”，是优化器在满足特定条件时自动启用的策略：它跳着读索引，只取每组第一个值，跳过组内其余行。但这个“跳”很娇气，稍有不匹配就退化。
- 必须是单表查询，不能有
JOIN、子查询、UNION -
GROUP BY字段必须是索引最左前缀，且顺序完全一致（比如索引是(a,b,c)，那GROUP BY a,b可以，GROUP BY b,a就不行） - 不能有
WHERE条件过滤非最左字段（比如索引(a,b)，WHERE b = 1会强制全索引扫描） - 聚合函数仅限
MIN()、MAX()、COUNT(*)；用SUM()、AVG()或带DISTINCT的函数会禁用松散扫描
怎么建索引才能触发松散索引扫描
核心是让索引覆盖 GROUP BY 列 + 所有 SELECT 中的非聚合列（即“功能依赖”列）。例如：SELECT a, MAX(b) FROM t GROUP BY a，理想索引是 (a,b) —— a 支持分组定位，b 支持直接取最大值而无需回表。
注意：如果语句里有 ORDER BY a，和 GROUP BY a 一致，不会额外开销；但如果 ORDER BY b，即使 b 在索引里，也可能导致优化器放弃松散扫描改走排序。
- 避免冗余字段：索引
(a,b,c)用于GROUP BY a是浪费，c不参与分组也不被聚合引用时，拖慢索引体积和维护成本 - 复合索引中，把等值条件字段放最左，再放
GROUP BY字段，最后放用于MIN/MAX的字段（如WHERE status=1 GROUP BY category ORDER BY created_at DESC→ 索引(status, category, created_at)） - 5.7+ 版本支持函数索引（虚拟列+索引），对表达式分组（如
GROUP BY DATE(created_at)）可建虚拟列再索引，否则必然全表扫
常见踩坑：明明建了索引，GROUP BY 还是慢
最典型的是隐式类型转换。比如字段是 VARCHAR，但 WHERE 条件写了 WHERE group_id = 123（整型字面量），MySQL 会把每行 group_id 转成数字比对，索引失效，自然也废掉松散扫描机会。
另一个高频问题是 SQL_MODE 含 ONLY_FULL_GROUP_BY 时，MySQL 会拒绝“非函数依赖列出现在 SELECT 中”的语句，表面报错，实则可能让你加了不必要的 ANY_VALUE() 或改成 MAX()，结果反而破坏了松散扫描前提（比如把 SELECT name 改成 SELECT MAX(name)，而 name 不在索引里）。
- 检查字符集/排序规则是否一致：联结字段或
WHERE字段若跨不同COLLATION，也会触发隐式转换 -
GROUP BY后跟常量（如GROUP BY 1）或表达式（如GROUP BY a+1）一定无法使用索引 - 分区表上
GROUP BY默认不合并各分区结果，除非明确写GROUP BY ... PARTITION语法（8.0+），否则性能更差
替代方案：当松散索引扫描不可用时，还能做什么
如果业务逻辑复杂、字段多、又必须用 SUM 或 AVG，松散扫描基本无望。这时候与其硬调索引，不如换思路：预聚合。
比如高频查询 “每个分类的销量总和”，与其每次 SELECT category, SUM(sales) FROM orders GROUP BY category，不如用定时任务或触发器把结果写入汇总表 category_sales_summary(category, total_sales, updated_at)，查询直接走主键。
- 汇总表更新要控制频率：实时性要求低的场景，用
INSERT ... ON DUPLICATE KEY UPDATE每小时刷一次比每单都更新更稳 - 临时表 + 强制索引有时比原表快：对大表先
CREATE TEMPORARY TABLE t2 AS SELECT ... WHERE ...，再在t2上GROUP BY，尤其当原表有大量无效数据时 -
SQL_CALC_FOUND_ROWS已废弃，别在分页GROUP BY场景里用；总数单独查SELECT COUNT(DISTINCT category)更可靠
松散索引扫描看着很美，但它的生效边界非常窄。真正卡住性能的，往往不是“没建对索引”，而是“以为建了索引就万事大吉”，忽略了条件顺序、类型一致性、甚至 SQL_MODE 的连锁影响。
