GROUP BY字段过多（尤其含高基数列）会引发磁盘临时表，应降维为低基数维度、用JOIN关联预处理字段、子查询先聚合再JOIN，或物化预聚合表。
GROUP BY字段太多导致Using temporary；必须降维或拆解
GROUP BY字段一超过3个，尤其含高基数列（如user_id、ip_address），MySQL极易触发磁盘临时表——EXTRA里出现Using temporary; Using filesort就说明分组已失控。这不是参数调大能解决的，是逻辑层面的数据膨胀问题。
- 每多一个分组字段，分组桶数量呈乘积级增长。比如
GROUP BY region, city, user_id，哪怕只有100个region、1000个city，百万用户也意味着上亿个潜在分组桶 -
user_id这类字段几乎必然高基数，直接参与分组等于放弃索引优化可能，松散索引扫描（Using index for group-by）完全失效 - 别指望
tmp_table_size调到8G就能扛住——磁盘临时表I/O会拖垮整个实例，SHOW PROCESSLIST里频繁看到Coping to tmp table on disk就是警报
把user_id换成user_type或region_id这类低基数关联字段
核心思路不是“少分一组”，而是“让每组有意义且可控”。真实业务中，90%的报表不需要按user_id聚合，需要的是其归属维度——这些维度通常已存在关联表中，且基数极低。
- 查“各地区高价值用户订单数”，别写
GROUP BY region, user_id，改用JOIN users u ON o.user_id = u.id GROUP BY region, u.tier（tier只有VIP/普通/试用3档） - 查“各渠道新用户来源分布”，别
GROUP BY channel, ip_address，而应先通过IP库映射出country或isp，再GROUP BY channel, country - 关键点：关联表的JOIN条件必须走索引（如
users.id主键、ip_geo.ip_range上的区间索引），否则只是把性能问题从GROUP BY转移到JOIN
用子查询先聚合再JOIN，避免笛卡尔爆炸
当必须保留原始粒度（如导出明细+汇总统计共存）时，强行在主查询里堆字段只会让优化器放弃所有索引策略。更稳的做法是把高成本聚合下沉到子查询，主表只负责轻量JOIN。
- 错误写法：
SELECT o.region, u.city, u.department, COUNT(*) FROM orders o JOIN users u ON o.user_id = u.id GROUP BY o.region, u.city, u.department—— 三字段联合分组，无索引可依 - 正确拆解：
SELECT t1.region, t2.city, t2.department, t1.cnt FROM (SELECT region, user_id, COUNT(*) cnt FROM orders GROUP BY region, user_id) t1 JOIN (SELECT id, city, department FROM users) t2 ON t1.user_id = t2.id
—— 子查询GROUP BY region, user_id虽仍慢，但至少可加INDEX(region, user_id)，且结果集远小于全表 - 注意：子查询结果若超
sort_buffer_size，仍会落盘；所以users表必须有PRIMARY KEY(id)，确保JOIN走主键查找而非全表扫描
为什么物化中间表比反复JOIN更可靠
当上述拆解仍无法满足秒级响应（比如日活百万用户按小时+城市+设备类型分组），说明实时计算已不可行。此时“预聚合”不是妥协，而是生产环境的标配。
- 建一张
summary_orders_hourly，主键为(hour_start, city_id, device_type)，每日凌晨用INSERT ... SELECT ... GROUP BY刷新昨日数据 - 关键约束：
ON DUPLICATE KEY UPDATE cnt = cnt + VALUES(cnt)支持增量合并，避免全量重刷；hour_start必须是DATETIME而非TIMESTAMP，防止时区转换引发重复或遗漏 - 最易忽略的一点：如果原始表有
WHERE status IN ('paid', 'shipped')，这个过滤条件必须下推到物化SQL里，否则汇总表会包含无效数据，后续查询还得二次过滤——又回到性能原点
