MySQL中GROUP BY性能差主要因缺索引、数据量大或聚合逻辑不合理；优化需确保GROUP BY字段有合适索引、优先WHERE过滤、避免函数分组、精简SELECT字段、用窗口函数替代低效关联，并考虑汇总表物化。
MySQL 中 GROUP BY 性能差，通常不是语法问题，而是缺少合适索引、数据量大或聚合逻辑不合理导致的。优化核心是让 MySQL 尽可能用索引完成分组，避免临时表和文件排序。
确保 GROUP BY 字段上有有效索引
MySQL 只有在能利用索引顺序完成分组时，才可能跳过排序操作。最理想情况是：索引字段顺序与 GROUP BY 列完全一致，且这些列都在索引的最左侧。
- 例如：
SELECT category, COUNT(*) FROM products GROUP BY category;，应在category上建单列索引，或作为联合索引的最左前缀 - 若语句是
GROUP BY a, b，索引必须是(a, b)或(a, b, c)，而不能是(b, a)或单独(a) - 使用
EXPLAIN查看type是否为index（而非ALL），并确认Extra中没有Using temporary; Using filesort
减少 GROUP BY 的数据扫描范围
在分组前先过滤，比全表分组后再用 HAVING 筛选更高效。WHERE 条件越早缩小结果集，GROUP BY 处理的数据就越少。
- 优先用
WHERE过滤行，而不是依赖HAVING（后者是在分组后才执行） - 避免在
GROUP BY表达式中使用函数或计算，如GROUP BY YEAR(create_time)会导致索引失效；可考虑冗余一个生成列并为其建索引 - 大表分组时，考虑加时间范围限制：
WHERE create_time >= '2024-01-01'
避免 SELECT * 和多余字段参与分组
SELECT 列中所有非聚合字段，都必须出现在 GROUP BY 子句中（SQL 标准模式下）。多出的字段会强制 MySQL 做更复杂的分组逻辑，甚至触发隐式排序。
- 只查真正需要的字段，尤其是避免
SELECT *后跟GROUP BY id - 如果只需要每个分组的某一条记录（如最新一条），不要用
GROUP BY+MAX(time)再关联查询，改用窗口函数（MySQL 8.0+）或关联子查询优化 - 确认 SQL 模式是否启用
ONLY_FULL_GROUP_BY，避免因不合规写法导致执行计划退化
考虑物化中间结果或汇总表
对于高频、固定维度的统计查询（如按日/按地区销量汇总），实时计算代价高，可提前聚合并存入汇总表。
- 用定时任务（如每天凌晨）将明细数据聚合写入
sales_summary_daily表 - 查询时直接读汇总表，响应快、压力小
- 配合触发器或应用层双写，保证轻量级实时性（如最近1小时数据仍查明细）
