报错是因为SQL标准要求SELECT中非聚合列必须出现在GROUP BY子句中，否则数据库无法确定分组后取哪行值；根本原因是GROUP BY执行早于SELECT，原始行已不可见，只能返回分组键或聚合结果。
GROUP BY 报错 “列不在 GROUP BY 子句中” 怎么回事
因为 SQL 标准强制要求：在 SELECT 列表中出现的非聚合字段，必须完整出现在 GROUP BY 子句里。这不是数据库“故意为难”，而是逻辑必然——分组后，一行代表一组，数据库无法确定该取哪一条明细的值。
常见错误现象：
-
SELECT name, department, AVG(salary) FROM emp GROUP BY department→ 报错，name未分组也未聚合 -
SELECT id, MAX(created_at), status FROM orders GROUP BY status→ 报错，id和status不匹配，id可能有多个
根本原因：GROUP BY 的执行阶段早于 SELECT，它先压缩行、再投影字段；此时原始行已不可见，数据库只能返回分组键或聚合结果。
想保留明细又算分组值？用窗口函数替代
窗口函数不压缩行，所有原始字段都可用，PARTITION BY 只是定义计算范围，不影响行结构。
实操建议：
- 把原来的
GROUP BY department, AVG(salary)拆成：AVG(salary) OVER (PARTITION BY department)，直接追加一列部门平均薪资 - 要同时显示员工姓名、部门、本人薪资、部门平均薪资、与平均的差额：全部写进同一
SELECT，无需子查询或 JOIN - 注意
ORDER BY在窗口函数里的作用仅限于当前窗口内排序（如用于ROW_NUMBER()或累计求和），和最终结果排序无关
示例：
SELECT name, department, salary,
AVG(salary) OVER (PARTITION BY department) AS dept_avg,
salary - AVG(salary) OVER (PARTITION BY department) AS diff_from_dept
FROM emp;
为什么不能在 WHERE 中过滤窗口函数结果
窗口函数在 SQL 执行顺序中属于最晚环节（在 SELECT 之后、ORDER BY 之前），WHERE 发生在更早阶段，此时窗口结果还没算出来。
典型错误：
-
SELECT *, SUM(amount) OVER (PARTITION BY user_id) AS total FROM orders WHERE total > 1000→ 报错：total未定义 - 想筛出“订单金额高于用户平均值”的记录，不能直接
WHERE amount > AVG(amount) OVER (...)
正确做法：套一层子查询或 CTE，先算出窗口列，再在外层过滤：
SELECT * FROM ( SELECT *, AVG(amount) OVER (PARTITION BY user_id) AS user_avg FROM orders ) t WHERE amount > user_avg;
性能和可读性怎么权衡：GROUP BY 还是窗口函数
不是“谁更好”，而是“谁更合适”。关键看你要不要原始行。
使用场景判断：
- 只要统计报表（如“各城市订单数”）→ 用
GROUP BY city，轻量、语义清晰、索引友好 - 要分析明细（如“每笔订单 + 所属城市的订单总数 + 占比”）→ 必须用窗口函数，否则得嵌套子查询 + JOIN，可读性和维护性陡降
- 低基数
PARTITION BY（比如全表只分 2–3 组）可能触发全局排序，比 GROUP BY 更慢；此时应检查执行计划，必要时加索引或改用物化中间结果
最容易被忽略的一点：窗口函数输出的是表达式，不是真实列，所以不能被 GROUP BY、WHERE、HAVING 直接引用——这个限制决定了它永远无法完全取代 GROUP BY，但能极大减少你写子查询的冲动。
