GROUP BY多字段必须确保SELECT中所有非聚合字段完整、一字不差地出现在GROUP BY子句中，且索引需按分组字段顺序建立联合索引，NULL和隐式差异需显式处理。
直接写 GROUP BY field1, field2, field3 就能实现多字段组合统计，但漏写非聚合字段、索引错配或 NULL 处理不当，都会让结果出错或变慢。
GROUP BY 多字段语法怎么写才不报错
核心规则就一条：SELECT 列表里所有没套聚合函数的字段，必须一字不差地出现在 GROUP BY 后面。
- 合法示例：
SELECT region, city, COUNT(*) FROM sales GROUP BY region, city - 非法写法：
SELECT region, city, status, COUNT(*) FROM sales GROUP BY region, city——status没进GROUP BY，MySQL 5.7+ 或 PostgreSQL 会直接报错ERROR 1055 - 别用别名替代原始字段名：
SELECT UPPER(city) AS city_name FROM t GROUP BY city是错的；得写成GROUP BY UPPER(city)或提前在 SELECT 里统一处理 - 字段顺序不影响分组逻辑，但会影响默认排序——如果依赖顺序，显式加
ORDER BY
为什么加了个字段，分组行数反而暴涨
这不是 bug，是分组粒度变细后的自然结果。比如原本按 region 分组有 5 行，加上 status 后变成 23 行，说明每个 region 内部 status 值分布很散。
- 先查分布：
SELECT region, status, COUNT(*) FROM sales GROUP BY region, status，确认是否真有多个status值混在同一个region里 - 注意隐式差异：字符串字段含空格（
'active 'vs'active'）、大小写（'Active'vs'active'）会被当成不同值，建议用TRIM(UPPER(status))统一后再分组 -
NULL会被当作一个独立分组值，如果某字段 NULL 占比高，会额外多出若干行；可用COUNT(*) FILTER (WHERE status IS NULL)（PostgreSQL）或SUM(CASE WHEN status IS NULL THEN 1 ELSE 0 END)快速估算
GROUP BY 多字段性能突然变慢怎么办
90% 的情况是索引没对上——单列索引对 GROUP BY a, b 几乎无效，必须建联合索引，且顺序要和 GROUP BY 字段一致。
- 错误做法：给
region和city各建一个单列索引 → 查询仍可能全表扫描 - 正确做法：建
INDEX idx_region_city ON sales(region, city)，B+ 树才能最左前缀匹配 - 如果查询还带
WHERE条件，比如WHERE region = '华东' AND city IN ('上海', '杭州')，这个联合索引依然生效；但若写成WHERE city = '上海'，索引就失效了 - 别在分组字段上套函数：
GROUP BY YEAR(order_date)会让索引失效，应提前用生成列或物化视图处理
需要层级小计（比如城市合计、大区合计）怎么搞
SQL 本身不分“嵌套”，所谓层级只是靠 WITH ROLLUP 或 GROUPING SETS 伪造出来的汇总行，它们本质是额外插入的 NULL 行。
- MySQL 用：
GROUP BY region, city WITH ROLLUP→ 生成(region, city)、(region, NULL)、(NULL, NULL)三类行 - PostgreSQL / SQL Server 用：
GROUP BY GROUPING SETS ((region, city), (region), ()) - 关键：别用
IFNULL(city, '城市小计')直接替换，万一真实数据里真有city = '城市小计'就冲突了；改用CASE WHEN GROUPING(city) = 1 THEN '城市小计' ELSE city END -
GROUPING()返回 1 表示该字段是汇总行生成的占位 NULL，不是原始数据里的 NULL
真正容易被忽略的是：多字段分组的结果是一张扁平表，不是树形结构；你看到的“层级”全是靠 NULL 和 GROUPING() 函数人工拼出来的，业务逻辑层千万别直接依赖这些 NULL 做判断。
