GROUP BY字段顺序必须与索引最左前缀严格一致才能命中索引，否则直接失效；如索引(a,b)仅支持GROUP BY a,b，不支持GROUP BY b,a或a,c（跳过b），否则触发全表扫描或filesort。
GROUP BY字段顺序不匹配索引最左前缀，索引直接失效
MySQL 和 PostgreSQL 对 GROUP BY 的索引利用完全依赖最左前缀匹配。哪怕字段全对、一个不缺，只要顺序错一位，索引就无法用于分组扫描——不是“效果差”，而是根本不用。
常见错误现象：EXPLAIN 显示 type: ALL 或 Extra: Using temporary; Using filesort，但你明明建了 (region, category) 索引，而查询写的是 GROUP BY category, region。
- 索引
(a, b, c)可支撑GROUP BY a, b、GROUP BY a, b, c，但不支持GROUP BY b, c或GROUP BY a, c（跳过b） - WHERE 条件字段应前置：如
WHERE status = 'active' GROUP BY region, city，理想索引是(status, region, city)，而非(region, city, status) - 即使
status基数低，也必须放最左——否则过滤后数据无法按后续字段物理有序读取
ORDER BY 和 GROUP BY 共用索引时，顺序错位会触发二次排序
如果查询同时含 GROUP BY a, b ORDER BY a, b，且存在索引 (a, b)，数据库可一次完成分组与排序；但若写成 GROUP BY a, b ORDER BY b, a，哪怕字段相同，也会强制执行 Using filesort。
- 索引
(a, b, c)支持GROUP BY a, b ORDER BY a, b, c，但不支持GROUP BY a, b ORDER BY a, c（中间跳过b） - MySQL 8.0+ 默认不保证
GROUP BY输出顺序，显式ORDER BY不可省略；但省略后加的ORDER BY若顺序不一致，代价更高 - 降序（
DESC）需在索引定义中显式声明，混合ASC/DESC时顺序和方向都必须严格一致
高基数字段放前面≠一定更好，关键看是否减少分组桶数量
把 user_id 放 GROUP BY 首位，几乎等于没分组——每行一个桶，哈希表或排序开销拉满；而 country（几十值）→ device_type（3–5值）这种天然层级顺序，更利于缓存局部性和索引跳转。
- 用
SELECT COUNT(DISTINCT col) FROM t快速估算各字段 NDV，辅助判断实际区分度 - 避免将主键或唯一键放在
GROUP BY开头，除非你真需要逐行聚合 - 业务上存在层级关系的字段（如
region → city → store_id）通常就是最优顺序，比纯按基数排序更可靠
NULL 值参与分组时，顺序会影响结果“可见层级”
所有数据库都将 NULL 视为相同值参与分组，但字段顺序会影响它在最终结果中的呈现位置。例如 GROUP BY a, b 中若 a IS NULL，则所有 a=NULL 的行先被归为一组，再按 b 细分；反过来写成 GROUP BY b, a，就会先按 b 分，b 相同再按 a 分——NULL 被“压”到第二层，可能让聚合结果看起来不一致。
这不是 bug，但容易误判。尤其当报表逻辑隐含层级假设（比如“先看地区，再看品类”），而索引/查询顺序与之相反时，问题会藏得很深。
真正难的不是建索引，而是把 WHERE 过滤、GROUP BY 分组、ORDER BY 排序、SELECT 字段这四者的列顺序，在一张索引里对齐——漏掉任意一环，性能就断崖下跌。
