MySQL靠索引避免临时表，核心是利用B+树天然有序性实现线性扫描分组：GROUP BY字段必须为索引最左前缀，使相同分组值在索引中物理连续，从而边读边分组，无需缓存全量数据；顺序错、函数包装、非聚合裸字段等均会导致索引失效。
因为 MySQL 能直接按索引的物理顺序读取数据，跳过排序和临时表——GROUP BY 本身不“用”索引，但索引的有序性让分组变成一次线性扫描。
GROUP BY 怎么靠索引避免临时表？
MySQL 只有在能连续读到相同分组值时，才不用建临时表。B+树索引天然有序，只要 GROUP BY 字段是索引最左前缀，数据库就能顺着索引一页页读：遇到新分组值就切一刀、累加完就输出，全程不缓存全量行。
- ✅ 松散索引扫描（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没聚合也没分组） -
WHERE条件用了函数或隐式转换：WHERE YEAR(create_time) = 2024或WHERE user_id = '123'（user_id是 INT） -
GROUP BY字段上有COALESCE()、UPPER()等函数包装，索引值被“变形”，无法匹配
怎么确认 GROUP BY 真的走索引了？
别只看 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 过滤太弱，该加条件而不是堆索引。
