结论：GROUP BY 多字段需严控顺序、NULL 处理及非聚合字段全包含。顺序影响分组层级、隐式排序与索引命中；非聚合字段必须全部列入 GROUP BY，否则报错或结果不可靠；NULL 值会单独成组，须用 COALESCE 或 CASE 预处理；WHERE 筛行、HAVING 筛组，不可混淆。
直接说结论：用 GROUP BY 后跟多个字段名即可，但顺序、NULL 处理、非聚合字段是否全部包含，这三点不处理好，结果就错。
GROUP BY a, b 的顺序到底要不要care？
要。不是数据对错问题，而是分组层级和后续排序逻辑会被悄悄影响。
- 写
GROUP BY region, product，系统先按region拆大组，再在每个region内按product细分；反过来就是先按产品再看区域——业务语义可能完全不同 - MySQL 5.7+ 默认会按
GROUP BY列顺序隐式排序，如果你没写ORDER BY，翻页或导出时顺序可能“跳变” - 索引能否命中也依赖顺序：比如有联合索引
(year, dept, role)，GROUP BY year, dept能走索引，但GROUP BY dept, role就不行（MySQL 要求最左前缀匹配）
SELECT 中出现的非聚合字段必须全写进 GROUP BY
这是 MySQL 5.7+ 严格模式下的硬性要求，也是逻辑正确性的底线。
- 比如你写
SELECT class_id, sub_name, mark_year, SUM(mark_mark)，那GROUP BY里就必须包含class_id、sub_name、mark_year——少一个，要么报错，要么返回不可靠值（随机取某一行） - 别指望数据库“猜”你想要什么；
sub_name如果和subpid不是一对一（比如同名科目存在），建议用subpid替代sub_name入GROUP BY，更稳妥 -
LEFT JOIN后加了WHERE m.mark_category = 'A'，实际会让LEFT JOIN变成INNER JOIN效果，不如一开始就写INNER JOIN，语义清晰且执行计划更稳
NULL 值会单独成组，不处理就多出“未知行”
只要任意一个分组字段为 NULL，整行就会被归入一个独立分组，常导致报表里突然冒出一行 NULL / NULL / 12345。
- 用
COALESCE(region, 'Unknown')或CASE WHEN region IS NULL THEN 'N/A' ELSE region END提前转换，别留到分组后才发现 - 如果所有分组字段都为
NULL（比如关联失败又没过滤），那一整行仍参与分组，HAVING COUNT(*) > 0挡不住它，得靠WHERE预过滤 -
COUNT(*)统计该组总行数（含所有NULL），COUNT(region)只统计region非NULL的行数——两者语义不同，别混用
WHERE 和 HAVING 别放反，否则查得慢还结果错
执行顺序是铁律：WHERE 先筛原始行，HAVING 再筛分组后的聚合结果。
- 时间范围、状态码、ID 区间等单行判断条件，一律进
WHERE；比如WHERE mark_year >= 2023，别拖到HAVING - 涉及
COUNT、SUM、AVG的条件，只能放HAVING；比如HAVING SUM(mark_mark) > 500，放WHERE直接报错：ERROR: aggregate functions are not allowed in WHERE - 如果误把时间条件放
HAVING，数据库会先把所有年份的数据分组完，再逐个过滤，白白浪费 CPU 和内存
真正容易被忽略的是：多字段分组后，每组的“唯一性”其实由这些字段共同决定，而业务上是否真需要这个粒度，往往比语法本身更关键——比如按学生+科目+年份分组是对的，但漏掉了考试类型（期中/期末），汇总结果就失真了。
