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) 是合法写法——所有主流数据库都会报错或静默出错，老老实实写逗号分隔