必须将SELECT中所有非聚合字段完整、一字不差地写入GROUP BY子句，如SELECT dept, region, COUNT(*) FROM employees GROUP BY dept, region；漏写或用别名/函数包装均会报错。
GROUP BY 多列语法怎么写才不会报错
SQL 中 GROUP BY 后跟多个字段时，必须确保 SELECT 列表中所有非聚合字段都出现在 GROUP BY 子句里，否则多数数据库（如 MySQL 8.0+ 严格模式、PostgreSQL、SQL Server）会直接报错：column must appear in the GROUP BY clause or be used in an aggregate function。
正确写法是把要分组的字段全部列出来，顺序无关，但建议和 SELECT 中出现顺序保持一致，便于阅读：
SELECT dept, region, COUNT(*) AS cnt, AVG(salary) FROM employees GROUP BY dept, region;
- 不能只写
GROUP BY dept却在SELECT里选region（除非加MAX(region)这类聚合） - MySQL 5.7 默认允许“隐式分组”，但这属于危险行为——结果不可预测，升级或换库就崩
- Oracle 和 PostgreSQL 对此更严格，连“函数依赖”都不自动推断，必须显式列出
为什么用多列 GROUP BY 后 COUNT(*) 和 COUNT(col) 结果不同
这是新手最常困惑的点：同一组里 COUNT(*) 统计行数，COUNT(some_col) 只统计该列非 NULL 的值。当分组字段本身含 NULL，或者被聚合的列有缺失时，差异立刻暴露。
例如：
SELECT country, city, COUNT(*), COUNT(phone) FROM customers GROUP BY country, city;
- 如果某组有 5 行，但其中 2 行
phone IS NULL，那COUNT(*)是 5，COUNT(phone)是 3 -
country或city为NULL时，它们会被当作独立的一组（不是被忽略），这点和WHERE中的IS NULL判断逻辑一致 - 想排除空城市的数据？得先
WHERE city IS NOT NULL，不能靠COUNT(city)魔改
ORDER BY 能不能用别名配合多列 GROUP BY
可以，但要注意执行顺序：GROUP BY → HAVING → SELECT → ORDER BY。所以 ORDER BY 能引用 SELECT 中定义的别名，但不能引用未出现在 GROUP BY 或聚合中的原始列。
下面这段是合法的：
SELECT dept, region, AVG(salary) AS avg_sal FROM employees GROUP BY dept, region ORDER BY avg_sal DESC;
- 但
ORDER BY salary会报错，因为salary没参与分组也没聚合 - PostgreSQL 允许
ORDER BY 1, 2（按 SELECT 列序号），MySQL 也支持，但可读性差，不推荐 - 如果排序字段是表达式（如
ROUND(AVG(salary), 0)），别名方式比重复写表达式更安全
GROUP BY 多列性能差，哪些操作会雪上加霜
多列分组本身就会增加哈希/排序开销，尤其当字段基数高（如 user_id, timestamp）或数据量大时。以下操作会让问题更严重：
- 在
GROUP BY字段上没建复合索引，比如GROUP BY status, created_date却只有单列索引status - 用函数包裹分组字段，如
GROUP BY YEAR(created_date), dept—— 索引基本失效，MySQL 和 PostgreSQL 都难优化 - 在
HAVING里写复杂条件（如子查询、UDF），导致无法提前过滤分组结果 - SELECT 中用了
DISTINCT+GROUP BY，属于冗余操作，DBMS 可能放弃优化路径
真正卡住的时候，先看执行计划里的 Using temporary; Using filesort，再检查分组字段是否覆盖了常用查询维度，而不是急着加内存参数。
