GROUP BY字段必须为索引最左前缀才能利用B+树有序性加速分组；否则触发Using filesort和Using temporary，需确保字段顺序匹配复合索引前缀、避免函数运算、优先用区间查询，并通过覆盖索引减少回表。
GROUP BY 字段必须是索引的最左前缀
MySQL 的 GROUP BY 要走索引加速，前提是它能利用 B+ 树的有序性做分组聚合。这要求 GROUP BY 后的字段顺序必须严格匹配某个复合索引的最左前缀。比如表有索引 INDEX idx_status_created (status, created_at)，那么 GROUP BY status 可用，GROUP BY status, created_at 也可用；但 GROUP BY created_at 或 GROUP BY user_id, status 就无法使用该索引。
常见错误是建了索引却没生效：只在 WHERE 条件里用了索引字段，但 GROUP BY 字段不在索引中或顺序错位，导致 MySQL 回表后排序再分组，触发 Using filesort 和 Using temporary —— 这两个提示一出现，基本就说明没走索引优化。
- 用
EXPLAIN检查type是否为range或ref，且Extra中不含Using filesort或Using temporary - 如果
SELECT中有非GROUP BY字段（如SELECT name, COUNT(*) FROM t GROUP BY status），MySQL 8.0+ 默认拒绝执行（sql_mode=ONLY_FULL_GROUP_BY），需显式聚合或改写 - 覆盖索引能进一步提速：把
SELECT中所有需要的列都包含进索引，避免回表，例如INDEX idx_status_cnt (status, id)配合SELECT status, COUNT(id) FROM t GROUP BY status
避免在 GROUP BY 字段上用函数或表达式
对 GROUP BY 字段做计算会直接让索引失效。比如 GROUP BY DATE(created_at)、GROUP BY UPPER(name) 或 GROUP BY CONCAT(first_name, ' ', last_name)，MySQL 无法用原始索引完成分组，只能全表扫描后计算再分组。
解决办法是提前物化计算结果：
- 加生成列（Generated Column）并为其建索引：
ALTER TABLE orders ADD COLUMN created_date DATE AS (DATE(created_at)) STORED;
CREATE INDEX idx_created_date ON orders(created_date); - 或在业务层/ETL 中预计算并存入普通字段，然后对这个字段建索引
- 时间范围分组（如按天/月）尽量用区间查询替代函数：
WHERE created_at >= '2024-01-01' AND created_at 至少能让WHERE先走索引过滤，减少分组数据量
ORDER BY NULL 显式禁用隐式排序
MySQL 默认会对 GROUP BY 结果按分组字段升序排序，即使你不需要。这个隐式排序会增加开销，尤其当分组键无索引或数据量大时。如果业务明确不要顺序，加上 ORDER BY NULL 能跳过这一步。
示例对比：
SELECT status, COUNT(*) FROM orders GROUP BY status;
vs
SELECT status, COUNT(*) FROM orders GROUP BY status ORDER BY NULL;
后者在 EXPLAIN 中 Extra 字段不会出现 Using filesort —— 即使 status 有索引，前者仍可能触发一次额外排序。
- 仅当确认下游不依赖返回顺序时才加
ORDER BY NULL - 如果同时需要
ORDER BY其他字段（如ORDER BY COUNT(*) DESC），那就无法避免排序，此时应优先确保GROUP BY索引有效，再考虑是否加SQL_BIG_RESULT提示让优化器倾向使用磁盘临时表而非内存表
小结果集用松散索引扫描，大数据量慎用 DISTINCT + GROUP BY
当 GROUP BY 字段区分度高、分组数少，且索引覆盖完整时，MySQL 可能启用“松散索引扫描（Loose Index Scan）”，即跳着读索引节点，大幅减少访问行数。这是最理想的执行路径，EXPLAIN 中 type 会显示为 index，且 rows 很小。
但要注意两个典型陷阱：
-
DISTINCT和GROUP BY在语义等价场景下混用（如SELECT DISTINCT status FROM tvsSELECT status FROM t GROUP BY status），MySQL 有时会选更差的执行计划，建议统一用GROUP BY并确保索引存在 -
聚合函数含非分组字段时（如
MAX(updated_at)），若该字段不在索引中，即使GROUP BY字段走了索引，仍需回表取值——此时应把被聚合字段也加入索引，形成覆盖，例如INDEX idx_status_updated (status, updated_at)
索引不是越多越好，但针对 GROUP BY 的索引必须紧扣实际查询结构：字段顺序、是否覆盖、是否避免计算 —— 少一个条件，优化就可能落空。
