答案是正确：select中非聚合列必须出现在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 时，非聚合列必须全部列出，缺一不可
常见漏写：联表查询中，JOIN 条件列（如 Articles.articleid）常被忽略，导致 articleid 出现在 SELECT 却不在 GROUP BY 中。
- 多列分组（如
GROUP BY dept, role）时，dept和role都得同时出现，不能只写一个 - 顺序无关，但缺一不可
- PostgreSQL 比 MySQL 更严格：连“函数依赖”（如
emp_id → dept）都不认，dept必须显式写进GROUP BY才能出现在SELECT中 - 这个限制不是 MySQL 特有，而是 SQL 标准行为。哪怕你关掉
ONLY_FULL_GROUP_BY，返回的name仍是不确定的——它可能来自任意一条匹配行，且优化器重写或并发执行时可能变化
最容易被忽略的一点：真要业务可靠，就别绕开规则。用 ANY_VALUE() 或临时关模式，只是把问题藏得更深而已。
