GROUP BY 出现 Using temporary 和 Using filesort 的根本原因是索引未被有效利用：要么缺失索引，要么索引结构不匹配查询逻辑，导致 MySQL 被迫创建临时表并额外排序；典型场景包括 GROUP BY 字段未置于索引最左前缀、WHERE 条件引发隐式类型转换或范围查询截断索引、SELECT 非聚合列未被覆盖、以及未加 ORDER BY NULL 抑制默认隐式排序。
GROUP BY 为什么总出现 Using temporary 和 Using filesort
这两个提示不是警告，是明确告诉你：MySQL 正在用磁盘或内存临时表做分组，还额外排序了。根本原因是索引没被有效利用——要么没索引，要么索引结构不匹配查询逻辑。
典型触发场景包括：GROUP BY 字段不在索引最左前缀里、WHERE 条件用了函数导致索引失效、SELECT 列超出索引覆盖范围、或者隐式排序没关闭。
-
Using temporary表示 MySQL 不得不建临时表来归组，哪怕只有几千行，一旦超出tmp_table_size或max_heap_table_size，就会落盘，I/O 开销陡增 -
Using filesort不一定来自ORDER BY，GROUP BY默认就带隐式排序，哪怕你没写ORDER BY，也会触发 - 松散索引扫描（Loose Index Scan）没启用，说明索引顺序和分组字段顺序不一致，MySQL 只能退化成紧凑扫描（Tight Index Scan），逐行读取再聚合
哪些索引能让 GROUP BY 直接走索引而不建临时表
关键不是“有没有索引”，而是索引能否同时满足两个硬条件：字段顺序完全匹配 GROUP BY 子句，且所有查询列都被覆盖。
- 单字段分组：直接在该字段建 B+ 树索引即可，例如
GROUP BY user_id→ 建INDEX idx_user_id (user_id) - 多字段分组：必须按分组顺序建联合索引，例如
GROUP BY dept, role→ 索引必须是(dept, role)，反过来(role, dept)就无效 - 带 WHERE 的分组：优先把过滤字段放索引最左，再接分组字段，例如
WHERE status = 'active' GROUP BY user_id→ 建INDEX idx_status_user (status, user_id) - 覆盖索引要包含所有
SELECT字段，比如SELECT user_id, COUNT(*) FROM t GROUP BY user_id，索引(user_id)就够（InnoDB 二级索引自带主键），但若查name，就得加进索引里变成(user_id, name)
ORDER BY NULL 真的有用，而且必须加
MySQL 5.7 及以后版本中，GROUP BY 默认按分组字段升序返回结果，这个行为会强制触发排序流程，哪怕你根本不需要有序结果。显式加上 ORDER BY NULL 是唯一能告诉优化器“别排”的方式。
- 不加时：执行计划里大概率出现
Using filesort，尤其当分组后数据量大时，排序开销远超聚合本身 - 加了之后：只要索引结构正确，
Extra字段会变成空或仅Using index，表示纯索引扫描完成全部工作 - 注意：如果业务真需要排序，比如
GROUP BY category ORDER BY SUM(sales) DESC，那就不能加NULL，而应确保SUM(sales)对应的排序字段也在索引中（MySQL 8.0+ 支持函数索引或虚拟列）
EXPLAIN 里看不到 Loose Index Scan 怎么办
松散索引扫描是 GROUP BY 最快的执行路径，但它对索引和查询写法极其敏感。即使有合适索引，也可能因以下原因降级为 Tight 扫描：
-
WHERE条件含范围查询（如created_at > '2025-01-01'），松散扫描就失效，只能先扫范围再分组 - 分组字段上用了函数，比如
GROUP BY YEAR(created_at)，索引无法直接跳组，必须全扫 - 联合索引中某字段有
IS NULL或OR条件，破坏最左匹配，优化器放弃松散策略 - 表统计信息过期，
ANALYZE TABLE没跑过，优化器误判数据分布，选错执行计划
真正难的不是建索引，而是让 MySQL 在每种 WHERE 组合下都稳定走松散扫描——这要求索引设计必须紧贴高频查询模式，而不是泛泛覆盖几个字段。
