为什么在SQL中对索引列执行GROUP BY效率更高？

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 过滤太弱，该加条件而不是堆索引。