GROUP BY 慢主要因未走索引分组，触发 Using temporary 或 Using filesort；需索引字段顺序严格匹配 GROUP BY 且覆盖 WHERE 条件，仅查分组键和聚合结果，并确保分组离散度低。
GROUP BY 为什么慢？先看执行计划里有没有 Using filesort 或 Using temporary
MySQL 对 GROUP BY 的处理依赖是否能复用索引排序。如果索引不能同时满足分组字段顺序和排序需求，就会触发临时表和文件排序——这两个标记一出现，基本就说明没走对索引。尤其当 EXPLAIN 的 type 是 ALL 或 index（全索引扫描）时，即使加了索引也可能白搭。
索引字段顺序必须严格匹配 GROUP BY 字段顺序
MySQL 只能利用索引的最左前缀做分组，且字段顺序、方向（ASC/DESC）必须与 GROUP BY 子句完全一致。比如：
SELECT dept_id, status FROM orders GROUP BY dept_id, status;
对应索引必须是：INDEX(dept_id, status)。写成 INDEX(status, dept_id) 就无效；加了 ORDER BY status DESC 但索引是 dept_id ASC, status ASC，也会退化。
系统功能强大、操作便捷并具有高度延续开发的内容与知识管理系统，并可集合系统强大的新闻、产品、下载、人才、留言、搜索引擎优化、等功能模块，为企业部门提供一个简单、易用、开放、可扩展的企业信息门户平台或电子商务运行平台。开发人员为脆弱页面专门设计了防刷新系统，自动阻止恶意访问和攻击；安全检查应用于每一处代码中，每个提交到系统查询语句中的变量都经过过滤，可自动屏蔽恶意攻击代码，从而全面防止SQL注入攻击
- 复合索引中，
GROUP BY字段必须从左到右连续出现，不能跳过中间字段 - 如果查询还有
WHERE条件，索引应把过滤字段放在最左，再接GROUP BY字段（例如WHERE category = ? GROUP BY dept_id, status→ 索引为INDEX(category, dept_id, status)） - MySQL 8.0+ 支持降序索引，如需
GROUP BY a DESC, b ASC，索引得显式声明为INDEX(a DESC, b ASC)，否则仍可能无法覆盖
避免 SELECT 中出现非分组字段或聚合函数外的列
开启 sql_mode=ONLY_FULL_GROUP_BY（默认启用）后，SELECT 列表里所有非聚合字段都必须出现在 GROUP BY 中，否则报错：Expression #1 of SELECT list is not in GROUP BY clause。这个限制不是性能问题，但会让人误以为加了索引就能随便选字段。实际上，一旦写了 SELECT * 或引入未分组字段，优化器大概率放弃索引分组，改走临时表。
- 只查分组键和聚合结果，例如：
SELECT user_id, COUNT(*) FROM log GROUP BY user_id - 不要在
SELECT里混用MAX(created_at)和裸字段ip（除非ip功能依赖于user_id，且启用了functional_dependence，但不建议依赖此行为） - 若真需要额外字段，优先用
ANY_VALUE()显式声明，但注意这不会提升性能，只是绕过语法检查
小数据量别硬套索引，大分组数反而让索引失效
索引优化 GROUP BY 的前提是：分组键重复度高、分组后结果集远小于原表行数。如果 GROUP BY id（主键），等于每行一个组，优化器会直接放弃索引分组，因为逐条回表比建临时表还贵。这时 EXPLAIN 会显示 type: index 甚至 ALL，但实际执行可能更慢。
- 用
SELECT COUNT(DISTINCT group_col) / COUNT(*) AS selectivity估算分组离散度；值越接近 1，索引收益越低 - 对超大表做分组统计，考虑预聚合（如汇总表 + 定时更新）或物化视图（MySQL 8.0 不原生支持，需用
CREATE TABLE ... AS SELECT模拟） - 某些场景下，强制使用索引（
FORCE INDEX）反而更差，务必对比EXPLAIN FORMAT=TREE中的 cost 估算
GROUP BY 的瓶颈常藏在数据分布、字段选择性和执行路径判断里。真正有效的优化，往往是从 EXPLAIN 里看到 Using index for group-by 这一行开始的——其余都是干扰项。 
