分组聚合（GROUP BY）在大数据量场景下容易成为性能瓶颈，核心问题常出在缺少合适的索引或索引未被有效利用。优化关键不是堆硬件，而是让数据库能快速定位、排序、去重和计算——这依赖于索引结构与查询模式的精准匹配。
索引要覆盖 GROUP BY 字段 + 聚合字段
仅对分组字段建索引往往不够。例如执行 SELECT dept_id, COUNT(*) FROM emp GROUP BY dept_id，理想索引是 (dept_id)；但若换成 SELECT dept_id, AVG(salary) FROM emp GROUP BY dept_id，则建议建 (dept_id, salary) 复合索引——这样可避免回表，且 MySQL 8.0+ / PostgreSQL 可直接用索引完成排序+聚合。
- 索引列顺序必须和 GROUP BY 子句字段顺序一致（如 GROUP BY a,b，则索引应为 (a,b)，而非 (b,a)）
- 聚合字段（如 salary）放在分组字段之后，才能支持索引覆盖扫描（Index Covering）
- COUNT(*)、MIN()、MAX() 对索引要求较低；SUM()、AVG()、STD() 更依赖索引中包含对应列
避免隐式类型转换和函数干扰索引
以下写法会让索引完全失效：
- GROUP BY UPPER(name) → 改为提前维护规范字段（如 name_upper），并在其上建索引
- GROUP BY DATE(create_time) → 改用范围条件 + 按日期字段分组，或建生成列索引（MySQL 5.7+）：ALTER TABLE t ADD create_date DATE AS (DATE(create_time)); CREATE INDEX idx_date ON t(create_date);
- WHERE status = '1' GROUP BY user_id（status 是 INT 类型）→ 字符串 '1' 触发隐式转换，导致索引失效
用物化视图或汇总表应对高频固定维度聚合
当某类 GROUP BY 查询（如按天/按地区/按品类统计销量）稳定且频繁，远超实时性要求（如T+1即可），应主动降维：
- 建立日粒度汇总表：sales_daily (dt, region, category, total_amt, order_cnt)，每日凌晨跑一次 INSERT ... SELECT ... GROUP BY
- 配合定时任务刷新，查询直接走主键或简单二级索引，响应从秒级降至毫秒级
- PostgreSQL 可用物化视图（CREATE MATERIALIZED VIEW），MySQL 可借助触发器或应用层双写保障一致性
检查执行计划，确认是否用了“Using index for group-by”
务必用 EXPLAIN FORMAT=TRADITIONAL（MySQL）或 EXPLAIN (ANALYZE, BUFFERS)（PostgreSQL）验证实际执行路径：
- MySQL 中出现 Using index for group-by 表示索引被高效用于分组，无需临时表或文件排序
- 若看到 Using temporary; Using filesort，说明当前索引不满足需求，需调整
- 注意 key_len 值是否与预期索引长度一致（比如 (a,b) 索引中 b 是 VARCHAR(100)，但只用到前 10 字节，key_len 会偏小，可能影响效率）
