直接写 GROUP BY field1, field2, field3 即可，但必须确保所有非聚合字段全部列出、顺序影响分组逻辑与索引命中、NULL 会单独成组、WHERE 筛行而 HAVING 筛组、联合索引需严格匹配字段顺序。
GROUP BY 多字段语法怎么写？
直接写 GROUP BY field1, field2, field3 即可，不需要额外语法糖或括号包裹。但必须确保所有非聚合字段都列全——比如 SELECT region, product, SUM(sales)，那 GROUP BY 后就必须是 region, product，少一个就报错或结果不可靠。
常见错误现象：Expression #2 of SELECT list is not in GROUP BY clause（MySQL 5.7+ 严格模式下）；PostgreSQL/SQL Server 直接拒绝执行。
- 字段顺序不是“可选”，而是决定分组逻辑：
GROUP BY region, product先按区域再细分产品；反过来就是先按产品再看区域，业务语义可能完全不同 - 别用别名替代原始字段名：
SELECT d.name AS dept_name后，GROUP BY dept_name在 MySQL 中不生效，得写GROUP BY d.name - 多表 JOIN 时必须加表前缀：
GROUP BY u.id, o.status，不能只写id, status，否则歧义或报错
NULL 值在多字段分组里怎么处理？
NULL 在分组中被当作一个独立且相等的值，只要任意一个分组字段为 NULL，整行就会归入一个单独分组。比如 region 为空、product 为 "A" 的记录，会和所有 region IS NULL AND product = 'A' 的记录同组，但绝不会和 region = 'CN' 的任何行混在一起。
容易踩的坑：报表里突然多出一行 NULL / NULL / 1234，或者某类“未知来源”数据被悄悄汇总进一个隐性分组。
- 想排除
NULL参与分组：前置过滤，WHERE region IS NOT NULL AND product IS NOT NULL - 想把
NULL显式转为可读标识：用COALESCE(region, 'Unknown')或CASE WHEN region IS NULL THEN 'N/A' ELSE region END替换原字段再分组 - 注意
COUNT(*)和COUNT(region)差异：前者统计整组行数（含region为NULL的行），后者只统计region非空的行
WHERE 和 HAVING 在多字段分组里怎么分工？
执行顺序是铁律：WHERE 先筛原始行，HAVING 再筛分组后的聚合结果。放反不仅逻辑错，还可能让查询慢几倍。
典型错误：把时间范围条件写进 HAVING，比如 HAVING order_date >= '2024-01-01' —— 这会先对全部历史数据分组，再逐组判断，浪费大量计算资源。
- 单行判断条件（时间、状态、ID 区间等）一律进
WHERE：如WHERE created_at >= '2024-01-01' AND status = 'paid' - 聚合函数条件（
COUNT(*) > 5、SUM(amount) > 10000）只能放HAVING -
HAVING中可以引用分组字段（如HAVING region != 'TEST'），但没实际意义，不如提前在WHERE过滤掉
多字段分组后性能和索引怎么优化？
联合索引是否命中，取决于 GROUP BY 字段顺序是否匹配索引最左前缀。顺序不对，索引基本失效。
比如有索引 (year, dept, role)，GROUP BY year, dept 能走索引；但 GROUP BY dept, role 就不行，MySQL 不支持跳过前缀字段。
- 建索引前先确认常用分组路径：如果业务常查“按年+部门”，就建
(year, dept)；如果常查“按部门+角色”，就建(dept, role) - 避免无谓的多字段分组：如果只是要每个
region的总销售额，别写GROUP BY region, product再用程序二次聚合 -
ORDER BY不继承GROUP BY顺序：即使你写了GROUP BY a, b，输出顺序仍是不确定的，需要显式加ORDER BY a, b
