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小时数据仍查明细）
