GROUP BY多字段顺序影响分组维度，(a,b)与(b,a)逻辑不同；WHERE在分组前过滤，HAVING在分组后过滤；NULL在分组中视为相同值；统计需明细时应使用窗口函数或子查询。
GROUP BY 多字段时顺序影响结果吗？
不影响分组逻辑，但会影响排序输出和索引利用效率。MySQL、PostgreSQL、SQL Server 都按 GROUP BY 字段从左到右建立分组键，(a, b) 和 (b, a) 是两个完全不同的分组维度，不是“顺序无关”。如果你发现分组数变少或聚合值异常，先检查字段顺序是否和业务语义一致——比如按 region, product_type 分组，和按 product_type, region 分组，物理分组桶数量可能一样，但后续 ORDER BY 或程序解析时容易错位。
- ORDER BY 默认不继承 GROUP BY 顺序，必须显式写
ORDER BY region, product_type - 联合索引
(region, product_type)能加速GROUP BY region, product_type，但对反序无效 - SELECT 列中所有非聚合字段，必须完整出现在 GROUP BY 中（严格模式下，如 MySQL 5.7+ ONLY_FULL_GROUP_BY 开启时）
WHERE 和 HAVING 混用时，哪个先过滤？
WHERE 在分组前过滤行，HAVING 在分组后过滤组。这是执行顺序决定的，不是语法位置。常见错误是把本该写在 WHERE 的条件挪到 HAVING 里，比如想筛出「2023 年的订单」却写成 HAVING order_date >= '2023-01-01'——这会报错（因为 order_date 不在聚合结果里），或侥幸通过但性能极差（先分完所有年份的组，再逐组判断）。
- 数值类条件（如
amount > 100）可放 WHERE 或 HAVING，但放 WHERE 更快 - 聚合函数条件（如
COUNT(*) > 5）只能写在 HAVING - PostgreSQL 和 SQL Server 对 HAVING 中非分组字段更严格；MySQL 低版本可能允许，但行为不可靠
多字段 GROUP BY 遇到 NULL 怎么算？
NULL 在分组中被视为“相同值”，即所有 NULL 会被归入同一组。这点和 WHERE col = NULL（永远为 false）完全不同。如果你的 category 字段有大量空值，又用了 GROUP BY category, status，那所有 category IS NULL 的记录，会按 status 再细分——但只要 category 是 NULL，它们就不可能和其他非 NULL category 混在一起。
- 测试方法：用
SELECT category, status, COUNT(*) FROM t GROUP BY category, status直接看 NULL 行是否自成一组 - 想排除 NULL 参与分组？加
WHERE category IS NOT NULL AND status IS NOT NULL - 想把 NULL 当作字符串处理（如显示为 'unknown'）？用
COALESCE(category, 'unknown')替换原字段再 GROUP BY
统计结果要带原始明细怎么办？
不能直接在同一个 SELECT 里既 GROUP BY 又查未聚合的明细字段，否则报错或结果不可控。正确做法是用窗口函数，或者子查询 + JOIN。例如要查每个 region, product_type 组的总金额，同时列出该组内金额最高的那条订单：
SELECT region, product_type, order_id, amount,
SUM(amount) OVER (PARTITION BY region, product_type) AS group_total
FROM orders
WHERE rank() OVER (PARTITION BY region, product_type ORDER BY amount DESC) = 1;注意：这里用的是 rank() 窗口函数，不是 GROUP BY。如果数据库不支持窗口函数（如旧版 MySQL），就得用自连接或相关子查询，性能会明显下降。
- MySQL 5.7 不支持窗口函数，必须用 JOIN 模拟，注意关联条件别漏掉多字段等值
- SQLite 3.25+ 支持，但 PARTITION BY 后不能用表达式，只能是列名
- 避免在 GROUP BY 外层再套一层 SELECT * ——很多同学试图用 “SELECT *, SUM(...) FROM ... GROUP BY” 来“保留明细”，这是典型误解
实际写多字段分组时，最常卡住的地方不是语法，而是没想清楚「这一行数据到底属于哪个逻辑组」。字段含义模糊、NULL 处理随意、WHERE/HAVING 错配，三者叠加就很难 debug。先跑通单字段，再加第二个，比一上来堆五个字段更容易定位问题。
