GROUP BY region, product_id执行变慢主因是分组键组合基数高导致中间结果集膨胀，如5个region×10万product_id达50万组，引发内存不足、磁盘临时表及Using temporary; Using filesort；需建严格匹配顺序的复合索引INDEX(region, product_id)，并前置WHERE过滤、慎用HAVING。
GROUP BY region, product_id 为什么执行变慢？
多列分组本身不慢，慢在数据库要为每组计算聚合值，而分组键组合越多、唯一值越分散，中间结果集就越大。比如 region 有 5 个值、product_id 有 10 万，组合后最多产生 50 万组——这会显著增加内存占用和磁盘临时表使用。
常见现象：EXPLAIN 显示 Using temporary; Using filesort，或查询耗时从毫秒级跳到秒级。
- 检查分组列基数：用
SELECT COUNT(DISTINCT region), COUNT(DISTINCT product_id) FROM sales看分布 - 避免低基数列前置：比如
status只有 'active'/'inactive' 两值，放在GROUP BY第一位会放大后续分组粒度 - 确认是否真需要所有组合：有时业务只要“每个 region 的 top 10 product”，那先
ROW_NUMBER() OVER (PARTITION BY region ORDER BY sales DESC)再过滤，比全量分组快得多
哪些索引能真正加速 GROUP BY a, b？
单列索引对多列分组基本无效；必须建复合索引，且顺序要和 GROUP BY 列一致（或前缀匹配）。例如 GROUP BY region, product_id，索引应为 INDEX(region, product_id)，而不是 INDEX(product_id, region) 或两个单列索引。
关键点：
- 索引列顺序必须严格匹配分组顺序，否则优化器可能放弃使用
- 如果
SELECT还包含WHERE region = 'CN'，该索引还能顺便过滤，进一步减少扫描行数 - 若查询中还有
ORDER BY region, product_id，同一索引可同时满足分组与排序，省去额外排序开销 - 不要在索引里加聚合字段（如
sales_amount），它不参与分组逻辑，纯属冗余
物化视图适合什么场景？
物化视图本质是把 GROUP BY 结果固化成一张物理表，适合查询模式稳定、数据更新不频繁的汇总需求。PostgreSQL 的 MATERIALIZED VIEW 或 Oracle 的物化视图能直接跳过分组计算。
但要注意限制：
- MySQL 不原生支持物化视图，需用定时任务 + 普通表模拟，且手动处理刷新逻辑
- 如果基础表每天增量 100 万行，但物化视图按天全量重算，反而拖慢 ETL 流程
- 当
GROUP BY中含CASE WHEN或函数（如DATE(created_at)），物化视图定义必须显式写出相同表达式，否则无法命中 - 权限和存储成本：物化视图占用额外磁盘空间，且需
REFRESH权限，DBA 通常限制非核心业务使用
HAVING 和 WHERE 的位置陷阱
很多人以为 HAVING 是“分组后的 WHERE”，就习惯性把所有过滤条件塞进去。但 HAVING SUM(sales) > 1000 是在分组后计算并过滤，而 WHERE status = 'shipped' 完全可以在分组前筛掉 90% 行——后者节省的是整个分组过程的 CPU 和内存。
典型错误写法：
SELECT region, product_id, SUM(sales)
FROM sales
GROUP BY region, product_id
HAVING region IN ('CN', 'US') AND SUM(sales) > 1000;
正确做法是把 region 条件提前到 WHERE：
SELECT region, product_id, SUM(sales)
FROM sales
WHERE region IN ('CN', 'US')
GROUP BY region, product_id
HAVING SUM(sales) > 1000;
容易被忽略的一点：某些数据库（如旧版 MySQL）在 WHERE 中引用别名会报错，但 region 是原始列，不存在这个问题——别为了“统一风格”而牺牲性能。
