GROUP BY性能问题主因是分组逻辑失控而非数据量大，高基数字段直接分组导致磁盘临时表、索引失效，应通过JOIN降维、子查询预聚合、避免DISTINCT混用等方式优化。
GROUP BY 性能崩掉，八成不是数据量太大，而是分组逻辑失控——Using temporary; Using filesort 出现在 EXPLAIN 的 Extra 列里，就说明 MySQL 已经放弃索引优化，开始往磁盘上写临时表了。
为什么 GROUP BY 会触发磁盘临时表
每多一个分组字段，潜在分组数不是线性增长，而是乘积级膨胀。比如 GROUP BY region, city, user_id，哪怕只有 100 个 region、1000 个 city，百万用户也意味着上亿个桶。高基数列（如 user_id、ip_address）直接进 GROUP BY，等于主动关闭松散索引扫描（Using index for group-by）。
-
tmp_table_size和max_heap_table_size调再大也扛不住——磁盘 I/O 一上来，整个实例响应就拖慢 -
SHOW PROCESSLIST里频繁出现Coping to tmp table on disk，就是明确警报 - 不是“加索引就能解决”，而是分组维度本身已超出数据库合理处理范围
用 JOIN 替代原始粒度分组
真实业务中，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
当必须保留原始粒度（比如导出明细+汇总统计共存），强行在主查询堆字段会让优化器彻底放弃索引策略。更稳的做法是把高成本聚合下沉到子查询。
- 错误写法：
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 - 子查询体积小、速度快；外层
JOIN后的数据集已大幅缩小，GROUP BY不再扫全表
避免 DISTINCT + GROUP BY 混用
SQL 标准禁止两者共用，MySQL 低版本或关闭严格模式可能绕过语法检查，但执行时会退化为全表扫描 + 多次临时表构建 + 随机排序，Handler_read_rnd_next 指标飙升就是典型信号。
- 原写法（慢）：
SELECT DISTINCT channel_code, DATE_FORMAT(create_date, '%Y'), COUNT(DISTINCT order_no) FROM user_order WHERE del_flag='0' GROUP BY channel_code, DATE_FORMAT(create_date, '%Y') - 优化后（快）：
SELECT b.channel_code, DATE_FORMAT(b.create_date, '%Y'), COUNT(DISTINCT b.order_no) FROM user_order b JOIN (SELECT DISTINCT channel_code, DATE_FORMAT(create_date, '%Y') AS y FROM user_order WHERE del_flag='0' AND create_date BETWEEN '2017-01-01' AND '2018-12-31') t ON b.channel_code = t.channel_code AND DATE_FORMAT(b.create_date, '%Y') = t.y WHERE b.del_flag='0' GROUP BY b.channel_code, DATE_FORMAT(b.create_date, '%Y') - 子查询只取分组键组合，不碰原始明细；若需分页（如
LIMIT 80,20），必须放在子查询里，否则外层仍要处理全部分组
真正卡住 GROUP BY 的，往往不是参数或硬件，而是“该不该在这层做这个分组”的判断——降维、预过滤、拆解聚合，每一步都在把不可控变成可控。最容易被忽略的，是业务语义和物理分组之间的错位：你想要的是“高价值用户”，不是“每个 user_id”。
