能提速，但仅当索引覆盖GROUP BY列及SELECT非聚合列、WHERE条件列置左，且EXPLAIN无Using temporary或filesort时才有效。
GROUP BY 查询慢，加索引真能提速吗
能，但只在特定条件下有效。MySQL 对 GROUP BY 的执行依赖是否能利用索引完成排序和分组——如果优化器可以跳过临时表和文件排序（Using temporary; Using filesort），性能提升会非常明显；否则加了索引也白加。
关键判断依据是 EXPLAIN 输出中是否出现 Using temporary 或 Using filesort。只要这两个提示还在，说明索引没被用于分组逻辑。
- 索引必须**覆盖 GROUP BY 列 + SELECT 中的非聚合列**（例如
SELECT a, COUNT(*) FROM t GROUP BY a，索引要包含(a)；若写成SELECT a, b FROM t GROUP BY a，则需(a, b)） - 如果语句含
WHERE条件，索引应把过滤列放在最左（如WHERE status=1 GROUP BY user_id，推荐索引(status, user_id)） - 避免在
GROUP BY列上用函数或表达式（如GROUP BY YEAR(created_at)），这会让索引失效
为什么给 GROUP BY 字段单独建索引有时没用
因为 MySQL 5.7+ 默认启用 sql_mode=ONLY_FULL_GROUP_BY，且优化器更倾向走「索引下推 + 聚簇索引回表」路径，而非纯索引扫描。单独一个 (user_id) 索引，在 SELECT user_id, SUM(amount) FROM orders GROUP BY user_id 中可能仍触发临时表——尤其当 amount 不在索引里，引擎得回主键查值，无法流式分组。
- 正确做法是建立**覆盖索引**：
ALTER TABLE orders ADD INDEX idx_uid_amount (user_id, amount) - 注意顺序：
GROUP BY列必须在索引最左，后续跟 SELECT 中的非聚合列（如还有status，就写成(user_id, status, amount)） - InnoDB 下，如果主键本身就是
user_id，那普通二级索引反而可能不如直接走聚簇索引（此时加索引未必有益）
ORDER BY + GROUP BY 混用时的索引陷阱
常见写法如 SELECT category, COUNT(*) FROM products GROUP BY category ORDER BY COUNT(*) DESC，看起来想按聚合结果排序，但 MySQL 无法用索引加速这个 ORDER BY，因为 COUNT(*) 是计算值，不是索引字段。
- 这种场景下，索引对
GROUP BY仍有用（比如(category)可避免临时表），但ORDER BY COUNT(*)必然触发额外排序 - 若必须高频执行，考虑物化中间结果：用
CREATE TEMPORARY TABLE或生成汇总表（如stats_category_count），定时更新 - 不要试图用
ORDER BY category来“假装优化”——它和聚合排序无关，且可能误导你误判索引效果
聚合查询中 COUNT(*) 和 COUNT(列) 的索引表现差异
COUNT(*) 在 InnoDB 中可走最小索引（比如二级索引比主键小，优化器可能选它来快速数行）；而 COUNT(非空列) 或 COUNT(可为 NULL 的列) 必须检查每行该列是否为 NULL，这时候索引是否包含该列就直接影响性能。
- 如果经常执行
COUNT(status)，且status允许为NULL，那么索引(status)就比没有强——至少避免回表 - 但
COUNT(*)在有合适二级索引时，可能连索引都不需要全扫（InnoDB 维护了行数估算），所以别盲目为COUNT(*)建索引 - 真正要优化的是带条件的聚合，比如
COUNT(*) WHERE deleted=0 GROUP BY type—— 这时复合索引(deleted, type)才关键
最常被忽略的一点：GROUP BY 性能不只看索引，还取决于数据分布。如果分组键基数极低（比如只有 3 个 status 值），即使没索引，临时表也很小；反之，如果分出 200 万组，再好的索引也救不了内存不足导致的磁盘临时表膨胀。
