GROUP BY字段顺序必须与索引最左前缀严格一致才能命中索引，否则触发全表扫描或filesort；如索引(region, category)仅支持GROUP BY region, category，不支持反序或跳过字段。
GROUP BY字段顺序必须和索引最左前缀完全一致
有影响，而且是决定性影响。MySQL、PostgreSQL 等主流数据库不会“智能匹配”字段集合，只认索引定义的字段顺序。比如建了 (region, category) 索引，GROUP BY region, category 能走索引；但 GROUP BY category, region 就无法利用——执行计划里 key 为空或显示 type: ALL，同时 Extra 出现 Using temporary; Using filesort。
- 索引
(a, b, c)可支撑GROUP BY a, b，但不支撑GROUP BY a, c（跳过b） - 即使 WHERE 条件用了
a = ?，若 GROUP BY 写成b, a，优化器仍大概率放弃该索引 - 方向也要一致：索引定义为
(a ASC, b DESC)，则GROUP BY a ASC, b DESC才可能复用；混用方向会退化为 filesort
WHERE + GROUP BY 复合场景下索引怎么排
真实查询往往带过滤条件，这时索引顺序要兼顾 WHERE 和 GROUP BY 的执行链路。WHERE 字段必须放最左，再接 GROUP BY 字段——因为 B+ 树只能从左到右连续匹配。
- 查询是
WHERE status = 'active' AND created_at > '2024-01-01' GROUP BY region, category，推荐索引：(status, region, category)或更优的(status, region, category, created_at) - 别把
created_at放在region前面：范围查询（>）会截断索引，导致region和category无法被有序扫描 - 用
IN替代部分范围条件可延续索引使用，比如created_at IN ('2024-01-01', '2024-01-02')能让后续字段继续生效
ORDER BY 和 GROUP BY 共用索引时顺序不能错位
如果查询同时含 GROUP BY a, b ORDER BY a, b，只要索引是 (a, b) 就能一次搞定分组和排序；但写成 GROUP BY a, b ORDER BY b, a，哪怕字段完全一样，也会触发二次排序。
- MySQL 8.0+ 支持降序索引，但 5.7 及以前对
ORDER BY a DESC, b ASC这类混合方向基本无解，必出Using filesort -
GROUP BY a, b ORDER BY a理论上可省排序，但别依赖——显式写出更稳定，且避免未来升级后行为变化 - 加
ORDER BY NULL能抑制隐式排序，但仅消除Using filesort，不解决Using temporary
容易被忽略的 NULL 和基数陷阱
字段顺序不仅影响索引，还影响分组结果的物理分布和中间计算开销。高基数字段（如 user_id）放在 GROUP BY 开头，会让分组桶数量趋近于总行数，哈希表膨胀、缓存失效；而低基数字段（如 country）打头，能显著压缩中间态。
-
GROUP BY user_id, region几乎等价于全表扫描后逐行分组，临时表极易溢出磁盘 - NULL 值在所有数据库中都被视为相同值参与分组，但顺序会影响它在结果中的“层级位置”，比如
GROUP BY region, category中region IS NULL的组会先出现，而反序则可能被归入不同逻辑层 - 用
SELECT COUNT(DISTINCT col)快速估算 NDV，比凭经验猜更可靠
索引字段顺序不是“写对就行”的细节，它是让数据在磁盘上按查询意图自然排列的关键。一旦顺序错一位，B+ 树就失去有序遍历能力，整个分组路径被迫切回低效的哈希/排序模式。
