GROUP BY多字段需用逗号分隔，顺序不影响分组逻辑但影响排序；常见错误是SELECT非聚合字段未出现在GROUP BY中，触发ONLY_FULL_GROUP_BY报错；取每组首行须用窗口函数而非GROUP BY直接实现。
GROUP BY 多字段的写法和常见错误
直接在 GROUP BY 后面用逗号分隔多个列名，顺序无关分组逻辑，但影响结果排序（若没加 ORDER BY，数据库可能按分组字段顺序隐式排序）。别写成 GROUP BY (col1, col2) —— 括号是多余的，会报语法错误（MySQL 8.0+ 会提示 “syntax error near '('”）。
常见错误现象：ERROR 1055 (42000): Expression #3 of SELECT list is not in GROUP BY clause，这是 SQL 标准模式（ONLY_FULL_GROUP_BY 开启时）的典型报错，说明 SELECT 里出现了未出现在 GROUP BY 中、又没被聚合函数包裹的字段。
- 正确写法：
GROUP BY dept_id, job_title - 错误写法：
GROUP BY (dept_id, job_title)或GROUP BY dept_id AND job_title - 如果用了
SELECT *，必须确保所有非聚合字段都列在GROUP BY中
多字段分组后如何选“每组第一条”数据
单纯 GROUP BY a, b 只能配合聚合函数（如 MAX()、COUNT()）出统计结果，拿不到原始行。想取每组中某条件下的完整记录（比如最新一条、薪资最高者），不能靠 GROUP BY 直接实现，得用窗口函数或关联子查询。
推荐用 ROW_NUMBER() 窗口函数（MySQL 8.0+/PostgreSQL/SQL Server 支持）：
SELECT emp_id, dept_id, job_title, salary
FROM (
SELECT emp_id, dept_id, job_title, salary,
ROW_NUMBER() OVER (PARTITION BY dept_id, job_title ORDER BY salary DESC) AS rn
FROM employees
) t
WHERE rn = 1;
注意：PARTITION BY dept_id, job_title 就是联合分组逻辑；ORDER BY 决定“第一条”的定义。别误用 RANK() 或 DENSE_RANK()——它们对并列值处理不同，可能返回多行。
GROUP BY 多字段的性能与索引建议
联合分组本身不慢，但扫描全表再内存分组就很慢。关键看有没有覆盖索引支持 GROUP BY 字段 + SELECT 中的非聚合字段。
- 理想索引：
CREATE INDEX idx_dept_job_salary ON employees(dept_id, job_title, salary);（把GROUP BY字段放前面，聚合依据字段（如salary）放后面） - 如果查询含
HAVING COUNT(*) > 1，索引仍有效；但含WHERE条件时，需确认条件字段是否也在索引前列，否则可能无法使用索引下推 - SQLite 和旧版 MySQL（5.7-）对多列索引的最左前缀匹配更敏感，
GROUP BY job_title, dept_id无法利用(dept_id, job_title)索引
MySQL 5.7 默认开启 ONLY_FULL_GROUP_BY 的坑
很多线上环境升级 MySQL 后，原来能跑的多字段 GROUP BY 查询突然报错，大概率是这个模式惹的祸。它强制要求：所有 SELECT 列要么在 GROUP BY 中，要么被聚合函数包裹。
临时绕过（不推荐生产）：SET sql_mode=(SELECT REPLACE(@@sql_mode,'ONLY_FULL_GROUP_BY',''));
真正解决方式是重写查询：
- 删掉
SELECT中多余的非聚合字段 - 或者补全
GROUP BY字段（例如原GROUP BY dept_id却SELECT dept_id, job_title, COUNT(*)，就得改成GROUP BY dept_id, job_title） - 若真需要“任意一行”的值（比如取某个字段的示例值），改用
ANY_VALUE(col)函数（MySQL 5.7+）
联合分组看着简单，但实际踩坑多在语义理解（GROUP BY 是分组逻辑，不是取行逻辑）和执行环境约束（SQL 模式、版本、索引设计）上，这两块漏掉一个，查出来的数据就可能不对或根本跑不动。
