GROUP BY 多维统计慢的核心是索引未覆盖分组字段组合顺序及过滤条件，需按最左前缀原则设计索引，前置高频过滤字段，添加聚合字段实现覆盖，避免函数或隐式转换导致索引失效。

GROUP BY 多维度统计慢，核心问题往往不在 SQL 写法本身，而在于索引是否覆盖了分组字段的组合顺序与过滤条件。设计不当的索引会导致全表扫描或临时表排序，性能断崖式下降。

索引字段顺序必须匹配 GROUP BY 的最左前缀

MySQL 和 PostgreSQL 等主流数据库对 GROUP BY 使用索引的前提是：索引的最左连续字段恰好是 GROUP BY 子句中出现的字段（顺序一致、无跳过）。例如：

• SQL 是 GROUP BY region, city, category → 推荐索引：(region, city, category)
• 若只建了 (city, region, category)，则无法用于该 GROUP BY，因为顺序不匹配
• 若建了 (region, category)，缺少 city，也无法完整匹配，可能退化为文件排序

把高频 WHERE 条件字段前置到索引中

实际查询往往带过滤条件，如 WHERE status = 'active' AND region IN ('CN','US') GROUP BY city, category。此时应把过滤性强、区分度高的字段放在索引前面：

• 理想索引：(status, region, city, category) —— 先快速定位数据范围，再按分组字段有序组织
• 避免仅建 (city, category)：即使能走索引，仍需回表或扫描大量无关行
• 注意：IN 列表较短（如 2~3 个值）时，仍可有效利用索引；若值过多，考虑改用临时表或物化中间结果

覆盖索引减少回表，尤其含聚合字段时

如果 SELECT 中包含非分组字段的聚合（如 AVG(price), COUNT(*)），且 price 存在于原表中，可在索引末尾加上这些字段，实现“索引覆盖”：

• 例如：GROUP BY region, city，同时查 AVG(price), MAX(created_at)
• 索引建议：(region, city, price, created_at)
• 这样无需访问主表，全部在索引 B+ 树中完成分组与计算，显著降低 I/O
• 但注意索引宽度：price 和 created_at 若类型较大（如 TEXT、BIGINT），需权衡空间与性能

避免隐式类型转换和函数包裹分组字段

以下写法会直接导致索引失效：

• GROUP BY UPPER(city) → 即使有 city 索引也用不上
• GROUP BY DATE(created_at) → 日期函数破坏索引有序性
• WHERE region = 123 GROUP BY region → 若 region 是字符串类型（如 '123'），数字比较引发隐式转换

解决办法：统一数据类型，必要时增加生成列 + 索引，例如：

ALTER TABLE sales ADD COLUMN city_upper VARCHAR(64) STORED AS (UPPER(city));
CREATE INDEX idx_region_city_upper ON sales(region, city_upper);