GROUP BY字段顺序必须严格匹配索引最左前缀，否则索引完全失效；如索引为(region, category)却写GROUP BY category, region，MySQL将触发全表扫描和Using temporary，PostgreSQL虽略灵活但仍要求无跳列。
GROUP BY字段顺序不匹配索引最左前缀，直接触发全表扫描
MySQL 和 PostgreSQL 都依赖索引的最左前缀匹配 GROUP BY 字段顺序；建了 (region, category) 索引，但写 GROUP BY category, region，数据库就完全用不上这个索引。EXPLAIN 里会看到 type: ALL 或 Extra: Using temporary; Using filesort——这不是慢一点的问题，是数据量一上去就卡死。
常见错误现象：
- 明明加了复合索引，
GROUP BY a, b却没走索引 - 把高频筛选字段（如
WHERE status = 'active'）放在 GROUP BY 后面，导致无法复用索引 - 索引是
(a, c, b)，但 GROUP BY 写成a, b，因跳过c，b无法命中
实操建议：
- 索引字段顺序 =
WHERE 等值条件+GROUP BY 字段+ORDER BY 字段（三者严格连续） - 如果查询带
WHERE shop_id = 123 GROUP BY user_id，索引必须是(shop_id, user_id)，不是(user_id, shop_id) - 范围条件（如
created_at >= '2024-06-01'）必须放索引末尾，否则后续字段失效
GROUP BY和ORDER BY顺序不一致，必然触发二次排序
当同时存在 GROUP BY a, b 和 ORDER BY a, b，MySQL 才可能复用同一索引完成分组与排序；只要顺序错一位，比如 ORDER BY b, a，就会在执行计划里看到 Using filesort——这意味着数据库要额外做一次排序，I/O 和 CPU 开销陡增。
实操建议：
- 如果业务上允许，让
ORDER BY严格跟随GROUP BY字段顺序，避免隐式重排 -
GROUP BY a, b ORDER BY a, b, c要求索引是(a, b, c)；若索引只有(a, b)，c仍会触发 filesort - 别依赖 MySQL 5.7 以前“默认按 GROUP BY 顺序输出”的行为，8.0+ 和 PostgreSQL 均不保证，显式写
ORDER BY是底线
高基数字段放前面 ≠ 性能一定好，关键看是否减少中间分组桶数量
把 user_id（几乎每行唯一）放在 GROUP BY 开头，会导致哈希分组或排序阶段产生海量小桶，缓存失效、内存压力大；而 country（几十个值）+ device_type（3–5 个值）这种组合，先按 country 分再细分，更利于局部性与索引跳转。
实操建议：
- 优先选有天然层级关系的字段顺序，比如
region → city → store_id，符合数据分布规律 - 用
SELECT COUNT(DISTINCT col) FROM t快速估算各字段 NDV，辅助判断基数高低 - 避免把主键或唯一键放在
GROUP BY开头，除非你真想每行一个组 - NULL 值会被整行归入同一组，但顺序会影响它在结果中的“层级可见性”，比如
GROUP BY category, status中所有category IS NULL的记录会按status再分，但不会混入非 NULLcategory组
WHERE 和 GROUP BY 字段顺序共同决定索引有效性
索引不是只为 GROUP BY 服务的，它是为整个访问路径设计的：先 WHERE 过滤，再 GROUP BY 分组，最后可能 ORDER BY 排序。三者字段顺序必须链式对齐，断掉任何一环，后半段就退化。
实操建议：
- 查询
SELECT region, COUNT(*) FROM sales WHERE date >= '2025-01-01' GROUP BY region，理想索引是(date, region)，不是(region, date) - 函数分组（如
GROUP BY DATE(created_at)）会让原字段索引完全失效；MySQL 8.0+ 可建函数索引CREATE INDEX idx ON t ((DATE(created_at)))，注意括号不能漏 - PostgreSQL 对字段顺序容忍度略高（只要索引包含全部 GROUP BY 字段且无跳列），但 MySQL 仍是铁律：顺序错，索引废
