SQL报表中GROUP BY慢的核心原因是索引无法支持分组，需按WHERE字段前置、GROUP BY字段严格左序、覆盖筛选+分组+排序来设计组合索引，并避免Using temporary和filesort。
SQL报表中GROUP BY慢，核心原因往往是数据库无法有效利用索引完成分组操作，导致全表扫描+内存排序。关键不在于“加索引”，而在于让索引结构与GROUP BY字段、WHERE条件、SELECT聚合列形成匹配关系。
索引字段顺序必须严格匹配GROUP BY顺序
MySQL和PostgreSQL等主流数据库要求：若GROUP BY a, b, c，则高效索引必须以a, b, c为最左前缀（可额外追加其他字段）。只建(b, a, c)或(a, c)无法跳过排序步骤。
- ✅ 正确示例：
GROUP BY dept_id, status→ 建索引(dept_id, status, create_time) - ❌ 无效示例：
(status, dept_id)或(dept_id)—— 后者虽能过滤但无法避免对status重新排序
WHERE条件字段要前置在索引中，且顺序优先于GROUP BY
索引需先满足过滤需求，再服务分组。如果查询带WHERE org_id = ? AND dept_id = ? GROUP BY status，索引应为(org_id, dept_id, status)，而非(status, org_id, dept_id)。
- 数据库会先用前缀字段快速定位数据范围，再在该范围内天然有序地分组
- 若
WHERE字段未包含在索引中，即使GROUP BY字段有索引，仍需回表或全扫
聚合字段（如SUM、COUNT）无需加入索引，但SELECT中的非聚合列必须是GROUP BY子集
索引本身不加速计算，但影响能否使用“松散索引扫描”（Loose Index Scan）。若SELECT dept_id, COUNT(*) FROM t GROUP BY dept_id，索引(dept_id)即可支持；但若写成SELECT dept_id, name, COUNT(*)且name不在GROUP BY中，不仅报错，更说明逻辑错误。
- 检查SQL是否符合SQL92标准：所有非聚合列必须出现在
GROUP BY列表中 - 避免
SELECT *+GROUP BY id这类隐式依赖，极易触发文件排序（Using filesort）
小表分组不必强求索引，大表务必覆盖筛选+分组+排序三重路径
当数据量低于5万行且无复杂过滤时，优化器可能认为全表扫描比走索引再回表更快。但超过百万级后，一个设计合理的组合索引能将GROUP BY耗时从秒级压至毫秒级。
- 用
EXPLAIN确认是否出现Using temporary; Using filesort—— 这是索引失效的明确信号 - 对高频报表表，可建立专用覆盖索引，例如：
(org_id, dept_id, status, amount)，让聚合直接在索引中完成，避免访问主键聚簇索引
索引不是越多越好，而是要让每一条GROUP BY查询都能“走直线”——从WHERE切片，到GROUP BY自然归并，再到聚合结果输出，全程不落地、不重排。
