GROUP BY字段顺序必须与索引最左前缀严格一致才能命中索引；如GROUP BY a, b仅能使用(a, b)索引，(b, a)或(a, c, b)均无效，否则触发全表扫描或filesort。
GROUP BY字段顺序如何影响索引是否生效
MySQL、PostgreSQL 等主流数据库对 GROUP BY a, b 的索引利用，严格依赖**最左前缀匹配**。这意味着只有当索引定义为 (a, b) 时，才能被该语句有效使用；反过来写成 (b, a)，即使字段完全相同，也无法命中。
常见错误现象：明明建了复合索引，EXPLAIN 却显示 type: ALL（全表扫描）或 Extra: Using temporary; Using filesort——大概率就是索引字段顺序和 GROUP BY 字段顺序不一致。
- 索引
(region, category)可加速GROUP BY region, category，但对GROUP BY category, region无效 - 若查询还带
WHERE status = 'active'，理想索引是(status, region, category)，把过滤字段放在最左 - 字段顺序错一位，比如建了
(a, c, b)却写GROUP BY a, b，b因跳过c而无法利用索引
高基数字段放前面真能提升性能吗
能，但不是绝对的“越高越好”，关键看它能否**显著减少中间分组桶数量**。例如 user_id 基数接近行数，用它做首个分组字段，几乎不会合并任何行，反而让哈希分组或排序开销拉满；而 country（几十个值）+ device_type（3–5 个值）组合，先按 country 分再按 device_type 细分，更利于缓存局部性和索引跳转。
- 优先选业务上天然有层级关系的字段顺序，比如
region → city → store_id，符合数据分布规律 - 避免把唯一键或主键放在
GROUP BY开头（除非你真想每行一个组） - 用
SELECT COUNT(DISTINCT col) FROM t快速估算各字段 NDV（distinct value count），辅助判断基数高低
ORDER BY 和 GROUP BY 共用索引时顺序必须严格一致
如果同时写 GROUP BY a, b ORDER BY a, b，数据库才可能复用同一个索引完成分组和排序；一旦顺序错位，比如 GROUP BY a, b ORDER BY b, a，就会触发二次排序（Using filesort），性能断崖下跌。
- MySQL 8.0+ 和 PostgreSQL 在
GROUP BY后默认不保证输出顺序，显式ORDER BY不可省略 - 联合索引
(a, b, c)可支撑GROUP BY a, b ORDER BY a, b, c，但不能支撑GROUP BY a, b ORDER BY a, c（c中间跳过了b） - 若只需按单字段排序（如
ORDER BY a），且a是GROUP BY的首字段，通常无需额外排序——但别依赖这个行为，显式写出更可靠
NULL 值和字段顺序一起出现时容易误判分组结果
所有数据库都把 NULL 当作相同值参与分组，但顺序会影响它在结果中的“可见层级”。比如 GROUP BY category, status 中，category IS NULL 的记录会按 status 进一步拆成多组；反过来写成 GROUP BY status, category，则 status IS NULL 的记录会按 category 拆分——两者的行数可能一样，但语义和下游程序解析逻辑完全不同。
- 上线前务必查原始数据中各字段的
NULL分布：SELECT COUNT(*) FILTER (WHERE category IS NULL) FROM t（PostgreSQL）或SUM(CASE WHEN category IS NULL THEN 1 ELSE 0 END)（通用） - 如果某字段
NULL占比超 20%，需评估是否应在应用层统一补默认值，或改用CASE WHEN ... ELSE 'unknown'预处理 - 不要假设
GROUP BY (a,b)是合法写法——所有主流数据库都会报错或静默出错，老老实实写逗号分隔
