GROUP BY字段顺序必须严格匹配索引最左前缀才能命中索引；MySQL不重排索引列，若建索引(region, product_id)却写GROUP BY product_id, region，则索引完全失效，触发Using temporary和Using filesort。
GROUP BY字段顺序直接影响索引能否被命中
MySQL不会自动重排索引列顺序去匹配你的GROUP BY写法。如果你建了索引(region, product_id)，但写的是GROUP BY product_id, region，这个索引就完全用不上——MySQL无法跳过最左列直接按第二列排序扫描，只能全表扫+建临时表。
PostgreSQL稍灵活些，只要索引包含全部分组字段（顺序不限），且中间没跳列，就可能用上位图扫描或索引聚合；但MySQL严格依赖最左前缀匹配。
- 检查是否走索引：用
EXPLAIN看key列是否有值，同时紧盯Extra列——出现Using temporary或Using filesort就是信号 - 高频查询的
GROUP BY字段组合，必须显式建联合索引，单列索引基本无效 - 索引列顺序应和你最常写的
GROUP BY顺序一致，而不是按“哪个字段基数高”主观排序
WHERE + GROUP BY混合时，顺序错位会截断索引有效长度
联合索引是线性结构，一旦WHERE条件用了范围查询（比如created_at > '2025-01-01'），索引在该列之后的所有字段就失效了。如果索引是(date, region, status)，而你写WHERE date > '2025-01-01' GROUP BY region, status，那region和status根本进不了有序扫描路径。
- 把等值条件字段（如
tenant_id = 123）放在索引最左，再放范围字段，最后放GROUP BY剩余字段 - 避免在WHERE里混用
IN和范围条件——IN在MySQL中也视为范围，会截断后续索引 - 隐式类型转换（如
user_id = '123'对比BIGINT字段）会让整个索引失效，务必保持类型一致
ORDER BY未显式声明时，数据库可能“借用”GROUP BY顺序输出
虽然SQL标准不保证GROUP BY a, b后结果一定按a、b排序，但MySQL 5.7及以前版本在无ORDER BY时常常这么输出。这会导致你误以为“顺序无所谓”，直到升级到8.0或换库后结果顺序突变，前端翻页错乱、报表对不上。
- 永远显式写
ORDER BY，别依赖GROUP BY顺序 - 如果
ORDER BY字段和GROUP BY字段高度重合，优先让索引覆盖二者顺序，避免二次排序 -
ORDER BY NULL能抑制隐式排序，但只解决Using filesort，不解决Using temporary——后者才是性能断崖点
NULL值在多字段分组中会被强制归入同一物理分组桶
所有region IS NULL且status IS NULL的行，和所有region IS NULL但status = 'active'的行，不会被混在一起。但只要任意一个字段为NULL，它就无法和任何非NULL值合并——这意味着GROUP BY region, status和GROUP BY status, region在NULL分布不均时，实际分组数可能不同。
- 想排除NULL干扰？加
WHERE region IS NOT NULL AND status IS NOT NULL，比在HAVING里过滤更早生效 - 想把NULL当普通值展示？用
COALESCE(region, 'unknown')代替原字段，再参与分组 - 测试NULL影响：直接
SELECT region, status, COUNT(*) FROM t GROUP BY region, status，一眼看出NULL是否自成一组
