能直接加速 group by 的索引必须满足字段顺序匹配分组逻辑且覆盖过滤与聚合列，否则退化为临时表+文件排序；有效索引需按 where + group by 顺序创建，如(status, dept_id, team_id)，并尽可能包含聚合字段以避免回表。
能直接加速 GROUP BY 的索引，必须满足两个硬条件：字段顺序匹配分组逻辑，且覆盖过滤与聚合所需列；否则数据库大概率退化为临时表 + 文件排序。
复合索引必须按 WHERE + GROUP BY 顺序建
MySQL 和 PostgreSQL 都依赖索引的物理有序性来避免显式排序。如果查询是 WHERE status = 'active' GROUP BY dept_id, team_id，那么有效索引只能是 (status, dept_id, team_id) 或 (status, dept_id, team_id, salary)（加聚合字段）。(dept_id, team_id) 单独存在也无效——因为 WHERE 条件没走索引，扫描行数爆炸，分组前数据量太大。
- 错误示例：
CREATE INDEX idx_dept_team ON emp(dept_id, team_id)→ 对WHERE status = 'active' GROUP BY dept_id几乎无用 - 正确写法：
CREATE INDEX idx_status_dept_team ON emp(status, dept_id, team_id) - PostgreSQL 中若
dept_id有单独索引但没包含status，优化器仍可能选HashAggregate，而非更轻量的GroupAggregate
覆盖索引能彻底避免回表
当 SELECT 中的非分组字段全在索引里，数据库不用查原表行，直接从索引页完成聚合。比如 SELECT dept_id, COUNT(*), AVG(salary) FROM emp WHERE status = 'active' GROUP BY dept_id，理想索引是 (status, dept_id, salary)。
- 如果只建
(status, dept_id)，AVG(salary)还得回表读每行salary，I/O 暴涨 - MySQL 8.0+ 支持函数索引，但
GROUP BY YEAR(create_time)仍无法用索引——得改用生成列 + 索引，如create_time_year INT AS (YEAR(create_time)) STORED，再建索引 - 字符串字段过长？用前缀索引（如
name(20)）可节省空间，但要确保前缀长度能区分业务值，否则分组结果不准
高基数字段分组时，索引可能失效
对 user_id（UUID）、email、ip_address 这类唯一值极多的字段做 GROUP BY，即使有索引，MySQL 也常触发 Using temporary; Using filesort —— 因为内存装不下几百万个分组桶，被迫写磁盘临时表。
- 检查执行计划：出现
Using temporary就代表已失控，索引救不了 - 别强行索引
GROUP BY email，先归一化：提取SUBSTRING_INDEX(email, '@', -1)做域名分组，再建索引 - PostgreSQL 用户可调大
work_mem，但单次查询超过 64MB 容易引发 OOM；MySQL 则受限于tmp_table_size和max_heap_table_size，且不能全局调太高，否则并发一高就内存溢出
真正卡住性能的往往不是“有没有索引”，而是“索引能不能让数据库跳过排序和临时表”——这要求你把 WHERE 条件、GROUP BY 字段、SELECT 中的聚合列，像拼图一样严丝合缝地塞进一个复合索引里，少一个环节，优化就断链。
