MySQL GROUP BY 分组优化：三种实现方式与性能对比
在 MySQL 中，GROUP BY 操作本质上包含 “排序” 和 “分组” 两个核心步骤，其性能很大程度上取决于是否能利用索引避免额外的排序或临时表。MySQL 实现 GROUP BY 主要有三种方式，性能从优到劣依次为：松散索引扫描 → 紧凑索引扫描 → 临时表。
松散索引扫描（Loose Index Scan）：性能最优
松散索引扫描是 GROUP BY 最理想的实现方式，它完全利用索引直接获取分组结果，无需扫描所有符合条件的数据，也无需创建临时表或排序，性能最佳。
核心原理
利用索引的有序性，直接定位每个分组的起始位置，跳过组内其他数据，仅读取分组所需的最小信息（如分组字段和聚合函数所需的值）。
例如，索引为 (c1, c2, c3)，当 GROUP BY c1, c2 时，松散索引扫描会直接定位每个 (c1, c2) 组合的第一个索引项，即可完成分组，无需扫描组内的 c3 数据。
必须满足的条件
- 单表操作：
GROUP BY仅作用于单个表，不涉及多表关联。 - 索引匹配：
GROUP BY的字段必须是某个索引的最左前缀且连续。
例：索引(a, b, c)支持GROUP BY a、GROUP BY a, b，但不支持GROUP BY b（非最左前缀）或GROUP BY a, c（非连续）。 - 聚合函数限制：仅允许使用
MIN()或MAX()，且若同时使用两者，必须作用于同一字段，且该字段需紧跟在GROUP BY字段之后（在索引中连续）。
例：索引(c1, c2, c3)支持SELECT c1, c2, MIN(c3), MAX(c3) FROM t GROUP BY c1, c2（c3在索引中紧跟c2）。 - 其他条件为常量：若查询中包含
WHERE条件，且条件字段在索引中但不属于GROUP BY字段，则该字段必须为常量（如WHERE c4 = 10，c4是索引中其他字段，值为常量）。
识别方式
执行 EXPLAIN 时，Extra 字段会显示 Using index for group by，表示使用松散索引扫描。
紧凑索引扫描（Tight Index Scan）：性能次之
当松散索引扫描的条件不满足时，MySQL 会尝试紧凑索引扫描。它仍利用索引，但需要扫描所有符合条件的索引项，再基于扫描结果完成分组。
核心原理
与松散索引扫描不同，紧凑索引扫描需要遍历索引中所有满足条件的数据（无法跳过组内数据），但因索引有序，无需额外排序，可直接在扫描过程中完成分组。
例如，索引 (a, b, c)，若 GROUP BY a, c（a 和 c 非连续），则需扫描所有包含 a 和 c 的索引项，再按 (a, c) 分组。
适用条件
- 索引依赖：
GROUP BY字段必须属于某个索引，但无需是最左连续前缀（可非连续或包含非前缀字段）。 - 无额外排序：因索引有序，分组过程无需额外排序（避免
Using filesort）。
与松散索引扫描的区别
- 松散索引扫描：跳过组内数据，仅读取分组起始项。
- 紧凑索引扫描：需扫描所有符合条件的索引项，无法跳过组内数据。
临时表（Temporary Table）：性能最差
当无法利用索引时，MySQL 会先将数据写入临时表，再对临时表进行排序和分组，性能最差（涉及磁盘 I/O 和排序开销）。
触发场景
- 无合适索引：
GROUP BY字段未包含在任何索引中，或索引无法支撑分组顺序。 - 多表关联：
GROUP BY涉及多表关联的结果，无法直接利用单表索引。 - 复杂聚合函数：使用了
MIN()/MAX()之外的聚合函数（如SUM()、AVG()），且无法通过索引优化。
识别方式
执行 EXPLAIN 时，Extra 字段会显示 Using temporary（表示创建临时表），可能伴随 Using filesort（表示需要排序）。
优化建议：避免临时表，优先利用索引
- 设计合适的索引：
将GROUP BY字段作为索引的最左前缀，且包含聚合函数所需字段（如MIN(col)/MAX(col)中的col）。
例：对GROUP BY a, b且需MIN(c)，创建索引(a, b, c)，可触发松散索引扫描。 - 简化聚合函数：
若业务允许，优先使用MIN()/MAX()，避免SUM()/AVG()等需全量计算的函数（或确保其字段在索引中）。 - 减少临时表触发：
避免GROUP BY多表关联结果，尽量在单表内完成分组；若需多表分组，确保关联字段和分组字段均有索引。