GROUP BY慢不一定没走索引，但索引列顺序必须严格匹配GROUP BY列顺序且不能跳过前导列；函数、NULL值、列顺序错误均会导致索引失效。

GROUP BY慢，是不是没走索引？

不是所有 GROUP BY 都能用上索引。MySQL（含8.0+）、PostgreSQL 等主流引擎只在特定条件下复用索引：**索引列顺序必须严格匹配 GROUP BY 子句的列顺序，且不能跳过前导列**。比如 GROUP BY a, b 能用 (a, b, c) 索引，但用不了 (b, a) 或 (a, c)。

常见误判现象：EXPLAIN 显示 type=ALL 或 Extra 里有 Using temporary; Using filesort —— 这说明引擎被迫建临时表排序分组，索引完全失效。

多列索引该按什么顺序写？

核心原则：**把 GROUP BY 列放在最左，WHERE 条件列紧随其后（如果存在），ORDER BY 列可追加在末尾（仅当需要避免额外排序）**。顺序错一个，索引就废一半。

例如查询：SELECT dept, status, COUNT(*) FROM user WHERE city = 'Beijing' GROUP BY dept, status ORDER BY status

最优索引是：CREATE INDEX idx_dept_status_city ON user (dept, status, city) —— 注意 city 放最后，因为它是 WHERE 条件，不是分组依据；ORDER BY status 已被覆盖，无需额外排序。

• (city, dept, status) ❌：前导列 city 不在 GROUP BY 中，索引无法用于分组
• (dept, city, status) ⚠️：city 插在中间，导致 status 无法被索引覆盖（非连续前缀），ORDER BY 失效
• (dept, status) ✅：基础可用；但加上 city 可让 WHERE 也走索引，减少回表

NULL值和函数会让索引直接失效

只要 GROUP BY 表达式里出现函数或类型转换，比如 GROUP BY UPPER(name)、GROUP BY DATE(create_time)，哪怕有对应字段索引，也必然退化为全表扫描。

同理，列允许 NULL 且实际含大量 NULL 值时，部分引擎（如旧版 MySQL）可能拒绝使用索引做分组，因为 NULL 不参与 B+ 树排序比较逻辑。

实操建议：

• 避免在 GROUP BY 中使用函数；必要时建函数索引（MySQL 8.0+ 支持 CREATE INDEX ... (UPPER(name))）
• 确认分组列 NOT NULL；若业务允许，设为 NOT NULL 并补默认值
• 用 EXPLAIN FORMAT=TREE（MySQL 8.0）或 EXPLAIN (ANALYZE, BUFFERS)（PostgreSQL）验证是否真走了索引扫描而非索引查找

聚合字段要不要放进索引？

不需要。索引本身不存储聚合结果，只加速分组过程。把 COUNT(*)、SUM(amount) 对应的字段塞进索引，只会增大索引体积、拖慢写入，对 GROUP BY 性能无帮助。

唯一例外：覆盖索引场景。比如查询 SELECT dept, COUNT(*) FROM user GROUP BY dept，而你建了 (dept) 索引——此时引擎可仅扫描索引树完成分组，无需回表查数据页。但如果还查 name 或 email，那就得回表，索引列再多也白搭。

所以重点永远是：**让分组列+过滤列尽可能走索引，而不是堆砌所有 SELECT 字段**。

真正容易被忽略的是：索引列顺序一旦定下，后续新增 WHERE 条件或调整 GROUP BY 列顺序，很可能让原有索引彻底失效，而不是“降级使用”。上线前务必用真实数据量 EXPLAIN 验证。