MySQL 的 GROUP BY 操作，性能瓶颈往往不在于分组本身，而在于为了分组需要付出的“组织成本”。很多人在优化 SQL 时都会遇到一个经典场景：明明在 GROUP BY 字段上建了索引，执行计划却不走，反而搞出一个临时表来硬撑。 这背后的原理，其实一句话就能说清——MySQL 靠索引避免临时表，核心是利用了 B+ 树天然的有序性来实现“线性扫描分组”。换句话说，只要 GROUP BY 的字段恰好是索引的最左前缀，那索引页里相同分组的值就会物理连续。MySQL 顺着索引一页页往下读，遇到新的分组值就切一刀，累加完直接输出，全程不需要把数据塞进临时表再排序。 ## GROUP BY 怎么靠索引避免临时表？ MySQL 只有在能“连续读到相同分组值”时，才会放弃临时表。B+ 树索引天然有序，这是它愿意走捷径的前提。 具体分为几种场景： - **松散索引扫描（Loose Index Scan）**：比如索引是 `(status, dept_id)`，你只 `GROUP BY status`，MySQL 可以跳着读 status 的每个不同值，极快，连扫描都省了。 - **紧凑索引扫描（Tight Index Scan）**：同样索引，但你加了 `WHERE create_time > '2024-01-01'`，那就得扫所有满足时间条件的索引项——虽然比全表快，但已经不再“松散”。 - **没索引或顺序错**：比如索引是 `(dept_id, status)`，你却写 `GROUP BY status`，那 MySQL 根本扫不到连续的 status 值，只能全表捞数据，再扔进临时表分组。 ## 为什么索引列顺序必须匹配 GROUP BY 字段顺序？ 这个问题问得很多，但答案其实很直接：索引是按定义顺序排序的，`GROUP BY a, b` 要求数据先按 `a` 排、`a` 相同再按 `b` 排。如果索引是 `(b, a)`，那 `a` 不可能是最左前缀，MySQL 没法保证 `a` 相同的行在索引里挨着，自然没法线性分组。 举个例子： - 索引 `(region, user_id, created_at)` → 支持 `GROUP BY region, user_id` 或 `GROUP BY region` - 索引 `(user_id, region)` → 不支持 `GROUP BY region`，除非 `WHERE user_id = ?` 把它变成了最左前缀 - MySQL 8.0+ 如果写 `GROUP BY a DESC, b ASC`，索引也得声明为 `(a DESC, b ASC)`，否则可能退化 ## 哪些写法会让索引分组失效？ 就算索引建得完全正确，SQL 写法出了问题，优化器也会主动放弃索引分组路径——它宁可走全表扫描，也不愿在约束下勉强用索引。 - `SELECT *` 或选了没出现在 `GROUP BY` 中的裸字段：比如 `SELECT dept_id, name, COUNT(*) FROM emp GROUP BY dept_id`，`name` 没有聚合也没分组，MySQL 只能建临时表。 - `WHERE` 条件用了函数或隐式转换：`WHERE YEAR(create_time) = 2024` 或 `WHERE user_id = '123'`（`user_id` 是 INT 类型），索引值被变形，无法匹配。 - `GROUP BY` 字段上有函数包装：比如 `COALESCE()`、`UPPER()` 等，索引值被“变形”，同样失效。 ## 怎么确认 GROUP BY 真的走索引了？ 很多人在 `EXPLAIN` 里看到 `key` 列有索引名，就以为优化成功了——这是个常见的陷阱。真正需要盯的是 `Extra` 和 `type` 两列。 - **健康信号**：`type` 是 `ref` 或 `range`，且 `Extra` 里没有 `Using temporary`、没有 `Using filesort` - **危险信号**：`type: index` + `Extra: Using index; Using temporary` → 全索引扫描但依然建临时表，索引白建 - **致命信号**：`Extra: Using temporary; Using filesort` 同时出现 → 既没利用索引顺序分组，也没利用索引顺序排序，纯硬扛 真正容易被忽略的是：即使 `EXPLAIN` 显示走了索引，如果 `rows` 扫描数远大于最终分组数——比如扫了 50 万行只产出 100 个分组——说明 WHERE 过滤太弱，该加条件而不是堆索引。索引不是万能的，它只是帮你走路的工具，路选对了，还得看路上有没有坑。