GROUP BY字段顺序必须与索引最左前缀严格一致；仅当GROUP BY列构成索引的最左连续前缀时，MySQL才能利用索引有序性避免排序和临时表，否则索引失效。
GROUP BY字段顺序必须和索引最左前缀严格一致
MySQL 的 GROUP BY 本身不“使用”索引，但它依赖索引的物理有序性来跳过排序（filesort）。只有当 GROUP BY 的列顺序与联合索引的**最左连续前缀**完全匹配时，数据库才能直接按索引顺序读取数据、逐组聚合，避免临时表和排序开销。
常见错误现象：GROUP BY status, user_id 却建了索引 (user_id, status) —— 这个索引对分组完全无效，因为 status 不在最左位置；哪怕只查 GROUP BY user_id，也必须是索引最左列才生效。
- 索引
(a, b, c)支持：GROUP BY a、GROUP BY a, b、GROUP BY a, b, c - 不支持：
GROUP BY b、GROUP BY b, c、GROUP BY a, c（跳过b就断了最左链） - WHERE 条件列必须放在索引最左：比如
WHERE shop_id = 123 GROUP BY user_id，索引就得是(shop_id, user_id)，不能反过来
WHERE + GROUP BY 组合决定了索引字段顺序
真正决定性能的不是单看 GROUP BY，而是整个访问路径：先过滤（WHERE），再分组（GROUP BY），最后可能排序（ORDER BY）。索引字段顺序必须按这个执行逻辑排布，否则后半段就失效。
例如查询：SELECT user_id, COUNT(*) FROM orders WHERE shop_id = 123 AND created_at >= '2024-06-01' GROUP BY user_id ORDER BY COUNT(*) DESC。这里 shop_id 是等值过滤，应放最左；user_id 是分组依据，紧随其后；created_at 是范围条件，只能放最后（且它之后的字段索引失效）；ORDER BY COUNT(*) 无法用索引优化，因为是聚合结果。
- 推荐索引：
(shop_id, user_id, created_at) - 错误写法：
(created_at, shop_id, user_id)——created_at是范围查询，导致shop_id和user_id都无法高效利用 - 别把大字段（如
TEXT或超长VARCHAR）塞进索引，会拖慢索引扫描甚至让优化器弃用索引
函数或表达式会让GROUP BY彻底失去索引能力
GROUP BY DATE(created_at) 看似合理，实则灾难：MySQL 必须对每一行计算 DATE() 函数结果，无法走 created_at 索引；即使你建了 (created_at) 索引，也完全失效。
正确做法是把时间逻辑下推到 WHERE，用范围比较替代函数分组：
SELECT DATE(created_at), COUNT(*) FROM orders WHERE created_at >= '2024-06-01' AND created_at < '2024-06-02' GROUP BY DATE(created_at);
- WHERE 先缩小数据集，GROUP BY 处理量级大幅下降
- 如果仍需按天分组，且高频查询，可考虑增加生成列
created_date DATE AS (DATE(created_at)) STORED并为其建索引 - 隐式类型转换同理：比如
WHERE user_id = '123'（字符串）对比INT字段，也会触发全表扫描
SELECT中带MAX/MIN时，索引覆盖能避免回表
如果查询里有 SELECT user_id, MAX(updated_at)，而索引是 (shop_id, user_id, updated_at)，那么在满足 WHERE shop_id = ? 后，MySQL 可以直接从索引页拿到 updated_at 值，无需回到主键索引查原始行（即“索引覆盖”）。
但注意：这个优化只在 updated_at 在索引中且位置靠右时才稳定生效；如果它被放在索引中间（如 (shop_id, updated_at, user_id)），分组时因 user_id 无序，仍可能触发 filesort。
- 优先保证：WHERE 列 → GROUP BY 列 → 聚合所需单列（如 MAX/MIN 所在列）
- 不要为了覆盖而加冗余字段，索引宽度增大反而降低缓存命中率
- 用
EXPLAIN看type是否为range或ref，Extra是否含Using index或Using temporary; Using filesort
created_at > ?）一旦出现在索引中间，它右边所有字段都作废——这点在复合业务查询里极难察觉。 
