复合索引最左前缀不满足时，GROUP BY 无法使用索引，因为MySQL优化器直接放弃索引而全表扫描+临时表排序；例如索引(user_id, status, amount)下，GROUP BY user_id或user_id,status可走索引，但GROUP BY status或user_id,amount则失效。
复合索引最左前缀不满足，GROUP BY 就没法用上索引
不是“部分列不能走”，而是 MySQL（和大多数主流数据库）压根不会去尝试用——只要 GROUP BY 字段顺序或组合不严格匹配复合索引的最左连续前缀，优化器就直接放弃走索引，转而全表扫描 + 临时表排序。
比如你建了索引 INDEX idx_user_status_amount (user_id, status, amount)：
-
GROUP BY user_id→ ✅ 走索引（只用最左1列） -
GROUP BY user_id, status→ ✅ 走索引（最左2列连续） -
GROUP BY status→ ❌ 不走（跳过user_id） -
GROUP BY user_id, amount→ ❌ 不走（amount不在status左侧，中间断开）
WHERE 和 GROUP BY 混用时，索引列顺序容易错位
很多人以为“只要字段都在索引里就行”，但实际执行计划中，WHERE 条件列必须放在 GROUP BY 列前面，否则索引可能只用于过滤、无法加速分组。
例如这个查询：
SELECT status, SUM(amount) FROM orders WHERE created_at > '2026-09-01' GROUP BY status;
如果索引是 (status, created_at)，那 WHERE 中的 created_at 是范围查询，status 反而被“卡”在后面，导致索引只能用于 GROUP BY，但 WHERE 部分无法高效定位——最终可能仍要扫大量行。
正确索引应为：(created_at, status, amount)，理由是：
-
created_at是范围条件，放最左可快速定位数据段 -
status紧跟其后，支持GROUP BY有序分组（避免Using temporary） -
amount放最后，构成覆盖索引，省去回表
聚合列没包含在索引里，照样要回表
建了 (user_id) 索引，但查询是 SELECT user_id, SUM(amount) FROM orders GROUP BY user_id —— 这个索引对 SUM(amount) 完全无用，因为 amount 不在索引中，MySQL 必须每组都回原表取值，IO 成倍增加。
真正有效的写法是让索引“覆盖”整个聚合需求：
-
COUNT(*)或COUNT(1)：只需(group_col)索引就够了 -
SUM(col)、AVG(col)、MAX(col)：必须把col加进索引，如(group_col, col) - 多个聚合列？比如
SUM(a), AVG(b)→ 索引得是(group_col, a, b)，顺序无关，但都得有
EXPLAIN 里出现 Using temporary 就说明索引没生效
这是最直接的信号。哪怕表只有几万行，只要 EXPLAIN 的 Extra 列里有 Using temporary，就意味着 MySQL 正在内存或磁盘上建临时表做分组排序——这时候再看索引是否建对、顺序是否匹配、列是否覆盖，比调优其他参数都管用。
注意几个典型陷阱：
-
GROUP BY DATE(created_at)→ 函数破坏索引，改用WHERE created_at >= '2026-10-01' AND created_at -
ORDER BY COUNT(*) DESC→ 这个排序永远无法走索引，COUNT(*)是计算结果，不是索引列 - 索引存在但
status字段只有两个值（比如 0/1），选择性太低，优化器可能主动弃用索引——这时得换高区分度字段前置，或考虑分区
真正卡住性能的，往往不是“有没有索引”，而是索引能不能让 GROUP BY 避开临时表；一旦出现 Using temporary，优先检查最左前缀、覆盖列、函数干扰这三点，比盲目加索引或调参更有效。
