group by多字段语法为group by field1, field2，用英文逗号分隔，顺序决定嵌套分组优先级；所有select中非聚合字段必须完整、一字不差地出现在group by中，否则mysql 8.0+/postgresql报error 1055。
GROUP BY 多字段语法怎么写
直接在 GROUP BY 后面跟多个字段名，用英文逗号分隔，顺序决定分组优先级。比如按部门和岗位统计人数：GROUP BY dept_name, job_title。注意字段必须出现在 SELECT 中（除非是聚合函数），否则 MySQL 8.0+ 和 PostgreSQL 会报错 ERROR 1055。
- 字段顺序影响结果排序逻辑：先按第一个字段分组，再在每个子组内按第二个字段分组
- 所有非聚合列都必须出现在
GROUP BY列表中，不能只写部分——这是 SQL 标准要求，不是 MySQL 特性开关能绕过的 - 如果用了
SELECT *，多字段GROUP BY几乎必然失败，因为 * 展开的列太多且不可控
常见错误：为什么 COUNT(*) 和 COUNT(字段) 结果不一样
COUNT(*) 统计每组的行数（包括 NULL），而 COUNT(字段) 只统计该字段非 NULL 的行数。例如统计每个部门下各岗位的员工数和有绩效评分的员工数：
SELECT dept_name, job_title,
COUNT(*) AS total_count,
COUNT(performance_score) AS scored_count
FROM employees
GROUP BY dept_name, job_title;
- 若某岗位下 5 人中有 2 人
performance_score IS NULL，则COUNT(*)返回 5，COUNT(performance_score)返回 3 - 别误用
COUNT(DISTINCT field)替代普通COUNT——它去重后计数，语义完全不同 - 在 SQLite 中
COUNT(NULL)是语法错误，必须用COUNT(*)或带字段名
ORDER BY 要不要加？什么时候必须显式写
GROUP BY 不保证输出顺序，即使你看到结果“刚好有序”，也不能依赖。MySQL 5.7 默认可能按分组字段顺序返回，但这是实现细节，升级到 8.0 或换数据库就失效。
- 需要稳定顺序必须显式写
ORDER BY dept_name, job_title，不能省略 -
ORDER BY字段可以是SELECT中的别名（如ORDER BY total_count DESC），但不能是未出现在SELECT中的原始字段（除非也在GROUP BY里） - 在窗口函数配合
GROUP BY时（如ROW_NUMBER() OVER (PARTITION BY dept_name ORDER BY COUNT(*) DESC)），内部ORDER BY和外层ORDER BY是两回事，别混用
性能陷阱：GROUP BY 多字段一定慢吗
不一定慢，但容易踩索引坑。数据库对多字段 GROUP BY 最好能用上复合索引，且字段顺序要和 GROUP BY 一致。例如 GROUP BY region, category，索引应建为 INDEX(region, category)，反过来就无效。
- WHERE 条件字段如果也参与分组，优先把过滤字段放索引前面（如
WHERE status = 'active' GROUP BY region, category→ 索引设为(status, region, category)） - PostgreSQL 对
GROUP BY推导哈希聚合很激进，但内存不足时会落盘，查EXPLAIN看是否有HashAgg (disk) - SQL Server 的
GROUP BY若含TEXT/NTEXT字段会直接报错，得先转成VARCHAR(MAX)
实际写的时候，最容易被忽略的是字段顺序一致性：GROUP BY、SELECT 非聚合列、ORDER BY、索引定义这四者里的字段顺序稍有不一致，轻则结果错乱，重则查询变全表扫描。
