GROUP BY本质是分组压缩行，非聚合列必须出现在GROUP BY中或用聚合函数包裹，否则因值不确定而报错；多列分组需全部列出，窗口函数适用于保留原行并计算汇总。
因为数据库无法确定该列在分组后该返回哪个值——它不是“算出来的”，又没被明确指定“按什么分”，结果必然歧义。
GROUP BY 的本质是压缩行，不是筛选行
执行 GROUP BY dept 时，数据库先把所有行按 dept 值拆成若干组，再把每组压成一行。这时，SELECT 中每个非聚合列（比如 name）在组内可能有多个不同值。数据库不会猜、也不会随机挑——它直接拒绝执行，避免返回不可靠结果。
- 错误示例：
SELECT dept, name, AVG(salary) FROM employees GROUP BY dept→name在“技术部”组里可能是张三、李四、王五，选谁？ - 正确做法：要么加进
GROUP BY dept, name（此时每组只含同部门同名员工），要么用聚合函数包裹，如MAX(name)（但注意：字典序最大 ≠ 薪资最高） - MySQL 5.7+ 默认开启
ONLY_FULL_GROUP_BY，这类语句会直接报错：Expression #2 of SELECT list is not in GROUP BY clause
想保留原始行又加聚合值？别硬套 GROUP BY，改用窗口函数
GROUP BY 是“压缩后汇总”，OVER() 是“带着原样算汇总”。两者解决的问题完全不同。
- 错误思路：用
ANY_VALUE(name)敷衍过去 → 不保证返回哪一行，查询结果可能每次都不一样 - 正确场景：查每个员工的工资，同时附带“所在部门平均工资” → 必须用
AVG(salary) OVER (PARTITION BY dept) - 关键约束：
OVER()子句不能省；PARTITION BY相当于逻辑分组，但不删行；所有原始字段（name、salary、hire_date）可直接出现在SELECT中
GROUP BY 列可以不出现在 SELECT 中，但通常没意义
语法允许 GROUP BY dept, hire_year 却只 SELECT COUNT(*)，但这样你只知道“有几组”，不知道每组对应什么部门或哪年入职——结果无法解读。
- PostgreSQL 比 MySQL 更严格：连“函数依赖”（如
emp_id → dept）都不认，dept必须显式写进GROUP BY才能出现在SELECT中 - 多列
GROUP BY时，SELECT中所有非聚合列必须全部列出，顺序无关，但缺一不可 - 常见漏写：联表查询中，
JOIN条件列（如Articles.articleid）常被忽略，导致articleid出现在SELECT却不在GROUP BY中
最易被忽略的一点：这个限制不是 MySQL 特有，而是 SQL 标准行为。哪怕你关掉 ONLY_FULL_GROUP_BY，返回的 name 仍是不确定的——它可能来自任意一条匹配行，且优化器重写或并发执行时可能变化。真要业务可靠，就别绕开规则。
